Provides search capabilities for court decisions using Elasticsearch query syntax, allowing for complex queries against the entscheidsuche.ch legal database
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Entscheidsuche MCP Server search for recent Swiss Federal Court decisions on data protection violations"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Note : this is a legacy project, that was created on 21.07.2025. As of 25.04.2026 there is now an official entscheidsuche MCP server at https://github.com/entscheidsuche/entscheidsuche-mcp. This legacy project is for archive read only.
A Model Context Protocol (MCP) server for searching and accessing Swiss legal case law through the Entscheidsuche API. This server enables legal professionals to efficiently research court decisions from Swiss federal and cantonal courts.
Search Case Law (search_case_law): Search through Swiss court decisions using natural language queries
Get Document (get_document): Retrieve full document content in JSON, HTML, or PDF format
List Courts (list_courts): Get information about available courts and their document counts
Court Status (entscheidsuche://courts/status): Real-time information about court document collections
Legal Research (legal_research): Template for conducting comprehensive legal research
Case Analysis (case_analysis): Template for analyzing specific legal cases
Related MCP server: Legal Court MCP Server
Clone or download this project
Install dependencies:
npm installBuild the project:
npm run buildAdd the following to your Claude Desktop configuration file:
macOS/Linux: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"entscheidsuche": {
"command": "node",
"args": ["/absolute/path/to/entscheidsuche-mcp/build/index.js"]
}
}
}Test the server using the MCP Inspector:
npx @modelcontextprotocol/inspector node build/index.jsUse the search tool to find cases on specific topics:
"Datenschutz DSGVO" (Data protection)
"Arbeitsrecht Kündigung" (Employment law termination)
"Mietrecht Mietzinserhöhung" (Rental law rent increases)
The search supports Elasticsearch query syntax:
"exact phrase" for exact matches
field:value for field-specific searches
term1 AND term2 for boolean operations
Once you find a relevant case, use the signature and spider name to retrieve the full document:
Signature: e.g., "CH_BGer_2023_1C_123_2023"
Spider: e.g., "CH_BGer" (Swiss Federal Court)
This server interfaces with:
https://entscheidsuche.ch/_search.php - Elasticsearch search endpoint
https://entscheidsuche.ch/docs/ - Document repository
https://entscheidsuche.ch/status - Court status information
This tool provides access to publicly available Swiss court decisions through the Entscheidsuche service. Please note:
Always verify legal information through official sources
This tool is for research purposes only
Consult qualified legal professionals for legal advice
Respect the terms of service of entscheidsuche.ch
npm run build - Build the TypeScript project
npm run dev - Build and run the server
npm run watch - Watch for changes and rebuild
src/
index.ts # Main server implementation
build/ # Compiled JavaScript output
package.json # Project dependencies and scripts
tsconfig.json # TypeScript configurationFeel free to submit issues and enhancement requests. When contributing:
Follow the existing code style
Add appropriate error handling
Update documentation as needed
Test your changes with the MCP Inspector
MIT License - see LICENSE file for details.
Entscheidsuche.ch for providing the open API
Model Context Protocol for the MCP framework
Swiss courts for making decisions publicly available
Retrieve the full content of a specific legal document
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Document format to retrieve | json |
| signature | Yes | Document signature (e.g., CH_BGer_005_5F-23-2025_2025-07-01) | |
| spider | No | Court/spider name (e.g., CH_BGer). If not provided, will be extracted from signature |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Retrieve' implies a read operation, it doesn't disclose important behavioral aspects like authentication requirements, rate limits, error conditions, response format, or whether this is a simple fetch versus a complex operation. The description is minimal and lacks operational context.
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 is extremely concise - a single sentence that directly states the tool's purpose. There's no wasted language, repetition, or unnecessary elaboration. It's front-loaded with the core functionality.
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 tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what constitutes a valid document signature, how the retrieved content is structured, error handling, or operational constraints. The minimal description leaves too many questions unanswered for effective tool usage.
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?
With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema - it doesn't explain the relationship between signature and spider parameters, provide examples of valid signatures, or clarify the format parameter's implications.
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 states the action ('Retrieve') and resource ('full content of a specific legal document'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search_case_law' or 'list_courts' - it doesn't explain that this retrieves a single document by signature rather than searching or listing.
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 provides no guidance about when to use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate versus 'search_case_law', or any context about what constitutes a 'specific legal document' that can be retrieved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about available courts and their document counts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Get information' but doesn't disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or what format the information is returned in. The description is minimal and lacks essential context for safe invocation.
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 is a single, efficient sentence that directly states the tool's purpose without any fluff or unnecessary details. It is front-loaded and appropriately sized for a simple tool with no parameters.
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 annotations and output schema, the description is incomplete. It doesn't explain what 'information' includes (e.g., court names, IDs, document counts), how results are structured, or any limitations. For a tool that returns data, more context is needed to guide the agent effectively.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and since there are none, it meets the baseline of 4 for not introducing confusion or redundancy.
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 states the verb 'Get' and the resource 'information about available courts and their document counts', which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'search_case_law', which might also involve court information but with different functionality.
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 provides no guidance on when to use this tool versus alternatives like 'search_case_law'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Swiss court decisions using Entscheidsuche database
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Starting position for pagination | |
| query | Yes | Search query for legal cases | |
| size | No | Number of results to return (max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic function. It lacks details on behavioral traits such as rate limits, authentication needs, error handling, or what the search returns (e.g., result format, metadata). This is inadequate for a search tool with no output schema.
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 is a single, efficient sentence that directly states the tool's purpose without redundancy. It's front-loaded and wastes no words, making it easy to parse quickly.
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 complexity of a search tool with no annotations or output schema, the description is insufficient. It doesn't explain what the search returns, how results are structured, or any limitations, leaving gaps for the agent to understand the tool's behavior fully.
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 description coverage is 100%, so the schema fully documents parameters like 'query' for search terms and 'from/size' for pagination. The description adds no additional meaning beyond implying a legal context, meeting the baseline for high schema coverage.
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 states the action ('Search') and target resource ('Swiss court decisions') with the specific database ('Entscheidsuche'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_document' or 'list_courts', which might also retrieve legal information.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention scenarios for searching case law compared to getting specific documents or listing courts, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_documentlist_courtssearch_case_lawEach tool has a clearly distinct purpose: get_document retrieves specific document content, list_courts provides metadata about courts, and search_case_law performs searches across the database. There is no overlap in functionality, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern (get_document, list_courts, search_case_law) with clear, descriptive verbs. There are no deviations in naming conventions, making the set predictable and easy to understand.
With only 3 tools, the server feels somewhat thin for a legal document search domain. While the tools cover core operations (retrieve, list, search), more comprehensive coverage might include tools for filtering, advanced search, or document metadata management, suggesting a borderline appropriateness.
The tools provide basic CRUD-like operations (get, list, search) for legal documents and courts, but there are notable gaps. For example, there is no tool for updating or deleting documents, managing user queries, or handling advanced search parameters, which could limit agent effectiveness in complex workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Slovak court decisions as MCP tools. 12,000+ decisions, GDPR-compliant, pseudonymized, SLA-backed.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/self-tech-labs/entscheidsuche-MCP-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
