get_invite

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only implies a read-only operation by using 'Get', but does not state whether any side effects occur, what authentication or permissions are required, or what the response format will be. This is insufficient for a tool with zero annotation coverage.

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, concise sentence that front-loads the purpose. There is no fluff or repetition. However, its brevity borders on under-specification, as it omits key contextual details, so it does not earn a 5.

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?

Given the simplicity (one parameter, no output schema) and low annotation coverage, the description should provide more context. It does not mention possible statuses, metadata fields, error scenarios, or how this tool relates to get_invite_result or other invite tools. An agent would still be uncertain about the expected output and edge cases.

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 no descriptions for the token parameter (0% coverage), so the description must compensate. It does clarify that the token is used to fetch the invitation status, which adds some meaning beyond the schema's bare 'token' field, but it does not explain the token's format, source, or how to obtain it. Given the low coverage, this is only a minimal compensation.

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 clearly states the verb 'Get' and the resource 'invitation status and metadata' with the parameter 'token' as the lookup key. It is distinguishable from sibling tools like get_invite_result by focusing on status and metadata rather than results, but it does not explicitly differentiate itself from list_invites or other invite-related tools.

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 alternatives such as list_invites, get_invite_result, or cancel_invite. It does not mention any prerequisites, use cases, or exclusions, leaving the agent to infer appropriate usage from context.

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