search_communication_types

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

The description is essentially a tautology of the tool name and adds no behavioral context beyond what the annotations already supply. It does not disclose side effects, return format, or how the search criteria are applied. The annotation readOnlyHint=false is not contradicted, but the description itself provides zero additional value.

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 only three words long, which is concise but severely under-specified. It omits crucial details about the search operation, making it insufficient for an agent to understand how to invoke the tool correctly. This is under-specification, not effective conciseness.

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?

The tool has no output schema, a required body parameter, and no explanation of how search filters work or how it differs from list_communication_types. Given the moderate complexity of the body parameter and pagination options, the description is materially incomplete for correct usage.

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%, with each parameter having a description (body, limit, offset, order_by). The tool description adds no extra meaning about these parameters, so the baseline of 3 is appropriate. The body parameter's description is vague, but the description does not compensate.

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 'Search communication types' clearly states the verb and resource. However, it does not distinguish itself from the sibling tool 'list_communication_types', which is also present in the API. The lack of differentiation prevents a score of 5.

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 guidance on when to use this tool versus list_communication_types, nor any context about the required 'body' parameter. It offers no explicit alternatives or usage scenarios, leaving the agent to infer when a search is appropriate.

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