Hallucination Prevention

The Problem

When an MCP server registers hundreds of tools at startup, every tool's full JSON schema is loaded into the model's context before a tool is selected. Schema volume can crowd out task context; the actual token cost depends on the server, caller, provider and caching. Steroid instead returns selected marketplace candidate descriptors after discovery. Models can still confuse fields or summarize results incorrectly.

Even on models with large context windows, over-registration causes distinct failure modes:

• Argument hallucination — the model invents field names that look plausible based on the tool description but do not match the actual schema
• Tool substitution — the model calls a similar-sounding tool from a different server with an incompatible argument shape
• Schema confusion — when two tools share argument names with different semantics (e.g. id meaning user ID in one tool and resource ID in another), the model mixes them up

How Steroid Prevents It

Steroid's prevention strategy has two mechanisms that work in tandem: a search-before-execute pattern that limits up-front marketplace schema loading, and an opaque capability whose server-side state authorizes the workflow/step and candidate set.

Mechanism 1 — Search before execute

The complete server exposes three Local or nine Connected operation schemas. For marketplace discovery, search_tools normally returns three candidates under tool_candidates, including tool_details.arguments. The agent should read those descriptors before execution rather than infer input names.

Mechanism 2 — Opaque capability handles

The capability_token returned by search_tools is a random ten-character handle into an in-process map, not a signed payload to decode. The guarded run checks workflow, step, expiry and allowed server/tool candidates. This means:

• An unknown handle or an unauthorized server/tool is rejected on this guarded path.
• Default expiry is five minutes; process restart also invalidates in-memory capabilities.
• A capability authorizes the returned candidate set, not arbitrary tools or correctness of the user's intent.

Token Efficiency

On-demand marketplace discovery can reduce schema context relative to registering every tool. It does not establish a constant token budget or a measured reduction for every caller. Include operation schemas, candidate metadata, arguments, outputs, retries and provider caching when benchmarking.

Caller/provider/model and pricing date
Registered operation schemas and cache behavior
Discovery query and returned candidate descriptors
Execution inputs, tool results and retries
Correctness criteria and observed failures

Local: 3 recall operations
Connected: 9 operations in total
Marketplace: search_tools + run_tool within that surface