Skip to main content
Glama
Sign In
Fontes

Fontes

by ykarapazar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

search_legislation

Find laws, acts, and statutory instruments in a selected jurisdiction by query and filters; returns result IDs for retrieving the full legislation.

Instructions

Find laws, acts and statutory instruments in one jurisdiction.

Args: jurisdiction: code from list_jurisdictions, e.g. "nl", "gb". query: (may be empty "" when filters alone select) words from the title (or full text where the source allows), in the source's language, e.g. "huurprijzen woonruimte" (nl), "Companies Act 2006" (gb). nl also accepts a BWB-id directly. limit: results per page (default 20). page: 1-based page number. filters: optional jurisdiction-specific filters as a dict, e.g. {"current_only": false} for nl or {"search_in": "text", "doc_type": "ukpga"} for gb. See list_jurisdictions.

Date, type and similar narrowing belong INSIDE filters; any other top-level argument is rejected.

Returns a markdown list; each hit has the id to pass to the get_legislation_* tools.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "jurisdiction": "<jurisdiction>"
    },
    "name": "search_legislation"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNo
limitNo
queryNo
filtersNo
jurisdictionYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the load and does so reasonably: it discloses the return format (markdown list with ids), the paging model, and a hard behavioral constraint that unknown top-level arguments are rejected. It omits any auth, rate-limit, or error-mode detail beyond that rejection rule.

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

Conciseness4/5

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

Purpose is front-loaded, then a compact per-argument block with no filler. A couple of lines restate schema defaults (limit default 20, page 1-based), costing a little density but aiding readability.

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 5-param search tool with a 0%-covered schema and no annotations, the definition covers selection rules, per-param meaning, and the retrieval handoff. An output schema exists so return-value detail is less critical, though the markdown-list claim is stated rather than elaborated.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate and does: it defines jurisdiction as a code from list_jurisdictions with examples, explains query language and the empty-string case plus nl BWB-id acceptance, and documents limit/page semantics. The filters dict is explained with per-jurisdiction examples and the key rule that date/type narrowing must go inside it.

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

Purpose4/5

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

States a specific verb+resource ("Find laws, acts and statutory instruments") and scopes it to one jurisdiction, which cleanly separates it from search_caselaw by resource type. It stops short of naming an alternative tool, so differentiation is inferable 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.

Usage Guidelines4/5

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

Gives concrete usage context: jurisdiction codes come from list_jurisdictions, query may be empty when filters alone select results, and results feed the get_legislation_* tools. It also warns that narrowing belongs inside `filters` and other top-level args are rejected. No explicit when-not guidance versus other search tools, so not a 5.

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

Deploy Server

Other Tools