simulate_intent

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses a concrete failure mode (simulation_verifier_unconfigured) and an authorization boundary (tool discovery does not grant simulation authority), which materially shapes how an agent should interpret a call. The annotations already cover idempotency and openness; the description adds the verifier-configuration caveat, though it doesn't explain whether calls have any side effects on the intent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The front-loaded bracket block (capability, tier, API, authority) is information-dense and useful, but the prose that follows is terse to the point of under-specification rather than efficient concision. Nothing is wasted, but the description is short where it needs to be explanatory.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, a nested object parameter, and 0% schema coverage, the description should explain what a successful simulation returns and what the readiness probe actually checks. Instead it only describes the unconfigured-verifier state, leaving the normal success path undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 5 parameters, including a nested free-form "simulation" object and session/authority fields, so the description is expected to compensate. It says nothing about any parameter; only the API path incidentally reveals that intentId is the intent being simulated. This is a significant gap for a tool with a nested object parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description calls itself a "Readiness probe for the generic intent simulation gate," which anchors the resource but uses abstract "gate/probe" language rather than saying plainly that it simulates an intent before execution. It does not distinguish itself from close siblings such as simulate_mee_intent or simulate_transaction_risk, leaving the agent to infer which simulation tool applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The note that "public callers cannot record trusted simulation evidence; until a server verifier is configured this returns simulation_verifier_unconfigured" gives an implicit when-not-to-use signal and warns of a likely failure outcome. However, it never names an alternative tool or the condition under which this probe should be preferred over the sibling simulation tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.