enquiry_fieldsEvery field of the Industrial Flooring 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It does this well by stating exactly what data the tool exposes and noting that options are included only 'where there are any'. It does not describe response structure or potential edge cases, but the tool is a simple zero-parameter read operation.
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 with no filler. The first sentence states the tool's scope and content, and the second connects it directly to the downstream submit_enquiry workflow. Every sentence earns its 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 simple, zero-parameter, no-output-schema introspection tool, the description is nearly complete: it describes the returned field metadata and how to use it. The only notable gap is the lack of any mention of the sibling enquiry_describe, which could leave an agent unsure which tool to pick in a broader workflow.
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 the input schema is empty, so there is nothing to document. The description adds meaningful semantic context by explaining that the returned field keys are the ones to use when submitting answers to submit_enquiry, which is helpful despite there being no parameters.
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 Industrial Flooring Cost enquiry, and lists exactly what is returned (key, label, type, required, help text, options). It does not use an explicit verb like 'returns' or 'lists', and it does not distinguish itself from the sibling enquiry_describe, so it falls just short of a 5.
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 phrase 'Pass answers to submit_enquiry keyed by field key' implies that this tool should be used to discover valid keys before calling submit_enquiry. However, there is no explicit when-to-use/when-not-to-use guidance and no differentiation from enquiry_describe, so usage context is only implied.
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 clear, separate role: enquiry_describe explains the overall process, enquiry_fields provides the schema, and submit_enquiry performs the submission flow. There is no meaningful overlap between them.
All names use snake_case and reference the enquiry domain, but the pattern is mixed: enquiry_describe and enquiry_fields are noun-led while submit_enquiry is verb-led. This is readable but not a uniform verb_noun convention.
Three tools is a well-scoped set for a narrow enquiry-submission purpose. Each tool earns its place: overview, field definitions, and submission.
The tools cover the full flow needed for this domain: understand the service, retrieve the required fields, and submit with consent and confirmation. No update, delete, or status tools are necessary for this single-purpose server.