Broker vs Advisor: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not...
Scored across 6 tools
The checker_* trio (start, answer, tree) is clearly separated by entry point vs. step vs. full dump, and the enquiry tools split into read-metadata (describe, fields) and act (submit). The only mild overlap is between enquiry_describe and enquiry_fields, since both are read-first metadata tools, but their content (behavior/consent vs. input schema) is distinguishable.
Two prefix families (checker_ and enquiry_) exist, but the verb placement is mixed: submit_enquiry leads with the verb while enquiry_describe and enquiry_fields lead with the noun, and checker_tree is a noun rather than an action. Readable overall, but not a single predictable verb_noun pattern.
Six tools is well-scoped for a decision-guide plus enquiry-submission flow, with no obvious filler or redundancy. Each tool maps to a distinct step an agent would need.
The decision guide is fully covered (start, per-answer traversal, full tree) and the enquiry lifecycle is covered (describe, fields, two-step submit with token). Minor gap: no tool to check enquiry status or retrieve a previously submitted enquiry, though the emailed confirmation link partly compensates.
Given a question id and the chosen option (its choice index), return the next question or the final verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| choice | Yes | ||
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the key behavior—returning either the next question or a final verdict—but it does not mention whether the flow state is mutated, what happens for invalid choices, or any session/state requirements.
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, information-dense sentence. The title and description work together without repetition or filler, and the key input/output behavior is front-loaded.
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?
Adequate for a two-parameter tool: it names both inputs and describes the possible return. However, with no output schema and no annotations, it falls short of fully describing the response shape, error behavior, or what the caller should do with the returned next question/final verdict.
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 has 0% description coverage, so the description's clarification that `question` is a question id and `choice` is the chosen option's index is essential. It adds meaning beyond the raw property names and types, though it omits details like how to obtain valid question ids or bounds beyond minimum 0.
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 operation: given a question id and a choice index, return the next question or final verdict. This clearly differentiates it from sibling tools like checker_start or checker_tree, which have different roles in the flow.
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?
Usage is implied: use this when a user has answered a question and the flow should advance. However, it does not explicitly state when not to use it, what prerequisites exist (e.g., starting with checker_start), or how it relates to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The first question of the Which model should sell your business? decision guide.
| 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 must carry the full behavioral disclosure burden. It only says the tool is the first question; it does not state whether invoking it starts a session, returns a question, or alters any state. This leaves the agent uncertain about the actual effect of the call.
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, front-loaded sentence with no filler or redundancy. It efficiently communicates the tool's role without repeating the title or adding unnecessary content.
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 0-parameter tool, the description provides enough context to identify it as the starting point, but with no output schema and no annotations, it should say what the agent will get back or what happens when called. The missing return/state details are the main 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 and an empty input schema, so there is no parameter meaning for the description to add. The baseline of 4 for a 0-parameter tool 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 a specific resource, the 'Which model should sell your business?' decision guide, and its position as the first question, which helps distinguish it from checker_answer and checker_tree. It lacks a strong action verb like 'starts' or 'returns,' so it is clear but not maximally explicit.
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?
'First question' implies this is the entry point before the answer and tree siblings, but it never names alternatives directly or states when not to use them. The usage context is implied rather than explicitly instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every question, option and verdict of the Which model should sell your business? guide, for reasoning end to end.
| 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 clearly discloses the output scope (all questions, options, verdicts) and the purpose (end-to-end reasoning), making it evident this is a read-only content accessor. It does not discuss return formatting, but for a zero-parameter static data tool this is a minor omission.
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?
One clean sentence with no filler; the core content scope ('Every question, option and verdict') is front-loaded before the purpose clause. The title reinforces it without 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 parameterless tool with no output schema, the description is largely complete: it names the guide, the included elements, and the intended reasoning use case. The only missing piece is an explicit statement of return format, which is not critical given the simple static nature.
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 has zero parameters and 100% coverage, so the baseline is 4. There are no parameters for the description to elaborate, and the tool's no-input nature is consistent with 'the whole decision tree'.
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 exactly what the tool provides: every question, option, and verdict in the named decision-tree guide, for end-to-end reasoning. The 'whole decision tree' scope clearly distinguishes it from sibling tools like checker_answer and checker_start, which cover narrower steps.
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?
Use is implied by 'whole decision tree' and 'for reasoning end to end' — an agent can infer this is for full-tree context rather than a single step. However, no explicit when-to-use or when-not-to-use guidance is given, and alternatives like checker_answer or checker_start are not named.
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 Broker vs 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 full burden. It clarifies that the workflow involves no purchase, no payment, and no guaranteed quote, and it states that the tool returns specific explanatory content. This makes the informational/read-only nature evident, though it never explicitly says this tool itself has no side effects.
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?
Every sentence earns its place: read-first guidance, what the tool does, what it does not do, and what it returns. The description is front-loaded with 'Read first.' and remains compact with no 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, no-output-schema explanatory tool, the description is complete enough. It covers purpose, key caveats, and the nature of the returned information, so an agent can invoke it and understand the outcome.
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 schema description coverage is 100%, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, the description does not need to add parameter detail.
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 action: it 'states plainly what submit_enquiry does' and enumerates the return content ('who receives the details, the consent wording, and how the person confirms'). This clearly separates it from submit_enquiry, though it does not explicitly differentiate it from other sibling tools like enquiry_fields.
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' clearly signals that this tool should be used before acting, and the description positions it as the explanatory precursor to submit_enquiry. It provides context (Broker vs Advisor) but does not explicitly state when not to use it or name alternative tools.
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 Broker vs 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains what information the tool exposes and clarifies that actual submission happens through submit_enquiry, not this tool. It does not mention side effects or auth, but for a metadata/field-listing tool that gap is minor.
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 wasted words. The first sentence states the content of the returned fields; the second gives actionable guidance for using them. Information is front-loaded and scannable.
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 parameterless introspection tool, the description is complete: it enumerates the output contents and connects them to the related submission tool. The absence of an output schema is compensated by the explicit field list in the description.
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 baseline is 4. The description adds useful semantic context about the output fields, even though it does not need to document input 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 a specific resource: 'Every field of the Broker vs Advisor enquiry' and enumerates the field metadata (key, label, type, required, help text, allowed options). It lacks an explicit verb such as 'returns' or 'lists', but the meaning is unambiguous.
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?
It provides clear usage context by telling the agent how to use the output: 'Pass answers to submit_enquiry keyed by field key.' It does not explicitly name alternatives or say when not to use this tool, but the integration guidance is strong enough for practical selection.
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 Broker vs 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: "Send my contact details to up to three business brokers and M&A advisers, chosen by Broker vs Advisor, 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 business brokers and M&A advisers, chosen by Broker vs Advisor, 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 validation behavior, the returned summary/consent line/token, that submission triggers an email with a click-through link before any provider sees the data, and the exact scope of consent (up to three firms, chosen by the service, with opt-out). Nothing about the write is left opaque.
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 key negative scoping, and the step sequence is easy to follow. Slightly penalized because the full consent sentence is quoted verbatim in the description while also appearing in the schema's consent description — content duplicated rather than adding new information.
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 two-step, consent-gated submission with a nested answers object and no output schema, the description covers the full lifecycle: inputs, validation, returned artifacts, second call, and the downstream email-confirmation gate. An agent has everything needed to invoke both steps 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, but the description adds real meaning: answers are keyed by field key from the enquiry_fields tool, consent has a precise semantic (person has read and agreed to the quoted text), and confirmation is the step-1 token reused verbatim in step 2. It clarifies the two-phase use of the same parameter set.
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?
Specific verb (submits) plus resource (an enquiry to human providers) with an explicit negative scope: 'NOT a purchase, NOT a guaranteed quote.' This distinguishes it from the sibling enquiry_* tools, which describe/collect fields rather than submit.
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 unambiguous when-to-call-this sequencing: step 1 with answers+consent, then step 2 only after the person approves the returned summary, passing the confirmation token. It also states the pre-condition (show summary and consent line to the person) and the alternative path (do not call step 2 if they don't agree).
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: Happy for my details to go to business brokers and M&A advisers, who'll contact me directly."New value: +"true only when the person has agreed to: Send my contact details to up to three business brokers and M&A advisers, chosen by Broker vs Advisor, 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."checker_answerchecker_startchecker_treeenquiry_describeenquiry_fieldssubmit_enquiryBusiness Value Now: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not...
Own vs Charter: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not a...
HMO Licence Checker: the site's own MCP server — checker, enquiry (enquiry = a human handoff,...
Compare Answering: the site's own MCP server — compare, enquiry (enquiry = a human handoff, not...
Add one secure layer between your agents and this server.