LOGGING.md: `get_schema` DOES reach the MCP server (delegates to get_stac_details)

[cboettig]

Problem

LOGGING.md:375 states:

Note: list_datasets and get_schema are local geo-agent tools — their results appear in tool_results_this_turn on the proxy but never reach the MCP server.

This is correct for list_datasets, but wrong for get_schema. get_schema is a client-side geo-agent tool, but its execute() calls the MCP server:

// geo-agent CDN core, app/map-tools.js:592
const collection = catalog.toStacDict(args.dataset_id);
const raw = await mcpClient.callTool('get_stac_details', { dataset_id, collection });

So a get_schema LLM tool-call does reach the MCP server, as a get_stac_details call (with the cached STAC forwarded inline).

Why it matters for log interpretation

The proxy logs the LLM tool-call name (get_schema); the delegated MCP get_stac_details request doesn't pass through the proxy, so it's invisible in these logs. Anyone counting MCP-server tool load from proxy logs will undercount get_stac_details. In the June 2026 corpus, get_stac_details shows 339 direct LLM calls but ~2,916 additional invocations arrive via get_schema — i.e. true MCP get_stac_details load is ~3,255 (the #2 MCP tool, not a minor one).

Suggested fix

Correct the note in LOGGING.md (and the example around lines 366–375): list_datasets is local-only; get_schema is a local delegate that forwards to the MCP get_stac_details tool, so its MCP call is not visible in proxy logs and must be attributed to get_stac_details when estimating server load.

Context

Found while auditing MCP STAC tool usage for the mcp-data-server source.coop fallback work (boettiger-lab/mcp-data-server#260, #263).