Apify just shipped the right pattern. Their new MCP Configurator lets a consumer pick 10–15 Actors out of the 25,000+ on the platform and expose just those to an agent through a custom MCP URL. Pre-configured. Bounded. Searchable when the agent needs to escape the box. That is context engineering at the vendor surface, done in public, and every other SaaS vendor shipping an MCP this year should be reading their post.
This is the same series we started with Notion’s MCP last week. Notion shipped a hosted MCP, a documented catalog, and an open-source self-host. Apify went one step further and shipped a configurator — the missing UI between “here is our entire surface” and “give my agent exactly the tools it needs.” Both moves are correct. Both stop being enough at the same point: the second vendor MCP in the same agent.
What Apify got right
Read their post and pull out the four design choices worth applauding.
- Fewer tools, higher accuracy. Apify is explicit that handing an agent 25,000 Actors is worse than handing it 10. The model picks the wrong one, the tokens balloon, and the run quietly degrades. The fix is to curate. That is the same principle that drives every well-engineered MCP server we’ve reviewed at API Evangelist.
- Search + call as a safety net. The configurator nudges you to always include
search-actorsandcall-actor. The bounded list handles 95% of work; the search tool lets the agent escape the box for the long tail. That is the right balance between determinism and discovery. - Multiple Actors for the same job. Apify’s post recommends configuring two or three Instagram scrapers and letting the agent pick the cleanest output. That is a consumer-side A/B test pattern that almost nobody else has written down yet, and it matters as the Actor / Skill / capability ecosystem matures.
- One config, many clients. A single configured URL works in Claude Desktop, Cursor, VS Code, Antigravity — anywhere MCP is spoken. That is the right scope for the vendor: ship the surface and let the consumer plug it in wherever they work.
Where it ends
Apify did its part. The consumer-side problem starts at the next vendor. Four things you cannot do from a curated Apify MCP that you can do from a Naftiko capability over the same surface:
- The same context engineering applied uniformly across every other vendor. Apify’s configurator is for Apify Actors. Notion’s hosted MCP is for Notion tools. Stripe will ship its own. Snowflake will ship its own. Each one is its own DSL, its own auth, its own observability story. A capability layer is where you do the same curation work once per vendor, in the same shape, versioned in Git.
- Declarative YAML over the configured surface. The MCP Configurator UI is a screen. Click, save, copy URL. That is fine for one workflow. It is not enough for fleet operations where the configuration is the spec — reviewed in a pull request, diffed across environments, rolled back when an agent goes off-script. A capability YAML is that spec.
- Observability and governance over your instance of the Apify MCP. Which agent called which Actor. Under which identity. Against which policy. For how many compute units. Apify Console answers the operational half. The fleet-level half — “is this agent staying inside the contract we wrote for it across all 12 vendor MCPs?” — has to live somewhere that can see every vendor’s MCP at once.
- Expand beyond Apify to any other provider. Today it’s Apify. Next week it’s the Notion MCP, the Stripe MCP, your internal payments API, your custom warehouse, your partner integrations. Every vendor MCP is its own snowflake. Naftiko capabilities give you one shape across all of them, with the same configurator-style discipline Apify already taught us is correct.
What that looks like
A Naftiko capability that consumes the Apify MCP is a single YAML file. It declares which Actors you want exposed, what AI-friendly context you want injected at each tool boundary, what governance tags the operation carries, and what telemetry it emits. It then exposes the result as MCP, REST, A2A, or an Agent Skill — same spec, multiple agent surfaces. Drop in a second capability that consumes Notion’s MCP, a third that wraps Stripe, and you have a uniform fleet of agent-callable operations governed at the spec layer.
The Apify MCP Configurator is the doorway. The capability layer is the building. The thing both of them are doing — and the thing every other vendor MCP needs to do this quarter — is engineer the context window for the agent that will be calling it.
When to use which
- Use the Apify MCP Configurator when you have one agent, you trust Apify-curated Actors, and you do not need to coordinate that configuration with the other 11 vendor MCPs your fleet will be calling next quarter.
- Use Naftiko when you have more than one MCP server in flight, when the configured surface is a versioned spec your governance team needs to review, when the same context-engineering discipline needs to apply uniformly across every vendor MCP your fleet consumes, or when an Apify-style configurator is what you wish every vendor had shipped.
Both paths are real. The first is the right starting point for any team taking the agent + Actor pattern seriously. The second is what you reach for at exactly the point Apify’s post hints at — when the same configuration discipline needs to scale beyond one vendor.
A note to API providers
If you are shipping an MCP server in 2026 and you have not read Apify’s configurator post, read it. Then ask whether your consumers can do the same thing with your surface. If the answer is “no, we expose all of it and hope the agent picks correctly,” you are about to ship a context-window problem to your own customers. Either build the configurator yourself, or make the capability layer they will use to do it for you part of your developer story.
The bottom line
Apify did the work of teaching the rest of the vendor ecosystem how an MCP configurator should look. Notion did the work of teaching it how a hosted MCP should look. The pattern across both is identical — engineer the context window before the agent ever sees the tool list — and the only thing missing is one place to apply that pattern uniformly across every vendor MCP your fleet consumes.
That place is a capability layer. That is what Naftiko does.
