UK Business Tools - Ledgerhall

Get Legislation Table of Contents

law_legislation_get_toc

Read-onlyIdempotent

USE THIS TOOL WHEN you have a known Act / SI and want the structural table of contents (parts, chapters, sections, schedules).

Returns structural elements with XML id and title, e.g. 'section-47: Definitions'. AFTER calling, pass the numeric section identifier (use '47', NOT 'section-47') into legislation_get_section for full text.

Large statutes (Companies Act 2006 has many hundreds of items) are paginated via offset/limit. Check has_more and total_items.

Alternative: call read_resource(uri="legislation://{type}/{year}/{number}/ toc") for the full TOC as a newline-separated id: title string (no pagination). Use this tool when you need the structured response with offset / limit / has_more for stepping through large statutes.

Input Schema

TableJSON Schema

Name	Required	Description
`type`	Yes	Legislation type code: 'ukpga' (Acts), 'uksi' (SIs), 'asp' (Scottish Acts), 'nia' (NI Acts). Use the value from legislation_search results.
`year`	Yes	Year of enactment
`limit`	No	Maximum items to return in this call (default 200, max 1000). Raise only when you need a larger slice in one response. Check has_more and total_items to know if further pages exist.
`number`	Yes	Chapter or SI number
`offset`	No	Number of items to skip from the flattened TOC. Use with limit to page through very large statutes like the Companies Act 2006 (1300+ items).

Output Schema

TableJSON Schema

Name	Required	Description
`type`	Yes	Legislation type code echoed from the request
`year`	Yes	Year of enactment echoed from the request
`items`	No	TOC entries in XML document order, formatted as '<id>: <title>', e.g. 'section-47: Definitions'. When calling legislation_get_section pass only the numeric part ('47', not 'section-47').
`limit`	Yes	Page size applied after offset
`number`	Yes	Chapter or SI number echoed from the request
`offset`	Yes	Offset applied to the full TOC item list
`has_more`	Yes	True if more items remain beyond offset+returned
`returned`	Yes	Number of items in this response
`total_items`	Yes	Total structural items parsed from the XML, before offset/limit. Compare to `returned` and `has_more` to decide whether to paginate.

TDQS

A4.9/5.0

Behavior5/5

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

Annotations cover read-only/idempotent safety, but the description adds concrete behavior: the return format ('XML id and title'), pagination semantics with offset/limit and has_more/total_items, and the specific example of Companies Act 2006. It also clarifies the id format ('section-47' vs '47'), which is valuable beyond 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.

Conciseness5/5

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

Four neatly separated paragraphs front-load the core purpose, then add return details, pagination guidance, and an alternative. Every sentence carries meaningful information; there is no filler or repetition, making it appropriately sized for a tool with 5 parameters.

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

Completeness5/5

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

Given the output schema exists, return values need no further explanation. The description covers key operational aspects: pagination with has_more/total_items, the alternative read_resource path, and chaining to legislation_get_section. This is comprehensive for a TOC retrieval tool.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description supplements by explaining how offset/limit paginate through large statutes, and that the type code comes from legislation_search results. While not essential given the rich schema descriptions, it adds practical usage context without redundancy.

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 opens with 'USE THIS TOOL WHEN you have a known Act / SI and want the structural table of contents', clearly specifying the action (get TOC) and resource (known Act/SI). It distinguishes from the sibling tool law_legislation_get_section and the alternative via read_resource, making its unique purpose unmistakable.

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

Usage Guidelines5/5

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

Explicitly states when to use ('when you have a known Act / SI') and provides a direct alternative (read_resource) with a comparison of structured vs. string output. Also instructs the agent to pass the numeric section identifier to legislation_get_section after calling, giving clear next steps and exclusions.

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

All UK Business Tools - Ledgerhall tools Inspect

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

A4/5.0

Disambiguation4/5

Tools are well-grouped by domain prefixes (dd_, gov_, law_, prop_) with clear descriptions that differentiate them. However, there is minor overlap, e.g., dd_search could be used instead of individual searches, and dd_fetch versus dedicated profile tools might cause confusion.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with domain-specific prefixes (dd_, gov_, law_, prop_). Names are descriptive and predictable, e.g., dd_charity_search, gov_govuk_search, law_bills_search_bills.

Tool Count4/5

70 tools is high but justified by the broad scope covering due diligence, government, legal, and property domains. Each domain has a reasonable number of tools (about 15-20 each). The count is on the upper end but still manageable.

Completeness5/5

The tool set is comprehensive across all domains: full CRUD for companies and charities, detailed legal research (cases, legislation, parliament, citations), property data (EPC, planning, price paid, rentals), and government information. No obvious gaps for the intended use cases.

Resources

Need Help?