Lawn Care Center

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds that the payload includes citations and an MCP resource link, which hints at a follow-up resource, but says nothing about missing/expired paths or error behavior. Modest added value on top of 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?

A single front-loaded sentence that names the verb first and packs the return contents and the provenance constraint into one efficient line. 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?

With a rich annotation set, a single well-constrained parameter, and an output schema that documents the return payload, the description covers what an agent needs to invoke it. Only the path-format taxonomy and failure behavior remain unstated.

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 one parameter with 0% schema description coverage: the schema only constrains it via a regex (articles/states/cities prefixes) and length bounds. The description clarifies that it is a path obtained from search results, but it never explains the three path shapes or that only published guides resolve, so it only partially compensates for the coverage gap.

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 (Get) and resource (one published lawn-care guide) and enumerates the payload (answer, metadata, citations, resource link). It also ties itself to the sibling search_lawn_care as the source of a valid path, though it does not contrast with list_lawn_care_taxonomy.

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 'one published guide path returned by search_lawn_care' implies the correct workflow: run search first, then fetch a single result's content. There is no explicit when-not guidance or mention of what to do with invalid/unknown paths, but the sequencing constraint is clear.

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 openWorldHint=false, so safety and mutation behavior are covered. The description adds the useful scoping detail that it returns 'one bounded taxonomy facet,' but does not explain what 'bounded' means, how many items are returned, or any pagination 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 states the action, scope, and facet options with no filler. Every element 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?

An output schema exists, so return values need not be explained, and the federated facet list is stated. However, with 0% schema description coverage, the description omits the meaning of limit and prefix and gives no guidance on selecting this tool over the two sibling search/content tools.

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%, so the description must carry parameter meaning. It enumerates the valid facet values, which usefully reinforces the sole enum parameter, but it provides no explanation for the limit or prefix parameters, leaving them undocumented in both schema and description.

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 ('taxonomy facet'), and enumerates the exact facet categories matching the enum (topics, tags, seasons, kinds, states, cities). This clearly distinguishes it from the content-fetching siblings get_lawn_care_content and search_lawn_care.

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 gives an implied usage context, 'for query planning,' which hints that the tool is for discovering vocabulary before searching. However, it does not explicitly state when to use this versus search_lawn_care or get_lawn_care_content, nor does it name any alternative or exclusion.

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 fully covered. The description adds two useful behavioral facts beyond that — results are restricted to 'published' guides and include MCP resource links for full Markdown — but says nothing about pagination via cursor or the limit cap, so it is additive but not rich.

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 with the purpose front-loaded, then filter guidance, then a result note — no filler. Slightly terse for a 9-parameter tool, 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?

An output schema exists, so return values need not be explained, and annotations cover safety. However, with 9 optional parameters and no schema descriptions, the agent still lacks guidance on query vs tag, pagination via cursor, and the default/limit behavior, leaving meaningful gaps for a search tool.

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 9 parameters, so the description carries the full explanatory burden. It names location, season, topic, and content kind, which roughly maps to city/state, season, topic and kind, but leaves query, tag, limit, and cursor entirely undefined — including the important distinction between a free-text query and a taxonomy tag.

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?

Clear verb+resource: 'Search published Lawn Care Center guides', which tells the agent exactly what is retrieved. It does not name the siblings (get_lawn_care_content, list_lawn_care_taxonomy), though the mention of resource links for full Markdown implicitly signals it is a discovery, not a fetch, tool.

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 sentence 'Use filters when location, season, topic, or content kind is known' implies when the tool is useful, but it gives no exclusions and never names the alternative (get_lawn_care_content) that should be used once a specific guide is identified. Usage is inferred rather than stated.

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