Here is what an agent pays before it asks a job-search tool anything. I pinned 20 job-search Actors from the Apify Store, one at a time, on the hos...
For further actions, you may consider blocking this person and/or reporting abuse
The tool list an MCP server sends is part of every model request, so its cost repeats on each turn, not once. Does your harness resend that list on every turn?
As far as I can tell, yes. The definitions sit in the model context, so they go out with every request, normally as cache reads and not as full-price input. Claude Code defers them until the tool is looked up, which moves the cost to first use but does not remove it. I did not measure the billed split per turn.
Good data. The 32.7K one is a strong case for deferred tool loading: send names and one-liners up front, and only the full schema once the model picks the tool.
Claude Code already does that for MCP tools: names up front, schema on lookup. The catch is what it loads at lookup. For the 32.7K one that is the output schema the server inferred from sample rows, so deferral helps until the first call and then you pay in full.
Fair point. So for that one the real fix is on the server side: publish a trimmed output schema instead of inferring it from sample rows.
Agreed, and the schema follows the shape of the rows. The 32.7K one came from a deeply nested row, about 3,400 schema nodes, so flat rows are the fix on the Actor side. A published trim would still beat inference.
Useful numbers. The 32,000-token output schema versus a 406-token input schema is surprising. Do you know if authors can override the inferred output schema to shrink it?
Thanks. Authors can declare a dataset schema (fields with types and descriptions) in the Actor definition, and the docs say agents rely on it. I have not tested whether the hosted server then uses it instead of sampling rows, so I will not promise it shrinks the tool. What kept ours small was flat rows with few fields; the 32K one had about 3,400 nested nodes.
The output-schema finding is the part I would act on first: a 32,136-token inferred schema dwarfs the 406-token input schema, so trimming the dataset schema matters more than shaving a few input fields. In practice, I would also keep Claude Code's deferred loading in mind, since the tax is paid when a definition is actually loaded rather than on turn one. How do you decide when a trimmed output schema loses too much information for downstream filtering, versus when it is simply removing fields no consumer uses?
I have not tested a trimmed schema against filtering quality, so I cannot give you a threshold. My rule would be to keep what the agent asks for in the fields list of get-dataset-items and cut the rest. In the recorded sessions it built that list on its own, without being told.
The discovery vs. pinning comparison is the most valuable part. One question: in the discovery session, you mentioned the agent never saw your Actor because it wasn't in the top results. How much of that is a 'new Actor' problem versus a 'search ranking' problem? Would better metadata or a different Store listing help?
Both, and I can only measure one of them. Store search through the MCP server ranks by users, and five job queries returned none of our Actors, so a new listing stays invisible however good its metadata is. Whether a better description helps once it is ranked I have not tested. What works today is pinning the Actor with the tools parameter in the config.
This is a really important point that gets lost in the 'just write better descriptions' advice. Visibility is a two-step problem: getting ranked, then converting the rank into a call. If the Store search doesn't surface you at all, metadata quality is irrelevant. Pinning is the workaround, but it puts the burden on the user.