Shift Pattern Generator: the site's own MCP server — calculator, enquiry (enquiry = a human...
Scored across 5 tools
Each tool has a clearly distinct purpose: calculate executes the calculator, calculator_describe documents its inputs/outputs, enquiry_describe explains the enquiry process and consent, enquiry_fields lists the enquiry schema, and submit_enquiry performs the submission. The descriptions make boundaries explicit, so an agent can easily select the right tool without confusion.
The names mix several patterns: a standalone verb (calculate), noun_verb forms (calculator_describe, enquiry_describe), a noun_noun form (enquiry_fields), and a verb_noun form (submit_enquiry). While all use snake_case, the inconsistent ordering of verb and noun reduces predictability.
Five tools is well-scoped for a calculator and enquiry submission workflow. Each tool earns its place with a unique role, and the count is neither too thin nor bloated for the domain.
The core workflow is covered: run the calculator, understand its inputs, learn the enquiry process, list fields, and submit an enquiry. Minor gaps exist (e.g., no tool to check enquiry status or update/cancel an enquiry), but agents can work around them for the primary use case.
Run the Shift pattern generator calculator: Cycle length in days; Average working hours a week; Hours a week under the 48 hour average limit; Crews needed to cover the operation. Missing inputs fall back to their documented defaults.
| Name | Required | Description | Default |
|---|---|---|---|
| onDays | No | Days on in one cycle | |
| offDays | No | Days off in one cycle | |
| nightWork | No | Does the pattern include night work? | night |
| coverHours | No | Hours a day the operation must be covered | |
| shiftHours | No | Paid hours in one shift |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It does add one meaningful trait — missing inputs silently fall back to documented defaults — and implies a pure computation with no side effects. However, it never explicitly states the operation is read-only/non-persistent, nor what happens on invalid input, even though one parameter is an enum and all values have bounded ranges.
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 tight sentences, front-loaded with the imperative verb and resource name. The semicolon-delimited output list is compact and scannable, and the defaults note earns its place as a real behavioral cue. Only minor reorganization (labeling the list as outputs) would improve it.
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 5-parameter calculator with no annotations and no output schema, the description covers the core: what is computed and how missing inputs are handled. But it leaves gaps that matter — the format/structure of the returned calculation results, whether the nightWork enum values materially change the outputs, and any edge-case behavior on out-of-range inputs.
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 description coverage is 100%, so the baseline is 3. The description adds some meaning beyond the schema by framing the parameters as inputs to four named calculations, which helps an agent anticipate what the numbers produce. This added value is modest, and 'Cycle length in days' could be misread as a requestable input rather than a computed output, slightly muddying the semantics.
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?
Uses a specific verb ('Run') plus a named resource ('Shift pattern generator calculator') and enumerates what it computes: cycle length, average working hours per week, hours under the 48-hour limit, and crews needed. This clearly states the tool's function and avoids tautology. It doesn't explicitly contrast with sibling 'calculator_describe', but the imperative 'Run' versus the sibling's 'describe' verb makes the distinction mostly inferable.
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 when-to-use guidance, no exclusion criteria, and no mention of alternatives — notably 'calculator_describe', which likely relates to the same calculator and would be a candidate for confusion. The only usage-adjacent note is that missing inputs fall back to defaults, which is a parameter behavior, not a tool-selection guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The inputs this calculator takes (with units, ranges and defaults), the outputs it returns, and the assumptions and tables behind it.
| 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 burden of explaining behavior. It conveys that the tool is informational, returning a description of inputs, outputs, assumptions, and tables rather than performing a calculation. Still, it does not explicitly state that no calculation is executed, whether the tool is safe/read-only, or what the response format will look like.
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 value: it tells the agent exactly what information the tool provides. No filler, no repetition of the schema, and every phrase contributes to understanding.
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 metadata tool, the description is sufficient: it names the inputs, outputs, assumptions, and tables the calculator is built around. It could be more complete by clarifying that this is the documentation/specification tool rather than the execution tool, but the sibling list and the 'describe' name make that reasonably inferable.
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, so the baseline is 4. The description does not need to explain tool parameters, and it appropriately focuses on what the described calculator itself takes and returns.
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 name and title clearly indicate this is the 'describe' counterpart to the calculator, and the description enumerates the specific content it provides: inputs with units/ranges/defaults, outputs, assumptions, and tables. It is clear about the tool's scope but does not use an explicit verb like 'returns' or 'describes,' and it does not directly contrast itself with the calculate sibling.
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: an agent would call this when it needs to understand the calculator's inputs, outputs, or underlying assumptions. However, there is no explicit guidance on when to choose this over the calculate tool or the enquiry_describe tools, leaving the routing decision to inference.
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 Shift Pattern Generator: 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 provided, the description carries the full disclosure burden. It clearly states what happens ('starts an enquiry with human providers who quote directly'), what does not happen ('Nothing is bought, ordered or paid; no quote is guaranteed'), and what the tool returns. This is strong, non-obvious behavioral context beyond the empty schema.
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 three sentences with no filler. 'Read first' front-loads the critical instruction, followed by a clear statement of function and key caveats. Every sentence contributes distinct, useful 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 zero-parameter, no-output-schema describe tool, the description fully covers what the tool does, what it returns, and its relationship to submit_enquiry. The caveats about purchase, quoting, and cost remove likely ambiguities. Nothing essential 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, so the baseline is 4 per the rubric. There is no parameter information to provide, and the description makes no misleading parameter claims. The empty schema and empty description are consistent.
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 uses a specific verb ('States plainly') and names the exact resource ('what submit_enquiry does on Shift Pattern Generator'). It also clarifies what the tool is not about ('not a purchase, not a guaranteed quote'), distinguishing it from transaction-like sibling tools. This is unambiguous and immediately actionable.
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' gives a clear directive to consult this tool before acting, and the description positions it as the explanatory companion to submit_enquiry. It does not explicitly name alternatives or exclusion conditions, but the intended context is obvious for a describe-style tool.
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 Shift Pattern Generator 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 must carry behavioral disclosure. It does disclose the response contents (field metadata and allowed options), but it does not explicitly state that this is a read-only, side-effect-free operation or describe any error/auth behavior. This is adequate but not rich.
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, no filler. The first sentence front-loads the core content and the second gives a practical usage hint. Both sentences earn their 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 zero-parameter, no-output-schema introspection tool, this is complete: it enumerates the returned field metadata and connects the tool to the next step, submit_enquiry. An agent knows what to expect and how to use 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 the baseline is 4 per the rubric. The description adds useful context about how the returned field keys should be used in submit_enquiry, but there are no parameters whose meaning needs elaboration.
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 (Shift Pattern Generator enquiry fields) and specifies exactly what is included: key, label, type, required, help text, and allowed options. It lacks an explicit action verb like 'list' or 'return', so it falls short of perfect, but the scope is unmistakable and the link to submit_enquiry helps disambiguate it from 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?
It gives clear context by telling the agent to pass answers to submit_enquiry keyed by field key, effectively showing when this tool is needed: before submitting. It does not explicitly exclude alternatives such as enquiry_describe or state when not to use it, so it earns a 4 rather than 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 Shift Pattern Generator — 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 payroll and HR service providers, chosen by Shift Pattern Generator, 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 payroll and HR service providers, chosen by Shift Pattern Generator, 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 that nothing is submitted until step 2, that a confirmation token is required, that the person must click an email link before any provider sees the data, and spells out the exact consent scope. This is unusually rich behavioral disclosure for a mutation-style 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?
Front-loaded with the key disambiguation, then a clean step-by-step. The only waste is the full consent string repeated verbatim from the schema's consent description, which inflates length without adding meaning.
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?
There is no output schema, and the description compensates by describing the step-1 return (summary, consent line, confirmation token) and the post-submission side effect (email link gating provider visibility). An agent has everything needed to drive both calls 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 the baseline is 3, but the description adds sequencing semantics beyond the schema: 'answers' must be keyed by field key from the enquiry_fields sibling, and 'confirmation' is only supplied on the second call after approval. That flow context is genuine added value, though the consent text is duplicated verbatim.
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 and resource ('Submits an enquiry to Shift Pattern Generator') and immediately disambiguates with 'NOT a purchase, NOT a guaranteed quote', which separates it from the calculator/description siblings. An agent can tell exactly what this does 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: step 1 with answers+consent to get a token, step 2 only 'if the person agrees' with the token added. It states the gating condition and the prerequisite, leaving nothing to inference.
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 rota and workforce scheduling suppliers, chosen by Shift Pattern Generator, 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 payroll and HR service providers, chosen by Shift Pattern Generator, 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 rota and workforce scheduling suppliers, who'll contact me directly."New value: +"true only when the person has agreed to: Send my contact details to up to three rota and workforce scheduling suppliers, chosen by Shift Pattern Generator, 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."calculatecalculator_describeenquiry_describeenquiry_fieldssubmit_enquiryDrivers' Hours Calculator: the site's own MCP server — calculator, enquiry (enquiry = a human...
Notice Period Calculator: the site's own MCP server — calculator, enquiry (enquiry = a human...
HGV Hours Calculator: the site's own MCP server — calculator, enquiry (enquiry = a human...
Leave Loading Calculator: the site's own MCP server — calculator, enquiry (enquiry = a human...
Add one secure layer between your agents and this server.