Determine whether a CQC statutory notification is required and return the correct route, channel, deadline, exceptions and evidence. Use facts_complete only when the relevant facts are known.
| 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 carries the behavioral disclosure burden. It usefully discloses that the tool evaluates and returns route, channel, deadline, exceptions, and evidence, but it does not address side effects, read-only behavior, error handling, or what happens when facts are incomplete.
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?
Two sentences with no filler. The purpose and output facets are front-loaded, and the usage caveat about facts_complete is a separate, crisp instruction.
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 large and complex input schema with ten notification types and many conditional facts, yet the description provides no guidance on mapping facts to notification types, no output schema, and no explanation of the decision behavior. It is too thin to fully support correct invocation for such a complex 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?
Schema description coverage for the top-level payload is 0%, and the description does not compensate by explaining the payload structure or required notification_type. The only parameter-level guidance is the facts_complete instruction, which adds limited meaning amid a large, complex input object.
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 states a specific action ('Determine whether a CQC statutory notification is required') and a specific resource, then enumerates the produced outputs: route, channel, deadline, exceptions, and evidence. This clearly distinguishes it from sibling preflight tools focused on location, provider structure, or registration scope.
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 gives one practical usage instruction: 'Use facts_complete only when the relevant facts are known.' This implies the tool should be invoked with complete facts, but it does not explicitly state when to prefer this tool over alternatives or when not to use it.
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 tool targets a distinct regulatory question—location, scope, structure, changes, notifications, documents, source freshness—and the descriptions clarify the boundary. However, cqc_application_readiness is a broad aggregate that overlaps with several component preflights (premises, staff, documents), so agents may occasionally misroute between the holistic check and the specific decision tools.
All tools share a cqc_ prefix and use clear snake_case names. Most decision tools use the _preflight suffix, but provider_info, required_documents, and source_status break that pattern, making the naming slightly uneven.
Nine tools is a well-scoped size for a regulatory decision layer. Each tool addresses a distinct aspect of CQC decisions without redundant or filler tools.
The set covers the main CQC regulatory decision surface: new provider readiness, location, scope, structure, change routing, documents, notifications, and source evidence. Minor gaps such as deregistration or voluntary cancellation are not represented, but the core registration and notification workflows are complete.