it-eli-mcp

Server Quality Checklist

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

Latest release: v0.6.1
Disambiguation5/5
Each tool targets a distinct resource and action: codes list, URN resolution, act metadata/text, Constitutional Court search/get/recent/stats, Cassazione search/get, administrative search/get, and citation verification. No two tools overlap in purpose.
Naming Consistency3/5
All tools share the 'it_' prefix and snake_case, but the pattern varies: some are verb-first (it_list_codes, it_get_act, it_verify_citations) while others are domain-first (it_case_search, it_cassazione_get, it_ga_search). This inconsistency is a minor deviation from a uniform convention.
Tool Count5/5
13 tools is within the ideal range and each tool covers a distinct aspect of Italian legal research. The count reflects the broad scope (statutes, three court systems, citation verification) without unnecessary proliferation.
Completeness5/5
The toolset covers the core research lifecycle: discovering codes, resolving any act identifier, retrieving act content, searching and fetching decisions from the three major Italian jurisdictions, monitoring index freshness, and verifying citations. No critical gaps are apparent for its stated purpose.
Average 4.1/5 across 13 of 13 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on August 7, 2026
- 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.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds ordering behavior ('newest first') and scope ('in the index'), but does not discuss pagination or limit handling, though the limit parameter is straightforward.
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?
The description is a single, clear sentence that front-loads the core purpose and ordering. Every word is meaningful and there is no redundancy or filler.
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?
With a single optional parameter, strong annotations, and an output schema present, the description is sufficiently complete for an agent to select and invoke the tool. It could mention a use case or alternative but is not lacking any essential context.
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?
The input schema covers 100% of parameters, and the limit parameter already has a clear description ('max items (1..100)'). The tool description does not add parameter-level meaning beyond what the schema provides, so the baseline of 3 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?
The description clearly states the tool returns the most recent Constitutional Court decisions in the index, ordered newest first. Though it lacks an explicit verb like 'list' or 'get', the resource and scope are specific enough to distinguish it from search and retrieval siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as it_case_search or it_case_get_decision. With many sibling tools present, explicit usage direction is missing.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety. The description adds the specific items covered (totals, years, last build), which is useful but does not explain how the stats are compiled or any limitations—still, it adds some value beyond 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?
One short, information-dense phrase; no filler or redundant text. It conveys the essential scope efficiently.
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 tool is simple with no parameters, and an output schema exists to describe return values. The description sufficiently orients the agent for a stats/overview call, though it could be slightly more explicit about the output format.
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?
There are zero parameters, so the input schema is complete and the description needs no parameter details. Baseline of 4 applies because no parameter information is missing.
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 identifies the tool as providing coverage and freshness metrics for constitutional case-law, including totals, years, and last build. While it lacks an explicit verb like 'get' or 'report', the noun phrase conveys the tool's purpose and distinguishes it from sibling search/retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over the many sibling tools. The description only lists content areas but does not mention alternatives or exclusions, so it fails to provide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond what the schema already provides (e.g., format options, article scoping, at_date behavior). It does not mention return format specifics, limitations, or any runtime considerations. No contradiction with annotations, but no extra disclosure either.
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?
The description is a single, concise sentence that front-loads the action and object ('Fetch the text'). It has no filler, redundant wording, or repetition of schema details. Every word serves to communicate the primary purpose.
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 presence of an output schema and detailed input schema descriptions, the minimal description is sufficient. It covers the core purpose without needing to explain return values or parameter details, as those are already in structured fields. The only minor gap is that it doesn't contextualize when to prefer this over it_get_act, but that's more a usage guideline issue.
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%, with each parameter (reference, format, article, at_date) having its own description. The tool description itself adds no parameter information, so the baseline of 3 applies. It neither enhances nor detracts from the schema, so the meaning is fully available from structured data.
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 action ('Fetch') and the resource ('text of a whole act or a single article'). It distinguishes the tool from siblings like it_get_act (which likely retrieves act metadata) by explicitly scoping to text content. The verb is specific and unambiguous.
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?
The description gives a clear idea of when to use the tool (when you need act/article text), but it does not mention alternatives, exclusions, or when not to use it. Usage is implied from the purpose rather than explicitly contrasted with sibling tools. Lacks guidance like 'use this instead of it_get_act for full text'.
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?
Annotations already cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the search is full-text, which is useful, but it does not elaborate on open-world behavior, pagination, or other runtime characteristics beyond what annotations and output schema provide.
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?
The description is a single, well-formed sentence that immediately communicates the tool's purpose without any filler or redundant wording. It earns its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only search tool, the description, along with the fully described schema and existing output schema, provides sufficient context. All required and optional inputs are documented, and annotations confirm the non-destructive, idempotent nature of the operation.
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?
The input schema has 100% coverage with clear descriptions for all four parameters, including defaults and allowed values. The description itself adds no parameter-level meaning beyond the schema, so it meets the baseline for high schema coverage.
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 identifies the tool as a full-text search over Corte Costituzionale (Constitutional Court) decisions, using a specific verb and resource. This clearly distinguishes it from sibling search tools targeting other courts, such as it_cassazione_search and it_ga_search.
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?
The description implies the tool is for full-text searching Italian Constitutional Court decisions, but it does not explicitly state when to use it over alternative tools like it_case_get_decision, it_case_recent, or it_cassazione_search. No exclusions or conditional guidance are provided.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds useful context: it retrieves 'full text' and does so 'live', which is not captured by annotations. This is meaningful beyond the structured data, though it doesn't detail failure modes or rate limits.
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 sentence that is front-loaded with the action, resource, and key identifier. No wasted words; every element 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?
The tool is simple (1 param, rich annotations, output schema present). The description covers the purpose and the 'live' behavior. It does not mention alternatives among the many siblings, but the schema already states the ID comes from search. Slight gap in distinguishing from similar get-decision tools, but overall adequate.
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% (sic_id is described with an example and its origin). The tool description merely repeats the identifier concept ('by its SentenzeWeb id') without adding new parameter semantics beyond the schema. Baseline 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 uses a specific verb ('Fetch') and resource ('full text of one Corte di Cassazione decision') with a precise identifier ('SentenzeWeb id'). It clearly distinguishes from sibling search tools like it_cassazione_search by stating it retrieves a single decision, not a list.
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?
The description implies usage: you need a SentenzeWeb id, likely from a prior search. However, it does not explicitly state when to use this tool over alternatives like it_get_text or it_case_get_decision, nor does it mention any exclusions. Only implied through the identifier requirement.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds no additional behavioral context (e.g., rate limits, authentication, or specifics about what 'metadata' includes). It doesn't contradict annotations, but it also doesn't enrich them.
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?
The description is one short, front-loaded sentence that states exactly what the tool does. Every word is necessary and there is 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?
With one well-documented parameter, strong annotations, and an output schema present, the description is sufficient for a simple metadata-fetching tool. It might benefit from mentioning that 'act metadata' excludes full legal text, but the tool name and sibling context help fill that gap.
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?
The single parameter 'reference' has a schema description that covers 100% of the parameter, listing four accepted formats. The tool description adds nothing beyond that, so the schema carries the weight. Baseline of 3 is appropriate given full coverage.
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 a specific verb and resource: 'Fetch act metadata from Normattiva.' This distinguishes it from sibling tools like it_get_text (which likely fetches full text) and it_list_codes (which lists codes). The scope is precisely defined.
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 implies usage context: use this tool when you need act metadata from Normattiva, as opposed to full text or other related services. It doesn't explicitly state when not to use it or name alternatives, but the clear 'act metadata' framing gives sufficient guidance.
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?
The annotations already indicate read-only, idempotent, non-destructive operations, so the safety profile is covered. The description adds that it returns the full text, but provides no additional context about edge cases like missing identifiers, result size, or precedence between ecli and anno+numero, offering minimal value beyond 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?
The description is a single, front-loaded sentence that directly states the action and object, with zero redundant content. It earns a top score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with a well-described schema, an output schema, and comprehensive annotations, this description is complete. It specifies the decision type, the court, and the allowed identifiers, which is all that is needed for a competent agent to invoke it correctly.
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?
The input schema describes all parameters with 100% coverage, including the relationship between anno, numero, and ecli. The description only restates 'by ECLI or year + number' without adding any new parameter-level details, so it meets the baseline but does not exceed it.
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 the specific verb 'Fetch' and identifies the resource as 'the full text of one Constitutional Court decision', which clearly distinguishes it from search and listing tools. It also specifies the two identification methods (ECLI or year+number), making its purpose 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?
The phrase 'by ECLI or year + number' establishes a clear condition for use—when a specific decision identifier is available—but it does not explicitly contrast with sibling tools like it_case_search for finding decisions by query, nor does it mention when not to use this tool. No exclusions are stated, only the positive context.
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 read-only, idempotent, and non-destructive hints, and the description adds substantial detail about actual behavior: extraction of specific citation types, checking against Normattiva and Constitutional Court indexes, trigram matching for parenthetical descriptions, and returning range hints for non-existent articles. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with useful information in three sentences, covering extraction, verification sources, content-checking, and edge-case behavior. While not wasteful, it exceeds a bare minimum and is organized effectively, though a slightly more compact style could earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (checking multiple citation types, multiple sources, and content matching), the description covers the key behaviors and edge cases. An output schema exists, so return values need not be described, and the description is sufficiently complete for an agent to invoke correctly.
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%, with both 'text' and 'max_citations' clearly described in the schema. The tool description itself adds no additional parameter meaning beyond what the schema already provides. 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 the tool verifies Italian legal citations found in a text against their real sources, specifying the exact types of citations (statutes, ECLIs) and the verification process. This specific verb+resource combination distinguishes it from sibling tools like it_resolve or it_case_search, which serve different purposes.
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?
The description implies when to use the tool (whenever you need to verify citations in a text) but offers no explicit comparison to alternatives or exclusions. There is no 'use instead of X' or 'not for Y' guidance, so it falls short of a 4 or 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?
The description adds behavioral context beyond the annotations: it performs live queries to an external public engine, does not use a local index, and matches decision body text (OCR), implying potential OCR errors. These details are not captured by the readOnly/openWorld/idempotent hints.
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?
The description is concise and front-loaded: the first sentence states the core purpose, and the second elaborates with essential behavioral details. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the strong annotations and full parameter schema coverage, the description sufficiently covers purpose, live external query behavior, and OCR search scope. An output schema exists, so return-value documentation is not needed. The description is complete for a search tool of this complexity.
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 clarifying that free-text search matches the OCR'd decision body, complementing the schema's 'decision text' phrase and giving context about what is searched.
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: full-text search of Corte di Cassazione decisions. It specifies the resource (Supreme Court decisions), the action (search), and distinguishes it from siblings by noting it queries the live external SentenzeWeb engine rather than a local index.
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?
The description implies usage context—'live' and 'no local index' suggest this is for real-time queries—but it does not explicitly state when to prefer this tool over alternatives like it_case_search or it_cassazione_get. No exclusions or alternative naming are provided.
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 already cover read-only, idempotent, and non-destructive behavior. The description adds the meaningful trait 'live' (no caching) and 'full text' (complete document content), which goes beyond the structured annotations without contradicting them.
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, front-loaded sentence that communicates the essential purpose without any filler. Every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, a detailed schema description, an output schema present, and comprehensive annotations, the description sufficiently covers what is needed to select and invoke the tool. The 'live' and 'one decision' details round out the behavioral context.
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% and the parameter description already provides excellent detail, including the exact format and provenance from it_ga_search. The description reinforces this by specifying 'by its document URL', adding a small but useful link to the workflow.
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 identifies the action (fetch), the resource (full text of one administrative decision), and the key qualifier (live, by document URL). It distinguishes this from sibling search and get tools by referencing the URL from it_ga_search.
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 parameter description explains that the input is a verbatim document_url from an it_ga_search hit, making the intended workflow clear. It doesn't explicitly name alternatives or exclusions, but the context of a search-then-fetch flow is well implied.
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?
The description discloses that the search is 'live' and 'real time', indicating results may change and the data comes from the public portal. This adds behavioral context beyond the annotations (readOnly, openWorld, idempotent) by specifying the dynamic nature and scale (3.4M+ provvedimenti). 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?
The description is compact and front-loaded: it opens with the purpose and scope in the first sentence, follows with useful backend context, and ends with a terse input hint. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and annotations, the description is sufficient. It explains what the tool does, the data source, and the input pattern. For a search tool with an output schema, this is a complete picture; the only minor gap is unlike sibling tools, but the purpose is clear enough.
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?
While the schema already provides thorough descriptions for all 6 parameters (100% coverage), the description adds a meaningful usage constraint: 'Provide a full-text query, a decision numero, or both.' This is not explicitly stated in the schema and helps the agent know a minimum input is expected.
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 Italian administrative case law, listing the specific courts (Consiglio di Stato, C.G.A.R.S., TAR). It uses a specific verb ('Search') and resource, and distinguishes itself by its exclusive focus on the administrative jurisdiction.
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 a clear context for when to use the tool: it's the live search over the Giustizia Amministrativa portal. It also instructs the agent to provide a query, decision number, or both, which helps in choosing inputs. However, it does not explicitly mention alternatives like it_ga_get_decision for known citations.
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 already declare readOnlyHint, idempotentHint, and openWorldHint, so the description adds meaningful context: the tool is a 'curated, verified dictionary' with specific legal codes and provides canonical URNs for further use. It omits details like sorting or full output structure, but the output schema covers those.
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?
The description is exactly two sentences with no fluff. The first states the core function, the second enriches with examples and usage direction. Every sentence earns its place, and it is easily parsable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with a provided output schema and read-only annotations, this description is complete. It covers what is listed, the curated nature, and how the output should be used. Nothing critical is missing.
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, so the description cannot add parameter semantics beyond the schema. The mention of feeding URNs is about output behavior, not inputs. Per the rubric, zero-parameter tools receive a baseline of 4, and the description appropriately frames the tool's role in the workflow.
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 the specific verb 'List' with the resource 'major Italian codes and consolidated acts' and the distinguishing output 'canonical URN'. Concrete examples (Codice civile/penale, Costituzione, etc.) further clarify the scope and differentiate it from sibling tools like it_case_search or it_cassazione_search.
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 explicitly directs the agent to feed the output URNs to it_get_act/it_get_text, providing an actionable downstream workflow. It does not explicitly contrast with alternatives like it_resolve, but the intended usage is clear for a zero-parameter list tool.
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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral info: it works offline, accepts friendly act_type forms, and produces partial URNs that still resolve on Normattiva. This goes beyond the annotations without contradicting them.
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?
Three short sentences, each earning its place: purpose, offline capability, and parameter semantics. Front-loaded with the main verb and object. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and rich annotations (read-only, idempotent), the description is sufficiently complete. It covers offline behavior, friendly input forms, and partial resolution semantics. The tool is simple, and no critical missing context is apparent.
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 schema already has 100% coverage (object description lists all fields). The description enriches parameter meaning by explaining that 'act_type' accepts friendly aliases like 'd.lgs' and 'dpr', and clarifies the significance of year+number vs. month/day for resolution. This adds semantic value beyond the raw 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?
The description clearly states the tool's function: 'Build a canonical, resolvable URN:NIR from act coordinates.' This uses a specific verb ('build') and resource ('URN:NIR'), and it is distinct from sibling tools like it_get_act (fetch act) or it_list_codes (list codes).
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 usage context, noting it is 'Offline (no network)' and explaining when to add month/day for exact dates vs. using only year+number for partial resolution. However, it doesn't explicitly contrast with alternatives (e.g., when to use it_get_act instead), so it doesn't reach a 5.
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:

[![it-eli-mcp MCP server](https://glama.ai/mcp/servers/matematicsolutions/it-eli-mcp/badges/card.svg)](https://glama.ai/mcp/servers/matematicsolutions/it-eli-mcp)

Score Badge

Copy to your README.md:

[![it-eli-mcp MCP server](https://glama.ai/mcp/servers/matematicsolutions/it-eli-mcp/badges/score.svg)](https://glama.ai/mcp/servers/matematicsolutions/it-eli-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/matematicsolutions/it-eli-mcp'

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