Apify shows what the MCP server does to a schema before an agent sees it

Apify shows what the MCP server does to a schema before an agent sees it

The most useful MCP post of the month is an audit by a seller, not a vendor. In What the Apify MCP Server Does to Your Actor Before an AI Agent Ever Sees It, published on Apify’s blog, Olivier Reynaud takes his own 121 public Actors on the Apify platform and works out how an agent experiences each one through Apify’s MCP server. The first finding is the one he “did not see coming”: 46 of the 121 were not reachable by an agent at all, because Actors on rental pricing were excluded from the server’s search. The second is subtler and will bite anyone publishing a JSON Schema: “a single JSON key in my input schema was telling agents that a mandatory field was optional.” A required field that also carries a default becomes optional in the tool definition the agent reads.

The figures are the author’s own, from his own listings, which makes them unusually honest. In twelve agent-driven tasks, two chose his Actors, four never saw them, and six saw them and picked something else. A competitor with far fewer users won a task because its inferred output schema proved it returned phone numbers while his description only promised them: “When those two disagree, the agent believes the runs. My Actor lost that task on a gap between my copy and my data, and it was right to.” The transformations the MCP server applies are documented one by one, store description becoming tool description verbatim, required fields gaining a **REQUIRED** prefix, enums capped at 20 values in prose, and a waitSecs field “that you never wrote” injected into every tool. The rule that falls out: “A required field with a default is always a bug.” And the structural one: “An autonomous agent cannot produce a LinkedIn session cookie. Every Actor that demands one is invisible to that entire class of caller, no matter how good it is.”

The catalog reads Apify the way the agent reads an Actor, from the schema out. The Apify provider page lists 6 API pages, and the audit runs over three of them: the Apify Actors API, where the input schema lives, the Apify Actor Runs API, which is what call-actor and get-actor-run wrap, and the Apify Datasets API behind get-dataset-items. The MCP server, agent skills, and the whole identity layer are lit on the Agent Readiness score, delegated identity, protected resource metadata, and dynamic client registration, which is what a remote server at a fixed address with OAuth should show. The agentic access profile maps 13 operations, 3 of them acting.

The Kin Score is 37.0, thin band, and the split inside it is the story. Discoverability is 80.0 and developer ergonomics 62.4, while contract quality is 26.6, access clarity 32.9, and operational transparency 10.5. The Agent Readiness score is 52.9, agent-ready, higher than the composite by a wide margin: the agent door is better built than the contract behind it. Error semantics and idempotency are unlit, and so is reversibility, on a platform where a call-actor costs money every time it runs. Reynaud’s lesson is that an agent believes the schema and the runs over the prose. The catalog believes the same two things, and on Apify’s own record they tell a thinner story than the store does.

← Amazon SES ships skills for the AWS MCP server, and its record already lights them
AWS names uncontrolled delegation as the root flaw, and Bedrock's record has no delegated identity →