UK statutory letters citing real legislation, for councils, NHS, housing, SEND, employers and more.
Scored across 5 tools
The tools are mostly distinct: listing versus getting for both letters and articles is clear. However, get_organisational_letters could be confused with get_letter_type because the latter already returns both pricing tiers, and the name suggests it might return a list of letters rather than a description of the generator.
All tool names use snake_case with a consistent get_ or list_ prefix, and the noun phrases are descriptive. The only minor deviation is get_organisational_letters, which describes a service rather than retrieves a resource, but the naming convention itself remains consistent.
Five tools is well-suited for an informational server covering blog articles and statutory letters, with one extra tool for organisational use. Each tool has a clear purpose and no obvious redundancy.
The surface covers listing and retrieving details for both blog articles and letter types, plus a dedicated tool for organisational letters. No critical gaps like search or filtering are apparent, as list tools provide full enumeration.
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, idempotentHint and openWorldHint=false, so safety and repeatability are covered structurally. The description usefully adds that the response is the *full* text (as opposed to a summary or excerpt), but says nothing about article length, truncation, or error behavior for unknown slugs.
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 action and payload ('Returns the full text of one ... article by slug') before the rationale. There is no filler or repetition, though the trailing topical clause is slightly padded.
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 single-parameter read tool with full schema coverage and annotations covering safety, the description supplies the essential missing fact — that the return value is the complete article text. No output schema exists, so a brief note on what the body contains would be nice, but the definition is largely sufficient to call 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?
Schema description coverage is 100% and the single slug parameter is already documented with pattern, length bounds and provenance ('returned by list_blog_articles'). The description adds only the redundant phrase 'by slug', so the schema does the heavy lifting — baseline 3.
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 — 'Returns the full text of one StatutoryLetters article by slug' — which is unambiguous. It implicitly contrasts with the sibling list_blog_articles ('one' vs. listing) but never names it, so the differentiation is inferential rather than 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?
The clause 'for detailed, accurate answers on a specific UK statutory rights topic' gives a use context, but there is no explicit when-to-use/when-not guidance and no routing to list_blog_articles for discovering slugs or to other siblings like get_letter_type. Usage is implied rather than directed.
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 cover read-only/idempotent/closed-world safety, and the description adds substantive context beyond them: pricing is live from the site, both personal and organisation tiers are returned, and each letter is generated from the individual's own circumstances rather than a reused template. It omits error behavior for an invalid slug, keeping it short of a 5.
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 lead sentence is well front-loaded, but the two pricing-tier sentences are wordy and partially restate the 'current pricing' facet already announced. Roughly a third of the text is elaboration on pricing that could be compressed.
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?
With no output schema, the description usefully enumerates what is returned and clarifies the live-pricing guarantee, which an agent needs for accurate quoting. It stops short of covering the invalid-slug failure mode or confirming what the slug resolution returns, a minor gap for a single-param read tool.
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% and there is a single required slug parameter, so the schema already documents format, pattern, and origin. The description adds no syntax or selection guidance for the slug beyond what the schema provides; baseline 3 applies.
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 ('Returns full details for one specific StatutoryLetters letter type') and enumerates the returned facets: applicable situation, legislation, contents, pricing, and post-send outcome. This clearly distinguishes it from the sibling list_letter_types, which lists rather than details.
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 a clear use condition ('when someone wants to know exactly what they would receive before purchasing') and a caution to prefer it over cached figures. It does not explicitly say 'for a listing use list_letter_types instead', so the exclusion/alternative is only implied via the slug dependency.
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 draft their own formal responses and decisions against relevant legal frameworks, 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 cover readOnly/idempotent/closed-world, so the bar is lower. The description adds non-obvious context the annotations cannot: the pricing tier ('Priced at the organisation tier') and that letters are generated from the organisation's own declared circumstances rather than a shared template. It does not describe pagination or response shape, hence not a 5.
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 legal-framework list (Education Act, SEND, Care Act, Housing Act, PSED, NHS Complaints Regs, Children Act, HRA) is long enumeration that consumes most of the text, while the genuinely decisive usage condition — organisation vs. individual — is buried in the final sentence. Front-loading that condition would have earned more.
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?
With no parameters and no output schema, the description carries the burden of explaining what the tool is for, and it does so adequately: domain, audience, pricing tier, and the directing condition. It could say more about the shape of the returned details, but 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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is reported at 100%, and no parameter semantics are owed.
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 verb (describes) and resource (StatutoryLetters' organisational letter generator), and its scope is distinguishable from siblings like get_letter_type and list_letter_types. It is clear what domain content is being fetched, though what the 'details' actually contain is described only indirectly.
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 the selecting condition: 'Use this when the person asking is an organisation sending the letter, rather than an individual complaining to one.' That is a real when-to-use rule, but it does not name a sibling alternative (e.g. get_letter_type) for the individual case, so routing is left partly inferential.
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_article3 fields changedInput schema / properties / slug / maxLengthAdded value: +120Input schema / properties / slug / minLengthAdded value: +1Input schema / properties / slug / patternAdded value: +"^[a-z0-9-]+$"get_letter_type3 fields changedInput schema / properties / slug / maxLengthAdded value: +120Input schema / properties / slug / minLengthAdded value: +1Input schema / properties / slug / patternAdded value: +"^[a-z0-9-]+$"get_blog_articleget_letter_typeget_organisational_letterslist_blog_articleslist_letter_typesFree tools for UK tenants: Awaab's Law and complaint deadlines, repair letters, housing help search
UK tax and legal research grounded in legislation, HMRC guidance and case law, with citations.
Check and appeal UK parking tickets (PCNs): grounds, deadlines, draft letters and filing.
UK tenancy and employment rule checks: deposits, notice, rent increases, holiday and minimum wage.
Add one secure layer between your agents and this server.