get_on_call_schedule

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't specify whether this requires authentication, returns paginated results, has rate limits, or what format the schedule data takes. It mentions nothing about permissions needed, error conditions, or whether the operation is idempotent. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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 extremely concise at just 4 words, but this brevity comes at the cost of being under-specified rather than efficiently informative. While it's front-loaded with the core action, it lacks the additional context needed for effective tool selection. The single sentence structure is simple but fails to provide necessary operational details that would help an AI agent use the tool correctly.

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 complexity of on-call scheduling systems and the lack of annotations or output schema, the description is incomplete. It doesn't explain what an 'on-call schedule' entails, whether it returns current or future schedules, if it includes team assignments or escalation policies, or what the return format looks like. With no output schema to document return values and no annotations covering behavioral aspects, the description should provide more operational context for a tool that likely returns structured scheduling data.

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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to compensate for any parameter gaps. However, it also doesn't add any parameter-related context beyond what the empty schema indicates. The baseline for 0 parameters with high schema coverage is 4, as the description doesn't need to explain parameters but also doesn't add value in this dimension.

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 'Get an on-call schedule' is a tautology that essentially restates the tool name 'get_on_call_schedule'. It specifies the verb 'Get' and resource 'on-call schedule' but lacks any distinguishing details about scope, format, or what exactly is retrieved. Compared to sibling tools like 'get_on_call_schedule_on_call' and 'get_on_call_team_on_call', it doesn't clarify how this differs from those alternatives.

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. With multiple sibling tools containing 'on_call' in their names (get_on_call_schedule_on_call, get_on_call_team_on_call, get_on_call_team_routing_rules, create_on_call_schedules, delete_on_call_schedule, update_on_call_schedule), the description fails to indicate whether this retrieves all schedules, a specific schedule, or schedules filtered by some criteria. There's no mention of prerequisites, constraints, or appropriate contexts for use.

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