enquiry_fieldsEvery field of the Notice Period Ireland 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 of explaining behavior. It does so by enumerating exactly what fields are returned and even notes conditional content ('the allowed options where there are any'). The read-only nature is implied by describing field metadata rather than any mutation, and no side effects are suggested.
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 two sentences, front-loaded with the core purpose, and every part earns its place. The first sentence defines the output shape, and the second connects it to the next action without any filler.
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 listing tool with no output schema, the description is complete: it specifies the domain, the fields included in the output, and how the output should be consumed. Nothing essential is missing for an agent to call this tool and use its result correctly.
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, so the description is not required to explain parameter meanings. It still adds helpful context by telling the agent that the returned keys are to be used as answer keys for submit_enquiry, which is more useful than the empty schema alone.
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 ('the Notice Period Ireland enquiry') and the content of the returned data: keys, labels, types, required flags, help text, and options. It stops short of a fully explicit verb like 'Returns' or 'Lists,' and it does not differentiate itself from the sibling tool 'enquiry_describe', so it loses the top score.
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 clear usage context: 'Pass answers to submit_enquiry keyed by field key,' which tells an agent how to use the output in a downstream call. It does not explicitly state when not to use this tool or contrast it with enquiry_describe or calculator_describe, so it lacks full alternative routing.
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.
calculate and submit_enquiry are clearly distinct in purpose. enquiry_describe and enquiry_fields both relate to the enquiry flow, but one provides plain-language behavior and consent context while the other gives the structured field schema, so the distinction is mostly clear.
Tool names are inconsistent: calculate is a bare verb, submit_enquiry is verb_noun, while enquiry_describe and enquiry_fields put the noun first. There is no shared convention across the set, making the naming feel fragmented.
Four tools for two core activities plus supporting documentation tools is a reasonable, well-scoped count. However, the stated tool count is five while only four tool definitions were provided, which introduces a small inconsistency.
The enquiry side is well supported with describe, fields, and a two-step submit flow. The calculator side is thinner: only calculate exists, with no equivalent describe or fields tool to expose input keys, defaults, and assumptions, making that half of the domain less discoverable.