Get config params

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's "Read-only" simply restates that. Beyond annotations it adds only the raw endpoint path, with no information about what is returned, whether auth/device state is required, or what happens if the MAC is unknown. With annotations carrying the safety profile, this adds little.

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?

Two short sentences with the core action front-loaded and zero filler. It is efficient, though the terseness borders on under-specification rather than disciplined brevity.

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?

With no output schema, the description should at minimum indicate what configuration data comes back or its shape; it says nothing. For a read tool with three parameters, an ambiguous "params" argument, and no return-value guidance, an agent is left guessing about the result.

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%, so the baseline is 3. The description adds no meaning beyond the schema, and notably does not clarify the ambiguous "params" query parameter (schema only says "Query params."), which is exactly the kind of gap prose could fill.

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 says "Get config params" and gives the endpoint GET /cti/{mac}, which together imply fetching CTI configuration for a device identified by MAC. But "config params" is vague about what configuration is being read, and the only differentiation from the sibling placetel_set_cti_config is the implicit read/write split. It is minimally identifiable but not specific.

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?

No statement of when to use this versus placetel_set_cti_config or any other CTI tool, and no prerequisites or context described. The agent must infer that this reads while set_cti_config writes, which is left to the name alone.

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