Skip to main content
Glama

Uk Gazette

by io.github.pipeworx-io

Gazette Deceased Estates

gazette_deceased_estates
Read-onlyIdempotent

Search UK deceased-estates notices in The Gazette (Trustee Act 1925 s.27 notices) — executors advertise a death so creditors and claimants can come forward before the estate is distributed. Used for probate research, tracing an estate, checking whether a death notice was placed, and finding the claim deadline. Filter by name, date of death, claim expiry date, or location. Example: gazette_deceased_estates({ name: "John Smith", died_after: "2026-01-01" })

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName of the deceased person
pageNoResults page, starting at 1
limitNoResults per page, 1-50 (default 10)
locationNoUK postcode or town/city name to search around (needs distance_miles, default 5)
died_afterNoEarliest date of death, YYYY-MM-DD
died_beforeNoLatest date of death, YYYY-MM-DD
distance_milesNoRadius in miles around location (default 5)
claim_expires_afterNoEarliest claim-expiry date, YYYY-MM-DD (find estates still open to claims by setting this to today)
claim_expires_beforeNoLatest claim-expiry date, YYYY-MM-DD

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds context about the legal notice type and claim deadlines, which aligns with annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences plus an example call. Every sentence adds value, front-loaded with purpose and use cases. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 9 parameters and no output schema, the description explains the legal context and use cases sufficiently. It covers what the tool does and why it's useful, though it could briefly mention the return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema documents all parameters. The description does not add extra semantics beyond the schema's field descriptions; it only provides example usage. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches UK deceased-estates notices under Trustee Act 1925 s.27, and lists specific use cases like probate research and tracing an estate. It distinguishes itself from sibling tools (e.g., gazette_insolvency_notices) by focusing on deceased estates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies the tool is used for probate research, tracing an estate, checking death notices, and finding claim deadlines. It provides clear context, though it does not explicitly mention when not to use it or call out alternative sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Uk Gazette toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation2/5

Many tools have overlapping purposes (e.g., ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded all serve similar query routing). Tools from unrelated domains (UK Gazette, Polymarket betting, AI visibility checks) are mixed together, making it hard for an agent to distinguish which tool to use for a given task.

Naming Consistency1/5

Naming is chaotic: some tools use descriptive phrases with underscores (gazette_deceased_estates, polymarket_arbitrage), others use generic verbs (remember, recall, forget), and some include version or mode indicators (ask_pipeworx_beta, scan_competitor_ai_presence). No consistent pattern across the set.

Tool Count2/5

With 36 tools, the server is overstuffed for its purported focus on the UK Gazette. The majority of tools (Polymarket, Pipeworx general, AI visibility, etc.) are unrelated to the server's name, making it feel like a bundling of many services into one, which is excessive for a coherent tool set.

Completeness2/5

For a server named 'Uk Gazette', there are only a handful of Gazette-specific tools (gazette_search_notices, gazette_insolvency_notices, etc.), while the rest cover unrelated domains. This leaves obvious gaps for Gazette-related tasks (e.g., no tool for searching particular notice types or filtering by edition), despite the large tool count.

Resources