get_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. The verb 'Get details' and the absence of any mutation language imply a read-only operation, and the Returns section transparently describes what data is returned. However, it does not explicitly state that the operation has no side effects, how errors are handled (e.g., schedule not found), or any authentication requirements. For a read-only lookup this is acceptable but not fully transparent.

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 front-loaded with a clear one-sentence purpose, followed by structured Args and Returns sections. However, the Returns section is quite long and largely duplicates the output schema that already exists (context shows has_output_schema: true). While it adds some nuance (e.g., 'omitted for private-mode applications'), the repeated field listing makes the description less concise than it could be. The structure is orderly, but the length is not fully justified given the output schema.

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 simple two-parameter lookup tool with an output schema present, the description is mostly complete: it states the purpose, explains both parameters, and details the return fields with optionality and enums. Minor gaps include lack of explicit usage guidance (when to choose get_schedule over list_schedules) and no mention of error behavior or permissions. These are not critical for a read-only get operation, so the overall completeness is high but not maximal.

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?

Schema description coverage is 0%, so the input schema provides only names and types with no meaning. The description compensates with an Args section that clearly defines each parameter: 'application_name (string, required): Name of the DBOS application' and 'schedule_name (string, required): Name of the schedule'. This gives enough semantic grounding for an agent to supply the correct values, though it could be enriched with formatting or example values. The compensation is solid but not exhaustive.

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 opens with a specific verb ('Get') and resource ('details of a specific schedule from DBOS Conductor'). This clearly identifies the operation as a single-item lookup, distinguishing it from sibling tools like list_schedules (which lists schedules) and pause_schedule/resume_schedule/trigger_schedule (which modify schedule state). The word 'specific' reinforces that it targets one schedule, not a collection.

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 implies when to use the tool: when you need details about a particular schedule identified by application_name and schedule_name. However, it does not explicitly contrast with list_schedules for enumeration or mention any exclusions (e.g., 'use list_schedules to see all schedules'). No alternatives or when-not-to-use guidance is provided, leaving usage context implied rather than explicit.

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