connects_schedule

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

The description adds valuable behavioral details beyond the annotations: date filtering is applied per upstream page, next_offset should be followed even on empty filtered pages, dates must be ISO, and there is a maximum 31-day window. This gives the agent practical knowledge about pagination and constraints that annotations do not provide.

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 compact and well-organized: it leads with the resource, then states the critical pagination behavior and date constraints. Every sentence earns its place, and there is no redundant or filler content.

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 description covers the most important operational details: date format, filter window, and pagination behavior, while the output schema presumably documents return values. The main missing piece is the meaning of the 'calendar' parameter and explicit differentiation from nearby tools, but overall the tool can be invoked correctly with the given information.

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?

With 0% schema description coverage, the description must compensate for the bare input schema. It adds meaning for start/end by specifying ISO format and the 31-day window, and it clarifies how offset should be used with next_offset. However, it does not explain the 'calendar' parameter or provide any semantics for 'limit', leaving gaps for those 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 clearly identifies the resource as the student schedule, and the surrounding details about date filtering and pagination make it evident the tool retrieves schedule data. It does not explicitly state a verb like 'list' or 'get', and it does not differentiate from sibling tools such as connects_events, so it misses the top score.

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 phrase 'Student schedule' implies this tool is for retrieving schedule-related data, and the date-window constraint gives some context for when it applies. However, there is no explicit guidance about when to prefer this over siblings like connects_events or blackboard_calendar, and no exclusions or alternative routing are provided.

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