List Coordination Issues (POST)

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

The description fails to clarify the actual behavior of the tool. It claims both listing (read) and creation (write) behaviors without explaining which is correct. The annotations indicate readOnlyHint=false, which could support a write operation, but the description's mixed messages prevent an agent from understanding the true side effects. There is no mention of required permissions or the nature of the response beyond the ambiguous creation claim.

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 contains approximately 80 words, which is reasonable, but includes redundant phrases like 'Use this to perform the list coordination action on Coordination Issues.' The insertion of contradictory creation wording adds unnecessary length and confusion. The API path information is useful but could be more succinctly expressed. The description would benefit from focusing on the single operation and removing the conflicting creation text.

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?

Despite having zero parameters and no output schema, the description fails to provide a complete, consistent picture of the tool's behavior. The critical contradiction between listing and creating leaves the agent without reliable knowledge of what the tool actually does. The mention of the endpoint path adds some context, but the fundamental confusion about the tool's operation makes it incomplete for safe and correct invocation.

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 input schema has zero parameters, with 100% schema description coverage. Since there are no parameters, the description cannot add parameter-level meaning beyond the schema. The description does not describe any request body or implicit parameters. Baseline 4 is appropriate as there is no burden to describe missing parameters.

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 starts by stating 'Lists Coordination Issues via POST' but later contradicts itself by saying 'Creates a new Coordination Issues and returns the created object'. The verb 'Creates' conflicts with 'List', making the primary purpose ambiguous and misleading. The tool name and title suggest a list operation, but the description incorrectly describes a creation operation. This is a fundamental failure in purpose clarity.

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 includes a clear use case: 'Use when query parameters would exceed URL length limits (e.g. large filter sets).' This provides specific guidance on when the POST variant should be preferred over the GET alternative. However, the contradictory creation statement undermines this guidance, as an agent might be confused whether to use this for listing or creating. The presence of a conditional usage hint saves this from a lower score.

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