Rechtsinformationen Bund DE MCP Server

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully explains the data source (rechtsinformationen.bund.de), result format (ECLI-based URLs), and URL construction pattern with concrete examples. It does not mention rate limits or authentication requirements, leaving minor gaps for a read-only search tool.

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?

The description uses clear markdown structure with headers and bullet points that make it scannable. While lengthy, every section serves a distinct purpose: scope definition, technical details (URL construction), usage guidance, domain reference (court list), and parameter summary. The 'SECONDARY TOOL' label is appropriately front-loaded.

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?

Given the lack of output schema, the description adequately covers the tool's purpose, data source, parameter semantics (including domain-specific court codes), and result URL format. It could be improved by describing the actual result structure/fields returned, but the ECLI URL explanation provides sufficient context for a search tool.

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 100%, establishing a baseline of 3. The description adds significant domain value by listing common court abbreviations (BGH, BVerfG, etc.) and clarifying document types. However, it contradicts the schema regarding the default value for 'limit' (description states 10, schema specifies 5), which creates ambiguity for the agent.

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?

The description clearly identifies the tool as searching German court decisions (Rechtsprechung) from federal courts via rechtsinformationen.bund.de. It explicitly distinguishes itself from siblings by labeling itself as a 'SECONDARY TOOL' and stating it should be used after 'intelligente_rechtssuche' for initial queries, making the specific scope unambiguous.

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?

Provides explicit 'When to use' criteria with four specific scenarios (follow-up searches, case-law-only results, specific court filtering, document types). The 'Usage Priority' section gives clear routing instructions: 'For initial queries → Use intelligente_rechtssuche first' and 'For court-specific searches → Use this tool', directly addressing sibling tool selection.

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