enquiry_fieldsEvery field of the Private Health Costs enquiry: key, label, type, whether required, help text and the allowed options where there are any. Pass answers to submit_enquiry keyed by field key.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the exact informational content of the output and implies a read-only, non-mutating lookup by describing fields rather than actions. It does not discuss error cases or pagination, but for a no-parameter metadata lookup these are minor.
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 carry all necessary information with no filler. The first sentence defines the output content compactly; the second sentence connects it to the submission workflow.
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, zero-parameter metadata tool, the description is largely complete: it names the target enquiry, lists the included field attributes, and links the output to submit_enquiry. It does not mention enquiry_describe, but nothing essential about invoking this tool is missing.
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 tool has zero parameters and the schema contains no properties, so no parameter documentation is needed. The description adds a useful cross-reference that the returned field keys are the keys used in submit_enquiry.
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 clearly identifies the resource ('every field of the Private Health Costs enquiry') and enumerates what is returned: key, label, type, required flag, help text, and allowed options. It stops short of an explicit action verb such as 'returns' or 'lists', and only lightly distinguishes itself from siblings by referencing submit_enquiry.
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?
It gives a clear, actionable usage hint: pass answers to submit_enquiry keyed by field key. This tells an agent how to consume the result, though it does not explicitly state when to prefer this tool over enquiry_describe or state exclusions.
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 has a clearly distinct role: explaining the process, returning the field schema, and submitting the enquiry. There is no overlap or plausible confusion between retrieving metadata and performing the two-step submission.
The names are readable and all use snake_case, but the pattern is inconsistent: enquiry_describe and enquiry_fields use enquiry as a prefix while submit_enquiry places enquiry at the end. This creates a minor mismatch in naming orientation.
Three tools is well-scoped for this focused server: one to describe the process, one to provide fields, and one to handle submission. Each tool earns its place and there is no unnecessary surface area.
The set fully supports the domain: users can understand the offering, inspect all required fields, and complete the two-step consent-enabled submission. There are no obvious missing operations or dead ends in the workflow.