Which M&A Advisor: the site's own MCP server — compare, enquiry (enquiry = a human handoff, not...
Scored across 6 tools
Each tool targets a clearly separate concern: comparison criteria, comparison options, the full comparison table, the enquiry explanation, the enquiry field schema, and submission. There is no real overlap or ambiguous boundary between any of the six tools.
The compare_* and enquiry_* prefixes give some structure, but the pattern is inconsistent: compare_criteria and compare_table use a verb-like prefix while enquiry_describe and enquiry_fields use noun-first naming, and submit_enquiry breaks the enquiry_ prefix convention. The names remain readable but do not follow a single predictable pattern.
Six tools is a well-scoped count for this server's purpose: three tools expose a comparison, two describe the enquiry form and flow, and one submits the enquiry. Nothing feels redundant or missing at the tool-count level.
The server covers the full apparent lifecycle for its purpose: users can inspect the comparison criteria, available options, the full comparison table, understand what submitting an enquiry does, see all required fields, and submit with a two-step confirmation. No obvious dead ends or missing operations exist for the stated domain.
The criteria and any filters of the Who may broker the sale of a US private company comparison.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects, return values, or any operational behavior. The agent has no idea what happens when the tool is invoked.
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 convoluted sentence that is not front-loaded with the most critical information. It is not concise in meaning; it is awkwardly phrased and does not prioritize clarity.
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?
Even though the tool is simple (no parameters, no output schema), the description is so vague that an agent cannot determine what the tool returns or how to use it. It lacks essential context about its purpose and expected 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?
The tool has zero parameters, so the schema is trivially complete and the description does not need to explain any parameters. Per the rubric, 0 params warrants a baseline of 4, and the description does not contradict this.
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 is a noun phrase ('The criteria and any filters of the ... comparison') rather than a clear verb+resource. It does not state what the tool does, such as returning or comparing criteria. It is vague and does not distinguish itself from sibling tools like compare_options or compare_table.
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 its siblings. There is no mention of context, alternatives, or exclusions, leaving the agent without any direction for selection.
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 Who may broker the sale of a US private company 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?
With no annotations, the description carries the behavioral burden. It discloses that filtering is optional and indicates the output fields, which is useful. However, it does not state what happens when no filter is provided, whether this is a read-only operation, or how filtering behaves with the filterKey/filterValue parameters.
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 compact sentence with no filler. It front-loads the core resource and adds filtering context efficiently, though the awkward phrase 'The options in...' detracts slightly from structure.
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?
Given no output schema, no annotations, 0% parameter coverage, and several sibling tools, the description is incomplete. It misses parameter semantics, usage distinctions, and behavioral defaults, leaving an agent to infer too much when deciding to invoke it.
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%, so the description must compensate for the undocumented filterKey and filterValue parameters. The phrase 'optionally filtered by a tag value' hints at filterValue's purpose, but filterKey remains unexplained, and the relationship between the two parameters is not clarified.
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 clearly: the options in a specific comparison, including the fields returned (name, what it is best for, tags). It is understandable and specific enough for an agent to know what the tool returns, though it lacks an explicit verb like 'list' or 'retrieve' and does not contrast with sibling tools.
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 a context ('Who may broker the sale of a US private company comparison') and mentions optional tag filtering, but it provides no guidance on when to choose this tool over siblings like compare_criteria or compare_table, and no exclusions or prerequisites.
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 Who may broker the sale of a US private company 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 burden of behavioral disclosure. It does state the output semantics: a complete cross of options by criteria. It does not mention filters, formatting, or side effects, but the tool's core behavior as a full-table display is conveyed.
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 sentence with the key scope placed first: 'each option's value on every criterion.' The trailing 'full table' is slightly redundant with the title, but there is no unnecessary elaboration.
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 table lookup with no output schema, the description conveys the essential return concept. It does not explicitly state that omitting 'option' returns all options, but that is fully covered by the schema, and the sibling tool names help clarify the table's role.
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 schema already fully describes the only parameter ('one option's name, else all'), and the description adds no meaningful operational detail beyond that. With 100% schema description coverage, the baseline 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 clearly identifies the tool's output as the full comparison table—every option's value on every criterion. The phrase 'full table' distinguishes it from sibling tools like compare_criteria and compare_options, though it lacks an explicit verb such as 'get' or 'return'.
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 'full table' phrasing implies this tool is for seeing the entire comparison rather than a single criterion or option. However, it never explicitly states when to use this tool instead of compare_criteria or compare_options, and it gives no exclusions or alternative 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 M&A Advisor: 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 behavioral burden. It transparently discloses what the tool returns: who receives the details, the consent wording, and how the person confirms. It also clarifies that no purchase or payment is involved, which is relevant context for the enquire-submission workflow.
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 'Read first', which immediately signals intent. It packs the key points into a few short sentences without excessive verbosity, though the title is a bit long and overlaps slightly with the description.
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 0-parameter, read-only descriptive tool with no output schema, the description adequately covers what the agent will get: the nature of the enquiry, free/non-binding status, and the returned details. It could be slightly more explicit about the output format, but it 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 is empty, so the 0-parameter baseline of 4 applies. There is no parameter information to add, and the description correctly focuses on the tool's output behavior instead.
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 the tool's role: it 'states plainly what submit_enquiry does' on Which M&A Advisor, and the title emphasizes it is about getting an enquiry with a human. It distinguishes itself from the sibling submit_enquiry by framing itself as an explanatory/read-first tool, though the verb 'describes' is only implicit.
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?
'Read first' gives a clear positional hint that this should be used before action, but it does not explicitly name when not to use it or directly compare against siblings like submit_enquiry or enquiry_fields. The usage guidance is implied rather than fully stated.
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 M&A Advisor 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?
No annotations are provided, so the description carries the full burden. It discloses the content (fields and attributes) but does not explicitly state that it is read-only, safe, or mention any potential side effects or limitations. It is not a contradiction, but it is not fully transparent about behavior.
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?
A single, dense sentence that front-loads the core purpose and lists the field attributes, then gives a direct usage hint. There is no wasted language; every part adds value.
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 retrieval tool with no parameters, no output schema, and no annotations, the description adequately covers what is returned and how to use it. It does not specify the exact output format (e.g., list vs. object), but given the simplicity, this is not a critical gap.
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 schema coverage is trivially 100%. Baseline for 0 parameters is 4. The description adds no parameter-specific semantics because there are none, but it does relate the output to submit_enquiry usage, which is contextually helpful.
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 that this tool retrieves every field of the 'Which M&A Advisor' enquiry, listing specific attributes (key, label, type, required, help text, options). This is a specific verb-like 'get' and resource, and it distinguishes itself from siblings like submit_enquiry and compare_* by focusing on field metadata.
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 a clear usage pattern: 'Pass answers to submit_enquiry keyed by field key.' This tells the agent when to use this tool (to obtain field structure before submitting) and ties it to a sibling. It does not explicitly say when not to use it, but the context is clear enough.
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 M&A Advisor — 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: "Happy for my details to go to M&A advisory firms, who'll contact me directly."
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | the person's answers, keyed by field key | |
| consent | Yes | true only when the person has agreed to: Happy for my details to go to M&A advisory firms, who'll contact me directly. | |
| 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 provided, the description fully discloses behavior: it is a two-step operation requiring consent and confirmation, it returns a summary and token in step 1, and it triggers an email verification step before submission. It also quotes the exact consent text and clarifies the consequence of proceeding. This exceeds typical annotation coverage and provides complete behavioral transparency.
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 lengthy but justified given the two-step process. It is front-loaded with purpose and exclusions, then structured with explicit Step 1 and Step 2 labels. Every sentence adds information; while it could be tightened, the verbosity is necessary for clarity and does not waste the agent's attention.
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?
The description covers all aspects needed for correct invocation: the two-step flow, consent requirements, the confirmation token, the email verification, and the explicit consent wording. It also explains what step 1 returns (summary, consent line, token). No output schema exists, but the description adequately describes the expected outcomes and side effects, making it complete for the agent.
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?
Although schema coverage is 100%, the description adds significant semantic value: it explains that answers are keyed by field keys from enquiry_fields, that consent must be explicitly agreed upon (quoting the exact text), and that confirmation is the token returned from step 1. This context is essential for correct usage and is not fully apparent 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?
The description clearly states the tool's function: submitting an enquiry to Which M&A Advisor, explicitly excluding purchase and guaranteed quotes. It also references the enquiry_fields tool for field keys, making it distinguishable from sibling tools. The two-step process is described with precision, leaving no ambiguity about the action.
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 explicit step-by-step usage instructions: when to call (step 1) and when to call again (step 2, only after consent). It also states exclusions ('NOT a purchase, NOT a guaranteed quote') and specifies that the person must receive and click an email link before providers see the enquiry. It lacks a direct contrast with sibling tools like compare_* but gives sufficient context for appropriate invocation.
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.
compare_criteriacompare_optionscompare_tableenquiry_describeenquiry_fieldssubmit_enquiryM&A Advisor Fees: the site's own MCP server — calculator, enquiry (enquiry = a human handoff,...
Accounting Firm Value: the site's own MCP server — compare, enquiry (enquiry = a human handoff,...
409A Providers: the site's own MCP server — compare, enquiry (enquiry = a human handoff, not a...
Broker vs Advisor: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not...
Add one secure layer between your agents and this server.