OneLessTool

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

Annotations already establish that this is a safe, idempotent, closed-world read, so the description is free to focus on output content. With no output schema, its disclosure that results include fit, quality scores, required skill, cheapest qualifying plan and limitations meaningfully tells the agent what it will get back. It adds no auth, rate-limit or cost-of-call context, so it stops short of a 5.

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?

A single sentence, front-loaded with the scope ('for one capability') and then the return contents; every clause carries information. Slightly dense as a comma-listed enumeration, but no filler.

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 single-parameter, read-only tool with no output schema, the description covers both the input scope and the shape of the returned comparison. Nothing essential is missing, though it does not say how many tools are compared or how results are ordered.

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 100% and the schema already explains that the capability may be a slug or a resolvable phrase. The description's example slugs ('youtube-thumbnails', 'crm-contacts') are mildly illustrative but largely restate what the schema provides, so the baseline of 3 applies.

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?

States a specific verb (compare) and resource (all known tools for one capability), with concrete capability examples that pin down the scope. It is distinguishable from siblings like find_alternatives or search_catalog by the exhaustive 'all known tools' framing, though no sibling is named explicitly.

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 phrase 'For one capability' implies when the tool applies, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as find_alternatives or recommend_stack, which cover adjacent intents. Usage is inferable rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower. The description nonetheless adds genuine methodology context the annotations do not: savings are split into 'likely' and 'possible', are never double-counted, and costs are normalized to what the user actually pays monthly across all seats. This bounds how the agent should interpret results, though return shape is not described.

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 dense sentences with no filler; the core action and the verdict taxonomy are front-loaded, and the savings/cost accounting rules follow. Some clauses ('with the arithmetic') are terse to the point of being cryptic, but nothing is wasted.

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?

There is no output schema, so the description carries the return-value burden. It enumerates the verdict labels and the two savings buckets, giving the agent a usable picture of the output, but it omits the 'skill' input's effect and any structural detail about the response, leaving minor gaps for a tool of this complexity.

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?

Top-level schema description coverage is 0%, so the description must compensate. It does clarify cost semantics ('what the user actually pays, monthly, all seats'), which pins down monthly_cost_usd and the meaning of seats, but it says nothing about the 'skill' enum (none/basic/technical) or how the subscriptions array should be populated beyond the sparse per-property descriptions.

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?

States a specific action (audit subscriptions, estimate savings) and enumerates the classification outcomes — keep, downgrade, redundant, test_replacement, review_unused, keep_critical — which makes the tool's analytical purpose concrete. It is distinguishable from siblings like recommend_stack or compare_solutions, though it never names them explicitly.

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?

Usage is implied by the phrasing 'Audit the user's subscriptions' — i.e. use it when the user has a list of subscriptions and wants savings analysis — but there is no explicit when-to-use/when-not guidance and no pointer to alternative siblings such as recommend_stack or find_alternatives.

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

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: results are ranked with owned tools first, and the response includes an honest case for keeping the tool.

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 tight sentences with no waste, leading with what the tool produces and the ranking rule, then the precision tip, then the honest-case note.

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 read-only, no-output-schema tool, the description covers what is returned (per-capability alternatives, ranked, with a keep-case) and how to get better results. Minor gaps only, such as how team_size influences output.

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 100%, so the schema already documents all four parameters. The description only adds the origin of capabilities (from get_tool) and the $0-extra framing for owned_tools; team_size and the tool parameter get no extra meaning.

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?

States a specific verb (list) and resource (capabilities + alternatives for a product), plus the distinctive output rule: owned tools ranked first at $0 extra. This differentiates it from siblings like compare_solutions and recommend_stack.

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?

Clearly frames the use case (a tool the user is considering dropping) and tells the agent to source capabilities from get_tool for precision. It does not explicitly name sibling tools to use instead, so it stops short of full routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful framing that results are concrete step-by-step procedures rather than lookups, but says nothing about limits, pagination, or result count, which matters for a search tool.

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 sentences, zero filler. The core capability is front-loaded and the filtering facets follow immediately, so an agent gets the essential facts in the first clause.

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 read-only, no-required-parameter search tool with a small schema, the description conveys what is searched and how it can be narrowed. No output schema exists, yet the shape of a result ('step-by-step workflows') is at least characterized, so nothing critical is missing.

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 only 25% (only replaces_tool is documented), so the description has to compensate and it partially does by naming the replaces_tool, capability, and query filters. However it gives no format examples and does not clarify how the free-text query differs from the capability filter, leaving two loosely overlapping string params undifferentiated.

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?

Specific verb (Find) plus resource (workflows) with a precise scope: step-by-step workflows that replace a paid tool or achieve an outcome using tools the user already owns. The 'step-by-step' framing implicitly distinguishes it from the sibling find_alternatives (single-tool swaps), though that contrast is never made explicit.

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 description names the three filter axes, which implies how the tool is driven, but never states when to choose find_workflows over find_alternatives, compare_solutions, or recommend_stack. No exclusions or prerequisites are given, so routing depends on inference from the name.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description meaningfully adds that each price comes with evidence status, verification date, and source URL — provenance information an agent needs to judge trustworthiness, though it says nothing about pagination or result limits for the all-tools case.

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?

A single tight sentence that front-loads the verb and resource, then enumerates the payload. Every clause earns its place with no filler.

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 read-only listing tool with no output schema, the description adequately covers both scope and the shape of returned metadata, and annotations handle the safety profile. The only real gap is how large result sets behave when no tool filter is supplied.

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% for the single "tool" parameter, so the description must carry the load. It does explain that the parameter scopes results to one tool and that omission returns all tools, but it never specifies the expected identifier format (slug, ID, display name) or the 80-character constraint rationale.

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 ("List") and resource ("plan prices") plus the scope options (one tool or all tools) and the accompanying metadata fields. It is clearly distinct from sibling tools like get_tool or compare_solutions, though it never names a sibling to sharpen the boundary.

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?

"for one tool or all tools" implicitly tells the agent the tool parameter is optional and what omitting it does, which is useful context. However, there is no explicit when-to-use vs. when-not guidance and no alternative tool is named for related pricing questions.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. What the description adds is uniquely valuable because there is no output schema: it discloses the shape and nature of the returned data, including that prices carry an evidence status and a verification date, signaling possible staleness. It does not cover lookup failures or caching behavior.

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?

A single front-loaded sentence that opens with the resource and then enumerates the payload. Every clause carries information, though the fragment style and long parenthetical list make it slightly dense.

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 and only one annotated parameter, the description carries the burden of describing returns, which it does across all major facets. What remains thin is behavioral edge cases – unknown slugs, unsupported products, or data freshness guarantees beyond the per-price verification date.

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?

There is a single parameter and schema description coverage is 100%, with the schema already supplying an example ('Canva' or 'canva'). The description adds nothing about identifier resolution, so the baseline 3 applies.

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 names the resource precisely – a software product's full structured profile – and enumerates the domains it covers (plans/prices, capabilities, replacement difficulty, risks, workflows), which distinguishes it from narrower siblings like get_pricing or get_workflow. It is a noun phrase rather than a verb phrase, and the ambiguous tool name 'get_tool' is only rescued by the title, but the resource is unambiguous.

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?

There is no when-to-use or when-not-to-use guidance. Several siblings (get_pricing, get_workflow, compare_solutions, find_alternatives) overlap directly with the content listed here, and the description never states whether to call this one for a broad profile or the narrower tools for specific facets.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world, so the safety profile is covered. The description adds content-scope context (what the guide contains, that a pre-cancellation verification checklist is included) but says nothing about lookup failure on an unknown slug, freshness, or size/latency of the payload.

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?

One front-loaded sentence: the category ('Full replacement guide') leads, followed by the itemized contents. The enumeration is long but each item maps to a real section of the payload, so little is wasted.

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, the description effectively serves as one by naming the return contents, which is exactly what an agent needs to decide to fetch it. It is only incomplete on how to obtain the slug and what happens with an invalid slug.

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 50%: 'sections' is documented in the schema with its default, while 'slug' has no description anywhere. The listed contents loosely map to the sections enum values, which adds mild reinforcement, but nothing explains that slug is the workflow identifier produced by find_workflows.

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?

States a specific resource ('full replacement guide') and enumerates its contents, so the agent knows this returns a complete migration plan rather than a search result like find_workflows. It never uses a verb phrase like 'retrieve the guide for a workflow slug', so the slug-driven nature is only implied.

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?

No statement of when to call this versus find_workflows, compare_solutions, or estimate_savings, and no note that a slug must first come from find_workflows. The 'verification checklist to run BEFORE cancelling' hints at a decision context but stops short of guidance.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description goes beyond that by disclosing the output's prioritization logic (owned tools surfaced at $0 first), the minimal-stack guarantee, and the presence of cost and risk warnings, which is meaningful behavioral context in the absence of an output schema.

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?

A single dense sentence that front-loads inputs and then enumerates outputs with no filler. It is somewhat packed with parenthetical asides, which costs a little readability but nothing is wasted.

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 7-parameter, zero-required, read-only tool with no output schema, the description is the only place the return shape can be learned and it covers that thoroughly (per-capability options, minimal stack, incremental monthly cost, warnings). An agent has enough to call it correctly.

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 43%, so the description must compensate; it maps most inputs to intent — outcomes as 'free text or capability slugs' (query/capabilities), 'what they already own' (owned_tools), and skill, collaboration and data sensitivity as warning triggers. Only team_size is left unaddressed.

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?

States a specific verb+resource ('recommend ... stack') and pins the scope to a cheapest/minimal stack, plus what it returns (per-capability options, owned tools at $0 first, incremental monthly cost, warnings). This clearly separates it from get_pricing or search_catalog, though it never names a sibling to route against, so it stops short of a 5.

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?

Usage is only implied by the input framing ('Given the outcomes the user needs ... and what they already own'). There is no explicit when-to-use, when-not-to-use, or named alternative such as compare_solutions or find_alternatives, leaving the agent to infer the routing condition.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the disclosure of ranking behavior and a return summary: ranked hits with URLs plus the most likely tool and capabilities. With no output schema, that return-format statement is genuinely useful. Nothing contradicts the annotations.

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 short sentences, front-loaded with the verb-resource pairing, then an example, then return behavior. Every sentence earns its place; the parenthetical gloss on 'capabilities' is slight filler but harmless.

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 3-parameter read-only search with full schema coverage and no output schema, the description supplies what the structured fields can't: matching semantics (synonyms) and the shape of results. Nothing an agent needs to invoke it correctly is missing.

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 100%, so the schema already documents query, kinds, and limit; the baseline is 3. The description loosely gestures at the kinds dimension ('software products, capabilities, replacement workflows') but adds no syntax or constraint detail beyond the schema.

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?

States a specific verb (natural-language search) and resource (catalog) with scope enumerated as software products, capabilities, and replacement workflows. The synonym example makes the matching behavior concrete. It doesn't name or contrast with siblings like find_workflows or get_tool, so differentiation is only partial.

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?

Usage is implied — this is the broad discovery entry point covering the same space as several siblings — but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer whether to start here or call find_workflows / get_tool directly.

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