Which Field Service: the site's own MCP server — compare, enquiry (enquiry = a human handoff,...
Scored across 6 tools
Three compare_* tools cover distinct slices (criteria, options, full table), and three enquiry_* tools cover a linear describe→fields→submit flow. Some overlap between compare_options and compare_table exists, but descriptions make boundaries clear.
Mixed conventions: compare_* and submit_enquiry use verb_noun, while enquiry_describe/enquiry_fields use a noun prefix. Readable, but not fully predictable across the set.
6 tools is well-scoped for a comparison-plus-enquiry server. Each tool supports a clear part of the workflow without bloat.
Comparison surface covers criteria, options, and full table; enquiry flow covers description, fields, and submission. Minor gap: no standalone status or follow-up tool, but core lifecycle is complete.
The criteria and any filters of the Field service management software for UK multi-engineer operations comparison.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of explaining behavior. It only states criteria and filters as the subject matter and does not disclose whether the tool returns data, lists available options, or performs any other observable action.
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 short and places 'criteria' first, but it is an ungrammatical fragment with a long prepositional chain. It could be much clearer with a simple verb-headed sentence such as 'Returns the criteria and filters used for the comparison.'
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 tool with no output schema, the description should clearly state what the call yields. It gestures at criteria and filters, which is probably sufficient for a trivial invocation, but it does not clarify the output format or distinguish this tool from sibling comparison tools.
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?
This tool has zero parameters, so there is no parameter information for the description to add. The schema already covers everything needed, and the description does not need to compensate for missing parameter docs.
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 identifies the resource: criteria and filters in the context of a Field Service Management software comparison. However, it is a noun phrase without an explicit verb like 'lists', 'returns', or 'compares', so the tool's action remains somewhat vague.
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?
There is no guidance on when to use compare_criteria versus compare_options, compare_table, or the enquiry_* sibling tools. No alternatives or conditions are mentioned, leaving tool selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The options in the Field service management software for UK multi-engineer operations comparison (name, what it is best for, tags), optionally filtered by a tag value.
| Name | Required | Description | Default |
|---|---|---|---|
| filterKey | No | ||
| filterValue | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not state whether the tool is read-only, how filtering behaves, what the output looks like, or any side effects. This is insufficient for an unannotated tool.
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 single run-on sentence is not well-structured and front-loads little useful information. The title 'The options' contributes no value, and the description is vague enough that the clarity cost outweighs its brevity.
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 tool with no annotations, no output schema, and 0% parameter coverage, this description fails to explain return value, parameter semantics, or usage context. An agent would be guessing about filterKey and the overall behavior.
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?
Schema coverage is 0%, and the description only clarifies that filtering is by 'tag value' (likely mapping to filterValue). The purpose and format of filterKey remain entirely unexplained, leaving the agent to guess how to construct a valid call.
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 identifies a resource ('the options' in FSM software for UK multi-engineer operations) and hints at what it returns (name, best-for, tags), but it lacks an explicit verb. It reads as a noun phrase rather than stating an action like 'list' or 'compare', so an agent must infer the operation.
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?
No guidance is given on when to use this tool versus siblings like compare_criteria or compare_table. The optional tag filter is mentioned, but there is no context about when filtering is appropriate or what problem this tool solves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each option's value on every criterion of the Field service management software for UK multi-engineer operations comparison — the full table.
| Name | Required | Description | Default |
|---|---|---|---|
| option | No | one option's name, else all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only describes the table's content, not the tool's behavior. It does not state output format, whether omitting 'option' returns all options, read-only status, or any other operational trait.
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 a single concise sentence that front-loads the key scope (each option's value on every criterion) and ends with the clear 'full table' qualifier. There is no filler or redundancy.
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 one-parameter read tool, the description is minimally adequate: it conveys the table's content. But with no output schema and no annotations, it leaves the exact return shape and the effect of the optional 'option' parameter implicit, and it does not differentiate clearly from sibling tools.
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 input schema already documents the single 'option' parameter with 100% coverage. The description adds no extra meaning about the parameter's format, allowed values, or default behavior, so the baseline score of 3 is appropriate.
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 identifies the resource (the comparison table) and the exact granularity: every option's value on every criterion. The verb is only implicit (returns/provides), but 'the full table' makes the retrieval intent clear and helps separate it from sibling tools like compare_criteria and compare_options.
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 'the full table' implies this tool is for obtaining a complete option-by-criterion comparison, offering some usage context. However, it never explicitly says when to prefer this over compare_criteria or compare_options, nor does it mention any exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read first. States plainly what submit_enquiry does on Which Field Service: it starts an enquiry with human providers who quote directly. Nothing is bought, ordered or paid; no quote is guaranteed; it is free. Also returns who receives the details, the consent wording, and how the person confirms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden, and it does well by disclosing that nothing is bought, ordered, or paid, that no quote is guaranteed, and that the service is free. It also tells the agent what information is returned: who receives the details, the consent wording, and how confirmation happens.
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 compact and front-loaded with the most important instruction ('Read first') followed by the tool's informational purpose. It includes a few helpful specifics about return content without excessive verbosity, though the title already conveys some of the same 'not a purchase, not guaranteed' messaging.
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, no-output-schema descriptive tool, the description is complete: it specifies the operation it describes, the behavioral expectations, and what the response will convey. An agent has everything needed to call this tool correctly and understand the result.
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 parameter-level documentation is not needed. The schema covers this vacuously, and the baseline of 4 applies because there is nothing for the description to add.
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 a specific purpose: it 'States plainly what submit_enquiry does' on Which Field Service, framing itself as the descriptive counterpart to that action. It also clearly differentiates from the sibling submit_enquiry tool by emphasizing the outcome is an enquiry with human providers, not a purchase or guaranteed quote.
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 opening 'Read first' is explicit advice to use this tool before submit_enquiry, which is strong usage guidance for a descriptive companion tool. It does not mention the other sibling tools, but they are not direct alternatives to this one, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every field of the Which Field Service 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 parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It tells the agent that the tool returns a comprehensive field definition and that submission is handled by submit_enquiry, which implies this tool itself is read-only and non-mutating. It could be more explicit about side-effect-free behavior or output shape, but the description is reasonably transparent for a metadata-listing tool.
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 tight sentences with no filler. The first sentence enumerates exactly what is returned, and the second provides the key usage instruction. It is front-loaded and every phrase 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 metadata tool with no output schema, the description covers the essential content and its relationship to submit_enquiry. It could more explicitly describe the return structure (e.g., list vs object) or confirm the absence of side effects, but none of these are critical given the tool's simplicity and the presence of the sibling hint.
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 cannot add much parameter-level detail. It does add value by explaining that field keys from the output are the expected keys for submit_enquiry, which is semantically useful. This meets the 0-parameter baseline and adds a relevant cross-tool hint.
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 states what the tool exposes: every field of the enquiry with key, label, type, required flag, help text, and allowed options. It connects to submit_enquiry by saying answers should be keyed by field key, which helps distinguish it from the comparison-focused siblings. However, it lacks an explicit verb like 'lists' or 'returns', and it does not contrast with enquiry_describe.
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 instruction 'Pass answers to submit_enquiry keyed by field key' provides clear context and a concrete usage pattern. It implies this tool should be consulted to learn the field keys before submitting an enquiry. It does not explicitly state when not to use it or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submits an enquiry to Which Field Service — NOT a purchase, NOT a guaranteed quote. Step 1: call with the answers (keyed by field key from enquiry_fields) and consent=true; it validates and returns a summary, the consent line and a confirmation token — show the person the summary and the consent line. Step 2: only if the person agrees, call again with the same answers, consent=true and the confirmation token; the enquiry is then submitted, and the person receives an email with a link they must click before any provider sees it. Consent means the person has read and agreed to: "Send my contact details to up to three industry software suppliers, chosen by Which Field Service, who'll contact me directly. I'll be emailed each firm's name as my details go to it, and can stop any more firms getting them."
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | the person's answers, keyed by field key | |
| consent | Yes | true only when the person has agreed to: Send my contact details to up to three industry software suppliers, chosen by Which Field Service, who'll contact me directly. I'll be emailed each firm's name as my details go to it, and can stop any more firms getting them. | |
| confirmation | No | the confirmation token from step 1, after the person has approved the summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses the validation step, the confirmation-token gate, that submission triggers an email, that the recipient must click a link before any provider sees the data, and the verbatim consent text. These are exactly the side effects an agent must know.
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?
Front-loaded with the negative scoping, then the two steps in order. The embedded consent quote is lengthy but functionally required, since consent=true depends on the person agreeing to exactly that text. Slightly dense but every part 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?
No output schema exists, yet the description explains what step 1 returns (summary, consent line, confirmation token) and what happens after step 2 (email + link gate). For a nested-object, two-phase tool this is complete enough to call 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?
Schema coverage is 100%, so baseline is 3; the description adds value by tying 'answers' to field keys from enquiry_fields and clarifying that 'confirmation' is the token returned by step 1 and used only after approval. That sequencing context is not fully derivable from the 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?
States a specific verb+resource (submits an enquiry) and immediately scopes it negatively — 'NOT a purchase, NOT a guaranteed quote' — which separates it from transactional siblings. An agent can identify the tool without opening the schema.
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?
Gives an explicit two-step protocol: when to call with answers+consent, what step 1 returns, and that step 2 happens 'only if the person agrees'. It also cross-references enquiry_fields as the source of field keys, routing the agent to the correct sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
submit_enquiry1 field changedInput schema / properties / consent / descriptionPrevious value: -"true only when the person has agreed to: Send my contact details to up to three field service software suppliers and implementation partners, chosen by Which Field Service, who'll contact me directly. I'll be emailed each firm's name as my details go to it, and can stop any more firms getting them."New value: +"true only when the person has agreed to: Send my contact details to up to three industry software suppliers, chosen by Which Field Service, who'll contact me directly. I'll be emailed each firm's name as my details go to it, and can stop any more firms getting them."submit_enquiry1 field changedInput schema / properties / consent / descriptionPrevious value: -"true only when the person has agreed to: Happy for my details to go to field service software suppliers and implementation partners, who'll contact me directly."New value: +"true only when the person has agreed to: Send my contact details to up to three field service software suppliers and implementation partners, chosen by Which Field Service, who'll contact me directly. I'll be emailed each firm's name as my details go to it, and can stop any more firms getting them."compare_criteriacompare_optionscompare_tableenquiry_describeenquiry_fieldssubmit_enquiryWhich Field Software: the site's own MCP server — compare, enquiry (enquiry = a human handoff,...
Answering Service Picker: the site's own MCP server — compare, enquiry (enquiry = a human...
Compare Answering: the site's own MCP server — compare, enquiry (enquiry = a human handoff, not...
Compare Call Answering: the site's own MCP server — compare, enquiry (enquiry = a human handoff,...
Add one secure layer between your agents and this server.