enquiry_fieldsEvery field of the Car Import Calculator 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 the full burden of behavioral disclosure. It implies a read-only metadata operation and describes the output contents, which is helpful. However, it does not explicitly state that the tool has no side effects, that the field definitions are static, or what happens if the enquiry is unavailable. This is acceptable but minimal.
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 with no wasted words. The first sentence enumerates the returned field attributes, and the second connects the output to the submission workflow. Both sentences earn their place.
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 adequately covers what is returned and how the output should be used downstream. There is no output schema, so the description's enumeration of key, label, type, required, help text, and options is essential and sufficient. A small gap is the absence of any mention of related siblings or limitations, but the description is complete enough for 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?
The tool has zero parameters and the schema has 100% coverage of that, so there are no parameter semantics to explain. The description adds value by instructing that answers should be keyed by the field keys returned here, which is the main parameter-related guidance an agent needs.
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 (fields of the Car Import Calculator enquiry) and enumerates exactly what is included: key, label, type, required flag, help text, and allowed options. It does not use an explicit verb like 'returns' or 'lists', but it is unambiguous and is easily distinguished from submit_enquiry, which consumes those field keys, and from the other siblings that describe or calculate.
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 provides clear usage context: the keys returned by this tool are the ones to use when passing answers to submit_enquiry. It does not explicitly name when not to use this tool versus alternatives, but the connection to the submission workflow makes the intended use obvious.
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 purpose: calculate performs the calculation, calculator_describe documents it, enquiry_describe explains the enquiry flow, enquiry_fields provides the schema, and submit_enquiry performs the submission. The two describe tools are separated by subject and are not ambiguous.
Names are readable and consistently lowercase with underscores, but they mix conventions: calculate and submit_enquiry are verb-first, while calculator_describe, enquiry_describe, and enquiry_fields are noun-first metadata names. This is not chaotic, but the word-order inconsistency prevents a higher score.
Five tools is well-scoped for this Car Import Calculator site: one calculation action, one calculator metadata tool, and a two-step enquiry workflow supported by two metadata tools and one submission tool. No tool feels redundant, and the count is comfortably within the ideal range.
The implied domain is a car-import cost calculator with human-provider enquiries. The set covers calculation, calculator documentation, enquiry instructions, field schema, and the full two-step submission/confirmation flow, leaving no obvious dead-end or missing lifecycle step.