Skip to content

A Cowork MCP Tool Called Before Its Schema Loads Can Return an Empty Result Instead of an Error

TL;DR — Cowork mode defers most MCP tool schemas until a session actually requests them via ToolSearch. Calling a deferred tool before its schema has loaded doesn't always fail loudly — depending on the harness version, it can silently return an empty/default stub ({}, [], total: 0, etc.) instead of erroring. If a mcp__<server>__* tool call comes back suspiciously empty on data you know exists, suspect the tool wasn't actually loaded yet before concluding the underlying server or data is broken.

The Problem

A mcp__majorvault__tasks_open_across_vault call in a Cowork session returned {"total_open": 0, "by_project": {}, "tasks": []} against a vault that plainly had over a hundred open task checkboxes across dozens of project files. Every plausible cause was ruled out one at a time: the local checkout wasn't stale, the server process's own environment variables were correct, and calling the exact same underlying Python function directly via a shell tool (bypassing the MCP layer entirely) returned the correct, real count. The vault, the checkout, and the code were all fine — only the live connected tool call in that specific session was wrong.

The session's own tool-registry listing showed the call routing through an unfamiliar proxy layer (visible only as an internal name like nexus-<server>:toolManager_getTools/useTools), sitting in front of the plain <server>:* tools. Nothing in the server's own documentation or prior incident history mentioned this layer.

Root Cause

That proxy layer is Cowork's own deferred-tool loading mechanism — visible from inside a session as the ToolSearch tool. Most MCP tool schemas aren't loaded into a session's context by default; they're deferred until the session explicitly calls ToolSearch (e.g. select:mcp__majorvault__tasks_open_across_vault) to fetch the real parameter schema. This keeps large tool catalogs from bloating every session's context up front.

The failure mode is that calling a deferred tool before loading its schema doesn't reliably produce a clear error. Some harness versions return a hard InputValidationError naming the problem outright. Others — apparently including whichever version was running for the original incident — degrade silently to an empty or default-shaped result instead, which is indistinguishable from "the underlying tool ran fine and legitimately found nothing."

This was confirmed by direct reproduction: calling the same tool cold returned the empty stub; calling ToolSearch first to load its schema, then calling the tool again in the same session, returned the correct, fully-populated result.

The Fix (There Isn't One — It's a Workflow Habit)

There is no server-side or vault-side fix here, because nothing on the server side was ever broken. The corrective action is entirely about how a session treats an unexpectedly-empty result from any mcp__<server>__* tool:

  1. Don't trust a suspiciously-empty result at face value, especially for a tool whose data you have independent reason to believe exists (a known task count, a known file list, etc.).
  2. Check whether the tool's schema was actually loaded this session before this call — if the tool name only ever appeared in a deferred-tools listing and was never the target of an explicit ToolSearch call before this invocation, that's the first thing to suspect.
  3. Reproduce directly if in doubt: call ToolSearch for the specific tool, then call it again. If the second call returns real data where the first didn't, the tool (and whatever it wraps) was never the problem.
  4. Only after ruling this out should you escalate to checking the underlying server, its data source, or its configuration.

This applies to any mcp__* tool in a Cowork session, not just vault-related ones — any deferred tool is subject to the same failure shape.