gh_get_parameter

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

The description is consistent with the readOnlyHint annotation and does not contradict it. It adds only the context that a 'current value' is being read; no additional behavioral details such as source document, staleness, or side-effect-free guarantees are disclosed, but the annotation already covers the safety profile.

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 a single focused sentence with no filler. The core action and resource are front-loaded, making it easy to parse quickly.

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 simple read operation with readOnlyHint and an output schema, this is mostly adequate. However, the missing parameter semantics and lack of routing to the paired write tool leave an agent with some ambiguity about how to identify the component/parameter and when to prefer this over related gh_* 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%, and the description does not explain component_id or the output parameter beyond what the schema's terse 'Output name or zero-based index' already states. The agent must infer that component_id selects a Grasshopper component and that output selects the specific parameter.

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 clearly states the action ('Read') and the resource ('current value of a component parameter'), and the readOnlyHint annotation aligns with this. It does not explicitly differentiate from siblings like gh_set_parameter or gh_data_tree_get, but the read-vs-set contrast is strongly 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?

The description gives no guidance on when to use this tool versus alternatives such as gh_set_parameter, gh_data_tree_get, or gh_component_list. The read-only use case is implied but no explicit when/when-not guidance or alternative routing is provided.

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