This server allows you to search, read, and compile Brazilian legal jurisprudence from JusBrasil, producing ready-to-use citations and Word documents for legal briefs.
buscar_jurisprudencia – Search court decisions with filters for tribunal (STF, STJ, TJs, TRFs, TST, etc.), document type (acordao, sumula, decisao, sentenca, despacho), time period (last 7/30/365 days), and sorting (by date or relevance). Returns title, court, CNJ number, date, summary (ementa), and URL.
buscar_sumulas – Dedicated search for legal súmulas (binding precedents), with optional filtering by tribunal.
ler_decisao – Extract full metadata from a specific decision URL, including title, tribunal, CNJ number, rapporteur, judging body, judgment/publication dates, full ementa, and a pre-formatted ABNT citation string.
ler_inteiro_teor – Retrieve the complete text of a ruling (relatório + voto + acórdão). Requires authenticated login credentials; returns text, character count, and authentication status.
compilar_dossie – Aggregate multiple decisions/súmulas into a single .docx Word document, including formatted citations, ementas, verification links, and optionally the full text of each decision.
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., "@jusbrasil-mcp Search STJ decisions on consumer protection from last year"
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.
Servidor MCP para pesquisar jurisprudência no JusBrasil em linguagem natural, ler o inteiro teor das decisões e gerar citações e dossiês .docx prontos para uso em peças jurídicas. Pensado para o Claude Desktop.
Ferramenta | O que faz |
| busca com filtros: tribunal ( |
| busca dedicada de súmulas |
| metadados + ementa + |
| texto integral do acórdão (relatório + voto + acórdão) — exige login |
| reúne várias decisões/súmulas num único |
Related MCP server: saij-mcp
Coleta via Scrapling StealthyFetcher — atravessa o Cloudflare em headless puro (sem janela).
Login automático com as suas credenciais, guardadas apenas no cofre do sistema (Keychain no macOS, Gerenciador de Credenciais no Windows), com sessão persistente. O login só é necessário para o inteiro teor e para desmascarar números/metadados; sem credenciais, opera anônimo (com dados parciais).
Parsing a partir do JSON estruturado (__NEXT_DATA__ / Apollo) embutido nas páginas — não de HTML frágil.
Citação por tribunal: formato convencional do STJ e genérico para TJs/TRFs/TST.
Requer uv, Python 3.12+ e Google Chrome instalado.
git clone https://github.com/fxbarros/MCP-Jusbrasil.git mcp-jusbrasil
cd mcp-jusbrasil
uv sync
uv run scrapling install # navegador usado pelo Scrapling
uv run python setup_credenciais.py # grava e-mail/senha do JusBrasil no cofreAs credenciais ficam somente no cofre de credenciais do sistema (serviço mcp-jusbrasil) — nunca em arquivo. O keyring escolhe o cofre certo automaticamente em macOS e Windows; o mesmo setup_credenciais.py serve para os dois.
{
"mcpServers": {
"jusbrasil": {
"command": "uv",
"args": ["run", "--directory", "/caminho/para/mcp-jusbrasil", "jusbrasil-mcp"]
}
}
}Variável | Padrão | Descrição |
|
| Timeout por navegação (ms) |
Roda sempre headless (sem janela). Exemplo de conversa:
Você: Busque acórdãos do STJ dos últimos 30 dias sobre penhora de bem de família.
Claude: [buscar_jurisprudencia] → resultados com citação e link.
Você: Lê o inteiro teor do segundo e monta um dossiê .docx com os três melhores.
Claude: [ler_inteiro_teor] → [compilar_dossie] → dossie.docx salvo.O filtro de tribunal aceita corte específica (TJ-PI, TJSP, TRF1) ou grupo (TJs, TRFs, TRTs), além dos superiores (STJ, STF…), com vários separados por vírgula.
O filtro de data é por período relativo (últimos N dias), não por intervalo exato.
O inteiro teor nem sempre existe para toda decisão.
Os filtros dependem dos parâmetros atuais do site e podem quebrar se o JusBrasil mudar.
O JusBrasil é um agregador privado, não é fonte oficial. Para citação formal, confira sempre o texto no site oficial do tribunal. As ferramentas incluem avisos anti-alucinação: campos não extraídos voltam nulos e não devem ser preenchidos por inferência. Respeite os termos de uso do site.
MIT. Construído por Fábio Ximenes Barros.
Pesquisa jurisprudencia no JusBrasil, com filtros reais do site.
Args:
query: termos de busca (ex: "dano moral atraso voo").
limite: numero maximo de resultados (1-50). Padrao: 10.
tribunal: filtra por sistema de tribunal. Valores: "STF", "STJ", "TST",
"TJs" (todos os TJs), "TRFs", "TRTs", "TSE", "STM", "TCU". Aceita varios
separados por virgula (ex: "STJ,STF"). (Filtro de tribunal especifico,
tipo TJ-PI isolado, nao e suportado por este filtro de topo.)
tipo: tipo de julgado. Valores: "acordao", "sumula", "decisao"
(monocratica), "sentenca", "despacho", "orientacao".
periodo: recorte de data por periodo recente. Valores: "7dias", "30dias",
"365dias" (ou apelidos "ultima semana"/"ultimo mes"/"ultimo ano", ou um
numero de dias). Obs.: o JusBrasil filtra por periodo relativo, nao por
data inicial/final exata.
ordenacao: "data" (mais recentes) ou "relevancia" (padrao).
Returns:
Lista de dicts com titulo, tribunal, numero_cnj, data, ementa, url.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | ||
| query | Yes | ||
| limite | No | ||
| periodo | No | ||
| tribunal | No | ||
| ordenacao | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: the periodo filter uses relative dates (not exact), the tribunal filter accepts multiple values separated by commas, and the return format is a list of dicts with specific fields. This goes beyond basic functionality, but does not mention rate limits, authentication, or side effects (likely none).
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 well-structured with Args and Returns sections, front-loading the purpose. It is appropriately sized but could be slightly more concise—some parameter descriptions are verbose (e.g., tribunal notes). However, no sentence is wasted, and the format aids readability.
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 complexity (6 parameters, need for output description) and presence of an output schema (mentioned as returning list of dicts), the description is thorough. It covers all parameters and return values. Minor gaps: no mention of error cases or pagination beyond limite, but overall adequate.
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 0% description coverage (no descriptions in schema properties). The tool description compensates fully by explaining each parameter with examples, default values, allowed values (e.g., tribunal values: 'STF', 'STJ', etc.), and behavior (e.g., periodo relative). This adds significant meaning beyond the raw 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 'Pesquisa jurisprudencia no JusBrasil, com filtros reais do site,' specifying the action (search jurisprudence), source (JusBrasil), and distinguishing feature (real site filters). It differentiates from sibling tools like buscar_sumulas (search summaries) and ler_decisao (read decision), which have different purposes.
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 explains parameters and acceptable values, providing context on when to use filters. However, it does not explicitly state when to use this tool over alternatives, nor does it mention when not to use it. There is no direct comparison to siblings, leaving the agent to infer from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pesquisa sumulas no JusBrasil (usa o filtro real jurisType=sumula).
Args:
query: termos de busca (ex.: "negativacao indevida", "dano moral").
limite: numero maximo de resultados (1-50). Padrao: 10.
tribunal: opcional — filtra por sistema de tribunal ("STJ", "STF", "TST", ...).
Returns:
Lista de dicts com titulo, tribunal, numero_cnj, data, ementa, url.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limite | No | ||
| tribunal | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only explains the search behavior, not side effects, authentication needs, or rate limits. Minimal disclosure beyond the obvious.
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 concise (two main sentences plus structured Args/Returns), front-loads the key purpose, and uses clear formatting. Every sentence adds value.
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 simple search tool with few parameters and an output schema, the description adequately covers functionality, return fields, and parameter details. Could mention pagination but limite param addresses limit.
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 description significantly adds meaning beyond the schema titles, explaining each parameter's purpose, format, and defaults. For example, 'query' is terms, 'limite' has range and default, 'tribunal' is optional with examples.
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 tool name and description clearly indicate it searches for 'sumulas' (precedents) on JusBrasil, using a specific filter. It is distinct from sibling 'buscar_jurisprudencia' which likely searches general jurisprudence, though not explicitly stated.
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 is given on when to use this tool versus alternatives, or when not to use it. The description merely states what it does without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compila varias decisoes/sumulas num UNICO documento Word (.docx).
Para cada URL, monta uma secao com a citacao formatada, a ementa, o link de
verificacao (JusBrasil) e, se pedido, o inteiro teor. Use depois de escolher,
com `buscar_jurisprudencia`/`buscar_sumulas`, quais decisoes quer reunir.
Args:
urls: lista de URLs de decisoes/sumulas (campo `url` das buscas).
incluir_inteiro_teor: se True, inclui o texto integral de cada decisao
(mais lento; exige login e nem toda decisao tem inteiro teor).
titulo: titulo do dossie (padrao: "Dossiê de Jurisprudência").
caminho: caminho .docx de saida (padrao: ~/Downloads/<titulo>-<data>.docx).
Returns:
Dict com arquivo (caminho salvo), n_itens, n_falhas, com_inteiro_teor.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| titulo | No | ||
| caminho | No | ||
| incluir_inteiro_teor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses that including full text requires login, is slower, and not always available. It also mentions return dict structure. Could mention overwrite behavior, but overall transparent.
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 well-structured with summary then args, but slightly verbose. Front-loaded with purpose. Could be tightened, but still effective.
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?
No output schema, but description explains return dict (arquivo, n_itens, n_falhas, com_inteiro_teor). Covers slower behavior and login requirements. Complete for a compilation 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 description coverage is 0%, so description fully compensates. Explains each parameter: urls (list of URLs), incluir_inteiro_teor (boolean with default and caveats), titulo (default), caminho (default). Adds meaning 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 compiles multiple decisions/sumulas into a single Word document, using the specific verb 'compilar' and resource 'UNICO documento Word (.docx)'. It also distinguishes from siblings by referencing 'buscar_jurisprudencia' and 'buscar_sumulas' as prior steps.
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 says 'Use depois de escolher, com buscar_jurisprudencia/buscar_sumulas, quais decisoes quer reunir', providing clear when-to-use guidance and reference to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Le uma decisao individual do JusBrasil e extrai todos os metadados.
Use APOS `buscar_jurisprudencia` para montar citacoes completas em peticoes.
A busca da ementa curta; use esta tool para pegar os dados formais
(relator, orgao julgador, data de julgamento) da decisao que voce quer citar.
IMPORTANTE - ANTI-ALUCINACAO:
- Se qualquer campo retornar None/vazio (especialmente `ementa`), NUNCA invente
nem reconstrua o conteudo com base em memoria ou conhecimento geral.
- Campos nulos indicam FALHA DE EXTRACAO ou AUSENCIA REAL no JusBrasil,
nao sao convite para preencher com texto plausivel.
- Verifique sempre o campo `_parse_warnings` no retorno. Se ele existir, siga
estritamente suas instrucoes e comunique ao usuario.
- Para uso em peticao, oriente o usuario a conferir o texto oficial
diretamente no site do tribunal (scon.stj.jus.br, sites dos TJs, etc.).
- JusBrasil eh agregador privado, NAO eh fonte oficial para citacao formal.
Args:
url: URL da decisao (ex: "https://www.jusbrasil.com.br/jurisprudencia/tj-pi/1629196340").
Pegue a URL do campo `url` retornado por `buscar_jurisprudencia`.
Returns:
Dict com:
- titulo, tribunal, tipo (Apelacao Civel, etc.)
- numero_cnj (formato 0000000-00.0000.0.00.0000 pronto pra citacao)
- relator, orgao_julgador, data_julgamento, data_publicacao
- ementa (texto completo)
- citacao_abnt: string ja formatada estilo "(TJ-PI - Apelacao Civel: NNN, Relator: ..., ...)"
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses that null fields indicate extraction failure or actual absence, warns against inventing content, and instructs to check _parse_warnings. It also clarifies the non-official nature of JusBrasil, which is critical for the tool's usage.
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 well-structured with clear sections (purpose, usage, anti-hallucination, args, returns). It is somewhat lengthy but every sentence serves a purpose. Minor redundancy could be trimmed, but overall it is efficiently organized.
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 no output schema and the complexity of the tool (extracting multiple fields, handling failures, anti-hallucination), the description is remarkably complete. It lists all return fields, provides the citation format, and includes critical usage warnings.
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 single parameter 'url' is exhaustively described: it provides an example URL, explains where to obtain it (from buscar_jurisprudencia's 'url' field), and clarifies it should be the full URL. With 0% coverage from the schema, the description fully compensates.
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 reads an individual decision from JusBrasil and extracts all metadata. It differentiates from siblings by specifying it is used after buscar_jurisprudencia to obtain formal data (relator, orgao julgador, data de julgamento) for citations. The verb 'ler' and resource 'decisao' are precise.
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 states when to use (after buscar_jurisprudencia) and provides context for building citations in petitions. It also includes anti-hallucination instructions and warnings about JusBrasil not being an official source, guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extrai o TEXTO INTEGRAL de uma decisao (relatorio + voto + acordao completos).
Diferente de `ler_decisao` (que traz so metadados + ementa), esta tool retorna
o inteiro teor do julgado. EXIGE login (credenciais configuradas no Keychain);
sem sessao autenticada o conteudo nao vem.
IMPORTANTE - ANTI-ALUCINACAO:
- Se `texto` voltar nulo/vazio, NUNCA invente o conteudo do acordao. Significa
que o inteiro teor nao esta disponivel no JusBrasil para esta decisao, ou que
a sessao nao esta autenticada. Informe o usuario e oriente a consultar o
inteiro teor no site oficial do tribunal.
- Verifique `_parse_warnings` no retorno e siga suas instrucoes.
- JusBrasil eh agregador privado, NAO eh fonte oficial para citacao formal.
Args:
url: URL da decisao (ex.: ".../jurisprudencia/tj-pi/1629196340") OU a URL
direta de inteiro teor (".../inteiro-teor-NNN").
Returns:
Dict com url, url_inteiro_teor, texto (texto integral), n_caracteres,
autenticado (bool).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes login requirement, behavior when no session, anti-hallucination instructions, limitations of JusBrasil, and return format. No annotations present so description carries full burden and does it thoroughly.
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?
Well-structured with clear sections, but slightly verbose with repeated emphasis on anti-hallucination. Every sentence is valuable, though could be tightened.
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?
Covers all important aspects: purpose, usage distinction, authentication, error handling, return format, and source reliability. No output schema, but description explains return dict fields fully.
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 provides no description for url, but the tool's Args section explains that url can be a decision URL or a direct full-text URL with example. This adds essential 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?
Description clearly states it extracts full text of a decision (report, vote, full judgment) and distinguishes from sibling ler_decisao which only returns metadata and summary.
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 contrasts with ler_decisao, provides authentication requirement, anti-hallucination guidance on null texto, and warns that JusBrasil is not official source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools are mostly distinct, with buscar_jurisprudencia and buscar_sumulas sharing similar but clarified purposes. The two reading tools (ler_decisao and ler_inteiro_teor) could cause confusion, but the descriptions clearly differentiate metadata extraction from full text retrieval.
All tool names follow a consistent verb_noun pattern in Brazilian Portuguese (e.g., buscar_jurisprudencia, compilar_dossie), making it easy to infer each tool's purpose.
With 5 tools, the server is well-scoped for legal research, covering searching, reading decisions, and compiling dossiers. The count is neither too few nor excessive.
The tool set covers the core workflow of searching, reading, and compiling jurisprudence. Minor gaps exist, such as lack of support for specific court filters and reliance on external login for full text, but the overall functionality is sufficient for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Case law search, court decisions and súmulas, across indexed public sources (STF, STJ, TST, state co
Search Brazilian case law from federal and state courts with verified decisions and source links.
Busca e verifica jurisprudência brasileira real (+400 mil julgados) — anti-alucinação para IA.
Busca semantica de jurisprudencia brasileira: STJ, STF e 9 tribunais estaduais, 650 mil+ decisoes.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/fxbarros/mcp-jusbrasil'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
