triz_parameter

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose useful content-level behavior ('alternate labels, interpretation guidance and nearby categories') and clarifies that these are historical matrix categories rather than typed quantities, which is real added context. However, it omits any statement about whether the lookup is read-only/cached, and 'where recorded' is vague about what the entry actually contains in edge cases.

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?

Four short sentences, front-loaded with the core action and range, then the list mode, then entry contents. The phrase 'nearby categories to distinguish where recorded' is awkward and slightly hard to parse, which is the only real drag on an otherwise tight description.

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?

This is a simple single-parameter lookup with no output schema, so the description's summary of what entries contain (labels, interpretation guidance, categories) does the work a return-value spec would otherwise do. It also flags the conceptual distinction from typed quantities. Minor gap: no statement on whether all 39 entries are returned in full or summarized when id is omitted.

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% and the single id parameter is already documented as 'Parameter number 1-39; omit to list all'. The description's 'Omit id to list all 39' restates the schema rather than adding syntax or semantics beyond it, 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?

The description gives a specific verb and resource ('Get a canonical TRIZ engineering parameter (1-39)') and states the list-all mode, so the agent knows exactly what is retrieved. It also draws a boundary against 'typed domain quantities', which helps separate it from other knowledge lookups, though it never names the closest sibling (triz_principle) or triz_matrix 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?

It does give one concrete usage rule: omit id to list all 39. That is guidance on invocation mode rather than on tool selection. Nothing says when to reach for this versus triz_principle, triz_matrix, or triz_knowledge, so an agent must infer routing from the description alone.

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