enquiry_fieldsEvery field of the Cataract Surgery Cost 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?
No annotations are provided, so the description carries full behavioral-burden. It discloses what the tool returns but does not explicitly state that it is read-only or side-effect-free. The zero-parameter, metadata-only nature strongly implies safety, but the description leaves it unstated.
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 concise sentences deliver the resource, the exact content of the result, and the downstream usage. Every word earns its place, and the main purpose is front-loaded.
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 zero-parameter metadata tool, the description sufficiently covers what is returned and how to use it. The only gap is the lack of explicit differentiation from the sibling enquiry_describe, which could cause an agent to pick the wrong tool without further investigation.
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 no parameters and an empty schema with 100% coverage, so the baseline is 4. The description adds useful context by explaining how returned field keys are used in submit_enquiry, which is more helpful than parameter documentation would be here.
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 exactly what the tool does: it lists every field of the Cataract Surgery Cost enquiry, including key, label, type, requiredness, help text, and allowed options. It clearly distinguishes itself from submit_enquiry by positioning itself as the metadata source for that submission 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 usage context by saying 'Pass answers to submit_enquiry keyed by field key', which tells the agent to fetch fields before submitting. However, it gives no explicit guidance on when to use this tool versus the sibling enquiry_describe, and no when-not-to-use conditions.
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.
enquiry_describe, enquiry_fields, and submit_enquiry each occupy a clearly distinct role: narrative overview, field schema, and actual submission. There is no meaningful overlap between any pair, though describe and fields both support the same submission flow.
The first two tools share an enquiry_ prefix and clearly group metadata/introspection, while submit_enquiry is the action verb. This is mostly consistent and readable, but the object-first vs verb-first ordering is a minor deviation from a single verb_noun pattern.
Three tools is well-scoped for a single-purpose enquiry submission server: each tool maps to a necessary stage (understand, get fields, submit). No tool feels redundant and the count is not too thin.
For the stated purpose of submitting a Cataract Surgery Cost enquiry, the set fully covers onboarding description, required field metadata, validation/consent, and two-step submission with confirmation token. No essential operation is missing; the flow cannot get stuck within this server's responsibility.