Search French and European case law and French legal texts (codes, statutes, treaties).
Fetch the full text and metadata of a decision by its url. The text carries inline markdown links to cited articles (/texte/, open with get_legal_text) and cited decisions (/decision/, open with get_decision); a citation spanning several articles (« articles 3 à 6 », « et suivants ») links its first article and appends the others as labelled links right after the span. appellateFate states in one line what became of THIS decision on review (INFIRMATION = reversed, it no longer stands; CONFIRMATION = upheld): read it before citing the decision as authority. caseChronology lists the prior AND subsequent decisions of the same case (appeal, pourvoi, renvoi). An absent fate or chronology never proves no recourse exists, only that none is linked in the corpus. commentaires carries the institutional commentary (official analyses inline, links to the rapporteur public's conclusions and related court documents): context, never the ruling, so quote the decision text and not a commentaire.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A librejustice.fr decision URL, from a search_decisions hit or an inline citation link; search_decisions first if you have neither. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| seat | No | |
| text | Yes | |
| title | Yes | |
| office | No | |
| solution | No | |
| procedure | No | |
| dateLecture | No | |
| legalDomain | No | |
| officialUrl | No | |
| publication | No | |
| commentaires | No | |
| appellateFate | No | |
| docketNumbers | No | |
| caseChronology | No | |
| jurisdictionCode | No | |
| jurisdictionType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds significant behavioral context beyond that: how citation spans are linked, what appellateFate and caseChronology mean, and that commentaires are contextual and must not be quoted as the ruling. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and somewhat long, but every sentence contributes essential operational or interpretive guidance. It front-loads the core fetch action and then systematically covers link handling, fate semantics, chronology, and commentary caveats. It could be tightened, but it is not padded.
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 an output schema and only one parameter, the description is complete for an agent to invoke it correctly: it explains the source of the URL, how to choose siblings, and how to interpret the key result fields. Nothing essential is missing for correct selection or invocation.
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 schema fully documents the single `url` parameter, so the baseline is 3. The description adds useful meaning by specifying that the URL should be a librejustice.fr decision URL obtained from a search_decisions hit or an inline citation link, which improves an agent's ability to supply the correct value.
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 opens with a specific verb and resource: 'Fetch the full text and metadata of a decision by its `url`.' It clearly distinguishes get_decision from siblings by explaining that inline links to cited articles open with get_legal_text and cited decisions open with get_decision, and it routes URL discovery through search_decisions.
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 explicitly says to call search_decisions first if you have neither a decision URL nor an inline citation link, and it tells the agent which sibling to use for cited articles versus cited decisions. It also warns that an absent appellateFate or caseChronology never proves no recourse exists, which is critical guidance for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a legal text, or one of its articles, as it stood on a given date. Returns the version in force at date (omit for today): full text, status, validity dates, and the timeline of all versions: say which version you quote. The text carries inline markdown links to cross-referenced articles (/texte/, open with get_legal_text; when served at a date, the links point to the same date). commentaires carries institutional commentary anchored on the article (analyses inline, links otherwise). num absent means you hold the whole text; a section entry of articles, fetched by its url, returns all its articles at once. Covers French codes and statutes, plus curated foreign codes and treaties.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | A librejustice.fr article URL `/texte/{code}/{article}`: take it from a search_legal_texts hit or an inline citation link, or compose it: {code} is the code slug ("code-civil", as in facets.legal_instrument), {article} the lowercase article key ("l761-1" for L. 761-1, "1240" for 1240). `/texte/{code}` alone addresses the text itself, which is how a text with no articles (circulaire, publication decree) is read. | |
| code | No | Code slug, when you hold the code and the article apart rather than as a url ("code-civil"). Alone, addresses the text itself. | |
| date | No | Consultation date (YYYY-MM-DD): returns the version in force at that date. Omit for the version currently in force. | |
| textId | No | Légifrance article id (LEGIARTI…), resolved to the article it designates. LEGITEXT and CID are not accepted. | |
| article | No | Lowercase article key, alongside `code` ("l761-1" for L. 761-1, "1240" for 1240). |
| Name | Required | Description |
|---|---|---|
| num | No | |
| url | Yes | |
| code | Yes | |
| etat | No | |
| nota | No | |
| text | No | |
| title | Yes | |
| dateFin | No | |
| omitted | No | |
| articles | No | |
| versions | Yes | |
| dateDebut | No | |
| sourceUrl | No | |
| articleCount | No | |
| commentaires | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent, and the description adds substantial behavioral detail beyond that: versioning at a date, full text/status/validity dates/timeline, same-date link resolution, commentaires structure, whole-text vs article resolution, and section batch behavior. There is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well front-loaded with purpose, then packs relevant behavioral edge-cases into compact clauses. Some phrasing is telegraphic ('say which version you quote', 'links otherwise'), slightly reducing clarity, but every sentence contributes information and there is no waste.
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?
For a complex tool with an output schema, the description adequately covers what an agent needs: date-based versioning, link behavior, whole-text vs article semantics, section returns, commentaires, and legal coverage. The remaining details are carried by the rich input and output schemas rather than omitted from the definition.
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?
Since schema description coverage is 100%, the baseline is 3. The description restates date semantics and url composition, but it does not meaningfully add parameter meaning beyond what the schema already provides. Output-focused details like num, section, and commentaires are not input-parameter semantics.
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 opens with a concrete verb and resource: 'Fetch a legal text, or one of its articles'. It immediately adds the key distinguishing dimension, temporal versioning: 'as it stood on a given date' and 'version in force at date'. This clearly separates it from decision retrieval and search siblings.
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 gives clear context for when to use the tool: fetching legal texts or articles at a chosen date, reading cross-referenced /texte/ links, and covering French codes/statutes plus curated foreign texts. It does not explicitly contrast itself with get_decision or search_legal_texts, but the scope and use cases are strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the authenticated user's own activity, most recent first. kind selects which tab: 'searches' (past queries with their structured filters and source), 'bookmarks' or 'readingHistory' (decisions, each with title, a summary and the url to chain into get_decision), or 'all' to get the three at once. Only the requested tab(s) are populated. In readingHistory, lastSource == 'web' means the user opened the decision manually at least once (a genuine read); 'mcp' means it was only ever opened through this connector. Requires a connected account.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Which tab to list: 'searches', 'bookmarks', 'readingHistory', or 'all' (default) for the three at once. | all |
| limit | No | Maximum number of entries per tab (1–100, default 50). |
| Name | Required | Description |
|---|---|---|
| searches | No | |
| bookmarks | No | |
| readingHistory | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation read-only, idempotent, and non-destructive, and the description adds genuinely new behavioral context: most-recent-first ordering, only requested tabs being populated, the meaning of lastSource 'web' vs 'mcp', and the requirement of a connected account. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is a front-loaded summary, and the subsequent sentences expand the kind parameter with no filler. It is dense but every clause carries decision-relevant information about behavior, output interpretation, or prerequisites.
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?
With an output schema present, return-value details do not need repeating. The description covers authentication, ordering, tab population, chaining to get_decision, and per-kind semantics, leaving nothing an agent needs to select and invoke the tool correctly missing.
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 schema already documents both parameters with defaults and ranges, so the baseline is 3. The description goes beyond the schema by explaining what each kind returns, noting that 'all' returns the three tabs at once, and defining the readingHistory lastSource semantics relevant to returned data.
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 opens with a specific verb and resource—'List the authenticated user's own activity'—and immediately states ordering. It enumerates the three tab kinds and the 'all' aggregate, making the tool's scope clear and distinguishable from the sibling decision-search and retrieval tools.
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?
It gives strong when-to-use context: for viewing the user's recent searches, bookmarks, or reading history, and explicitly says URLs from readingHistory chain into get_decision. It does not explicitly name sibling alternatives or exclusion cases, but the tab semantics make the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search decisions by meaning and keywords combined. Returns a shortlist: title, url, an overview (aiSummary: AI-written summary of what the decision is about, a machine paraphrase never quotable as the court's words; or snippet: the verbatim passage where your keywords matched) and metadata; get_decision reads the full text. Put constraints in the structured filters (jurisdiction, dates, articles, codes), keep the query for the legal issue. Values within one filter are OR'd; different filters are AND'd. The response carries a facets block: per filter name, a map of filter value to decision count under the current query. Reuse those keys verbatim to refine. Hit metadata fields carry the same tokens under the same names: a hit's jurisdictionCode, legalDomain or solution passes back verbatim into the matching filter.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'auto' is the right choice in almost all cases, it picks the regime from the query shape. auto: combines meaning and keyword matching on plain queries; switches to keyword-only when the query contains ET / OU / SAUF or quoted phrases. lexical: force keyword-only matching. Every term becomes required and nothing recovers a miss, so it fits a string you expect word for word (a consecrated formula, the direction of a holding, a party named in the text) and an empty answer is then an answer. semantic: force the meaning+keyword hybrid even on quoted or operator queries (where auto would fall back to keyword-only). | auto |
| seat | No | Restrict to one or more seats, as a dotted path from the court type down to the room: "CC", "CC.SOCIALE", "CA.PARIS", "CA.PARIS.P5.C3". A path matches itself and everything below it, so this one filter also covers what jurisdiction_type and jurisdiction_code express. Take the paths from facets.seat. | |
| sort | No | Result ordering. Use 'relevance' (default) unless the user wants chronological order. | relevance |
| limit | No | Maximum number of results (default 10). | |
| query | Yes | French query, the primary input. Two regimes, pick the right tool for the job: (a) Natural language or descriptive keywords for legal-issue searches; the engine handles synonyms and reformulations. Examples: « responsabilité hôpital infection nosocomiale » ; « étranger malade soins inaccessibles dans son pays d'origine » ; « licenciement discrimination syndicale charge de la preuve ». (b) Quoted exact phrases and ET / OU / SAUF operators for a named entity (company, municipality, person), a precise legal formula, or the direction of a holding: semantic matching ignores negations (« n'est pas X » ranks like « est X »), and only an exact phrase targets which way the court ruled. Examples: « "Société Générale" » ; « "commune de Saint-Denis" SAUF Réunion » ; « "force majeure" ET épidémie ». Using operators or quotes switches the engine to keyword-only matching for the whole query (no synonyms), so do not mix the two regimes. | |
| office | No | Filter by specialised judge/office (JLD, JAF, JCP, JEX, juge des enfants, premier président, magistrat désigné). Absent value = ordinary bench. | |
| date_to | No | Latest decision date, inclusive (YYYY-MM-DD). | |
| solution | No | Filter by the ruling of the operative part (référentiel solution). REJET / IRRECEVABILITE / DESISTEMENT / NON_LIEU_A_STATUER are procedural or negative endings; CONFIRMATION / INFIRMATION* / REFORMATION are appeal outcomes; CASSATION* is cassation-specific; ANNULATION covers administrative annulment; SATISFACTION_TOTALE / SATISFACTION_PARTIELLE cover first-instance civil rulings granting the claim. | |
| ai_rerank | No | When enabled (default), reorders results by actual relevance to the query using an LLM reranker. Keep on for agentic use, shortlist quality is significantly higher. Cost: a few seconds of extra latency. Disable only for high-rate exploratory searches where latency matters more than ranking quality. | |
| date_from | No | Earliest decision date, inclusive (YYYY-MM-DD). | |
| procedure | No | Filter by procedural track (référés, QPC, EU referral, révision, tierce opposition…). Absent value = ordinary contentious procedure. | |
| publication | No | Filter by publication, at the grain the Cour de cassation itself uses (any-of, membership is multiple: a decision matches every value whose code it carries). Judicial order: PUBLIE_RAPPORT (annual report, the strongest signal), PUBLIE_BULLETIN, LETTRE_CHAMBRE, COMMUNIQUE, INEDIT_BULLETIN. Administrative order: PUBLIE_LEBON, MENTIONNE_LEBON, INEDIT_LEBON. Lower courts carry no publication statement and match no value. | |
| legal_domain | No | Filter by legal domain (curated domain tree): 9 roots and their leaves (e.g. CIVIL_DROIT_LOCATIF). Selecting a root also matches all its leaves. | |
| legal_article | No | Restrict to decisions citing a specific article of a specific code, as a composite key "<instrument>|<article>" where <instrument> is a slug or an exact text name, resolved like legal_instrument (e.g. "code-civil|1240", "code-de-justice-administrative|L761-1"). The instrument prefix is required: the same article number exists in several codes. | |
| legal_instrument | No | Restrict to decisions citing one or more given codes or statutes. Accepts a slug from facets.legal_instrument (e.g. "code-civil") or an exact text name resolved server-side (e.g. "Code civil"). | |
| jurisdiction_code | No | Restrict to one or more precise court units by referential code. Code shapes: "cc" (Cour de cassation), "ce" (Conseil d'État), "cnda", "cedh", "cjue"; "ca_<city>", "caa_<city>", "ta_<city>", "tj_<city>", "tcom_<city>" (e.g. "ca_paris", "ta_marseille", "tj_paris", "tcom_lyon"). When unsure, guess with the city name in the code: the error names the nearest valid ones. Each code is a court; a room inside it is reached with seat, which also expresses this filter as a path. | |
| jurisdiction_type | No | Restrict to one or more court categories: TJ (tribunal judiciaire), CA (cour d'appel), CC (Cour de cassation), TCOM (tribunal des activités économiques), TA (tribunal administratif), CAA (cour administrative d'appel), CE (Conseil d'État), CNDA (asylum), CONSTIT (Conseil constitutionnel), TC (Tribunal des conflits), CNIL (sanctions), CEDH and CJUE (European courts). |
| Name | Required | Description |
|---|---|---|
| hits | Yes | |
| query | Yes | |
| total | Yes | |
| facets | No | |
| pinned | No | |
| filterRewritten | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: aiSummary is an AI paraphrase never quotable as the court's words, snippet is the verbatim match, values within one filter are OR'd while filters are AND'd, and facet keys can be reused verbatim. This is valuable operational context not present in the annotations.
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 front-loaded with purpose, then covers result shape, filter strategy, combinatorics, and facet reuse in efficient sentences. For a tool with 17 parameters, this is appropriately sized and every sentence earns its place.
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 rich schema, annotations, and presence of an output schema, the description covers the essential strategic context: what results look like, how to structure queries, how to refine with facets, and when to follow up with get_decision. The agent has enough to select and invoke the tool correctly.
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 100%, so the per-parameter descriptions carry most of the load. The description adds meaningful cross-parameter semantics: OR within filters, AND across filters, and facet/hit metadata keys round-tripping into filters. It does not enumerate every parameter, but it does not need to.
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 opens with a specific verb and resource: 'Search decisions by meaning and keywords combined.' It clearly distinguishes itself from the sibling get_decision by stating that get_decision reads the full text, and the focus on 'decisions' separates it from search_legal_texts.
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?
Provides strong usage guidance: keep the query for the legal issue, put constraints in structured filters, and use get_decision for full text. It does not explicitly describe when to prefer search_legal_texts or get_legal_text, but the decision-vs-text distinction is implied clearly enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find legal articles from their subject or wording when the article number is unknown; returns a ranked shortlist with highlighted snippets and the exact total. Query in French, descriptive terms (« délai de recours contentieux refus implicite »); put the code in the code filter (slug or exact name), keep the query for the subject. The response carries a facets block (code, jurisdiction): per filter name, a map of filter value to article count, reuse those keys verbatim to refine. Chain a hit into get_legal_text with its url, plus date when the dispute is governed by an earlier version.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | Restrict to one code/text by its URL slug ("code-civil", as in facets.code) or exact name. Omit to search the whole navigable referential. | |
| date | No | Consultation date (YYYY-MM-DD): searches the versions valid at that date (point-in-time, same semantics as get_legal_text). Omit to search the versions currently in force. | |
| limit | No | Maximum number of results (default 10). | |
| query | Yes | French query over legal articles. Matches article titles (boosted) and bodies; alias expansion handles acronyms and usual names. | |
| jurisdiction | No | Filter by country/legal order, as an ISO 3166 alpha-2 country code: "FR" (France, the bulk of the corpus) or a foreign code ("SN", "DZ", "MA", "VN", "PE", …); plus "UE" for EU law and "INTL" for treaties/international law. |
| Name | Required | Description |
|---|---|---|
| hits | Yes | |
| query | Yes | |
| total | Yes | |
| facets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent, and the description adds substantial behavioral detail beyond that: it returns a ranked shortlist with highlighted snippets and an exact `total`, carries a `facets` block reusable verbatim for refinement, and explains the date-versioning interaction with get_legal_text. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, query construction, filter behavior, facets, and chaining to get_legal_text. It is front-loaded with the core purpose and contains no filler or repetition.
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?
For a search tool with an output schema and five parameters, the description is complete: it explains the query language, filter usage, facets, date semantics, and the correct follow-up call. The presence of the output schema means return-value details need not be restated, and nothing essential for correct invocation is missing.
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?
Although the schema covers all 5 parameters, the description enriches them with usage semantics: query should be in French descriptive terms, code should be a slug or exact name with the query reserved for subject, and date has the same point-in-time semantics as get_legal_text. This goes well beyond the schema's property 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 opens with a specific verb and resource: 'Find legal articles from their subject or wording when the article number is unknown.' This clearly differentiates it from get_legal_text (article known by URL/number) and search_decisions (decisions, not articles), so an agent can select it correctly without opening schemas.
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?
It gives explicit conditions: use when the article number is unknown; query in French descriptive terms; put the code in the `code` filter; keep the query for the subject. It also names the follow-up alternative by instructing to chain a hit into get_legal_text with `url` and `date`, which is clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
French legal research: statutes in force at any date, case law both ways, verified citations.
Search 18M+ legal documents worldwide — case law, legislation, and doctrine across 110+ countries.
Search national and EU case law, legislation and regulation, with citations you can verify.
Search French companies: financials, directors, ownership, M&A and insolvency events.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action: decisions, legal texts, search over each, and user activity. Even though get_decision and get_legal_text both fetch documents, their domains are clearly separated by name and description.
All tool names follow the same snake_case verb_noun pattern: get_*, search_*, list_*. There is no mixing of conventions, vague verbs, or inconsistent casing.
Five tools is well-scoped for a legal research server: search and retrieval for both decisions and legal texts, plus user activity. Every tool fills a clear role without redundancy.
The domain is read-oriented legal research, and the set covers both search and retrieval for its two primary object types, with user activity as a useful auxiliary. There are no obvious dead ends or missing core operations.
