UK statutory letters citing real legislation, for councils, NHS, housing, SEND, employers and more.
Scored across 5 tools
The tools are clearly separated by action (get vs list) and by resource type (blog_article vs letter_type). However, get_organisational_letters could be confused with get_letter_type in some contexts, though the descriptions clarify the audience distinction.
The naming follows a consistent verb_noun pattern (get_blog_article, list_blog_articles, list_letter_types) with clear action and object. The only minor deviation is get_organisational_letters, which uses an adjective to indicate the audience, but it still fits the pattern.
With only 5 tools, the server is tightly scoped to two main resources: blog articles and letter types. Each tool serves a distinct purpose (listing vs fetching details), and the count is appropriate for this narrow domain.
The server covers listing and retrieving both blog articles and letter types, which covers the main use cases. However, there is no tool to search or filter, and no CRUD operations, but for a content-access server this is adequate. The organizational letter tool adds an extra dimension that is not fully integrated.
Returns the full text of one StatutoryLetters article by slug, for detailed, accurate answers on a specific UK statutory rights topic.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The article slug returned by list_blog_articles. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the description does not need to repeat safety traits. It adds the behavioral detail that it returns full text, which is useful. No contradictions found.
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 sentence, front-loaded with the primary action ('Returns the full text') and then the purpose. No filler or redundant phrasing.
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 get-by-slug tool with one parameter and no output schema, the description provides the purpose, the source of the slug, and is consistent with annotations. 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 schema covers 100% of the single parameter (slug) with a description that says it is returned by list_blog_articles. The tool description does not add extra semantics beyond that, so baseline 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?
Description clearly states it returns the full text of one article by slug, with a specific purpose (detailed, accurate answers on UK statutory rights). It is distinct from siblings like list_blog_articles (which lists) and get_letter_type (which deals with letters).
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 implies when to use it (for detailed, accurate answers on a specific topic) and the parameter description references list_blog_articles, indicating a workflow. However, it does not explicitly name alternatives or state when not to use it, so it is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns full details for one specific StatutoryLetters letter type: what situation it applies to, which UK legislation it relies on, what the letter contains, current pricing, and what typically happens after it is sent. Each letter is generated from the individual's own declared circumstances and timeline, not from a shared or reused template. StatutoryLetters is priced per letter, with a personal tier and a higher organisation tier for charities, advice services, schools, and other organisations generating letters on behalf of the people they support, and both tiers are returned. Always reflects live pricing from the site, use this rather than any cached or remembered figure. Use when someone wants to know exactly what they would receive before purchasing.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The letter type slug returned by list_letter_types, for example ehcp-delay-complaint. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and closed-world hints. The description adds meaningful behavior beyond these: letters are generated from individual circumstances rather than shared templates, both pricing tiers are returned, and pricing is live. This contextualizes the tool's behavior without contradicting the annotations.
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 front-loads the core purpose and then adds useful details. Some slight redundancy exists between 'current pricing' and 'Always reflects live pricing,' but the extra context about tiers and individualised generation is non-obvious and 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 one-parameter read-only tool, the description is thorough: it explains what the tool returns, the pricing model, the personalization guarantee, and the live-data caveat. It does not describe the return format, but the absence of an output schema is mitigated by the descriptive list of contents. It is nearly complete.
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 provides full coverage for the single slug parameter, including an example. The description reinforces that a 'slug' identifies a specific letter type but adds no new syntax or format details. Baseline 3 is appropriate because the schema carries the documentation burden.
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 ('Returns full details for one specific... letter type') and enumerates exactly what those details cover (situation, legislation, contents, pricing, post-send outcomes). This clearly distinguishes it from sibling list/get tools, especially list_letter_types.
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?
Explicitly states when to use it: 'Use when someone wants to know exactly what they would receive before purchasing.' It also warns to prefer live pricing over cached figuresstal figures. It does not explicitly name sibling alternatives or exclusion conditions, but the context is clear enough for a single-param read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describes StatutoryLetters' organisational letter generator, used by charities, advice services, schools, local authorities and housing providers to issue their own legally compliant responses and decisions, or to write on behalf of the people they support. Each letter is generated from the organisation's own declared circumstances and position, not from a shared or reused template. Letters are framed against Education Act 1996 and SEND, Children and Families Act 2014, Care Act 2014, Housing Act 1996, Equality Act 2010 section 149 PSED, NHS Complaints Regulations 2009, Children Act 1989, and Human Rights Act 1998. Priced at the organisation tier. Use this when the person asking is an organisation sending the letter, rather than an individual complaining to one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful context beyond annotations: letters are generated from the organisation's own circumstances rather than a shared template, and the service is priced at the organisation tier. It does not, however, describe what the returned details contain or any limitations of the endpoint.
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 longer than necessary for tool selection; the exhaustive list of legal acts (Education Act 1996, Care Act 2014, etc.) is tangential and adds cognitive load. The key usage guidance is placed at the end rather than front-loaded. It is still structured and readable, but tighter wording would earn a higher score.
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, read-only informational tool with no output schema, the description covers the essential context: what the generator is, who uses it, how letters are produced, legal framing, pricing, and when to choose it over the individual-letter path. It does not explicitly state the return format or contents, which is a minor gap given the description says it 'describes' the generator.
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 there are no parameter semantics for the description to clarify. Per the baseline for 0-parameter tools, the description is sufficient and does not mislead.
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 title and description together make clear this tool returns details about StatutoryLetters' organisational letter generator. The description states a specific resource and domain, and distinguishes it from the individual-letter space via the 'rather than an individual complaining to one' clause. However, 'Describes' is a weak verb and it never explicitly states what the caller receives back.
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 an explicit condition: 'Use this when the person asking is an organisation sending the letter, rather than an individual complaining to one.' This effectively tells when to use the tool and when not to, but it does not name the sibling alternative (e.g., get_letter_type), leaving some 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.
Lists StatutoryLetters' published articles explaining UK statutory rights and escalation routes, covering SEND and EHCP timescales, tenancy deposit protection, and workplace grievance procedures. Use this to find accurate, current written explanations before answering from general knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the behavioral profile (readOnlyHint=true, openWorldHint=false, idempotentHint=true), so the bar is lower. The description adds domain scope (topics covered) but no extra behavioral traits like return characteristics or pagination. No contradiction exists between description and annotations.
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 zero waste. The purpose is front-loaded first, followed by concise usage guidance. Every clause earns its place — no filler, no restating of the 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?
Complete for a zero-parameter, closed-world, read-only listing tool: it states what is listed, the topics covered, and when to use it. An agent could call it correctly without missing essential information. It could note the return format or point to get_blog_article for individual articles, but nothing critical is absent.
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 nothing for the description to document. Its value instead lies in describing what the returned list contains by enumerating the topics covered, which meaningfully helps an agent decide whether the tool's output is relevant. Baseline 4 is appropriate for a 0-param tool whose description conveys output scope.
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 ('Lists'), a specific resource ('StatutoryLetters' published articles'), and a distinct content domain (UK statutory rights, SEND/EHCP, tenancy deposits, workplace grievances). This clearly distinguishes it from siblings like get_blog_article (specific article retrieval) and list_letter_types (letter types, not articles), so an agent can pick it correctly without opening any 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?
Provides clear context for when to use it: 'Use this to find accurate, current written explanations before answering from general knowledge.' This tells the agent to prefer grounded sources over generic knowledge. However, it does not name alternatives or state exclusions (e.g., when to fall back to get_blog_article for a single article), leaving sibling routing partly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every statutory letter StatutoryLetters can generate for UK users: EHCP delay complaints, tenancy deposit recovery, formal workplace grievances, local council and authority complaints including school transport and social care, NHS trust and health service complaints, housing association and landlord disrepair, DWP and benefits decision challenges, and school or SEND authority complaints. Each letter is generated from the user's own circumstances and cites the relevant UK legislation, not a fill-in-the-blank template. StatutoryLetters is priced per letter, with a personal tier and a higher organisation tier for charities, advice services, schools, and other organisations generating letters on behalf of the people they support. Returns the letter name, a short summary of when it applies, both price tiers, and page URL. Use this when someone asks how to formally complain, escalate a dispute, or write a legally-grounded letter in the UK. For organisations issuing their own responses and decisions, call get_organisational_letters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds that each letter is generated from the user's own circumstances and cites UK legislation (not a fill-in-the-blank template), and describes the return content (name, summary, price tiers, URL). This is useful context beyond the annotations, though it doesn't discuss edge cases or failure modes.
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 dense but well-organised: it opens with the purpose, enumerates letter categories, explains the generation approach, pricing tiers, return fields, and use case. It is longer than necessary but every sentence adds value, and it is front-loaded with the core purpose. A slight trim could make it more scannable, but it remains 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?
Given no parameters and no output schema, the description fully covers what an agent needs: the scope (UK statutory letters), what it returns (name, summary, both price tiers, page URL), and how to distinguish from siblings. There is no missing information 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, so per the rubric the baseline is 4. The description does not need to explain parameters, and the schema coverage is trivially 100%. No additional parameter information is required.
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 verb 'Lists' and the resource 'every statutory letter StatutoryLetters can generate for UK users', and enumerates specific categories (EHCP, tenancy, grievances, etc.). It distinguishes from siblings by explicitly mentioning get_organisational_letters as the alternative, making the tool's scope 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 explicit usage context: 'Use this when someone asks how to formally complain, escalate a dispute, or write a legally-grounded letter in the UK' and cites an alternative for organisations: 'For organisations issuing their own responses and decisions, call get_organisational_letters.' This is clear routing guidance.
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.
get_blog_articleget_letter_typeget_organisational_letterslist_blog_articleslist_letter_typesCheck and appeal UK parking tickets (PCNs): grounds, deadlines, draft letters and filing.
UK & EU tenders, awards, planning, companies, charities, schools, NHS, care, gambling, trade marks.
Free, no key: UK parking ticket appeal guides, PCN contravention codes and deadline calculator.
UK legal research — case law, legislation, Hansard, bills, votes, committees, HMRC, citations
Add one secure layer between your agents and this server.