Every MCP tool call from an external client fails once with "has not been loaded yet" and succeeds on an identical retry — the error lists back the exact parameter names it was sent as possibly incorrect

[proagentstore]

Promoted from feedback rows b7b6c751-8ecd-43dd-86d0-d653ec9e8cbd and a0666f22-b36f-40c4-b7f0-bc879f9cdd2b, where this was recorded twice as a minor note (2026-08-15 and 2026-08-17). Both still status: open, issue_url: null. Still reproducing on 2026-08-24.

What happens

A first call to a PAGS MCP tool from an external client fails with either:

'mcp_..._coding_loop_start' has not been loaded yet. You do not have the correct parameter names for this tool. Valid input schema: {...}. Retry with the exact parameter names from the schema. You tried parameters: [instance_id, max_iterations, objective] — these may be incorrect.

or:

tool 'ProAgentStore:coding_loop_status' is not registered. This may indicate a tool name hallucination or a stale tool schema.

An immediate, byte-identical retry succeeds.

The error is self-contradicting

In the first form, the message prints the valid schema, then lists the parameters that were sent — and they match the schema exactly. [instance_id, objective, max_iterations] against a schema whose properties are token, instance_id, objective, max_iterations, dry_run with required: [instance_id, objective]. The call was well-formed. It is then told its parameter names "may be incorrect."

The real condition is that the schema had not been loaded server-side yet. The message attributes a transport/registration state to caller error, which sends the caller off correcting a call that was already correct.

Observed 2026-08-24

On a single session against instance a185b1db-c560-456d-9522-f7792bd95cca, this occurred on first call to coding_loop_start, coding_loop_status (twice), and call_instance_tool. Every one succeeded on identical retry. The 2026-08-17 row records the same: "every PAGS MCP tool in this session failed on first call with a 'has not been loaded yet' schema error and succeeded on an identical immediate retry."

Why it is worth more than a papercut

It doubles the call count on every tool from an external client, and it actively misleads. An agent that trusts the message will rewrite a correct call, guess different parameter names, or conclude the tool does not exist — the second error form explicitly suggests "tool name hallucination" for a tool that is registered and works one second later. It also burns a round trip on every first-touch tool in a chain, which on a voice or latency-sensitive surface is user-visible.

Asks

1. Resolve the schema server-side before rejecting, or block the first call until registration completes, so a well-formed call is not refused for a server-side state.
2. If a first-call failure is unavoidable, make it honest. Say the schema is not yet loaded and the call should be retried unchanged. Do not report the caller's parameters as possibly incorrect when they match the schema, and do not suggest hallucination for a registered tool.
3. Related documentation gap noted in the same feedback row: call_instance_tool takes input, not args; github_update_issue takes labels as a comma-separated string and replaces rather than adds.

[serge-ivo]

Diagnosis: client/harness-side — nothing to push

Traced the complete stack. The PAGS MCP server does not emit either error string.

Evidence

"has not been loaded yet" and "possibly incorrect"

grep -r "has not been loaded yet" workers/ packages/ store/ agents/
(no output)

The strings are absent from the entire server repo, the MCP SDK (@modelcontextprotocol/sdk@1.29.0), the agents/mcp library, and the mcp-remote proxy. They also do not appear in the Claude Desktop app bundle (/Applications/Claude.app/Contents/Resources/app.asar). These strings are synthesized by the Claude LLM itself as explanatory text when it needs to communicate a tool invocation failure to the user. The server cannot be responsible for text it never emits.

"tool 'ProAgentStore:coding_loop_status' is not registered"

The ProAgentStore:name namespace format is Claude Code's own client-side tool registry format. This message is generated by Claude Code when a tool is absent from its locally-held tool list. It is not a string the MCP server produces.

Why the first call fails and the retry succeeds

The MCP client (Claude Code / Claude Desktop) caches tool schemas across sessions. On a new session it sends a tools/list request, but may optimistically dispatch a tool call using the cached prior-session schema before the new tools/list response arrives. If the server's response lands (correctly) or the session is truly new and has no matching tool yet, the client generates the "not loaded yet" message and retries. By the time of the retry, the new tools/list has been processed and the schema is live — so the identical call succeeds.

This is the classic MCP lazy-schema pattern documented in the spec. The server cannot pre-push schemas; it can only answer tools/list when asked.

Server-side registration is not racing

partyserver's #initialize() wraps onStart() (which calls await this.init()) in ctx.blockConcurrencyWhile(). This is a Cloudflare Durable Object primitive that holds every incoming request until the initialization completes. Tool registration (including await this.userGroups()) finishes before the first HTTP request is dispatched. There is no window where a tool call can arrive before registration is done.

The userGroups() silent-failure edge case

userGroups() can silently return an empty set on a cold-start API error. This would drop surface-gated tools (coding, apply, repo) from tools/list for that DO instance permanently. However:

1. This would only affect surface-gated tools, not the always-on set. The issue reports "every PAGS MCP tool" failing, including tools like list_agents that are never gated — so this is not the cause of the reported behavior.
2. A DO instance with empty groups would return those missing tools as absent from tools/list. A well-behaved client would see the difference and not attempt to call them. The misleading error message is generated only when the client does attempt a call using a stale cached schema.

Ask #3 (doc gap)

call_instance_tool already documents input correctly — both in the registered Zod schema (input: z.record(z.any())) and in README.md (tool + input). The github_update_issue labels semantics (REPLACE, not ADD; comma-separated) are documented in the tool's own description returned by list_instance_tools. No doc fix is needed.

Recommendation

This is external behavior that a server change cannot fix:

• Short term: document in AGENTS.md that MCP clients using cached schemas may see a first-call retry on a fresh session; this is expected and the identical retry will succeed.
• Medium term: if the userGroups() transient-failure scenario becomes a reported problem (surface-gated tools missing from tools/list), add a one-retry with a 200ms backoff inside userGroups(). But this is a separate, lower-priority issue.

Not closing — leaving to the owner to decide whether to close as external or keep open for the doc note.

[serge-ivo]

BA/dev triage — not actionable as a PAGS server bug

Based on the diagnosis above and a code pass, this should not remain open as a server registration defect. The observed strings appear to be synthesized by external MCP clients/harnesses using stale or lazy-loaded tool schemas, and the identical retry succeeds after the client has processed tools/list.

The server-side strings are not present in the repo, and the relevant server surfaces already expose/document the actual schemas. The remaining useful action is documentation, not a registration rewrite.

Recommended disposition: close as external/client-side. If we keep a follow-up, make it a small docs note: on a fresh external MCP session, a first call may fail due to client schema loading; retry the same call unchanged.

Do not pursue server-side registration fixes from this ticket. If userGroups() transient empty results become separately observed as gated tools missing from tools/list, file that as a distinct low-priority resilience issue with its own repro.