Return core and curated service-specific CQC supporting documents plus conditional and review-required items.
| Name | Required | Description | Default |
|---|---|---|---|
| is_nhs_trust | No | ||
| service_type | Yes | ||
| is_corporate_provider | No | ||
| building_control_required | No | ||
| uses_xray_or_ionising_radiation | No | ||
| has_lifting_equipment_subject_to_loler | No | ||
| specialist_autism_or_learning_disability_service | No |
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 disclosing behavior. It indicates a read-style 'Return' action and mentions conditional/review-required items, but it does not disclose output format, whether the boolean conditions alter results, permissions/rate limits, or side effects. The description is not contradictory, but it is too thin to make behavior predictable.
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 a single front-loaded sentence with no filler or redundancy. It states the action and the main categories of returned items directly, making it efficiently scannable for an agent.
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 tool with 7 parameters, no annotations, no output schema, and no parameter descriptions, this minimal description leaves major gaps: meaning of each boolean, output shape, and relationship to sibling CQC tools. It gives a high-level purpose but is not enough to ensure correct invocation.
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%, and the description does not explain any of the 7 parameters. 'Service-specific' hints that service_type matters, and 'conditional' vaguely gestures at the boolean flags, but there is no mapping of flags like is_nhs_trust, building_control_required, or uses_xray_or_ionising_radiation to outcomes. The description does not compensate for the empty schema descriptions.
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 ('Return') and identifies a concrete resource: 'core and curated service-specific CQC supporting documents plus conditional and review-required items.' This conveys a documents-return tool and is distinguishable from the sibling preflight/info/status tools, though it does not explicitly name any sibling.
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 wording implies the tool is for retrieving CQC supporting documents for a given service type, so an agent can infer a basic context. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as cqc_application_readiness or cqc_location_preflight, leaving routing partially 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 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.