Route an existing-provider CQC registration change to the correct forms, companion manager actions, timing and approval gates. Use unknown rather than guessing missing change facts.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the tool routes a change to forms, actions, timing, and approval gates, and it instructs callers to use 'unknown' rather than guessing. However, it does not disclose whether the tool is read-only, what its return value contains, whether it has side effects, or what prerequisites exist, which is a significant gap without annotations.
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 filler. The primary purpose and output categories are front-loaded, and the second sentence provides a distinct, useful guidance about handling unknown facts. It is appropriately sized for the content it conveys.
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 tool has a complex nested input schema and no output schema or annotations, yet the description never explains what the caller receives—such as a list of required forms, a timeline, or approval gates—or how the routing result is structured. The guidance about unknowns helps, but it does not sufficiently complete the behavioral or output picture for an agent invoking the tool.
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 top-level payload parameter has no description in the tool description, but the nested schema provides detailed descriptions for most properties, including the same 'Use unknown rather than guessing' guidance for manager_status. The description therefore adds little beyond the schema; it mostly restates a rule already present in the schema rather than enriching parameter understanding.
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 a specific verb ('Route') and a specific resource ('existing-provider CQC registration change') and lists concrete outcome categories: forms, companion manager actions, timing, and approval gates. It differentiates from siblings by focusing on routing a change through CQC registration processes, though it does not explicitly name an alternative tool.
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 the tool should be used when an existing provider has a registration change to route, which is a clear context. It adds the instruction 'Use unknown rather than guessing missing change facts,' but it does not state when not to use this tool or mention alternatives such as cqc_registration_scope_preflight, leaving sibling selection mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each preflight tool targets a distinct CQC decision area, and provider_info/source_status are clearly separate metadata utilities. cqc_application_readiness does aggregate gap checking that overlaps with location/structure/document preflights, but descriptions are sufficiently scoped to avoid misselection.
All tools share the cqc_ prefix and use consistent snake_case naming. The five decision tools uniformly use the _preflight suffix, while the remaining tools use clear noun phrases, creating a predictable and coherent naming convention.
Nine tools is well within the ideal range and each tool maps to a meaningful CQC decision support question. There are no redundant or filler tools, and the count feels well-scoped for the server's purpose.
The set covers new-provider readiness, location eligibility, provider structure, registration scope, change routing, statutory notifications, required documents, metadata, and source freshness. This forms a complete preflight decision layer for CQC provider regulation with no obvious dead ends.