Jusratio Case File

Server Quality Checklist

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

Latest release: v0.7.5-beta
Disambiguation5/5
Each tool has a clearly distinct purpose, with detailed descriptions that prevent overlap. Tools like 'abrir_no_computador', 'abrir_pagina', and 'abrir_trecho' target different operations (open PDF externally, extract text, reopen evidence verbatim) without ambiguity.
Naming Consistency4/5
Most tool names follow a consistent verb_noun pattern in Portuguese (e.g., 'abrir_no_computador', 'analisar_caso_civel', 'buscar_no_processo'). However, 'case_file' and 'dossie' deviate from this pattern, and 'linha_do_tempo' is a noun phrase, causing minor inconsistency.
Tool Count4/5
With 21 tools, the set is slightly above the ideal range of 3-15, but it is justified by the complexity of legal case analysis. The tools cover a broad scope, and each serves a specific function, so the count is appropriate despite being on the higher end.
Completeness5/5
The tool set provides comprehensive coverage for legal case analysis, including ingestion, searching, evidence management, OCR, dossiers, jurisprudence integration, and validation. There are no obvious gaps; the surface appears complete for the intended domain.
Average 3.5/5 across 21 of 21 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- Last stable release on July 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions 'com lacunas explicitas' and 'Respeite global_analysis_allowed', but lacks details on side effects, permissions, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences), but the structure is poor due to unexplained jargon and lack of clarity. Conciseness is positive, but at the expense of informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain the tool's purpose, inputs, or outputs adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not mention any parameter names or meanings. The agent has no guidance on what 'case_id', 'objetivo', 'lado', or 'max_items' represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses domain-specific terms like 'cobertura', 'radar processual', and 'pacote de evidencias' without explaining what they mean, making it vague. It does not clearly distinguish from sibling tools like 'analisar_radar_processual_civel'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is 'Respeite global_analysis_allowed', which is a constraint. There is no explanation of when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions output components (evidence_id, coverage, queries) but does not disclose behavioral traits such as side effects, authorization needs, or whether the tool is read-only or destructive. This is insufficient for a mutation-like tool implied by 'montar'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise, though the structure could be improved by separating purpose from output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is severely inadequate. It does not explain the tool's behavior, response format, or when to invoke it, leaving the agent with insufficient information to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the four parameters (case_id, objetivo, lado, max_items). The output components referenced (evidence_id, coverage, queries) are not directly tied to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies that the tool produces a compact package of facts including evidence_id, coverage, and suggested queries for a jurisprudence MCP. This clearly identifies the tool's output components but does not explicitly state the verb or action, leaving some ambiguity about what 'montar' means operationally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions it is for a connected jurisprudence MCP but does not specify conditions, prerequisites, or excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the tool does not emit a final conclusion, which is a behavioral constraint. However, it lacks information on return format, side effects (e.g., mutation), authorization requirements, or whether it depends on external data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is relatively dense and front-loaded with key information. However, it could be slightly more structured to separate purpose from constraints. Overall, it is concise and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and incomplete parameter documentation, the description is insufficient. It fails to specify what the tool returns, how to interpret output, or any dependencies. More context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the parameters. It mentions 'evidence_ids' but no such parameter exists; only 'case_id' and 'lado' are defined. The description adds no meaning to the parameters, leaving ambiguity about how they relate to the stated function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides civil procedural notes (deadlines and opportunities) anchored in evidence_ids and explicitly says it does not emit a final conclusion. However, it does not differentiate from the sibling tool 'analisar_caso_civel', which likely performs a broader analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not specify prerequisites, when not to use, or compare with similar tools like 'analisar_caso_civel'. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description to cover behavioral traits. It states 'reopens' implying state change, but lacks details on consequences, permissions, idempotency, or reversibility. Significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, with two sentences front-loading the purpose and usage. However, it could be more structured with parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two string parameters and no output schema, the description covers the main action and usage context but lacks parameter semantics and behavioral transparency. It is minimally adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters. The description only mentions evidence_id in context, and does not explain the meaning or format of case_id or provide additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (reopens) and the resource (verbatim of evidence by evidence_id). It provides context for when to use the tool, but does not explicitly distinguish it from sibling tools like 'abrir_pagina'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the tool ('before citing any excerpt'), but does not specify when not to use it or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'valida' but does not disclose side effects, return values, permissions, or what happens on failure. This lack of detail limits the agent's understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the purpose and usage. It is efficient and avoids unnecessary words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role as a validation gate, the description is incomplete. It lacks details on return values, validation criteria, or how the agent should handle results. With no output schema and no annotations, the agent is left with significant uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions). The description mentions evidence_ids and doc_ids but does not explain each parameter individually or their relationship. For three required parameters, the description adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates evidence_ids and doc_ids before the final report. It uses the verb 'valida' and specifies the resources, distinguishing it from other sibling tools that focus on analysis or data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Nada deve ser afirmado ao usuario sem passar por aqui', providing a strong usage guideline: use this tool before making any assertions to the user. It implies a mandatory gate-keeping step, though it does not list specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions 'restores state', but does not clarify if it is read-only, has side effects, or requires permissions. It lacks details on what happens or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose and usage. It is efficiently written but could benefit from a more structured format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the main purpose and when to use it. However, it does not specify the return format or what 'restores' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, case_id, but the description does not explain its meaning or format. Schema coverage is 0%, so the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool restores investigation state with findings and evidence IDs. It uses specific verbs and resources, but does not explicitly differentiate from siblings like 'anotar_achado' or 'listar_casos'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to start here when resuming an investigation, providing clear context. It does not list when not to use or alternatives, but the guidance is direct and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns extracted text and a local path/link for the original PDF, which adds transparency beyond the schema. However, it does not disclose whether the operation is read-only, any authentication requirements, or behavior for invalid page numbers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the essential information without extraneous text. Every part is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary function and mentions a key return value (original path/link). However, it lacks details on error handling, return format, and does not specify if the text extraction includes formatting or metadata. Given the simple tool signature, it is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It links 'page' to a specific page and 'case_id' to a process, but provides no additional details about expected formats, bounds, or semantics beyond the schema's min/max.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it extracts text from a specific page of a process, which is clear and specific. However, it does not explicitly differentiate from sibling tools like 'abrir_trecho' or 'buscar_no_processo', and the domain (legal case) is implied but not stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must handle transparency. It discloses the returned content (coverage, events, radar) and notes it excludes full pages, but lacks explicit safety or permission details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded with key information; no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers what the tool returns adequately, though it assumes domain knowledge of 'radar' and 'cobertura'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not mention the required 'case_id' parameter, providing no added meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a compact map of the case, listing specific elements like coverage, dated events, and radar, distinguishing it from sibling tools that open pages or analyze cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a compact overview without full pages, but does not explicitly state when to use over alternatives or provide when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses background ingestion as a key behavioral trait. No annotations are provided, so description carries full burden; missing details on auth requirements, side effects, or error handling. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with purpose. Slightly verbose but efficient; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 3 params, the description is insufficient. Does not cover default area, slug purpose, error conditions, or return value format beyond case_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and description adds no parameter-specific guidance. Only implies pdf_path refers to the PDF; area and slug are completely unexplained, leaving agent unable to determine correct values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates a local case from an existing PDF in an authorized folder and starts background ingestion, with instruction to return case_id and follow with status_caso. This verb+resource combination is distinct from sibling tools like status_caso or retomar_ingestao.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly suggests using after PDF is in authorized folder and to subsequent call status_caso. No explicit when-not or alternative tool comparisons, leaving some ambiguity for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses idempotency, BYOK, and an explicit Gemini call cap, but does not cover authorization needs, error handling, or effects on existing data. Partial transparency is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy: first sentence states purpose and scope, second explains key behavioral traits (opt-in, cap, idempotency). Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and moderate complexity (external API, idempotency, cap), the description lacks return value information, error conditions, and prerequisites (e.g., key setup). Gaps remain for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds minimal parameter context. 'max_calls' is hinted via 'teto explícito de chamadas Gemini', but 'case_id' is not explained at all. The description fails to clarify what these parameters represent or their format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates local embeddings for meaning-based search, using specific verb 'gera' and resource 'embeddings locais'. It distinguishes itself from sibling tools (e.g., 'analisar_caso_civel') by focusing on indexing rather than analysis or navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for semantic indexing with opt-in and a call cap, but does not explicitly specify when to use this tool over alternatives like 'buscar_no_processo' or when not to use it. The idempotency hint is useful but guidance is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It omits behavioral details like overwrite behavior, idempotency, side effects on existing data, or required permissions for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences efficiently convey the tool's core function and its critical role relative to verificar_referencias, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description does not specify output behavior, error handling, or data model effects (e.g., whether registration appends or replaces), leaving agent uninformed about operational outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description adds no explanation for case_id or documentos other than hinting at registration, leaving parameter meaning and constraints largely undeclared.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers real doc_ids from a jurisprudence MCP and uniquely enables verificar_referencias to accept a doc_id, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly recommends use when real doc_ids are available from the connected jurisprudence MCP and as the only path to feed verificar_referencias, providing clear usage context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses important behavioral traits: the hybrid search mode, the nature of hits (allegation in petitions vs fact), and the instruction to open verbatim before citing. This goes beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three impactful sentences. It front-loads the main action and packs critical details without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers purpose, result structure, and a behavioral caveat. However, it lacks details on parameter usage, return format beyond listed fields, and how to process results (e.g., using document IDs).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the three parameters (query, case_id, limit). There is no guidance on what values to use or their effect on results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a local search in process evidence, explains hybrid behavior (semantic vs lexical), and specifies result contents (evidence_id, page, snippet, source document). This distinguishes it from sibling tools like 'abrir_trecho' and 'abrir_pagina'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching within evidence but does not explicitly state when to use this tool versus alternatives. It provides a follow-up action ('abra o verbatim com abrir_trecho antes de citar') but lacks comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the informational outputs (pages, OCR, alerts, job status) but does not specify read-only behavior, authentication needs, or side effects. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and key details. Every element is relevant, and there is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested schemas, no output schema), the description provides the essential purpose and output categories. However, it lacks details on the output format or structure, and could be more complete for an agent to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'case_id' with no description and no enums. Schema coverage is 0%, meaning the schema provides no context beyond the parameter name. The description does not explain what 'case_id' refers to or how to format it, failing to compensate for the schema's lack of information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: showing progress of local ingestion including processed pages, pending OCR, alerts, and job status. It uses a specific verb ('Progresso') and resource ('ingestao local'), and distinguishes from siblings like 'criar_caso_local' (creation) and 'retomar_ingestao' (resumption).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking ingestion status but does not provide explicit guidance on when to use this tool versus alternatives like 'analisar_caso_civel' or 'buscar_no_processo'. No when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states that the tool authorizes OCR, but does not disclose side effects, whether it triggers OCR immediately, or what happens if limits are exceeded. Key behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: the first states the action, the second specifies the condition. No unnecessary words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters and no output schema or annotations, the description provides essential context (authorization limits and condition) but lacks details on prerequisites, what happens post-authorization, and the meaning of 'case_id'. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'max_pages' and 'max_calls' by linking to 'tetos explicitos', but does not explain 'case_id'. The description partially clarifies parameters but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: authorizing OCR BYOK execution with explicit page and call limits. It also specifies the condition when it is obligatory, which distinguishes it from sibling tools that handle different states or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear condition for usage: 'Obrigatorio quando status_caso indicar paused_awaiting_ocr_approval.' This tells the agent exactly when to use the tool. However, it does not mention when not to use it or suggest alternatives, missing explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden. It mentions 'sem repetir trabalho ja feito' (without repeating already done work), which implies idempotent or incremental behavior. However, it does not disclose whether the tool is read-only, modifying, or its safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose and usage conditions efficiently. However, it could be structured to include parameter information without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the key usage scenarios but lacks explanation of the parameter's role and what the tool returns or does upon completion. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'case_id' with no description. The tool description does not mention this parameter, leaving the agent to infer its meaning from the name alone. With 0% schema description coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resumes local ingestion without repeating already done work, and specifies the scenarios for use. The verb 'retomar' (resume) and resource 'ingestao local' are specific, and the tool is distinct from siblings like 'autorizar_ocr' or 'criar_caso_local'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditions for when to use the tool: after client restart, when the Gemini key exists, or after authorizing OCR. This provides clear context, though it does not explicitly list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that the tool is a local curated table, warns against calculating final dates, and mentions optional filtering. However, it lacks details on data freshness, update frequency, or what happens when the filter is applied. The warning is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sentences. The first sentence front-loads the core purpose and source, the second adds optional filter capability, and the third clarifies usage constraint. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the essential aspects: source (curated table), scope (civil deadlines), usage (reference only, no date calculation), and filter availability. It is nearly complete, though could specify what the output looks like (e.g., list of deadlines).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one optional string parameter 'ato', but the description mentions filtering by 'ato/tipo/artigo' (act/type/article), suggesting parameters beyond what is defined. This adds meaning but creates ambiguity about how these filters work given the single parameter. With 0% schema coverage, the description partially compensates but is unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a curated local table of civil deadlines (CPC) with legal basis, serving as the single source for product deadlines. The verb 'consultar' and the explanation 'Referência para conferência do advogado' make the tool's purpose unambiguous. It distinguishes itself from siblings like 'analisar_caso_civel' by focusing on reference only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implicit guidance by stating 'nunca calcule data final' (never calculate final date), implying it is for reference only, not for computation. However, it does not explicitly contrast with alternatives like 'analisar_caso_civel' which might handle deadline calculations, nor does it state when to use this versus other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior: opens locally, reveal option, only within authorized folder. No annotations exist, so description carries full burden adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. Front-loaded with main action. Could combine usage and restriction for slightly tighter structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose, usage context, and constraints. Missing explanation of 'page' parameter and output behavior, but given tool's nature (local open), completeness is good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description explains 'alvo' and 'revelar' (reveal=true reveals file), but 'page' and 'case_id' lack explicit explanation. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it opens PDF of page or full process on user's computer. Distinguishes from siblings like 'abrir_pagina' by specifying 'NO COMPUTADOR' and restricting to authorized folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use quando o usuario quiser VER o original', providing clear context. Does not state when not to use or name alternatives explicitly, but sibling differentiation is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses persistence across sessions, validation of evidence IDs against an index, and the nature of the fact as a short phrase. It does not detail error handling or side effects, but the core behavioral traits are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the core action, the second gives usage guidance. The description is front-loaded and each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description is fairly complete: it explains the action, its persistence, validation, and when to use. It lacks details on return values or error conditions, but for a recording tool, the provided context is sufficient for an agent to make informed decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 'achado' as a short phrase and 'evidence_ids' as array of IDs validated against an index. 'case_id' is not elaborated but is standard in context. The description adds some meaning beyond the schema but could specify constraints more fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it records a fact (achado) with evidence IDs into a persistent dossier for a case. The phrase 'o dossiê sobrevive à compactação da conversa e a novas sessões' differentiates it from ephemeral conversation tools. It also mentions validation against an index, providing 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using during long investigations because the dossier survives conversation compression and new sessions, giving clear context for when to use. It does not explicitly state when not to use or mention alternative tools, but the guidance is effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavior. It discloses that data is extracted from the footer of PJe and includes page range, signer, and date. However, it omits authorization, rate limits, or idempotency details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first defines the index and its contents, second lists use cases. No filler words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description sufficiently explains the tool's purpose and output. It could mention read-only nature, but overall complete for an index tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description adds meaning: it implies case_id is required and clarifies that 'tipo' is an optional filter by document type. This compensates for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides an index of documents with page range, signer, and date, and lists specific use cases (timeline, locate primary source, assign claims). This distinguishes it from siblings like 'abrir_pagina' or 'buscar_no_processo'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (to build a timeline, locate primary source, assign claims) and mentions an optional filter. However, it does not compare with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the burden of disclosing behavior. It covers default file opening, automatic formatting (A4, Times 12, justified, black titles), accent handling in file names, markdown duplication avoidance, and supported markdown elements. This provides good insight into the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but is dense with useful information without being overly long. It could be structured more clearly, but it effectively communicates the main action and key details upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (3 required), no output schema, and no annotations, the description provides enough context: what it does, where it saves, default behavior, formatting, and markdown support. It lacks details on error handling or return values, but for a conversion tool, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has no descriptions (0% coverage), the tool description adds significant meaning for 'titulo' (pass with normal accents, file name generated without them) and 'conteudo_markdown' (supports markdown, no duplication if starts with #, lists, bold/italic, tables, quotes). For 'abrir', it mentions the default is true. For 'case_id', it is only implied in the path. Overall, the description compensates well for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts a report/minuta/pacote to DOCX format, saves it in the exports/ folder within the case directory, and by default opens the file. It specifies the output format, location, and formatting details, distinguishing it from siblings that only open files or perform other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates that final deliverables for the end user should be produced using this tool, and not left as loose files in a temporary folder. While it does not explicitly mention when not to use it or compare to siblings, the context is clear enough for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the output (ordered chronology, events, filing dates) and source context (PJe footer). It implies a read-only operation without side effects, though it does not explicitly state non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with purpose and followed by usage and filter info. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not detail the return structure, but it sufficiently conveys the core functionality and filter options. It lacks error handling or limit mentions, but is adequate for a straightforward list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining the two optional parameters 'de' and 'ate' as ISO-format filters. The required 'case_id' is implied by context. No additional details on format constraints are given, but it adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing a deterministic chronology of the case with dated events and filing dates, and explicitly contrasts it with opening pages individually. This distinguishes it from siblings like 'abrir_pagina'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool (for timeline instead of opening pages one by one) and mentions optional filter parameters. It provides clear context but does not explicitly list when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes what the tool lists but does not explicitly state if the operation is read-only, safe, or if any authentication is required. However, the nature of listing implies a read operation, so it is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise, and front-loaded with the action. Every word serves a purpose, with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should indicate what the tool returns. It specifies that it lists cases with parts, pages, status, and findings, providing sufficient context for an AI agent to understand the return values. Slightly more detail could be beneficial, but it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. The description does not need to add parameter details since there are none. A baseline score of 4 is appropriate for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists existing cases in the authorized folder with specific details (parties, pages, status, findings). It provides a verb+resource description and distinguishes from siblings by specifying when to use (when user doesn't name the case).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use quando o usuário não nomear o caso — NUNCA presuma qual é.' This gives clear guidance on when to use the tool and what not to do, differentiating it from tools that require a specific case name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![jusratio-case-file MCP server](https://glama.ai/mcp/servers/carlosvictorodrigues/jusratio-case-file/badges/card.svg)](https://glama.ai/mcp/servers/carlosvictorodrigues/jusratio-case-file)

Score Badge

Copy to your README.md:

[![jusratio-case-file MCP server](https://glama.ai/mcp/servers/carlosvictorodrigues/jusratio-case-file/badges/score.svg)](https://glama.ai/mcp/servers/carlosvictorodrigues/jusratio-case-file)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/carlosvictorodrigues/jusratio-case-file'

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