Own vs Charter: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not a...
Scored across 6 tools
The checker tools are mostly distinct, though checker_tree overlaps with checker_start/checker_answer since it exposes the full question tree. The enquiry tools have clearly separate purposes: describing the process, listing fields, and submitting. Descriptions help resolve the remaining ambiguity.
All names use snake_case and are grouped by checker_ and enquiry_ prefixes. However, submit_enquiry follows a verb_noun pattern while the others are noun_verb or prefix-noun, a minor deviation.
Six tools are well-scoped for two focused workflows: a three-tool decision guide and a three-tool enquiry submission flow. There is no unnecessary bloat or missing count.
The decision guide covers starting, answering step-by-step, and viewing the full tree. The enquiry flow covers description, field discovery, and a two-step submission with consent and confirmation. No obvious gaps for the stated domain.
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 Own, fractional, jet card or charter decision guide.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It states only that this is the first question, not what invoking it does such as presenting a question, initializing state, or returning choices, and it does not mention side effects or follow-up 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, compact sentence with no wasted words or repeated schema content. It is front-loaded with the tool's role and the decision-guide context.
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 starter tool, the entry-point context is present, and sibling names hint at the surrounding workflow. However, with no output schema and no annotations, the description should have said what the agent receives after calling or what the next step is; that is missing.
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 describes them completely, so there is nothing for the description to add. The baseline of 4 applies because no parameter documentation is needed.
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 tool as the entry point to a specific decision guide, 'Own, fractional, jet card or charter', which makes its role clear from the name and title. It does not use a strong action verb or explicitly contrast with checker_answer/checker_tree, so it stops 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?
No explicit guidance is given about when to call this tool versus checker_answer, checker_tree, or the enquiry_* siblings. The phrase 'first question' implies it should be used before the rest of the flow, but the description leaves that inference to the agent.
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 Own, fractional, jet card or charter 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 provided, the description carries the full burden of behavioral disclosure. It states that the tool contains every question, option, and verdict, but it does not disclose the response format, whether this is a static read-only retrieval, or how much data will be returned. It also does not clarify whether this is the underlying data structure or an interactive step-through flow.
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 one compact sentence and wastes little space. The opening title 'The whole decision tree' immediately communicates scope, and the description elaborates with the specific content categories. A slightly more action-oriented opening would improve it, but it is still efficient.
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 conveys the main content of the tool reasonably well. However, it does not clarify how this tool relates to the sibling checker tools or what an agent should expect in terms of invocation flow, leaving some ambiguity about whether this returns raw data or an interactive prompt sequence.
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 there is little for the description to add to parameter semantics. The baseline for a parameterless tool is 4, and the description appropriately focuses on what the tool provides rather than on input arguments.
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 complete decision tree covering 'Own, fractional, jet card or charter' options, including all questions, options, and verdicts. It lacks a direct verb like 'retrieve' or 'return', and it does not explicitly distinguish itself from the sibling checker tools, but the scope is concretely specified.
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 'for reasoning end to end' implies the intended use case of walking through the entire decision tree rather than a single step. However, there is no explicit guidance about when to prefer this over checker_answer or checker_start, and no exclusions or alternative conditions are stated.
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 Own vs Charter: 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 behavioral burden and does so well: it explicitly states that the enquiry process is free, involves no purchase/order/payment, and does not guarantee a quote. It also discloses what information will be returned, including recipient, consent wording, and confirmation mechanics.
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 concise, front-loaded with "Read first," and every clause adds useful information: the purpose, the non-transactional nature, the free guarantee, and the returned content. No filler or redundant repetition of the tool name or title.
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 does a good job explaining what the agent will get: recipient details, consent wording, and confirmation method. It does not define the Own vs Charter distinction, but this is likely part of the tool's output content, so the description is reasonably complete for its low complexity.
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 with 100% coverage, so there is no parameter information the description needs to add. The baseline of 4 applies here because nothing is missing.
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 purpose: it describes what submit_enquiry does, distinguishing between Own and Charter, and explains that no purchase or payment occurs. It also specifies the returned content (who receives details, consent wording, confirmation method), making the tool's role unambiguous and distinct from actually submitting an enquiry.
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" is an explicit usage directive that positions this tool as the prerequisite before using submit_enquiry. The description implicitly tells the agent to consult this before acting, though it does not explicitly mention when to prefer or avoid the sibling checker/fields 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 Own vs Charter 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 does reveal what data will be returned and that the output keys feed into submit_enquiry, but it does not explicitly state that the tool is read-only, how errors behave, or what happens if the enquiry has no fields.
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 only two sentences, front-loads the core purpose, and contains no filler or repetition. Every clause adds value, and the connection to submit_enquiry is placed at the end as a practical tip.
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 is sufficiently complete. It lists exactly what information will be returned and explains how that information should be used by submit_enquiry. There is no missing context that would prevent an agent from invoking it 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 and the schema confirms this, so the baseline is 4. The description adds no parameter details because none are needed, and its mention of using field keys for submit_enquiry is about output semantics rather than 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 states the resource as 'Every field of the Own vs Charter enquiry' and enumerates the returned metadata (key, label, type, required, help text, allowed options). It is specific and actionable, though it does not explicitly differentiate itself from the sibling enquiry_describe, so it stops 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 instruction 'Pass answers to submit_enquiry keyed by field key' gives useful context about how the output should be used. However, it does not explicitly state when to use this tool instead of alternatives, nor does it mention any exclusions or prerequisites.
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 Own vs Charter — 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 relevant aviation advisers or brokers, chosen by Own vs Charter, 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 relevant aviation advisers or brokers, chosen by Own vs Charter, 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: it discloses validation behavior, the exact step-1 return payload, the two-phase commit requiring a token, the downstream side effect (contact details sent to up to three advisers/brokers who may contact the person directly), and the double-opt-in email link that must be clicked before any provider sees it.
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 critical 'NOT a purchase' framing, then cleanly divided into Step 1 and Step 2. It is long, but the length is justified by a genuinely two-phase tool; the only waste is the full consent sentence, which largely duplicates the consent parameter description in the schema.
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 and none is needed, since the description enumerates what step 1 returns (summary, consent line, confirmation token). With no annotations, it compensates by covering side effects, human consent requirements, and the confirmation-email gate.
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% and every parameter is already documented there, so the baseline is 3. The description earns an extra point by explaining the temporal relationship between parameters: 'confirmation' is only supplied on the second call and only after the person has approved the summary, which the schema does not convey.
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 (submits) and resource (an enquiry to Own vs Charter) and immediately rules out the two most likely misreadings with 'NOT a purchase, NOT a guaranteed quote.' The reference to enquiry_fields for the answer keys orients the agent relative to its siblings.
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: step 1 with answers + consent=true, step 2 only if the person agrees, with the same answers plus the returned token. It also names the prerequisite sibling call (enquiry_fields) and the human-approval gate that selects step 2.
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 a relevant aviation adviser or broker, who'll contact me directly."New value: +"true only when the person has agreed to: Send my contact details to up to three relevant aviation advisers or brokers, chosen by Own vs Charter, 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_enquiryCharter vs Own: the site's own MCP server — calculator, enquiry (enquiry = a human handoff, not...
Broker vs Advisor: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not...
Eligible By Descent: the site's own MCP server — checker, enquiry (enquiry = a human handoff,...
Class Q Checker: the site's own MCP server — checker, enquiry (enquiry = a human handoff, not a...
Add one secure layer between your agents and this server.