Nalegalu MCP
Server Details
Semantic search over Polish law and case law, citing the exact in-force article.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- nalegaluorg/nalegalu
- GitHub Stars
- 4
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 7 of 7 tools scored. Lowest: 2.2/5.
Each tool has a clear, distinct purpose: fetching articles, court cases, health, related cases, searching by signature, searching law, and verifying quotes. No ambiguity.
Naming is mostly descriptive but inconsistent: 'get_', 'search_', 'verify_', 'health', and 'related_' mix verb_noun and adjective_noun patterns.
7 tools is appropriate for the domain of Polish legal research, covering core operations without being excessive.
Covers the main workflow: fetching articles, finding and verifying cases, and searching law. Minor gap: no tool to list acts or courts, but search_law and related_cases cover them.
Available Tools
7 toolsget_articleAInspect
Fetch the exact text of one article (or paragraph) of a Polish legal act.
Deterministic lookup by act address (e.g. WDU19740240141) and article
key (e.g. "133" or "Art. 133."). Optional paragraph_key (e.g. "1" or
"§ 1.") narrows the result to a single paragraph.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| article_key | Yes | ||
| paragraph_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It states deterministic lookup but doesn't disclose response format, error behavior, or any side effects. Minimal but not misleading.
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?
Two sentences with a bullet list, no wasted words. First sentence clearly states purpose. Perfectly concise and well-structured.
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?
Has output schema covering return values. Parameter descriptions are adequate for a 3-param tool. Could mention error scenarios or character limits, but overall sufficient for a fetch operation.
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 has 0% description coverage; description adds meaning by specifying address format (e.g., WDU19740240141), article_key examples, and optional paragraph_key narrowing. Adds significant value beyond property names.
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?
Description clearly states verb 'Fetch', resource 'exact text of one article (or paragraph) of a Polish legal act', and distinguishes from siblings like search_law which is broader. Specific examples of valid keys enhance clarity.
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 explicit guidance on when to use this tool vs alternatives like search_law or get_case. Sibling names imply differences but description doesn't provide usage rules or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_caseAInspect
Fetch one SAOS court judgment (metadata + bounded text excerpt).
Use the saos_id from related_cases or search results. Long judgments
are paged: when has_more is true, call again with offset=next_offset.
If the response has ok=false with a fallback hint, SAOS is unavailable
or rate-limited — fetch the returned saos_url yourself with your own
web tools instead of retrying this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| saos_id | Yes | ||
| max_chars | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses key behaviors: paging (has_more, offset), fallback on error (ok=false, fetch URL yourself), and suggests rate-limiting. It does not explicitly state read-only nature, but 'fetch' implies it.
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 concise three-sentence paragraph. The first sentence front-loads the purpose. Each subsequent sentence adds essential information without redundancy or fluff.
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 (paging, fallback, error handling), the description covers paging behavior, error fallback, and source of saos_id. An output schema exists so return values need not be described. Could mention max_chars more explicitly, but overall sufficient.
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 0% schema description coverage, the description adds meaning for saos_id and offset, explaining their source and usage. However, max_chars is not explained. It partially compensates for the lack of schema descriptions.
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 'Fetch one SAOS court judgment (metadata + bounded text excerpt)', specifying the verb (fetch) and resource (SAOS court judgment). This distinguishes it from siblings like search_case_by_signature and related_cases.
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 usage context by stating 'Use the saos_id from related_cases or search results' and explains paging behavior with has_more and offset. While it doesn't explicitly state when not to use, the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthAInspect
Return local vector search service metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation returning metadata, which is transparent enough given the lack of annotations. However, it does not mention potential errors, response structure, or performance implications. With no annotations, more detail would improve transparency.
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, well-structured sentence with no wasted words. Information is front-loaded and immediately actionable.
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 tool's simplicity (no parameters, low complexity) and presence of an output schema, the description is nearly complete. It could briefly mention typical use cases (e.g., health checks), but the current version is sufficient.
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 tool has zero parameters, so schema description coverage is 100% trivially. The description adds no parameter info, but none is needed. Baseline for 0 parameters is 4.
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 uses the specific verb 'Return' and clearly identifies the resource as 'local vector search service metadata.' It effectively distinguishes from sibling tools like get_article or search_law, which operate on different data.
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 vs. alternatives (e.g., to verify service availability or retrieve configuration). The description only states what it does, not the context or criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_case_by_signatureAInspect
Check whether a cited case signature (sygnatura) exists, e.g. "II CSK 448/14".
Answers from a local index of all SAOS judgments first; only on a
local miss does it query live SAOS. Read the verdict field:
"confirmed" (matches listed with saos_id, court, date, type —
different courts reuse signatures, so check the court), "not_found"
(strong evidence the citation is fabricated or wrong),
"outside_coverage" (administrative courts NSA/WSA are not in SAOS —
verify in CBOSA instead), "unverified" (local miss and SAOS
unreachable; do not treat as nonexistent). Optional court_type:
COMMON, SUPREME, CONSTITUTIONAL_TRIBUNAL, NATIONAL_APPEAL_CHAMBER.
has_text=false on a match means SAOS stores no text for it, so
verify_quote cannot check quotes against that judgment.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| signature | Yes | ||
| court_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses all behavioral traits: local-first then live lookup, all verdict meanings, court signature reuse, and has_text implications. Fully transparent.
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 moderately long but every sentence adds value. It is structured with clear sections (verdicts, court_type, has_text). Could be tightened slightly.
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 there is an output schema, the description covers verdict field and has_text. It is complete for the tool's complexity, with no gaps.
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%, but description explains signature with example, court_type with enum-like values (COMMON, SUPREME, etc.), and implies limit via default. Adds meaning beyond schema.
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 tool checks whether a cited case signature exists, providing an example and explaining the behavior. It distinguishes from siblings like get_case, verify_quote, etc., by focusing on signature existence checking.
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 explains when to use the tool and how to interpret results (verdicts). It implies alternatives for outside_coverage (use CBOSA) but does not explicitly differentiate from sibling tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_lawCInspect
Search Polish legal acts and return compact article-level hits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| domain | No | ||
| status | No | ||
| address | No | ||
| article | No | ||
| act_type | No | ||
| top_cases | No | ||
| case_law_boost | No | ||
| candidate_multiplier | No | ||
| include_non_in_force | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions 'compact article-level hits' but fails to specify permissions, side effects, rate limits, or any non-obvious behavior. The tool likely mutates nothing, but this is not stated.
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 sentence, which is concise and front-loaded. However, it could add essential parameter guidance without sacrificing brevity. The current version is under-specified for the tool's complexity.
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 tool has 11 parameters, no schema descriptions, and an output schema (which is not referenced), the description is grossly incomplete. An agent would lack critical information on how to invoke the tool 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?
With 0% schema parameter descriptions, the description must compensate but does not. None of the 11 parameters are explained. The description only implies the 'query' parameter by mentioning 'search'. This leaves the agent unable to understand limit, domain, status, etc.
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 tool searches Polish legal acts and returns compact article-level hits. It distinguishes from siblings like get_article (which retrieves specific articles) and search_case_by_signature (searches cases).
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 get_article or search_case_by_signature. No explicit context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_quoteAInspect
Check whether a quoted fragment actually appears in a SAOS judgment.
Pass the saos_id (from search_case_by_signature or related_cases) and
the fragment as quoted. One call replaces paging through the full
text: verdict is "exact" (verbatim after normalizing whitespace,
quote marks and dashes), "near_match" (best passage plus similarity
score — compare it against the claim), or "not_found" (treat the
quote as fabricated or misattributed). If ok=false with a fallback
hint, fetch saos_url with your own web tools instead of retrying.
| Name | Required | Description | Default |
|---|---|---|---|
| quote | Yes | ||
| saos_id | Yes | ||
| min_similarity | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
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 discloses the three possible verdicts ('exact', 'near_match', 'not_found'), explains normalization of whitespace, quote marks, and dashes, and mentions a similarity score for near_match. This provides sufficient behavioral context for an agent.
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 concise at 6 sentences, front-loaded with the main purpose. Every sentence adds unique value: purpose, parameter sources, verdict explanation, and fallback guidance. No wasted words.
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 an output schema exists (though not shown), the description adequately covers usage, parameters, and behavioral details. It explains verdict categories and fallback. It indirectly addresses parameter through example usage. It is complete enough for the tool's complexity, though min_similarity could use more explicit explanation.
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 0%, so the description must add meaning. It explains that saos_id comes from search_case_by_signature or related_cases and that quote is the fragment as quoted. However, it does not clarify the min_similarity parameter (default 0.75) beyond the schema, leaving some ambiguity. Overall, it adds value but not full 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 tool's purpose: 'Check whether a quoted fragment actually appears in a SAOS judgment.' It uses a specific verb ('check/verify') and resource ('quoted fragment in a SAOS judgment'), distinguishing it from siblings like get_case (fetch full text) and search_case_by_signature.
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 explicit guidance: pass saos_id and fragment, and notes that one call replaces paging through full text. It also advises fallback behavior when ok=false with a hint, telling the agent to use web tools instead of retrying. While it doesn't name other tools, it clearly implies when not to use this tool (e.g., prefer web tools for fallback).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!