Shroom Labs

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that this returns curated guide topics, but does not mention response format, pagination, or whether content is static versus dynamic.

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 description is front-loaded with the core purpose and then provides the topic list efficiently. It repeats the schema's 'omit topic to list all' instruction and uses 'and more,' which is slightly redundant, but overall every sentence contributes useful selection information.

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 optional enum parameter with no output schema and annotations covering safety, the description provides enough context to choose a topic or list all. It does not describe all seven enum values by name, but 'and more' signals the remainder, which is adequate.

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 baseline would be 3, but the description adds semantic meaning to several enum values: 'chambers' means which chambers work, 'install' means installing OpenShrooly firmware, and 'terrashroom' means keeping one running. This goes beyond the bare enum labels in 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?

The description names a specific verb and resource ('Get Shroom Labs guides for automated mushroom grow chambers') and enumerates the topic families, so an agent knows this retrieves static guide content rather than profile or timeline data. It does not explicitly distinguish itself from siblings like search_grow_content, but the resource is clear.

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 says 'Omit topic to list all,' which gives one concrete usage behavior, but it does not state when to use this versus search_grow_content or the other sibling tools. Usage is implied by the topic list rather than explicitly guided.

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 and closed-world, so safety is covered; the description adds substantive behavioral context by disclosing the actual payload shape (per-stage days, dual-unit temperatures, FAE, light hours, chamber tips, sources), which matters because there is no output schema. It stops short of stating behavior on a missing/unknown slug.

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 with a dense but scannable enumeration; the parenthetical examples could be trimmed since the schema repeats them, but nothing is 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 one required parameter, no output schema, and safety covered by annotations, the description does the work that matters by describing return contents in detail. Only the error/not-found case is unaddressed.

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 already explains the slug format, the list_profiles source, and that a plain name works. The description's 'by slug' plus inline examples largely duplicate that, adding no new parameter guidance. 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?

States a specific verb and resource ('Get the full grow recipe for one mushroom by slug') and enumerates exactly what the profile contains (stages, days, temp in C/F, humidity, fan, light hours, tips, sources). An agent can distinguish this from list_profiles (which enumerates slugs) without inspecting schemas.

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 mushroom by slug' implicitly contrasts with the list_profiles sibling and the slug example hints at a two-step flow, but no when-to-use/when-not and no mention of get_chamber_guide or grow_timeline, which plausibly overlap. 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered, and the description adds real value by describing the returned structure (per-stage start day, end day, conditions, plus total days to harvest). That detail matters because there is no output schema. It stops short of noting failure behavior for an unknown slug.

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 tight sentences with zero filler: the first front-loads what the tool returns, the second front-loads when to reach for it. Nothing repeats the name or title needlessly.

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, single-parameter lookup, the description covers purpose, return shape and a usage trigger well enough to call it confidently without an output schema. The only gap is undefined behavior when the slug is not found.

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?

Only one parameter exists and schema coverage is 100%, with the schema itself giving the 'pearl-oyster' example. The description adds nothing about the slug, so the baseline 3 applies rather than a higher score.

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 resource (a day-by-day grow timeline for one mushroom) and enumerates what the result contains: stage start/end days, conditions, and total days to harvest. This makes it clearly distinguishable from get_profile, get_chamber_guide and search_grow_content, though it never names or contrasts those siblings 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?

'Use for how long does X take to grow' gives a concrete query pattern that maps well onto the single-slug input. It provides a clear positive trigger but no exclusions or guidance about when to prefer get_profile or search_grow_content instead.

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 (readOnlyHint, openWorldHint=false), but the description adds non-obvious behavior beyond them: the default exclusion of Off-menu content and the guarantee that Off-menu results always carry a legal notice. That legal-notice behavior is something an agent could not infer from annotations or schema, which is exactly the extra context worth crediting.

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: what it is, what each record contains, and the off-menu opt-in caveat. The most decision-relevant framing (identity and content shape) is front-loaded, and no sentence is 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 no output schema, the description usefully discloses the return shape (slug, total grow days, canonical URL) and the legal-notice behavior for Off-menu items, which covers the main gaps. Minor omissions remain — no hint about result ordering, count, or pagination for a list endpoint — but nothing blocks correct invocation.

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 baseline is 3: both 'query' and 'include_off_menu' are documented with examples and defaults in the schema itself. The description reinforces the include_off_menu default and its consequence, but adds no syntax, format, or matching semantics beyond what the schema already provides.

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 ('List Shroom Labs mushroom grow profiles') and immediately scopes it with examples (lion's mane, pearl oyster, shiitake). It also names the sibling relationship ('a slug for get_profile'), so an agent can distinguish it from get_profile and search_grow_content without opening any schema.

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?

Gives clear default behavior ('culinary only by default') and the exact condition to widen scope ('set include_off_menu to also list educational Off-menu profiles'), plus a forward pointer to get_profile via slug. It stops short of explicitly ruling out search_grow_content as the alternative for free-text discovery, so it's strong but not a full when/when-not guide.

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 and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the return shape (titles, short descriptions, canonical URLs) and the intended downstream behavior of citing those URLs, which no structured field provides.

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, front-loaded with the verb and resource scope, and the return-value statement in sentence two does real work. The parenthetical topic enumeration is slightly long, but it doubles as query-vocabulary guidance, so it mostly 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 two-parameter search tool with annotations and no output schema, the description covers scope, query domain, and return shape thoroughly. The only missing piece is explicit routing relative to the retrieve-by-name siblings, which matters given five tools in this namespace.

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 both parameters, including the default of 8 and the max of 20, are already documented in the schema. The parenthesized failure-mode list hints at the sort of query strings that work, but it adds only marginal semantic meaning beyond the schema's own example.

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 ("Search") and enumerates the resource types covered: grow profiles, troubleshooting guides with concrete topics, and blog posts. It's clearly distinguishable from get_profile/list_profiles in spirit, but it never names those siblings, so differentiation is inferred rather than stated.

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 content-type list implies when this tool is appropriate (topic discovery vs. fetching a specific profile), but there is no explicit when-to-use guidance and no routing to siblings like get_profile or get_chamber_guide. Usage is left to inference from the domain vocabulary.

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