polish-caselaw-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes: search_case_law searches judgments, get_judgment fetches full text, find_judgments_for_provision finds judgments citing a provision, and list_courts filters court types. However, caselaw_about and caselaw_list_sources overlap significantly in purpose (both describe coverage/provenance/freshness of the SAOS source), creating some ambiguity between them.
Naming Consistency4/5
Four tools follow a consistent verb_noun or noun_action pattern (search_case_law, get_judgment, list_courts, find_judgments_for_provision). The two 'caselaw_about' and 'caselaw_list_sources' tools deviate from this pattern with reversed/awkward naming, but the overall set is largely consistent and readable.
Tool Count5/5
With 6 tools, the count sits squarely in the ideal 3-15 range. Each tool appears to earn its place: search, fetch, filter configuration, citation lookup, and two metadata/provenance tools. This is well-scoped for a caselaw server.
Completeness4/5
The core workflow is complete: search, fetch full text, filter by court type, and find judgments citing a provision covers the primary use cases well. The redundancy between caselaw_about and caselaw_list_sources suggests one is likely redundant, and advanced features like text pagination or citation-chaining (finding citing judgments of a judgment) are absent, but these are minor gaps for the stated purpose.
Average 4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 36 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. For a read-only list tool this is low-risk, but the description doesn't disclose return format, ordering, or whether the list is exhaustive. It does clarify the data scope (Polish court types only), which adds some value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly-worded sentence that says exactly what the tool does and why it exists. Zero wasted words — ideal conciseness.
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?
This is a simple dependency-support tool (feeds a filter in another tool). The description fully covers its role. It doesn't describe the return structure, but no output schema exists and for a simple list tool this is acceptable. Minor gap: doesn't state whether results are ordered or localized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and the schema is empty (100% coverage trivially). With no parameters to document, the description's clarification of what the output represents is all that's needed. Baseline 4 for a no-param tool is appropriate.
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?
Clear verb+resource: 'List the Polish court types' with specific purpose (for the court_type filter in search_case_law). It distinguishes itself from siblings by referencing a specific filter in another tool, though it doesn't explicitly contrast with all sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the purpose contextually — that the output is for use as a filter in search_case_law — which implies when to use it. However, it doesn't explicitly say when NOT to use it or mention alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that this is a metadata query (not a data mutation) and notes it's 'live SAOS,' which signals freshness of the data source, but doesn't describe caching behavior, latency expectations, or what 'SAOS' stands for. The 'live' qualifier adds some transparency value.
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?
Two concise sentences that front-load the purpose and then add usage guidance. 'Live SAOS' is a bit cryptic/technical without expansion, but the overall text is tight with no wasted words.
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 0-parameter metadata tool with no output schema, the description adequately conveys what information is returned (coverage, provenance, freshness) and when to call it. It would benefit from listing what specific data structures or fields are returned, but given the tool's simplicity, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema (which is empty) provides nothing. Per the rubric, 0 params earns a baseline of 4. The description doesn't need to explain parameters since none exist, and it appropriately focuses on the tool's behavior instead.
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?
The description has a specific verb+resource (returns metadata, provenance, and freshness of case-law server) and clearly states it covers quality attributes rather than search results. It distinguishes from siblings like search_case_law and get_judgment which operate on content, though it doesn't explicitly name them.
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 description gives clear context: 'Call to understand coverage and basis before relying on results.' This implies usage as a precondition/prerequisite before other case-law operations, which is useful guidance. It doesn't explicitly list when NOT to use it or name alternatives, but the 'before relying on results' framing clearly scopes its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. Being a metadata/provenance tool, it's reasonably likely to be non-destructive and read-only, which is implied by 'Provenance and legal-basis metadata.' However, it does not disclose the return format, whether it performs network requests, authentication needs, or data freshness characteristics. The description gives enough to infer a safe, informative call but doesn't add depth beyond the obvious metadata purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver both purpose and usage guidance with zero wasted words. The 'Call FIRST' instruction is front-loaded and actionable. This is exemplary conciseness—every word earns its place.
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 zero-parameter metadata/discovery tool with no output schema, the description is appropriately complete. It establishes the tool's role (provenance and legal-basis), identifies the source (SAOS), and prescribes when to call it (FIRST). It could optionally hint at what downstream decisions this metadata informs, but given the tool's simplicity and the lack of output schema, this is sufficient. The main gap is that it doesn't describe what the returned metadata looks like, but no output schema exists to supplement this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description provides contextual semantic value beyond the empty schema. It tells the agent what metadata categories are returned (provenance, legal-basis, SAOS coverage), which would not be inferable from the schema alone. With 0 params, the baseline is 4, and since the description meaningfully adds conceptual context about the tool's informational scope, it earns that baseline.
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?
The description clearly states this tool provides provenance and legal-basis metadata for the case-law source (SAOS), using a specific noun (provenance/legal-basis) plus resource (case-law source). It indicates this is a metadata/provenance tool rather than a search or retrieval tool, which helps distinguish it from siblings like search_case_law and get_judgment. However, the purpose lacks a verb—it describes what it contains rather than what action it performs, and differentiates only weakly from the similar caselaw_about sibling.
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 description gives explicit usage instruction: 'Call FIRST to understand what this case-law server covers.' This provides clear when-to-use guidance, positioning it as a discovery/prerequisite step before other tools like search_case_law or get_judgment. It does not explicitly state when NOT to use it or name alternatives, so it misses the full guidance credit, but the 'Call FIRST' directive is strong actionable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does well: it explains the confirmed_reference semantics (true=verified via referenced regulations, false=only text match), states 'Live from SAOS', and includes a 'not legal advice' disclaimer. The main gap is not disclosing behavior for edge cases like zero results or ambiguous IDs.
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 two sentences, front-loaded with the core purpose and identifier formats, followed by the confirmed_reference explanation and pragmatics. Efficient and well-organized, though the confirmed_reference detail could arguably be more prominent given its importance for interpreting results.
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?
This is a moderately complex search tool with 6 parameters, no output schema, and no annotations. The description covers purpose, identifier requirements, optional refinements, result semantics (confirmed_reference), and sourcing (SAOS). It's reasonably complete for the complexity, though it could add a sentence about expected return format since there's no output schema.
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 every parameter already has documentation. The description adds modest value by giving concrete examples ('art. 267', 'Kodeks karny', 'pl-du-1997-553') and clarifying the either/or relationship between document_id and journal_year+journal_entry. This enriches the schema but doesn't substantially exceed the baseline.
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 uses a specific verb+resource: 'Find Polish judgments that cite a given statutory provision.' It clearly distinguishes itself from sibling tools like search_case_law by focusing on provision-citation lookup rather than general case law search, and explains the identifier formats (document_id, journal_year + journal_entry).
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 description gives explicit usage patterns: 'Provide either document_id or journal_year + journal_entry, optionally an article and title_hint.' It notes these are optional refinements to sharpen search. However, it doesn't explicitly contrast with sibling tools or state when NOT to use this tool versus search_case_law, leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses the tool is 'Live from SAOS' (network dependency) and 'not legal advice' (user-facing caveat). But it doesn't disclose behavioral traits like response size, pagination, error handling for invalid ids, or rate limits despite being a live fetch.
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?
Front-loaded with the core purpose in the first clause, then efficiently enumerates return fields. The field enumeration is slightly verbose but useful. Second sentence adds context. Approaching appropriately compact given the informational payload.
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 single-param fetch tool, the description covers purpose, id provenance, return fields, and caveats. No output schema exists, so the description's enumeration of return content (judges, decision, summary, legal bases, referenced_regulations) compensates well. Slight gap on error/not-found behavior but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single param 'id' with description 'SAOS judgment id.' The description adds the crucial context that this id comes from search_case_law and is a SAOS identifier, enriching the schema meaning. For a single well-documented param, this is solid.
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?
Specific verb 'Fetch' + clear resource 'single Polish court judgment' identified by SAOS id. Clearly distinguishes from siblings by explicitly referencing search_case_law as the source of the id, and lists detailed return content. Purpose is unambiguous.
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?
Tells the agent the id comes from search_case_law, establishing usage context. Notes it's 'Live from SAOS' and 'not legal advice'. However, doesn't explicitly contrast against siblings like find_judgments_for_provision or caselaw_about, nor give when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that results include 'confirmed_reference (verified via referenced regulations),' notes it is 'Live from SAOS; not legal advice,' and warns against misinterpreting citations as invalidations. It implies a read-only operation. It lacks details like pagination or error handling, but covers key nuances for a legal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a clear opening statement, a brief input instruction, and a warning. It front-loads the core purpose and avoids redundancy. The IMPORTANT note adds necessary caution without being verbose, though it makes the description slightly longer than ideal.
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?
Given no output schema and no annotations, the description covers the essential input requirements and hints at the return value ('Returns TK judgments with confirmed_reference'). It also includes a legal disclaimer and a caution about interpretation. It does not fully explain the return structure, but for a search tool with well-described parameters, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by grouping parameters into alternatives ('document_id or journal_year + journal_entry') and clarifying optionality ('optionally an article and title_hint'). It also mentions the output concept 'confirmed_reference,' which enhances understanding of how parameters affect results.
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 clearly states the tool's function: 'Find Polish Constitutional Tribunal (TK) judgments that cite a given statutory provision.' It specifies the resource (TK judgments), the action (find/cite), and the input method (document_id or journal_year + journal_entry). This distinguishes it from general case law search tools and aligns with the sibling 'find_judgments_for_provision' while adding a specific court focus.
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 description provides usage context by explaining the required identifiers ('Provide document_id or journal_year + journal_entry') and optional parameters ('optionally an article and title_hint'). It also includes an important caveat about interpreting results ('does NOT by itself mean the provision was struck down'). However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries full burden. It discloses that data is live from SAOS, includes snippet format (>>> <<< markers), and clarifies it's not legal advice requiring verification against official portals. This is meaningful behavioral context beyond a simple mutation/read distinction.
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?
Four sentences, each earning its place: source identification, return format + sibling pointer, data separation nuance, and legal disclaimer. Slightly dense but efficient; no fluff. The data-source and disclaimer sentences add genuine value rather than padding.
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?
Given no output schema and no annotations, the description covers search purpose, return format, data source, sibling linkage, and legal caveats. For a 6-param tool with documentation-rich schema, this is reasonably complete. It could benefit from mentioning pagination or result-count limits more explicitly, but the defaults are in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 6 parameters are already documented in the schema. The description adds value by explaining the query language (Polish full-text), the return format (snippets, court, case number, date), and the default sort behavior (relevance per the schema enum default). This supplements rather than repeats schema info.
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?
Description clearly states a specific verb ('Search') + resource ('Polish court judgments from SAOS API'). It names the data source, distinguishes from statutory law, and differentiates from siblings by noting that get_judgment fetches full text — making this the search counterpart. High clarity.
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?
Description gives clear when-to-use context (searching case law live from SAOS, separate from statutory law) and points to get_judgment as the follow-up for full text. However, it doesn't explicitly name alternatives like find_judgments_for_provision or say when NOT to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![polish-caselaw-mcp MCP server](https://glama.ai/mcp/servers/PawelHaracz/polish-caselaw-mcp/badges/card.svg)](https://glama.ai/mcp/servers/PawelHaracz/polish-caselaw-mcp)

Score Badge

Copy to your README.md:

[![polish-caselaw-mcp MCP server](https://glama.ai/mcp/servers/PawelHaracz/polish-caselaw-mcp/badges/score.svg)](https://glama.ai/mcp/servers/PawelHaracz/polish-caselaw-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PawelHaracz/polish-caselaw-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server