get_measurement

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool returns a full summary, which implies read-only behavior, but it does not explicitly state that it has no side effects, requires no special permissions, or how it behaves when the measurement is not found. The description adds minimal behavioral context beyond the basic 'Get' verb.

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, front-loaded sentence with no redundant words. Every part contributes meaning: 'one measurement' scopes the noun, 'full summary' specifies the output, and 'all metadata REW holds for it' clarifies the extent. It is concise and well-structured.

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 get tool with one well-documented parameter and no output schema, the description is nearly complete. It explains what is returned (full summary of metadata) and the schema covers the input. It lacks guidance on edge cases or error handling, but given the tool's simplicity, it is sufficiently complete.

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?

The schema provides 100% parameter description coverage and the parameter description already explains the UUID vs index distinction and the stability caveat. The tool description itself adds no parameter-specific meaning, so the baseline of 3 is appropriate given the schema does the heavy lifting.

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 uses the specific verb 'Get' with the resource 'measurement' and explicitly scopes to 'one measurement' and 'full summary (all metadata REW holds for it)'. This clearly distinguishes it from siblings like list_measurements (which lists) and get_measurement_commands (which gets commands), leaving no ambiguity about what the tool does.

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 clearly implies the use case: when you need a single measurement's complete metadata. However, it does not explicitly mention alternative tools or when not to use it, such as pointing out that list_measurements is for enumerating measurements. This is clear context but lacks explicit exclusions or alternative recommendations.

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