Skip to main content
Glama
matematicsolutions

mcp-nsa

by matematicsolutions
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

Server Quality Checklist

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

  • Latest release: v1.1.0

  • Disambiguation4/5

    Tools are mostly distinct: search for general queries, search_by_case for case number lookup, and get_judgment for full retrieval by ID. The only minor overlap is that search_by_case is described as a shortcut for search with a case number, which could cause slight confusion but is clearly documented.

    Naming Consistency5/5

    All tool names use a consistent snake_case pattern with verbs (get, search) followed by nouns or qualifiers. The naming is uniform and predictable across the set.

    Tool Count4/5

    With 3 tools covering search, retrieval, and case-specific lookup, the set is minimal but reasonable for a focused legal database. The scope is narrow (administrative courts), so no heavy tool count is needed.

    Completeness3/5

    The tools cover basic search and retrieval, but notable gaps exist: lack of filtering by date, court level, or other metadata in search, and get_judgment only returns the first 2000 characters, limiting full-text access. Agents may need workarounds for deeper queries.

  • Average 4.3/5 across 3 of 3 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 17 commits in the last 12 weeks
    • Last stable release on
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI is passing

  • This repository is licensed under MIT License.

  • This repository includes a README.md file.

  • Tools from this server were used 6 times in the last 30 days.

  • This repository includes a glama.json configuration file.

  • 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

  • Behavior4/5

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

    Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by explaining the return behavior (top-N results with full metadata, max 5 documents per query, and the MVP nature). No contradictions with annotations.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness3/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single paragraph of four sentences in Polish. It includes some domain-specific commentary that, while informative, could be trimmed for conciseness. It is front-loaded with the primary action.

    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?

    The description covers the database scope, return metadata, result limit, and relationship with get_judgment. It is fairly complete for an MVP tool, though it could clarify the interaction between pageSize and the max 5 limit. The schema descriptions help fill in the gaps.

    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 coverage is 100% with each parameter having a description. The tool description does not add parameter-specific semantics beyond what is in the schema, so baseline score of 3 applies.

    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 searches the CBOSA database of administrative court judgments, specifies the courts included, and notes the domain (GDPR, tax, etc.). It differentiates from siblings by mentioning that detailed reading should use get_judgment and implies that search_by_case is for case number searches.

    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 clear context on when to use the tool (for broad searches) and explicitly instructs to use get_judgment for detailed document retrieval. However, it does not explicitly state when not to use it or compare with search_by_case.

    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?

    Annotations declare readOnlyHint=true, idempotentHint=true, and description confirms it is a read operation. Adds behavioral detail that only first 2000 characters of content are returned.

    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 sentences, no wasted words. Action verb 'pobiera' front-loaded, structure clear.

    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?

    Without output schema, description adequately lists returned metadata fields and states content truncation at 2000 characters. Sufficient for agent to use tool.

    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?

    Single parameter doc_id with schema description providing format example. Description reinforces the format and source, adding value beyond schema.

    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 it retrieves a full judgment by doc_id, specifies the format (10-znakowy hex), and notes the doc_id comes from the 'search' tool, distinguishing it from siblings.

    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?

    Explicitly says doc_id comes from 'search' results, implying usage after search. Does not explicitly state when not to use, but context of sibling tools provides differentiation.

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

  • Behavior5/5

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

    Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds value by explaining this is a shortcut equivalent to search with caseNumber, and that it may not find judgments from certain courts, prompting a fallback. No contradiction with annotations.

    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?

    Very concise: two sentences convey purpose, equivalence, and fallback advice. Every sentence earns its place with no fluff.

    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 the tool's simplicity (one parameter, no output schema, safe annotations), the description is nearly complete. It states what it searches, the input format, and provides error handling guidance. Minor gap: no mention of the output structure, but it implies a judgment object. Almost complete.

    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 coverage is 100% with one parameter 'caseNumber' described with an example. The description adds that if the judgment is not found, the case number might be from other courts, but this is contextual rather than direct parameter semantics. Baseline 3 is appropriate.

    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 it searches for a judgment by case number ('szuka orzeczenia po sygnaturze'). It distinguishes from siblings by being a shortcut for 'search' with the caseNumber parameter and provides a fallback alternative (saos__search_by_case) for other court types.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines5/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    Explicitly tells when to use: as a shortcut for search with caseNumber. Also gives guidance on when not to: if judgment not found, case number might be from other courts (common, Supreme, etc.), then use saos__search_by_case. This clear when-to-use and alternative advice is excellent.

    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

mcp-nsa MCP server

Copy to your README.md:

Score Badge

mcp-nsa MCP server

Copy to your README.md:

Latest Blog Posts

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/matematicsolutions/mcp-nsa'

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