MCP parity: 71 console capabilities have no MCP path — the first run's inventory, by group

71 console capabilities have no MCP path — the first run of the parity check (#610)

scripts/check-mcp-parity.mjs (shipped with #610) compares what the console calls to what the
MCP worker calls. Both are clients of the same API, so a capability the console has is
structurally available over MCP; where it is missing it is either a deliberate exclusion or an
accident, and until now nothing could tell the two apart.

First run, measured 2026-08-15:

console capabilities : 161   (distinct METHOD + path, 5 call sites unreadable)
MCP routes           : 130   (3 call sites unreadable)
reachable over MCP   : 80/161 (49.7%)
deliberately excluded: 10 across 5 route rules + 6 statement rows
known gaps (ratchet) : 71 across 14 groups
UNLISTED gaps        : 0

The 10 exclusions are decisions and are published in platform-docs/mcp.md, which is now
GENERATED from the list the check enforces. The 71 below are not decisions — nobody has ever
weighed them. They are recorded in KNOWN_GAPS so a NEW gap fails CI, and each group is listed
here so closing one is a ticketed act rather than a diff nobody asked for.

Each group is independently workable: give a dev agent this issue number and the group heading.
An entry that becomes reachable must be deleted from KNOWN_GAPS in the same commit — the check
fails on a dead entry, which is how this list is kept from rotting into an allowlist.

Regenerate this list at any time with node scripts/check-mcp-parity.mjs --gaps.

Priority, as measured rather than assumed

The groups an owner is most likely to feel are the ones where the console can SEE something the
assistant cannot: the per-run controls (a stuck agent's takeover and resume), machines/terminals,
notifications, and outbound MCP connections. The agent-template group is the largest by route
count and the least urgent — it is creator tooling, and create_agent/update_agent already
cover the write path.

15 route(s)

Agent TEMPLATE authoring (the creator side of AgentDetail). create_agent/update_agent exist, but reading an agent as its OWNER does not — agent_info serves /v1/public/agents/{}, the published projection, which omits drafts and config. Nor is there delete, export, version history, rollback, the template's own memory/state/chat, or the AI agent-builder. #613.

DELETE /v1/agents/{}
DELETE /v1/agents/{}/knowledge/{}
GET /v1/agents/{}
GET /v1/agents/{}/capabilities
GET /v1/agents/{}/export
GET /v1/agents/{}/memory
GET /v1/agents/{}/messages
GET /v1/agents/{}/state
POST /v1/agent-builder/execute
POST /v1/agent-builder/plan
POST /v1/agents/{}/chat
POST /v1/agents/{}/versions
POST /v1/agents/{}/versions/{}/rollback
PUT /v1/agents/{}/capabilities
PUT /v1/agents/{}/state

5 route(s)

Notifications and account preferences. The console reads a notification feed, marks items read, and edits per-account preferences (timezone, notification channels); MCP has neither. A caller cannot tell an owner what their agents have been trying to tell them. #613.

GET /v1/notifications
GET /v1/preferences
POST /v1/notifications/read-all
POST /v1/notifications/{}/read
PUT /v1/preferences

3 route(s)

Voice settings — STT mode, TTS provider/voice/speed, language, commandsEnabled. get_instance_settings reads typed agent settings, which is a different table; the voice block has no tool at all. #613.

DELETE /v1/instances/{}/voice-settings
GET /v1/instances/{}/voice-settings
PUT /v1/instances/{}/voice-settings

5 route(s)

Outbound MCP connections — the console lists presets, tests a server, reads and writes per-server consent, and answers an elicitation (mcp/input-requests). None of it is reachable over MCP, which is the loop this platform is most likely to want closed. #613.

GET /v1/instances/{}/mcp/consent
GET /v1/instances/{}/mcp/input-requests
GET /v1/mcp/presets
POST /v1/instances/{}/mcp/test
PUT /v1/instances/{}/mcp/consent

6 route(s)

Machines and terminals — the Terminals page lists every connected CLI across agents, forgets a node, and pins an instance to one machine (runner-node); the Tmux tab reads and writes a terminal session. instance_runtime_status answers for ONE instance and cannot do any of it. #613.

DELETE /v1/terminals/nodes/{}
GET /v1/instances/{}/runner-node
GET /v1/instances/{}/terminal-session
GET /v1/terminals/nodes
PUT /v1/instances/{}/runner-node
PUT /v1/instances/{}/terminal-session

8 route(s)

A run's detail view: read one task, delete it, resume it, and drive a live human takeover (end/input/resume) or answer a needs_input handoff. instance_board lists cards and coding_timeline narrates a coding session, but the per-run controls a stuck agent actually needs are console-only. #613.

DELETE /v1/instances/{}/tasks/{}
GET /v1/instances/{}/tasks/{}
POST /v1/instances/{}/browse
POST /v1/instances/{}/input
POST /v1/instances/{}/takeover/{}/end
POST /v1/instances/{}/takeover/{}/input
POST /v1/instances/{}/takeover/{}/resume
POST /v1/instances/{}/tasks/{}/resume

3 route(s)

Standing agent tasks (agent-tasks) — the recurring instructions an agent carries, created, edited and deleted in the console's Tasks section. Distinct from runtime tasks, which run_instance_task covers. #613.

DELETE /v1/instances/{}/agent-tasks/{}
POST /v1/instances/{}/agent-tasks
PUT /v1/instances/{}/agent-tasks/{}

4 route(s)

Teamwork plumbing: delete a connection, read the delivery outbox, replay a dead delivery, and read a supervisor's direction. list_instance_connections and the supervision tools cover the happy path; the failure path — which is what an outbox is for — does not. #613.

DELETE /v1/instances/{}/connections/{}
GET /v1/instances/{}/connections/deliveries
GET /v1/instances/{}/supervision/{}/direction
POST /v1/instances/{}/connections/deliveries/{}/replay

3 route(s)

Knowledge writes the console has and MCP does not: edit an existing document in place, ingest a URL, and edit one record of a collection. add_knowledge only appends, so a correction over MCP means delete-then-add under a new id. #613.

POST /v1/instances/{}/knowledge/ingest-url
PUT /v1/instances/{}/collections/{}/records/{}
PUT /v1/instances/{}/knowledge/{}

2 route(s)

Product feedback — file, list and dismiss. list_feedback does not exist; an agent that hits a platform defect can only tell the user to open the console. #613.

DELETE /v1/feedback/{}
POST /v1/feedback

2 route(s)

Loop presets — the saved objectives the console offers when starting a loop. start_instance_loop takes a free-text objective, so the presets an owner curated are invisible to it. #613.

GET /v1/instances/{}/loop-presets
PUT /v1/instances/{}/loop-presets

5 route(s)

Trigger and connector metadata the console uses to BUILD a trigger: the action catalogue (/triggers/actions), a dry-run preview (/triggers/preview), the account connector list, the per-instance connector list and its write-consent toggle. create_instance_trigger can write one blind; nothing lets a caller check it first. #613.

GET /v1/connectors
GET /v1/instances/{}/connectors
GET /v1/triggers/actions
POST /v1/triggers/preview
PUT /v1/instances/{}/connectors/{}/consent

3 route(s)

File-connector reads and imports: list a granted Drive folder's files, and import from Drive or WorkDrive into an instance. The grants themselves ARE reachable (list_instance_connector_grants), which is what makes the missing import conspicuous. #613.

GET /v1/drive/instances/{}/files
POST /v1/drive/instances/{}/import
POST /v1/workdrive/instances/{}/import

7 route(s)

Assorted single routes with no group: the creator dashboard tallies, the stats source catalogue, the behaviour SCHEMA (get_instance_behaviour reads the values but not the field table the console renders), deleting one chat turn, posting a system message into a conversation, and the translation endpoint the gloss layer calls. #613.

DELETE /v1/instances/{}/messages/{}
GET /v1/dashboard/creator
GET /v1/dashboard/usage
GET /v1/instances/behaviour-schema
GET /v1/stats/sources
POST /v1/instances/{}/system-message
POST /v1/instances/{}/translate

What is NOT in the number

Five console call sites and three MCP ones pass a path this check cannot resolve statically (a
member expression off a data table, e.g. entry.flow.start in AccountConnections.tsx, and the
api()/apiCall() wrappers' own definitions). They are printed on every run rather than hidden,
because a coverage figure over a tree with silently skipped calls is not a coverage figure.

Verified vs inferred

Verified: every route above is a real call in store/console/src/** with no matching call
in workers/mcp/src/**, extracted by the same parser both sides go through. The three parsing
shapes that produced 22 false gaps in the prototype (a nested template, a variable path, a
table-driven prefix) are each covered by a unit test in scripts/lib/api-calls.test.mjs.
Inferred: that every one of the 71 SHOULD be exposed. Some may be excluded on inspection —
POST /v1/instances/{}/browse drives a browser pane, and POST /v1/instances/{}/translate
serves a UI gloss layer. Moving an entry from KNOWN_GAPS to EXCLUSIONS with a reason is a
valid way to close it, and the doc will then publish it.

Files: scripts/check-mcp-parity.mjs, scripts/lib/api-calls.mjs, platform-docs/mcp.md

feat(guards): every console capability is reachable over MCP, deliber…

feat(mcp): the timeline answers with the newest page, and an instance…

Reopened — the auto-close was my mistake. Notifications + account preferences group delivered in `37b67628`; 13 groups (66 gaps) remain.

Why it closed: the commit title says "five tools close #613's notifications group". GitHub read "close #613" in that phrase as a closing keyword, although the body says refs #613 and "Not closing #613". This issue tracks 14 independently workable groups and one is done, so it is open again.

The group, delivered

Five always-on MCP tools in workers/mcp/src/instance-tools/account.ts, and the group's KNOWN_GAPS entry deleted. check-mcp-parity.mjs now reports 90 of 167 reachable, 66 recorded gaps (was 85 / 71).

Tool	Route	Scope
`list_notifications`	`GET /v1/notifications` (`unread_only`, `limit`)	read
`mark_notification_read`	`POST /v1/notifications/:id/read`	write, dry_run
`mark_all_notifications_read`	`POST /v1/notifications/read-all`	write, dry_run
`get_account_preferences`	`GET /v1/preferences`	read
`set_account_preferences`	`PUT /v1/preferences`: only the sections supplied (`timezone`, `notifications`, `voice`, `translation`)	write, dry_run

Named account_preferences, not notification_preferences: the route holds all four sections, and this group's heading names timezone. A notification-only tool would have left timezone, voice and translation unreachable while the parity check counted the route as covered.

One API fix, found while wrapping it: POST /v1/notifications/:id/read answered {success:true} for any id, including a typo, a stale id, or another user's. It now returns 404 when nothing matched. Re-marking an already-read row is still 200, and both console callers already catch a failure.

Bookkeeping:

MCP 0.1.27 → 0.1.28 + surface-lock entry.
MCP_TOOL_COUNT 154 → 159 (always-on 130 → 135), risk counts, contract golden and write-readback updated.
Every doc that states the count updated (docs:drift clean).

Verified:

19 new tests: 6 on the route against real SQLite, and 13 on the tools through the real safety layer. The tool tests include matching the section list against the route's own body type.
Mutation-checked: dropping the 404 fails 2; manufacturing absent sections fails 4.
Full suite 11,443/11,443.

Not verified: calling the tools from a live MCP client after the deploy.

Remaining groups

Regenerate with node scripts/check-mcp-parity.mjs --gaps:

agent template authoring (15)
voice settings (3)
outbound MCP connections (5)
machines & terminals (6)
run detail / takeover (8)
standing agent tasks (3)
teamwork plumbing (4)
knowledge writes (3)
product feedback (2)
loop presets (2)
plus the rest of the recorded list

feat(mcp): knowledge-writes tools – update_instance_knowledge, ingest…

Knowledge-writes group delivered in `a8a8f72c`: 12 groups (63 gaps) remain

Three always-on MCP tools, and the group's KNOWN_GAPS entry deleted. check-mcp-parity.mjs now reports 93 of 167 reachable, 63 recorded gaps (was 90 / 66).

Tool	Route	Where
`update_instance_knowledge`	`PUT /v1/instances/:id/knowledge/:docId`	`instance-tools/knowledge.ts`
`ingest_instance_knowledge_url`	`POST /v1/instances/:id/knowledge/ingest-url`	`instance-tools/knowledge.ts`
`update_instance_record`	`PUT /v1/instances/:id/collections/:name/records/:recordId`	`storage-tools.ts`

All three are write with dry_run.

update_instance_knowledge: sends only the title / content supplied and keeps the document id. Its result reports vectorized:false if re-indexing did not happen.
ingest_instance_knowledge_url: the server does the fetch (https-only, SSRF-guarded, 50KB, counted against the 20-document cap), and its dry run fetches nothing.
update_instance_record: merges data into the record, never a replace; the collection's schema and unique constraints are enforced.

Bookkeeping: MCP 0.1.28 → 0.1.29 + surface-lock entry; tool counts 159 → 162 (always-on 135 → 138); contract golden, write-readback and docs updated.

Verified:

15 tests through the real safety layer.
Mutation-checked: a manufactured field fails 3; dropping the non-object data guard fails 2.
Full suite 11,458/11,458.

Not verified: calling the tools from a live client after deploy.

Remaining groups: node scripts/check-mcp-parity.mjs --gaps.

feat(mcp): loop presets reach MCP — get_instance_loop_presets, set_in…

Loop-presets group delivered in `2a90ceb5`: 61 gaps remain

Two always-on MCP tools in workers/mcp/src/instance-tools/composition.ts, beside start_instance_loop, and the group's KNOWN_GAPS entry deleted. check-mcp-parity.mjs now reports 95 of 167 reachable, 61 recorded gaps (was 93 / 63).

Tool	Route	Scope
`get_instance_loop_presets`	`GET /v1/instances/:id/loop-presets` → `{presets, source, driver}`	read
`set_instance_loop_presets`	`PUT /v1/instances/:id/loop-presets`: replaces the whole list; `[]` clears the instance's own so it inherits again	write, dry_run

One behaviour the route did not have: sanitizeLoopPresets (workers/api/src/lib/loop-presets.ts:84) silently drops an entry with a blank label or objective, truncates an over-long one, and cuts the list at 12, then answers 200. The tool refuses such a list whole, naming each problem, before sending anything, so a caller never reads success for a list that was not saved. The limits are copied (the MCP worker cannot import the API worker), and a test reads them back out of the API source.

Bookkeeping:

MCP 0.1.29 → 0.1.30 + surface-lock entry.
Tool count 162 → 164 (always-on 138 → 140); risk counts, contract golden and write-readback updated.
Docs updated (docs:drift clean).

Verified:

13 new tests through the real safety layer.
Mutation-checked: dropping the refusal fails 5; drifting a limit fails 2.
Full suite 11,471/11,471.

Not verified: calling the tools from a live MCP client after the deploy.

Stale text spotted, not changed: the product-feedback gap entry says list_feedback does not exist, but list_feedback and resolve_feedback are live tools. Only POST /v1/feedback and DELETE /v1/feedback/{} are missing.

Remaining groups: node scripts/check-mcp-parity.mjs --gaps.

feat(mcp): filing and deleting feedback reach MCP — record_instance_f…

Product-feedback group delivered in `05d02f00`: 59 gaps remain

Two always-on MCP tools in workers/mcp/src/instance-tools/observability.ts, beside list_feedback / resolve_feedback. The group's KNOWN_GAPS entry is deleted, and with it the entry's stale claim that list_feedback did not exist. check-mcp-parity.mjs now reports 97 of 167 reachable, 59 recorded gaps (was 95 / 61).

Tool	Route	Scope
`record_instance_feedback`	`POST /v1/feedback`: sends only the anchors supplied (`trace_id`, `message_id`, `session_id`, `target_text`, `sentiment`, `surface`)	write, dry_run
`delete_feedback`	`DELETE /v1/feedback/:id`: hard delete; the dry run points at `resolve_feedback` `dismissed` instead	destructive, dry_run + confirm

Who the row says wrote it. agent_feedback.author is user (the console) or agent (the instance's own record_feedback), and the row is kept as evidence of what the owner said. An MCP caller is usually a model acting for the owner, so the tool:

sends author: "user" only under a description that requires the owner's own words;
stamps context: {via: "mcp"} on every row it files, so MCP-filed feedback is always distinguishable.

A dedicated third author value would widen lib/feedback.ts's closed enum and the console label; I left it out of this slice.

Docs: docs:drift caught that four docs list every tool requiring confirm. delete_feedback was added to platform-docs/mcp.md, store/llms.txt, store/llms-full.txt and the operator skill (with both plugin copies).

Bookkeeping:

MCP 0.1.30 → 0.1.31 + surface-lock entry.
Tool count 164 → 166 (always-on 140 → 142); risk counts, contract golden and write-readback updated.

Verified:

13 new tests through the real safety layer, including one that checks every POST key against the keys routes/feedback.ts actually reads.
Mutation-checked: dropping the via:mcp stamp fails 2; dropping the delete's confirmation fails 3.
Full suite 11,490/11,490.

Not verified: calling the tools from a live MCP client after the deploy.

Remaining groups: node scripts/check-mcp-parity.mjs --gaps.

Parity update — 2026-09-13

21416a3a (pushed to main) closed the connector-accounts group that was recorded at #736.

Current count: 99 of 167 console capabilities reachable over MCP, 57 gaps remaining across 11 groups (previously reported as 97/59 in the last comment — the two extra capabilities were in the connector-accounts group now covered by get_instance_connector_account / set_instance_connector_account).

The remaining groups are tracked in KNOWN_GAPS in scripts/check-mcp-parity.mjs — list them with node scripts/check-mcp-parity.mjs --gaps. No owner decision is needed to continue.

feat(loop): how long a run may be belongs to the agent, not to whoeve…

feat(mcp): a granted folder can be looked inside, and a file taken ou…

File-connector group delivered in `ea9ee873`: 26 gaps remain

The grant tools (#15) handed out folder access and nothing could use it. An MCP caller could give an instance a Google Drive folder and then neither see what was in it nor pull anything out — list_instance_connector_grants returned the permission, and the half that does something was console-only. That is the "conspicuous" this group's own entry named.

Three always-on tools in workers/mcp/src/instance-tools/connectors.ts, and the group's KNOWN_GAPS entry deleted.

check-mcp-parity.mjs now reports 129 of 166 reachable, 26 recorded gaps across 4 groups (was 126 / 29).

Tool	Route	Scope
`list_instance_drive_files`	`GET /v1/drive/instances/:id/files` → `{files, grant, folder}`	read
`import_instance_drive_file`	`POST /v1/drive/instances/:id/import`	write, dry_run
`import_instance_workdrive_file`	`POST /v1/workdrive/instances/:id/import`	write, dry_run

Three tools, not one switching on `provider`

Every other tool in that file takes providerSchema and parameterises /v1/drive vs /v1/workdrive. These do not, deliberately: the two import routes are not symmetrical. Drive takes fileId and answers driveFile with a webViewLink (routes/drive.ts:249); WorkDrive takes resourceId and answers workdriveFile with a permalink (routes/workdrive.ts:233). A single tool would have to silently re-key the caller's file argument, and sending Drive's key to WorkDrive is a 400 nothing warns you about.

Browsing is asymmetrical too. Drive's file list is GET …/instances/:id/files; WorkDrive's is GET …/instances/:id/folder, a different route that is already reachable over MCP and so is not duplicated. That is why only Drive gets a list tool — and why both descriptions say so, rather than leaving a caller to conclude the WorkDrive one is missing. The reasoning is in the code and in the surface-lock entry, so it is not "fixed" back into the PROVIDERS pattern later.

`grant_id` is required on all three

Not a convenience: the routes refuse without it (400 grantId required), and the grant IS the permission. A file outside the granted subtree is refused 403 by driveFileDescendsFrom / workDriveFolderContainsFile — not by the id you happen to hold. Each description points at list_instance_connector_grants for it, the same cross-reference delete_instance_connector_grant already carries.

Either/or arguments (file_id OR url; resource_id OR url) are refused in the tool rather than at the route, which answers one 400 for both halves and therefore cannot tell a caller which name this tool takes.

One honest `null` in READBACK

title is the only argument that becomes stored content — it lands as the knowledge document's title — so it is the only one declared readable (list_instance_knowledge). url and resource_id are null: the imported document keeps sourceUrl, which is the provider's own canonical link read off the file, not an echo of the url the caller sent, and nothing at all when the caller sent an id. Declaring a reader there would claim a round-trip that does not hold.

Bookkeeping: MCP 0.1.40 → 0.1.41 + surface-lock entry; tool count 199 → 202 (always-on 175 → 178, gated stays 24); risk counts +1 read, +2 write; contract golden, write-readback, and every doc stating a count updated (docs:drift clean).

Verified: full suite 11,824/11,824; pnpm -r typecheck; docs:drift; size:check; mcp:parity; openapi:coverage. The three new tools lint clean.

Not verified: calling the tools from a live MCP client after the deploy, and no test drives a real Drive or WorkDrive import end to end — these are proxies and are tested as proxies. Same gap the earlier groups record.

Remaining: 26 gaps, 4 groups

agent template authoring (15) — the creator side of AgentDetail: owner-side read, delete, export, versions/rollback, template memory/state/chat, agent-builder. This issue's own priority note calls it the largest and least urgent.
assorted singles (7) — dashboard/creator, dashboard/usage, stats/sources, behaviour-schema, delete-one-message, system-message, translate. Not one slice; and translate plus the two dashboards are plausible EXCLUSIONS rather than tools, which is worth deciding before anyone writes seven of them.
machines & terminals remainder (3) — still annotated deliberate rather than pending. Closing it most likely means moving its entries to EXCLUSIONS with the reason already written there, not writing tools. That would take this to 23 across 3 without adding capability.
resync-identity (1) — tracked at [bug] A seed personality fix never reaches existing instances — #483's CLI protocol is in the agents row and in neither live tmux Operator #496, not here.

Leaving this issue open for ongoing tracking. Regenerate with node scripts/check-mcp-parity.mjs --gaps.

feat(console): what every instance is doing, in one call instead of o…

feat(console): a warning that has been firing for three days says so …

feat(coding): the Pilot keeps what it learned, and is told it is the …

feat(loop): see what a continue would carry forward, before spending …

feat(mcp): read your own agent template — the half of #613's largest …

Agent-template authoring, the READ half, delivered in `00fee86d`: 20 gaps remain

The group this issue's own priority note calls "the largest by route count and the least urgent". Its read half turned out to be neither — it was the one place MCP gave a wrong answer rather than no answer, so it went first.

check-mcp-parity.mjs now reports 138 of 169 reachable (81.7%), 20 recorded gaps across 4 groups (was 132 / 26).

The defect

agent_info looks like "read an agent" and calls /v1/public/agents/{id} — the catalogue projection. So before this:

a creator's own draft did not exist over MCP: agent_info 404s it exactly as it does for a stranger;
on a published agent, visibility, status, cron_schedule, owner_id, the declared capabilities and the template's own state and memory were all unreachable;
a caller could create_agent and update_agent and never read back what it had made.

New registrar workers/mcp/src/instance-tools/agent-authoring.ts, six always-on reads:

Tool	Route	Scope
`my_agent`	`GET /v1/agents/:id` with the owner's bearer	read
`get_agent_capabilities`	`GET /v1/agents/:id/capabilities`	read
`get_agent_state`	`GET /v1/agents/:id/state`	read
`get_agent_memory`	`GET /v1/agents/:id/memory`	read
`agent_messages`	`GET /v1/agents/:id/messages` (`limit`, `before`)	read
`export_agent`	`GET /v1/agents/:id/export`	read

Three things the descriptions had to carry

TEMPLATE, not instance. Five of the six have an instance-side twin with a nearly identical name — get_instance_state, get_instance_memory, instance_messages — over a completely separate store. Template memory is seed material copied at subscribe time, so editing it does not reach an instance that already exists. Each description opens by naming which side it reads and points at its twin: the same discipline agent-tasks.ts follows for the two task stores, for the same reason — reaching the wrong one answers confidently about somebody else's data.

my_agent degrades rather than refusing. /v1/agents/{id} has optional auth (it must still answer an anonymous caller with the published view), so on an agent you do not own it returns exactly what agent_info returns. A tool named my_agent quietly answering about a stranger's agent is a surprise worth removing, so the description says a row without owner_id is not yours.

export_agent is whole on purpose. It bundles state + every knowledge document + every memory entry, unpaged and untrimmed: a truncated backup is one that cannot be restored, which is a worse failure than a large response. The description says so and names the per-part reads (get_agent_state, get_agent_memory, list_knowledge) for a caller that only wants to look.

Classification

All six are reads, ungated beyond auth — every route refuses a non-owner server-side, via resolveAgent's 403 (whose own comment records why that check exists) or an explicit owner_id match. The one I checked rather than assumed was /export: it composes a blob and stores nothing, so "export" describes the shape of the answer, not an effect.

agent_info's description now points at my_agent. Descriptions sit outside the surface fingerprint, so that cost no version bump — recorded in the lock entry anyway, because a reader diffing 0.1.45 → 0.1.46 will see it and should not conclude the hash missed it.

Deliberately NOT in this slice

The group's other nine routes all mutate a template other people may be subscribed to: delete the agent or one of its documents, PUT capabilities or state, creator chat, cut a version, roll one back, and the two agent-builder calls. Each needs a confirm gate and a dry-run story; shipping them here would have put a destructive surface inside a slice justified as read-only.

So the KNOWN_GAPS entry stays, with its why rewritten to say that and its regex narrowed to the nine. That narrowing matters beyond bookkeeping: a GET that stops being reachable now fails as an UNLISTED gap instead of being silently re-absorbed by a broad pattern.

Verified

17 new tests in workers/mcp/src/agent-authoring.test.ts, through the real registrar and authedCall; only fetch and the audit KV are stubbed.
Mutation-checked — each turns tests red: pointing my_agent at /v1/public/agents (the exact wrong fix — it closes the gap on paper while answering the same wrong thing); dropping before from the paged read ([bug] "Load older messages" re-returns the newest page — the before cursor is a UUID, the route drops it, and the DO never implemented it #428's own recorded defect, on this very route); reaching /v1/instances/ instead of the template; dropping the agent id's URL-encoding.
Bookkeeping: MCP 0.1.45 → 0.1.46 + surface-lock entry; 205 → 211 registrations, always-on 181 → 187, gated stays 24; tool-metadata read 97 → 103; contract golden gained the agentAuthoring group and six rows; README table, CLAUDE.md module tree and every doc stating a count updated. No READBACK entries needed — that guard classifies writers, and these are all reads.
Full suite 12,033/12,033; pnpm -r typecheck plus the three test-config typechecks (Three tsconfigs exclude test files and CI typechecks none of them, so a type-level guard in any worker test is inert #599); biome; docs:drift; all 13 check-*.mjs including check-surface-lock --require-history.

Not verified: calling the tools from a live MCP client after the deploy — the same gap every earlier group here records.

Remaining: 20 gaps, 4 groups

agent template authoring, write half (9) — delete agent, delete knowledge doc, PUT capabilities, PUT state, creator chat, versions, rollback, agent-builder plan/execute. Needs confirm gates + dry runs; a coherent next slice.
assorted singles (7) — dashboard/creator, dashboard/usage, stats/sources, behaviour-schema, delete-one-message, system-message, translate. Still not one slice, and translate plus the two dashboards remain plausible EXCLUSIONS rather than tools — worth deciding before writing seven.
machines & terminals remainder (3) — still annotated deliberate rather than pending; closing it most likely means moving the entries to EXCLUSIONS with the reason already written, not writing tools. That would take this to 17 across 3 without adding capability.
resync-identity (1) — tracked at [bug] A seed personality fix never reaches existing instances — #483's CLI protocol is in the agents row and in neither live tmux Operator #496, not here.

Leaving this issue open for ongoing tracking. Regenerate with node scripts/check-mcp-parity.mjs --gaps.

Parked for now

Owner call: pausing work on this issue. Too much judgement-call surface (exclusion-vs-tool decisions) to hand off right now without more time to think it through properly.

Do not pick up automatically. No further slices should be started against #613 until the owner explicitly says go.

For whoever resumes this later

Remaining: 20 gaps across 4 groups, per the last comment above:

Agent template authoring, write half (9 routes) — delete agent, delete knowledge doc, PUT capabilities, PUT state, creator chat, versions, rollback, agent-builder plan/execute. Needs confirm gates + dry-run story. Flagged as the coherent next slice once this resumes.
Assorted singles (7) — dashboard/creator, dashboard/usage, stats/sources, behaviour-schema, delete-one-message, system-message, translate. A run was started on this slice today and then deliberately stopped before it produced anything — no partial work landed. Owner guidance captured live in conversation: translate should very likely be an EXCLUSIONS entry, not a tool — fairly confident call. The two dashboards (dashboard/creator, dashboard/usage) and stats/sources are murkier — owner did not decide these; leave the judgement call on those to whoever resumes, same as prior groups in this issue.
Machines & terminals remainder (3) — annotated deliberate rather than pending; likely becomes EXCLUSIONS entries with the reason already written, not new tools.
resync-identity (1) — tracked separately at [bug] A seed personality fix never reaches existing instances — #483's CLI protocol is in the agents row and in neither live tmux Operator #496, not here.

No code changes were made in this session — this comment exists purely so the research and the owner's partial decisions (translate = likely exclusion) aren't lost before the next pass.

feat(mcp): add agent authoring write parity (refs #613)

feat(mcp): add connector consent read parity (refs #613)

feat(mcp): add assorted console parity (refs #613)

feat(mcp): add identity resync parity (refs #613)

MCP parity: 71 console capabilities have no MCP path — the first run's inventory, by group #613

Description

71 console capabilities have no MCP path — the first run of the parity check (#610)

Priority, as measured rather than assumed

15 route(s)

5 route(s)

3 route(s)

5 route(s)

6 route(s)

8 route(s)

3 route(s)

4 route(s)

3 route(s)

2 route(s)

2 route(s)

5 route(s)

3 route(s)

7 route(s)

DELETE /v1/instances/{}/messages/{} GET /v1/dashboard/creator GET /v1/dashboard/usage GET /v1/instances/behaviour-schema GET /v1/stats/sources POST /v1/instances/{}/system-message POST /v1/instances/{}/translate

What is NOT in the number

Verified vs inferred

Activity

serge-ivo commented on Sep 13, 2026

Reopened — the auto-close was my mistake. Notifications + account preferences group delivered in 37b67628; 13 groups (66 gaps) remain.

The group, delivered

Remaining groups

serge-ivo commented on Sep 13, 2026

Knowledge-writes group delivered in a8a8f72c: 12 groups (63 gaps) remain

serge-ivo commented on Sep 13, 2026

Loop-presets group delivered in 2a90ceb5: 61 gaps remain

serge-ivo commented on Sep 13, 2026

Product-feedback group delivered in 05d02f00: 59 gaps remain

serge-ivo commented on Sep 13, 2026

Parity update — 2026-09-13

12 remaining items

serge-ivo commented on Sep 19, 2026

File-connector group delivered in ea9ee873: 26 gaps remain

Three tools, not one switching on provider

grant_id is required on all three

One honest null in READBACK

Remaining: 26 gaps, 4 groups

serge-ivo commented on Sep 20, 2026

Agent-template authoring, the READ half, delivered in 00fee86d: 20 gaps remain

The defect

Three things the descriptions had to carry

Classification

Deliberately NOT in this slice

Verified

Remaining: 20 gaps, 4 groups

proagentstore commented on Sep 20, 2026

Parked for now

For whoever resumes this later

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

DELETE /v1/instances/{}/messages/{}
GET /v1/dashboard/creator
GET /v1/dashboard/usage
GET /v1/instances/behaviour-schema
GET /v1/stats/sources
POST /v1/instances/{}/system-message
POST /v1/instances/{}/translate

Reopened — the auto-close was my mistake. Notifications + account preferences group delivered in `37b67628`; 13 groups (66 gaps) remain.

Knowledge-writes group delivered in `a8a8f72c`: 12 groups (63 gaps) remain

Loop-presets group delivered in `2a90ceb5`: 61 gaps remain

Product-feedback group delivered in `05d02f00`: 59 gaps remain

File-connector group delivered in `ea9ee873`: 26 gaps remain

Three tools, not one switching on `provider`

`grant_id` is required on all three

One honest `null` in READBACK

Agent-template authoring, the READ half, delivered in `00fee86d`: 20 gaps remain