Skip to main content
Glama

list_documents

Read-onlyIdempotent

List documents in a jurisdiction with structured filters and pagination. Use this tool when: - The user wants to find legal content for a specific jurisdiction and optional filters - The user asks about available content for a portal name, title, section_title, url, status, repealed, publication_date and crawling_date - The user wants to filter content for type of authority, issuing authority, source identifier, source secondary identifier, tag

Parameters: 
- iso (required): Jurisdiction ISO code (e.g. "US").
- portal (optional): Portal name.
- limit (optional): Number of results to return.
- offset (optional): Number of results to skip.
- document_id (optional): Document ID.
- title (optional): Title.
- section_title (optional): Section title.
- url (optional): URL.
- last_updated (optional): Last updated date.

Returns:
- Contents list with title, section_title, publication_date, effective_date, expiration_date, date_of_enactment, date_of_last_amendment, date_of_repealed, date_of_decision, status, version, source_identifier, source_secondary_identifier, issuing_authority, type_of_authority, language, legal_link, repealed, metadata, summary, tags, source_keywords, crawling_date, portal, portal_name, last_updated
- Only returns content that has crawled data

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
isoYesFilter by Jurisdiction ISO code (e.g. 'US')
tagNoFilter by tag
urlNoFilter by URL
langNoFilter by language
limitNoNumber of results to return
titleNoFilter by title
offsetNoNumber of results to skip
portalNoFilter by portal name
statusNoFilter by status
versionNoFilter by version
repealedNoFilter by repealed status
document_idNoFilter by document ID
last_updatedNoFilter by last updated date
crawling_dateNoFilter by crawling date
section_titleNoFilter by section title
effective_dateNoFilter by effective date
file_data_onlyNoReturn file data only
last_amendmentNoFilter by last amendment date
expiration_dateNoFilter by expiration date
date_of_decisionNoFilter by date of decision
publication_dateNoFilter by publication date
date_of_enactmentNoFilter by date of enactment
issuing_authorityNoFilter by issuing authority
source_identifierNoFilter by source identifier
type_of_authorityNoFilter by type of authority
source_secondary_identifierNoFilter by secondary source identifier

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the behavioral detail that it 'only returns content that has crawled data', which is not in annotations. It does not contradict annotations and provides additional context about output restrictions.

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?

The description is well-structured with clear sections and front-loaded purpose. It lists parameters and return fields efficiently, though it repeats schema parameter descriptions, adding some redundancy. The length is justified by the tool's complexity (26 params, no output schema).

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 complex tool with no output schema, the description provides a comprehensive return-field list and the crawled-data restriction, which are essential. It also gives usage conditions. It lacks details like default limit/offset values, ordering, or interaction between filters, but these are not critical for correct invocation. The description is sufficient for an agent to call the tool appropriately.

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 description coverage is 100%, so all 26 parameters are already documented in the schema. The description repeats these parameter meanings without adding new semantics like date formats, value constraints, or default behaviors. It does list return fields (valuable since no output schema exists), but that is output semantics, not parameter semantics. Baseline 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 states a clear verb ('List'), resource ('documents'), and scope ('in a jurisdiction with structured filters and pagination'). It distinguishes itself from sibling list_* tools (which list authorities, categories, etc.) and get_* tools (which retrieve specific documents) by focusing on document listing with filters.

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 'Use this tool when' section provides explicit conditions covering user intents and filter scenarios, making when-to-use clear. It lacks an explicit 'when not to use' or named alternatives, but the conditions are specific enough to guide selection without ambiguity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.