Search Bundestag printed papers (motions, minor interpellations) by keyword, type and date with authors and PDF.
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "search_documents"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| doc_type | No | ||
| from_date | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that results include authors and PDF links, but says nothing about pagination behavior despite a limit parameter, nor about auth needs, rate limits, or result ordering. A search tool that returns PDFs with no pagination note leaves a real gap.
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?
A single, front-loaded sentence that packs verb, resource, domain clarification, search dimensions and return content with no wasted words. Slightly dense, but structurally sound and well ordered.
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 4-parameter search tool with no annotations, no output schema and 0% schema description coverage, one sentence is thin. Date syntax, doc_type values, pagination via limit, and the distinction from sibling search tools are all 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?
Schema coverage is 0%, so the description is the only source of parameter meaning. It maps three search dimensions (keyword, type, date) onto query, doc_type and from_date, which adds genuine value, but the limit parameter is unaddressed and date format/expected doc_type values are left unspecified.
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 (Search) plus the resource (Bundestag printed papers) and even resolves the domain jargon with examples (motions, minor interpellations). This clearly distinguishes it from siblings like search_speeches or search_lobby_register, though it does not name those alternatives explicitly in the body.
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 description lists search facets (keyword, type, date) but gives no when-to-use guidance, no exclusions, and no routing to alternative search tools. An agent gets no help deciding between this and search_speeches or search_poll_archive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.