Get Source Filter

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

Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) fully cover the safety profile, and 'Gets the info' is consistent with these—no contradiction. However, the description adds essentially nothing beyond the annotations: no clarification of what 'info' contains, no mention of the optional canvasUuid disambiguation behavior, and no error/edge-case notes. The HIGH example received a 3 for adding date-range scoping context; this description has no equivalent added context.

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, grammatically correct sentence that front-loads the key information with no wasted words—'Gets the info for a specific source filter' earns every word. It's appropriately sized for a simple getter. Slightly docked because the word 'info' is vague (versus 'settings' or 'configuration'), but this is a marginal quibble for an effectively concise 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?

For a simple read-only operation with no output schema and 100% parameter coverage, this description is functional but minimal. It meets the 'minimum viable' bar: an agent could correctly reason this returns data for a single filter. However, since there's no output schema, the description's job is larger, and it could have clarified what 'info' means (e.g., settings, enabled state) or that the source name can be disambiguated by an optional canvas UUID—context that would materially help the agent.

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%, so the baseline of 3 applies even though the destination description provides no parameter details. The schema fully documents sourceName and filterName, and the optional canvasUuid is self-describing. The description adds no parameter-level information, but the rubric doesn't require it at this coverage level.

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 'Gets the info for a specific source filter' uses a specific action verb ('Gets') and resource ('source filter'). The word 'specific' subtly distinguishes it from the sibling list variant (obs-get-source-filter-list), but unlike the highest-caliber examples, it doesn't explicitly name the alternative tool or contrast itself against related getters like obs-get-filter-kind-list.

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 provides no when-to-use guidance, exclusions, or mention of alternatives. Unlike the HIGH calibration example that explicitly suggested 'use search_calls_extensive instead', this description doesn't help the agent decide between this and the closely related obs-get-source-filter-list, obs-set-source-filter-settings, or others. The guidance is simply absent, not misleading.

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