Skip to main content
Glama

Search Rulings

search_rulings
Read-onlyIdempotent

Search Italian administrative-court rulings (Consiglio di Stato and the regional TAR tribunals) by words or phrase, optionally narrowed by ruling type and by court seat. Covers public-procurement and contract-award disputes, planning and permits, public-sector employment, licensing and regulatory appeals -- e.g. rulings from the Brescia TAR naming a company or a tender. Returns each ruling's type, seat, section, number, ECLI, case number, a text snippet around the match, and a link to the full text; use get_ruling to read one. Italian search terms work best. Source: Giustizia Amministrativa. Covers administrative justice only -- not civil or criminal courts.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "seat": "Brescia",
      "type": "sentenza",
      "limit": 20,
      "all_words": "appalto"
    },
    "name": "search_rulings"
  }
}

Input Schema

NameRequiredDescriptionDefault
seatNoCourt seat: "Consiglio di Stato", "C.G.A.R.S", or a TAR city such as "Brescia", "Milano", "Roma", "Napoli" (default: all)
typeNoRuling type (default: all)
limitNo20, 40 or 60 results (default 20)
phraseNoExact phrase that must appear, e.g. "informativa antimafia"
all_wordsNoWords that must ALL appear, e.g. "appalto Brescia" or a company name
exclude_wordsNoWords that must NOT appear

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered; the description adds substantive context beyond that — result fields returned, the link to full text, the source system, and the jurisdictional scope limit. It does not mention pagination depth beyond the limit param or ranking behavior, which keeps it below 5.

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 action and scope, and every clause carries information (domains, return fields, sibling routing, language tip, source, exclusion). It is a single dense paragraph that runs slightly long, which costs a point but nothing is truly wasted.

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 6-parameter, all-optional search tool with no output schema, the description supplies the return shape (type, seat, section, number, ECLI, case number, snippet, link), the follow-up path via get_ruling, and the domain boundary — everything an agent needs to call and interpret it.

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 meaningful guidance beyond the schema by noting that Italian-language search terms perform best, which directly affects the phrase/all_words/exclude_words parameters and is not captured in the schema text.

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?

States a specific verb and resource (search Italian administrative-court rulings from Consiglio di Stato and TAR), then enumerates the subject domains covered and the concrete example query. It is clearly distinguishable from get_ruling and from unrelated search siblings.

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?

Gives explicit routing: 'use get_ruling to read one' for full text, and a hard exclusion boundary ('Covers administrative justice only -- not civil or criminal courts'). It also states a practical query condition, that Italian search terms work best, so the agent knows both when to use it and how to phrase input.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.