get_guide

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

With no annotations, the description carries the full burden. It usefully discloses the scope of the knowledge base (what topics return content), but does not state that the operation is a read-only lookup, nor describe output shape or size. For a low-risk documentation fetch this partial disclosure is acceptable but not strong.

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?

Compact, front-loaded with the core purpose ('Modeling know-how on demand'), followed by a single dense list where each item corresponds to available content. No filler sentences, though the comma-separated wall lacks grouping or hierarchy.

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 one-parameter, no-annotation, no-output-schema tool the description covers what content is available, which is the main need. It omits when to invoke it and the index-discovery affordance documented in the schema, leaving a modest gap in operational completeness.

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 already 100%, so the baseline is 3, but the description goes beyond the terse schema entry by effectively enumerating the valid topic names (workflow, dimensions, japan, game_assets, recipes, etc.), which meaningfully constrains and guides the single parameter. It stops short of mapping each topic to its exact enum string.

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 frames the tool as on-demand modeling know-how and enumerates the domains it covers (hard_surface, organic, detailing, materials, troubleshooting, etc.), so an agent can tell it retrieves reference guidance rather than performing a modeling action. It is distinguishable from action siblings like edit_mesh or create_primitive, though it never states the verb 'get/retrieve a guide' 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?

There is no explicit when-to-use guidance: nothing says to consult this before authoring geometry, nor when it should be skipped in favor of execute_python or the reference-comparison siblings. The topic list implies what content exists but not the conditions that should trigger a call. The schema's 'call with index to list them' hint is not echoed in the description.

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