get_scheduling_page

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

The description adds behavioral context beyond the readOnlyHint annotation by noting that the tool returns the full config including availability_window. It also reveals that update_scheduling_page performs a full replace, which is critical for understanding how the fetched config will be used.

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 two sentences with no unnecessary words. It front-loads the action and then provides essential contextual guidance about the update workflow, making every sentence useful.

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?

For a single-parameter read-only tool with an output schema, the description covers the core purpose and usage relationship to update. It could mention error handling or prerequisites, but the simplicity of the tool and presence of the output schema make the current description sufficient.

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 description does not explain the page_id parameter beyond what the schema already provides (integer type). With 0% schema description coverage, the description should compensate but does not, leaving ambiguity about how to identify a scheduling page.

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 uses the specific verb 'Get' and names the resource as a single scheduling page's full config, including the availability_window. It clearly distinguishes this tool from sibling tools like list_scheduling_pages (which lists all pages) and update_scheduling_page (which modifies config).

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 explicitly advises to fetch before update_scheduling_page and explains why (update is a full replace), giving a clear when-to-use directive. It does not explicitly state when not to use it, but the instruction to fetch before update implies its role as a read-only prerequisite.

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