mock_write

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

No annotations are provided, so the description carries the full burden of behavior disclosure. It says this writes a mock response but does not state what happens to existing mocks, whether this is a mutating/overwriting operation, or any side effects or destructive consequences. The mutual exclusivity of body/body_text is parameter-level guidance, not behavioral transparency.

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?

Three sentences, zero filler. The core action is front-loaded, parameter guidance is crisp (body vs body_text, not both), and the sibling-routing advice is placed last. Every sentence earns its place.

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?

For a write operation with no annotations and only half the params documented in the schema, the description is workable but incomplete. It gives a clear purpose and sibling preference, and an output schema exists so return values are covered, but it omits what happens when used against an existing mock or whether body/body_text may both be omitted. An agent could call this correctly most of the time but may need to inspect surroundings first.

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 coverage is only 50% (host, path) and body/body_text have no schema descriptions, so the description must compensate. It clarifies that body is a JSON value, body_text is raw text, and they should not be used together. This is valuable, but it stops short of saying whether one is required or what happens if both are provided.

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 uses a specific verb and resource ('Write a mock response'), and the qualifier 'from scratch' clearly differentiates it from mock_create_from_entry. Even with many sibling tools, an agent can identify this tool's purpose immediately.

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?

It explicitly says to prefer mock_create_from_entry when a real response exists, telling agents when not to use this tool. It also gives concrete guidance on the body vs body_text choice, so the agent can select parameters correctly without further research.

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