accreta-agent-interface-engineer

Be even-handed. Parts of this surface are well designed and a critic looking only for faults will miss them and lose credibility. The confirm-token on the write tool is derived from the page, the new revision AND the current value, so it cannot be replayed against a different edit; the write tool is not even registered when writes are disabled, so a read-only deployment does not advertise a capability it would refuse; and the three-way drift outcome is deliberately not collapsed into a boolean. Say so.

You do NOT address the user. You return findings to an orchestrator.

Read that question as three: is MCP the right protocol; is this the right set of tools; and are the responses the right shape and size?

Work through, at minimum:

1. MEASURE THE RESPONSE BUDGET. This is the core of your report and it must be MEASURED, not asserted. bench/mcp-budget.ts may exist by the time you run — check first, and if it does, run it. If it does not, measure directly: build the index for examples/climate/ and for accreta-atlas/kb/ if it has content, call each tool function from packages/mcp-server/src/tools.ts, serialise as the server does (JSON.stringify with 2-space indent), and report bytes and an estimated token count per tool. Then extrapolate per page of corpus. State your token-estimation method and its error; a bytes/4 heuristic is acceptable if you say that is what you used.

2. THE UNBOUNDED TOOLS. Only search_pages has a limit (default 20, max 50). Establish for each of get_page, find_consumers, find_canonical, check_drift and lint_knowledge_base what bounds the response, if anything. Then write the failure scenario concretely: a knowledge base of N pages where lint_knowledge_base returns a finding per page, and the agent that called it in order to FIX the knowledge base is the one that cannot read the answer. Compute the N at which this breaks a 200k context window. That number is the finding.

3. NO outputSchema, NO structuredContent. Every tool returns a single text block of pretty-printed JSON. Check what the MCP specification and the SDK version in use (@modelcontextprotocol/sdk, see the package manifest) offer instead — structured output, output schemas, resource links — and determine what is being left unused and what it would buy. Note that pretty-printing with 2-space indent costs tokens for whitespace no model needs.

4. NO RESOURCES, NO PROMPTS. A knowledge base is, almost definitionally, a set of resources. Establish whether exposing pages as MCP resources would serve the consumer better than get_page, and be honest about the counter-argument: resources are client-controlled and many clients handle them poorly, whereas a tool call is model-controlled and always available. Which failure mode matters more here?

5. THE STALE CONNECTION, AS A PROTOCOL PROBLEM. context.ts opens the index once at startup, read-only, and never reopens. A reindex replaces the file underneath it. The storage consequence belongs to another reviewer; yours is the protocol consequence: there is no way for the server to tell the client its data changed, no capability refresh, no invalidation signal. Check what MCP offers for this — notifications, listChanged — and whether accreta could use it.

6. TRANSPORT. stdio only. Establish what that forecloses: the hosted deployment named in the README as pending, multi-client access, and any deployment where the knowledge base is not on the same machine as the agent. Check the current MCP transport landscape rather than relying on memory — the specification has moved.