Compare your metric against percentiles from teams in the same industry and stage. It flags when fewer than ten teams make percentiles unreliable.
Compare your numbers with percentiles from teams at the same industry and stage.
Below ten teams the percentiles mean nothing — say so plainly instead of reporting them.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | Yes | ||
| csv_path | Yes | ||
| industry | Yes | ||
| value_event | Yes |
Changes observed during successful MCP inspections.
v0.1.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and while the under-ten-teams guard is a genuinely useful behavioral disclosure (it changes what the agent should report), nothing is said about required permissions, where csv_path data comes from, error modes, or result shape. One good behavior disclosed, many untouched.
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?
Two short, front-loaded sentences with essentially no waste. The second sentence is somewhat instructional in tone but earns its place by setting a reporting rule.
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?
A four-required-parameter tool with 0% schema coverage, no annotations, and no output schema leaves the agent guessing about input formats and return structure. The description should have compensated and only partially does.
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 0% and four required parameters (csv_path, value_event, industry, stage) go completely unexplained. The description mentions industry and stage conceptually but never as inputs, and says nothing about the expected format of csv_path or what a value_event is.
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 states a specific verb and resource: comparing the user's numbers against peer-group percentiles, scoped by industry and stage. The strongest sibling it must be distinguished from, submit_benchmark, is not named, so the agent gets a clear action but no explicit routing between the two.
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 implies usage (compare when you have your own numbers and peer grouping by industry+stage) but gives no when-not guidance and never mentions submit_benchmark or find_similar_cases as alternatives. The small-sample caveat is behavioral rather than a usage-selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.