This server provides access to Brazilian open legal data APIs — covering federal legislation, court dockets, and judicial rulings — without API keys or registration.
Legislative Tools
Search federal bills: List Brazilian federal bills (PL, PLP, PEC, etc.) by type and year from the Câmara dos Deputados.
Get bill details: Fetch full detail and current legislative status for a specific bill by its numeric ID.
Resolve enacted laws: Look up an enacted Norma Jurídica by its urn:lex:br: URN — returns identification, Diário Oficial publication provenance, amendment history, and STF unconstitutionality notes.
Browse law structure: List the addressable structure (parts, titles, chapters, articles, etc.) of a Norma Jurídica by URN Lex.
Read law article text: Fetch the full text of a specific article or structural element of a law by URN Lex and article suffix.
Court Docket Tools (DataJud CNJ — metadata only)
Search court dockets: Search procedural metadata (class, subjects, judging body, timeline) across STJ, TST, TSE, TRFs, TJs, TRTs, TREs, and military courts — does not include ruling text.
Get a specific docket: Fetch one court docket by its exact CNJ unified process number.
Case Law / Ruling Text Tools
STJ rulings: Search and fetch Superior Tribunal de Justiça acordãos with real ementa + decisão text (coverage: May 2022+).
CARF tax rulings: Fetch one CARF (federal tax appeals board) acordão by exact docket or decision number — exact lookup only, no free-text search.
TST labor rulings: Free-text search (AND semantics, exact phrase) across 3.75 million TST rulings, or fetch one by CNJ process number — returns ementa and full inteiro teor.
TCU audit rulings: Free-text search (with field-scoped query syntax) across 525,000+ TCU acordãos on public procurement/spending, or fetch one by number/year/chamber — returns deliberation text, rapporteur's report, and vote.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@br-eli-mcp get details on PL 2597/2024"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for eight keyless, no-registration Brazilian open-data APIs:
Camara dos Deputados (dadosabertos.camara.leg.br) - the federal legislative
process: bills (proposicoes) as they move through committees and floor votes.
Congresso Nacional Dados Abertos Legislativos (legis.senado.leg.br/dadosabertos) -
the real LexML URN Lex resolver for enacted Normas Juridicas (laws, decrees,
constitutional amendments): identification, Diario Oficial da Uniao publication
provenance, amendment history, STF unconstitutionality notes.
normas.leg.br - the full-text companion to (2): real article-by-article text of enacted legislation, addressed by the same URN Lex.
DataJud CNJ (api-publica.datajud.cnj.jus.br) - court DOCKET metadata (not
ruling text) across STJ/TST/TSE/TRFs/TJs/TRTs/TREs and military courts.
STJ Open Data Portal (dadosabertos.web.stj.jus.br) - real acordao (ruling)
full text + ementa (headnote) from the Superior Tribunal de Justica, Brazil's
second-highest court. Coverage starts May 2022.
CARF (acordaos.economia.gov.br) - real acordao (tax ruling) full text from
Brazil's federal tax appeals board, by exact docket/decision number.
TST (jurisprudencia-backend2.tst.jus.br) - real ruling full text (inteiro
teor) + ementa from the Tribunal Superior do Trabalho, Brazil's labor supreme
court: free-text search and exact CNJ-process-number lookup (3,751,594 acordaos,
8,483,448 documents across all types - verified live 2026-07-07).
TCU (pesquisa.apps.tcu.gov.br) - real acordao full text (deliberation,
rapporteur's report, vote) from the Tribunal de Contas da Uniao, the Federal
Court of Accounts - public-procurement jurisprudence (525,620 acordaos -
verified live 2026-07-07).
br_get_norma resolves a urn:lex:br:... against the Senado's own API gateway
(public, no key or registration) and returns identification, publication provenance,
and amendment history. br_get_norma_index + br_get_norma_texto resolve the same
URN against normas.leg.br's structured Legislation tree for the real text of one
article - not a summary. See DISCOVERY.md for how both endpoints were
found: v0.1.0 tested the wrong host for identification and wrongly reported it as
unconfirmed; v0.2.0 fixed that but still lacked full text; v0.3.0 found the
full-text API on the same domain as the human-readable citation page.
This connector does not scrape Planalto (planalto.gov.br) HTML - no confirmed
mechanical rule maps a URN Lex to a Planalto URL for every act type, and fabricating
one would risk the citation-hallucination failure mode this fleet exists to prevent.
Re-verified live 2026-07-07: legislacao.presidencia.gov.br (the REFLEGIS portal
the manifest names) does not return a plain HTTP response to a keyless client at
all - the connection is accepted but the request times out with zero bytes
received, consistent with a bot-challenge/WAF in front of it, not a structured API.
A minority of act types (mostly decrees) have no inline text in normas.leg.br
either; for those, see DISCOVERY.md.
For case law, DataJud (docket metadata only, redistribution restricted by CNJ
Resolution 446/2022), the STJ Open Data Portal (real acordao text, May 2022+),
CARF (real tax-ruling text, exact lookup only), TST (real ruling text - free-text
search and exact CNJ-process-number lookup, both confirmed live 2026-07-07 after
a browser network trace of the real frontend revealed the request fields the
earlier reverse-engineering missed) and TCU (real acordao/relatorio/voto text)
are wired in below. TRF4/TRF5 were probed and rejected - their hosts never accept
a connection from outside Brazil (geo_restricted) - and RFB's sijut2consulta is
a scrape-class HTML app with no JSON backend. See DISCOVERY.md
for the exact probes run and each confirmed request/response contract.
Related MCP server: senado-br-mcp
Tool | Purpose |
| List bills by type ( |
| Full detail + current status for one bill by id |
| Resolve an enacted Norma Juridica by URN Lex - identification, DOU provenance, amendment history, STF notes |
| List the addressable structure of a Norma (parts, books, titles, chapters, sections, articles) |
| Fetch the real text of one article (dispositivo) of a Norma |
| Search court dockets (metadata only) in one tribunal's DataJud CNJ index |
| Fetch one court docket by exact CNJ unified process number |
| Search STJ acordaos (real ruling text) by process number or free text |
| Fetch one STJ acordao by exact process number - ementa + ruling body text |
| Fetch one CARF tax acordao by exact docket or decision number - ementa + ruling body text |
| Search TST labor-court rulings by free text (real ruling text; 3.75M acordaos) |
| Fetch one TST ruling by exact CNJ unified process number - ementa + inteiro teor |
| Search TCU (Federal Court of Accounts) acordaos by free text (525K acordaos) |
| Fetch one TCU acordao by (numero, ano, colegiado) - deliberation + report + vote text |
| Declare what this connector covers, when each family was captured, and - explicitly - what it does NOT cover. Every gap carries a fallback. |
Bill type codes (sigla_tipo), for reference:
Code | Portuguese | English |
| Projeto de Lei | ordinary bill |
| Projeto de Lei Complementar | complementary-law bill (implements a constitutional provision) |
| Proposta de Emenda a Constituicao | constitutional amendment proposal |
Every response carries lex_uri, human_readable_citation and source_url.
For br_search_proposicoes/br_get_proposicao, lex_uri is Camara's own stable
API URI (not a URN Lex - a bill isn't enacted law yet). For br_get_norma,
lex_uri is the real urn:lex:br:... you queried with, e.g.
"urn:lex:br:federal:lei:2002-01-10;10406" (Codigo Civil). For br_get_norma_texto,
lex_uri is that URN plus the article suffix, e.g. "...;10406!art5".
pip install br-eli-mcpSmart App Control blocks unsigned executables, which covers uvx.exe, pip.exe
and the br-eli-mcp.exe launcher that pip writes at install time. The python.exe and
py.exe from the python.org installer are signed by the Python Software
Foundation, so running the module through the interpreter works:
python -m pip install br-eli-mcp
python -m br_eli_mcppip.exe is blocked for the same reason, so install with python -m pip, not
pip install. If python is not on PATH, use the Windows launcher: py -3 -m br_eli_mcp.
{ "mcpServers": { "br-eli-mcp": { "command": "python", "args": ["-m", "br_eli_mcp"] } } }Do not turn Smart App Control off to work around this - it cannot be re-enabled without reinstalling Windows.
Env var | Default |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Apache-2.0 (code). The Camara dos Deputados open-data API is open data requiring attribution - see SOURCES.md.
Declare what this connector covers, how it is sourced, and what it does NOT cover.
Call this before telling a user that the law "does not contain" something, and whenever a search comes back empty: the absence may be a gap in this connector rather than in the law. Every gap carries a fallback saying where to look instead.
Returns:
Coverage with families, an as-of note, and a non-empty list of known gaps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | No | |
| families | No | |
| as_of_note | Yes | States what the dates mean, and what they do not promise. |
| known_gaps | No | Never empty. An empty list would mean 'not checked', not 'no gaps'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnly, openWorld, idempotent, and non-destructive hints. The description adds valuable behavioral context by warning that empty searches may reflect gap coverage rather than legal absence, and by promising a fallback for each gap. This goes beyond what annotations alone convey and aligns with them—no contradiction.
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 the core purpose, followed by targeted usage triggers, then the return summary. Every sentence earns its place; the Returns section is clearly separated and concise. 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?
The description fully covers the tool's purpose, invocation signals, and output expectations. It even provides the open-world caveat that is essential for correct interpretation of search results. Given it is a parameterless, read-only metadata tool, nothing material 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?
The input schema has zero parameters, so the description does not need to explain parameter behavior. Baseline of 4 applies because there are no parameters to document and schema coverage is 100% by default.
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 states a specific verb('Declare') and resource('what this connector covers...does NOT cover'), making it clearly distinct from the search and retrieval sibling tools. It immediately communicates this is a meta-tool for understanding connector scope, not for querying legal content.
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?
Explicit when-to-use guidance is provided: call before asserting something is absent from the law, and whenever a search returns empty. It also explains why (absence may be a connector gap) and what to expect from gaps (fallbacks). This fully equips an agent to decide when this tool is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one CARF (tax appeals) acordao by exact docket or decision number.
Exactly one of numero_processo / numero_decisao must be given - this
is an exact lookup, not a search. There is no free-text search tool for
CARF because its full-text index is not reliably populated upstream
(confirmed empty on live probing for common Portuguese terms).
| Name | Required | Description | Default |
|---|---|---|---|
| numero_decisao | No | CARF decision number, e.g. ``"9101-002.402"``. | |
| numero_processo | No | CARF docket number, e.g. ``"16095.000602/2007-70"``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds context about exact lookup and upstream index unreliability, which goes beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. The second sentence adds usage constraint and justification. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description need not detail return values. It covers purpose, parameter constraints, usage context, and even explains the absence of a search tool. Complete for a fetch tool.
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% with parameter descriptions including examples. The description adds the constraint that exactly one parameter must be provided and that it is an exact lookup, providing meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch one CARF (tax appeals) acordao by exact docket or decision number.' It specifies the verb, resource, and method, and distinguishes it from sibling tools like br_get_case_stj by naming CARF and exact lookup.
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 explicitly states 'Exactly one of numero_processo / numero_decisao must be given - this is an exact lookup, not a search.' It also explains why there is no free-text search tool for CARF, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one STJ acordao by its exact numeroProcesso, with real ruling text.
| Name | Required | Description | Default |
|---|---|---|---|
| orgao | Yes | deciding chamber/section, e.g. ``"CORTE ESPECIAL"``. | |
| numero_processo | Yes | the STJ process or registration number (digits; punctuation ignored). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds 'with real ruling text' but does not disclose additional behavioral traits. 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 a single, front-loaded sentence that efficiently conveys the core action. Every word serves a purpose, though it could benefit from additional context.
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 presence of an output schema and simple two-parameter input, the description covers the essential purpose. However, it lacks usage guidelines and prerequisites, leaving some gaps for a complete understanding.
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 schema already documents both parameters. The description emphasizes 'exact numeroProcesso', adding slight context, but does not significantly enhance understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a single STJ acordao by exact numeroProcesso, with real ruling text. It uses specific verbs and resource names, distinguishing it from sibling search 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?
The description implies use when exact numeroProcesso is known, but does not explicitly state when to use this tool versus alternatives like br_search_case_stj. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one TCU acordao with the real ruling text: acordao_texto
(deliberation), relatorio (rapporteur's report) and voto (vote).
A TCU acordao is uniquely identified by (numero, ano, colegiado) - the
same numero/ano recurs across the Plenario and the two Camaras. When
colegiado is omitted and more than one acordao matches, this errors
and lists the matching bodies instead of guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | Yes | four-digit year, e.g. ``"2026"``. | |
| numero | Yes | acordao number, e.g. ``"1771"``. | |
| colegiado | No | deciding body - ``"Plenário"``, ``"Primeira Câmara"`` or ``"Segunda Câmara"`` (accent-sensitive, as spelled in the index). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. Description adds crucial context: the error behavior when colegiado is omitted and ambiguous, and the exact fields returned. This goes 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core function, followed by essential clarification on uniqueness and error handling. No redundant or verbose content.
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 presence of an output schema and annotations, the description fully explains input, output (three text fields), uniqueness, and error case. No gaps remain for this fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant context: explains that (numero, ano, colegiado) uniquely identify an acordao, and that the same numero/ano recurs across bodies. This enriches understanding beyond basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches a single TCU acordao with specific text fields (acordao_texto, relatorio, voto). It distinguishes from sibling tools that target different courts (CARF, STJ, TST) by specifying 'TCU' explicitly.
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?
Description explains the uniqueness constraint (same numero/ano recurs across bodies) and warns that omitting colegiado when ambiguous causes an error, listing matching bodies. This provides clear guidance on when to include the optional parameter, though it does not explicitly compare to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one TST ruling by its exact CNJ unified process number - real
ruling text (ementa + inteiro_teor).
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | document type (default ``"ACORDAO"``). | ACORDAO |
| numero_processo | Yes | CNJ unified process number, formatted (``"21036-38.2019.5.04.0021"``) or as the raw 20 digits. The fifth segment is 5 (Justica do Trabalho) for every TST case. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds value by specifying the returned content ('real ruling text with ementa + inteiro_teor'), which clarifies the behavioral output beyond 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 a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose and key detail about the returned content.
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 presence of an output schema, the description does not need to explain return structure. It covers the essential purpose, parameter nuances, and a key behavioral trait (returning full ruling text). The tool is well-documented for its complexity.
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 covers both parameters (100% coverage). The description adds meaningful detail: the formatting rule for numero_processo (fifth segment 5) and the default for tipo, which enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a TST ruling by exact CNJ process number and returns the full text. However, it does not explicitly differentiate from sibling tools like br_search_case_tst, which could be used for non-exact searches.
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 implies usage when you have the exact CNJ number, but does not explicitly state when not to use this tool (e.g., for fuzzy search) or mention alternative tools like br_search_case_tst. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a Brazilian Norma Juridica (enacted law/decree/amendment) by its URN Lex.
Identification + Diario Oficial da Uniao publication provenance + amendment history + any STF unconstitutionality notes - NOT the full compiled article text (no confirmed URL rule to Planalto; see DISCOVERY.md).
| Name | Required | Description | Default |
|---|---|---|---|
| urn | Yes | a URN Lex, e.g. ``"urn:lex:br:federal:lei:2002-01-10;10406"`` (Codigo Civil). Must start with ``"urn:lex:br:"`` - never invent one, take it from the user or from another tool's output. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark tool as read-only, open-world, idempotent, non-destructive. Description adds specific data returned (publication provenance, amendment history, STF notes) and what is omitted (full text), providing context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with one main sentence listing contents and exclusions. Uses a dash and parenthetical note, which is slightly dense but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose and annotations, description fully explains what is returned and what is not, including reference to external documentation (DISCOVERY.md). Output schema exists, so return value explanation is not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with description for 'urn'. Tool description adds useful context: format is URN Lex, example given, and instruction not to invent one, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Resolve a Brazilian Norma Juridica... by its URN Lex' with specific items returned and explicit exclusion of full text, distinguishing it from siblings like br_get_norma_texto.
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?
Describes what the tool returns (metadata, provenance, history) and what it does not (full article text). Mentions no confirmed URL rule to Planalto and references DISCOVERY.md, but does not explicitly state when to use or avoid this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the addressable structure of a Norma Juridica: parts, books, titles, chapters, sections, and articles, in document order.
Use this to find the dispositivo suffix for the article you need (e.g.
"art5"), then pass it to br_get_norma_texto - do not guess a suffix.
| Name | Required | Description | Default |
|---|---|---|---|
| urn | Yes | a URN Lex, e.g. ``"urn:lex:br:federal:lei:2002-01-10;10406"`` (Codigo Civil). Must start with ``"urn:lex:br:"``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds that structure is returned 'in document order' and that output contains a suffix. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, first sentence states purpose and output, second gives usage guidance. No wasted words, front-loaded with key information.
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?
Output schema exists so return values not needed. Description covers purpose, usage flow with sibling, and document order. Adequate for a single-parameter tool with rich annotations.
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 covers 100% with clear description of the urn parameter. Description does not add extra meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'addressable structure of a Norma Juridica', enumerating parts like parts, books, titles, etc. It distinguishes from siblings like br_get_norma and br_get_norma_texto.
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?
Explicitly tells when to use: find the 'dispositivo' suffix for an article, then pass to br_get_norma_texto. Includes negative instruction 'do not guess a suffix' and a concrete example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the real text of one dispositivo (article, or a titulo/capitulo header) of a Norma Juridica.
An article's text includes its caput and every paragraph/inciso/alinea beneath it, concatenated in document order - not a summary.
| Name | Required | Description | Default |
|---|---|---|---|
| urn | Yes | a URN Lex, e.g. ``"urn:lex:br:federal:lei:2002-01-10;10406"``. | |
| dispositivo | Yes | a suffix from `br_get_norma_index`, e.g. ``"art5"``. Never guess one - a wrong suffix returns `not_found`, it does not silently fall back to a different article. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's read-only, idempotent, and non-destructive. The description adds valuable behavioral context: the text includes caput and all nested sub-elements concatenated in document order, and it is not a summary. It also clarifies error behavior on incorrect input. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences. The first sentence states the core function, the second clarifies what the text includes and excludes. No unnecessary words. Efficiently front-loaded with the key action.
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 presence of an output schema (not shown), high schema coverage, and detailed annotations, the description covers all essential aspects: what the tool returns, how parameters should be used, and error behavior. No apparent gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with detailed descriptions for both parameters. The description reinforces the meaning of 'dispositivo' (must come from br_get_norma_index, no guessing) but does not add new parameter-specific semantics beyond the schema. Baseline is 3, raised to 4 for the explicit warning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches the real text of one dispositivo (article or header) of a Norma Juridica, distinguishing it from siblings like br_get_norma_index (which returns an index) and br_get_norma (which likely returns the whole norma). The specific verb 'fetch real text' and the scope 'one dispositivo' provide precise purpose.
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 warns against guessing the dispositivo suffix and specifies that a wrong suffix returns 'not_found' with no fallback, guiding correct usage. It implies this tool is for detailed text extraction, but does not explicitly mention when to use it over siblings such as br_get_norma or br_get_norma_index. Still, the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one court docket by its exact CNJ unified process number.
| Name | Required | Description | Default |
|---|---|---|---|
| tribunal | Yes | one of the supported tribunal codes, e.g. ``"STJ"``. | |
| numero_processo | Yes | the CNJ unified process number (digits, punctuation ignored), e.g. ``"5000035-87.2010.8.21.0057"``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool's safety profile is covered. The description adds value by specifying that it fetches exactly one docket and requires an exact CNJ number, which is a behavioral constraint beyond the annotations. No contradictions.
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?
Single sentence that is front-loaded with the key action and resource. No redundant or filler content. Every word earns its keep.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (fetch one item by ID), the presence of annotations covering safety, and the existence of an output schema, the description is sufficiently complete. It provides the essential information for an agent to 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% with clear descriptions for both parameters, and the tool description adds clarifying notes: tribunal code (e.g., 'STJ') and numero_processo format with parentheses and punctuation ignored. This extra context (format, example) moves beyond the schema baseline of 3 to a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'one court docket', and the specific method 'by its exact CNJ unified process number'. This differentiates it from sibling tools like br_search_processos (search) and court-specific get tools (e.g., br_get_case_stj) by being generic and requiring an exact match.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that for court-specific dockets the dedicated get tools should be used, nor does it specify that it should not be used for searching or partial matches. The description only implies exact match via 'exact CNJ unified process number' but provides no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full detail (including current status) for one bill by its numeric id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | the Camara dos Deputados proposicao id (from ``br_search_proposicoes``). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false. The description adds that the tool returns 'current status', implying dynamic data, but this is consistent with annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key information. Every word is necessary and there is no redundancy.
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 only one parameter and an output schema available, the description fully covers what the tool does, what the parameter is, and what the output contains (full detail including current status).
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%. The description adds context for the 'id' parameter by specifying its source ('from br_search_proposicoes'), which goes beyond the schema's description and helps the agent understand where to obtain the id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('full detail for one bill'), and includes a specific detail ('including current status'). It distinguishes from sibling tools that deal with other entities (cases, normas, processos) or search operations.
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 implies that this tool is used when you have a numeric id, likely from a search tool like 'br_search_proposicoes'. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search STJ (Superior Tribunal de Justica) acordaos - real ruling text.
Unlike br_search_processos (DataJud, metadata only), this returns the
actual ementa (headnote) and decisao (ruling body prose) from the
STJ Open Data Portal. Scans the most recent monthly bulk files for one
orgao julgador (chamber/section) - a miss means "not in the scanned
window", not "does not exist". Coverage starts May 2022.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max results (default 20). | |
| orgao | Yes | deciding chamber/section, one of the keys in the supported list, e.g. ``"CORTE ESPECIAL"``, ``"TERCEIRA TURMA"``. | |
| query | Yes | free text - a process/registration number (6+ digits) matches exactly; anything else matches `ministroRelator` or `ementa` (case-insensitive substring). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 crucial behavioral context: it scans monthly bulk files, a miss means 'not in scanned window' not 'does not exist', and coverage starts May 2022. This fully discloses behavior 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: first states purpose, second differentiates from sibling, third explains scanning behavior and coverage. Front-loaded, no unnecessary details, 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?
With output schema present and annotations covering safety, the description is quite complete. It covers purpose, differentiation, behavioral notes, and coverage start. However, it could slightly improve by explicitly stating that results may not be real-time due to monthly file scans, though it is implied.
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 baseline is 3. The description does not add significant new meaning beyond the schema for any parameter. It restates that orgao is a chamber/section and query matches process number or text, but the schema already provides equivalent descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches STJ acordaos and returns actual ruling text (ementa and decisao). It explicitly contrasts with sibling br_search_processos (metadata only), providing a specific verb+resource combination that distinguishes it from other similar 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?
The description explicitly says 'Unlike br_search_processos (DataJud, metadata only), this returns the actual...' which directly guides when to use this tool vs the sibling. It also explains the scanning window limitation and coverage start, setting proper expectations for results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search TCU (Federal Court of Accounts) acordaos - public-procurement and public-spending jurisprudence.
Returns summaries (sumario) plus the index's own total. Use
br_get_case_tcu for the full ruling text of one acordao. The query
supports the portal's own field-scoped syntax in addition to plain
words, e.g. NUMACORDAO:1771 ANOACORDAO:2026.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max results (default 20). | |
| query | Yes | free text or field-scoped query. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe read-only, idempotent behavior. Description adds that it returns summaries plus index total, which is useful context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded purpose, no fluff. Every sentence adds value: purpose, alternative tool, query syntax.
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?
Output schema exists, so return values are covered. Description explains it returns summaries and index total, and how to get full text. For a search tool, this is complete.
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 covers 100% of parameters. Description adds value by explaining field-scoped query syntax with example, and noting limit defaults to 20, which is helpful beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Search', resource 'TCU acordaos', and domain 'public-procurement and public-spending jurisprudence'. Clearly distinguishes from sibling tools like br_get_case_tcu (full text) and other court searches.
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?
Explicitly directs to br_get_case_tcu for full ruling text, providing an alternative. Also explains query supports field-scoped syntax with example, aiding correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search TST (labor supreme court) rulings by free text - real ruling text.
The query goes into the TST frontend's own "contendo as palavras" (AND)
field - quote an expression for an exact-phrase match, e.g.
"adicional de insalubridade". Returns the index's own total plus a
page of records carrying the real ementa and inteiro_teor prose.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | document type - ``"ACORDAO"`` (default), ``"DESPACHO"``, ``"SUM"`` (sumulas), ``"OJ"`` (orientacoes jurisprudenciais), ``"PN"``, ``"DESPGP"``, ``"DESPGVP"``, ``"DESPGCG"``. | ACORDAO |
| limit | No | max results per page (default 20). | |
| query | Yes | free text (AND semantics; quotes for exact phrase). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining that the query goes into the TST frontend field, the return includes index total and a page with ementa and inteiro_teor. It is consistent with readOnlyHint, idempotentHint, and openWorldHint, and no contradictions exist.
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?
Three sentences, front-loaded purpose, each sentence providing essential information without redundancy. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description adequately covers input semantics and output structure, making it complete for the tool's complexity of 3 parameters and a simple return type.
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%, but the description enhances understanding by explaining the query field and providing an exact phrase example. It also describes the output fields, adding meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches TST (labor supreme court) rulings by free text using real ruling text. It distinguishes from sibling tools which target other courts or legal entities, providing a specific verb and resource.
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 explains when to use (for TST ruling search) and details query semantics like AND and exact phrase matching. While it doesn't explicitly mention when not to use, the sibling context makes alternatives clear, and the description lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search court dockets (procedural metadata, NOT ruling text) in one tribunal's DataJud CNJ index.
DataJud carries classe/assuntos/orgaoJulgador and the full procedural
timeline (movimentos) for each docket - it does not carry the prose
text of a ruling/acordao/ementa. STF is not covered (see server docstring).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max results (default 20). | |
| query | Yes | free text - a CNJ process number (15+ digits) matches `numeroProcesso` exactly; anything else matches `classe.nome`. | |
| tribunal | Yes | one of the supported tribunal codes, e.g. ``"STJ"``, ``"TST"``, ``"TRF1"``, ``"TJSP"``, ``"TRT2"``, ``"TRE-SP"``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only, idempotent, non-destructive traits. The description adds behavioral context: what data is included (timeline, metadata) and excluded (ruling text), and coverage limits (STF not covered). This goes 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences, front-loaded with purpose, no wasted words. Efficient and clear.
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?
The description covers key aspects: what is searched, what is excluded, coverage, and references additional documentation. Output schema exists, so return format is not needed. Minor gap: no explicit comparison with sibling tools, but overall sufficient for agent 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?
Schema covers all three parameters with descriptions (100% coverage). The main description does not add significant new parameter information beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches court dockets (procedural metadata) in a tribunal's DataJud CNJ index, specifically excluding ruling text. It distinguishes from siblings by describing the resource and coverage (e.g., STF not covered).
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 does not explicitly state when to use this tool versus alternatives. It implies usage for procedural metadata and mentions exclusions (no ruling text, no STF), but lacks direct guidance on when to prefer other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Brazilian federal bills (proposicoes) of a given type and year.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | Yes | year, e.g. ``2024``. | |
| itens | No | max results (default 20, API caps around 100). | |
| sigla_tipo | Yes | bill type code, e.g. ``"PL"`` (Projeto de Lei), ``"PLP"``, ``"PEC"``. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds context about the scope (federal bills) and the required filters. No behavioral traits beyond annotations are needed, and the description aligns 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 a single concise sentence that conveys the essential action and constraints. No wasted words; it is front-loaded with the verb and resource.
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 low complexity, small number of parameters, and presence of output schema and annotations, the description is complete enough. It tells the agent exactly what the tool does and what inputs are required. No gaps are apparent.
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 covers all 3 parameters with descriptions. The description reinforces the purpose of sigla_tipo and ano. For itens, the default and API cap are noted, adding useful detail beyond the schema. No enums or further nuance needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (List) and identifies the resource (Brazilian federal bills) with clear filters (type and year). It distinguishes from sibling tools that retrieve specific cases (br_get_case_*) or norms (br_get_norma*), making the tool's role unambiguous.
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 implies when to use it (when you need a list filtered by type and year) but does not explicitly state when not to use it or mention alternatives. Sibling tools are listed but not contrasted, so the agent must infer from names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.8.3br_coveragev0.7.0br_get_case_carfbr_get_case_stjbr_get_case_tcubr_get_case_tstbr_get_normabr_get_norma_indexbr_get_norma_textobr_get_processobr_get_proposicaobr_search_case_stjbr_search_case_tcubr_search_case_tstbr_search_processosbr_search_proposicoesEach tool targets a distinct court or entity (STJ, TCU, TST, CARF, Normas, Proposicoes) and a distinct action (get exact vs search free text). There is no ambiguity between tools; even search_case vs search_processos differ by content type (rulings vs procedural metadata).
The naming follows a clear br_{action}_{entity}_{court} pattern for most tools (e.g., br_get_case_stj, br_search_case_tcu). Minor inconsistencies exist: br_get_processo and br_get_norma lack court suffix, and br_search_processos uses 'processos' instead of 'case', but overall the pattern is predictable.
14 tools is well-scoped for a specialized legal research server. The number covers core retrieval operations for multiple high courts and norms without being excessive or barebones.
The tool set covers major courts (STJ, TCU, TST, CARF) and norms with get and search capabilities. Notable gaps include absence of STF tools and no direct full-text retrieval for norms (requires index + text two-step). The CARF search is intentionally missing due to upstream limitations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Brazilian Federal Senate open data (legislative, administrative, e-Cidadania).
An MCP server that provides congressional transcripts
Access U.S. congressional data - bills, votes, members, committees - via MCP.
Brazilian legal stack in one MCP: lawsuits, court publications, case law, tenders, certificates.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/matematicsolutions/br-eli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
