MCP-SPA-PMT

by fxbarros

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources: boxes, processes, documents, notifications, and deadline summaries. The main overlap is between baixar_processo and baixar_documento_judicial (when called without an id), but their descriptions clarify different sources and purposes.
Naming Consistency3/5
The set is split between verb_noun names (listar_caixa, buscar_processo, baixar_processo, etc.) and noun-only or noun-adjective names (notificacoes, prazos_urgentes, entradas_recentes, triagem). While mixed, the names remain readable and somewhat predictable.
Tool Count5/5
With 12 tools, the server is well-scoped for legal process consultation. Each tool serves a distinct step in the workflow—listing, searching, retrieving, downloading, reading, and summarizing—without unnecessary bloat.
Completeness4/5
The toolset covers the core consultative lifecycle: list boxes, search and get processes, download full cases or individual documents, extract text, and generate deadline/recent-entry briefings. It lacks write operations like moving processes or taking official notice, but the read-only focus appears intentional, so gaps are minor.
Average 4/5 across 12 of 12 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations available, the description carries the full burden of disclosure, but it only provides context about the source (SPA bell) and audience (logged-in attorney). It does not disclose whether the tool lists notifications, marks them as read, or requires specific permissions, leaving significant behavioral gaps.
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, concise sentence that directly states the purpose without unnecessary words. It is appropriately sized and front-loaded with the key 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?
While the tool is simple with no parameters and has an output schema, the description is sparse. It explains what the tool is about but does not clarify the action (e.g., whether it lists or retrieves notifications) or provide any context about the notification behavior, making it minimally adequate but not fully 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?
The tool has zero parameters, so the baseline is 4. The description provides no parameter-specific information, but none is needed given the empty schema, and the context about notifications adds value for understanding what the tool returns.
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 identifies the tool as handling SPA bell notifications for the logged-in attorney, which is clear and distinct from sibling tools focused on processes and documents. However, it lacks an explicit verb like 'list' or 'get', so the action is implied rather than 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. The description simply states what it is, leaving the agent to infer that it is for retrieving notifications, with no mention of exclusions or 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?
Annotations are entirely absent, so the description carries the full burden. It discloses the search criteria but doesn't mention that the operation is read-only, any rate limits, pagination behavior, or what the response contains. This is a notable gap for a search tool.
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, front-loaded sentence that directly conveys the purpose and parameter semantics with zero wasted 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?
For a simple one-parameter search tool with an output schema, the description covers the core purpose and parameter meaning. Still, it lacks explicit usage guidelines and behavioral details (e.g., read-only confirmation), leaving some gaps for an AI agent deciding between tools.
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 single parameter 'termo' is explicitly explained as accepting a CNJ number, party name, or CPF/CNPJ, which adds significant meaning beyond the bare schema. However, it doesn't specify formatting details (e.g., CNJ punctuation), so it's not exhaustive.
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 searches processos in SPA-PMT by CNJ number, party name, or CPF/CNPJ, with a specific verb ('Busca') and resource. It distinguishes itself by noting it's the global top-of-system search, but it doesn't explicitly name alternative tools for different use 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 phrase 'a busca global do topo do sistema' implies this is the general-purpose search tool, but it doesn't explicitly state when to use it over siblings like obter_processo or listar_caixa, nor does it mention any exclusions or prerequisites.
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 burden of explaining behavior. It discloses the interpretation of 'prazo vigente' (the closest future date from a field that accumulates historical deadlines) and clarifies that negative remaining days indicate overdue processes. This is meaningful context beyond the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences that front-load the main purpose and then provide necessary detail about the deadline logic. There is no wasted wording, and the structure is logical.
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 core scanning behavior, ordering, and the vigente calculation, and mentions the output field `prazo_completo`. However, it omits explanations for two of the three parameters and does not describe pagination or edge cases, leaving the tool only partially specified.
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%, so the description must explain the parameters. It clearly explains `dias` (the lookahead window) but leaves `por_fluxo` and `incluir_atrasados` completely unexplained, creating a significant gap for a tool with only three 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 clearly states it scans all user boxes and returns processes with deadlines within the next `dias` days, sorted by urgency. The action and resource are specific, though it does not explicitly differentiate from sibling tools like listar_caixa or buscar_processo.
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 when to use this tool (to find processes with upcoming deadlines) but does not provide explicit guidance, exclusions, or alternatives. It does not mention when not to use it or which sibling tool would be preferable in other scenarios.
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 reveals the data source (PJe/TJPI) and document types, and the verb 'Lista' implies a read-only operation. However, it does not explicitly state read-only nature, pagination, ordering, or potential side effects like triggering a download.
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 front-loads the main action and then adds necessary context about the document source and types. It is reasonably compact, with parenthetical examples adding useful detail without excessive length.
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's low complexity (2 params, output schema exists), the description is adequate: it explains what documents are included and their origin. Return values are not described but are covered by the output schema. It does not address ordering or filters, but that is not critical for a listing tool.
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 input schema already covers both parameters with 100% coverage (numero_processo as CNJ number, soap_setting_id as communication origin). The description adds no additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.
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 'Lista os documentos externos do processo judicial' with a specific verb and resource. It further distinguishes itself from siblings like baixar_documento_judicial and ler_documento_judicial by identifying the 'Pasta do Processo' scope and providing document examples.
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 the use case (listing external judicial documents) but does not explicitly compare with alternative sibling tools or specify when not to use it. There are no named alternatives or exclusions, so guidance is implied rather than explicit.
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 discloses an important behavioral nuance: entry dates may be approximate (±1 day) depending on whether the SPA exposes full tooltips. It also states the ordering behavior. This adds meaningful context beyond the schema, though it doesn't discuss pagination or limits.
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, front-loaded with the core purpose and ordering, followed by a concise explanation of date precision. Every sentence adds value without unnecessary detail.
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?
An output schema exists, so return values don't need explanation. However, the description omits the meaning of the required parameter flow_id and the optional limite, which are part of the tool's correct invocation. The date precision nuance is helpful, but the tool is not fully described for correct use.
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%, so the description must explain all parameters. It explains 'dias' (time window and date precision) but does not clarify the required 'flow_id' (likely the box identifier) or 'limite' (record limit). This leaves critical parameters undocumented for the agent.
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 states a specific verb and resource: lists processes that entered a SPA box within a time window, ordered newest to oldest. This clearly distinguishes it from siblings like 'listar_caixa' (likely current contents) and 'buscar_processo' (search by criteria).
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 retrieving recent arrivals, but it does not explicitly state when to use this tool versus alternatives like listar_caixa or buscar_processo. No exclusions or alternative recommendations are provided.
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 two operating modes and the source system, but lacks details on error handling (e.g., invalid ID), file naming, or required permissions. The description adds value beyond the schema but falls short of full behavioral transparency.
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 with the main action front-loaded and the alternative mode clearly introduced by a dash. Every word contributes to understanding, with no redundancy.
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?
The description covers the core behavior and both modes, and an output schema exists to handle return values. However, with 4 parameters and no annotations, more could be said about parameter semantics and error behavior, but the tool's simplicity makes this adequate.
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 clarifies that documento_id is the ID returned by listar_documentos_judiciais and that omitting it triggers full-case download, but it leaves numero_processo, pasta, and soap_setting_id only partially explained by their names and defaults.
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 that the tool downloads a document from the judicial case folder (PJe/TJPI) using an ID from listar_documentos_judiciais, and also supports downloading complete case files as a single PDF when no ID is provided. It distinguishes itself from sibling tools like listar_documentos_judiciais (which lists) and ler_documento_judicial (which reads content).
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?
It specifies when to use the tool: when you have a document ID from listar_documentos_judiciais or when you want the full case files by omitting the ID. It does not explicitly exclude or compare with baixar_processo, but the two-mode behavior is clearly described, providing adequate usage context.
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 transparency burden. It discloses the key behavior that the tool downloads an integral PDF assembled by the system, which is useful context. However, it does not mention permissions, potential errors, or side effects, though for a download operation this is acceptable.
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, concise sentence that front-loads the action ('Baixa o PDF integral') and includes all essential information without any filler. It is easy to parse and well-structured.
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 download tool with two parameters and an output schema, the description is fairly complete. It explains the output (PDF), destination, and full-process scope. It does not detail error handling or how to obtain the process ID, but these are not critical for using the tool correctly.
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 descriptions are missing (coverage 0%), so the description must compensate. It adds meaning to 'pasta' (indicated folder) through 'para a pasta indicada', but 'id_processo' is only implied via 'do processo' and its name. The description partially clarifies parameters but not 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 that the tool downloads the full PDF of a SPA-PMT process, including all parts in a single file, to a specified folder. The verb 'Baixa' and resource 'processo do SPA-PMT' are specific, and it distinguishes itself from sibling tools like 'baixar_documento_judicial' which handles individual judicial documents.
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 implies the tool is used when a user needs the complete process PDF, as opposed to individual document downloads or process lookup. It provides clear context but does not explicitly mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does well: it states it scans all boxes, aggregates entries from the last N days, summarizes only documents for cases with judicial integration, does not download PDFs, and explicitly declares 'Leitura passiva: não toma ciência nem executa passo de fluxo' (passive read, no state change). It doesn't mention rate limits or error conditions, but the core side-effects and output expectations are clear.
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 long, front-loads the tool's purpose ('TRIAGEM em uma chamada'), and every clause earns its place: scanning all boxes, time-window, judicial integration filter, summary content (description/date), and absence of PDF downloads. No fluff or repetition.
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?
The tool is a read-only triage/aggregation function with three optional parameters and an output schema (not shown). The description covers the full scope: all inboxes, time window, filtering by judicial integration, what is summarized, what is omitted (PDFs), and that no workflow action is taken. With an output schema present, the description need not detail return formatting, making this sufficiently 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 for the three parameters. It explicitly explains the 'dias' parameter in context ('nos últimos `dias` dias'), but does not mention 'max_processos' or 'max_documentos' by name. These names are self-explanatory and the description implies limits via 'para cada processo... resume os documentos mais recentes', but full compensation is not achieved.
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 uses a strong verb 'varre' (scans) and specifies the scope: all mailboxes, gathering items from the last 'dias' days and summarizing recent documents per process. It clearly distinguishes from siblings like listar_caixa (single box) and baixar_documento_judicial (downloads PDFs) by explicitly stating it does not download PDFs and is a passive read-only briefing.
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?
It states the use case: 'TRIAGEM em uma chamada — briefing da caixa do procurador' (one-call triage to get a prosecutor inbox briefing). It implies when to use it (quick overview) and contrasts with alternatives by noting it scans all boxes without downloading files or executing workflow steps. However, it never explicitly names sibling tools as alternatives or gives a 'use X instead' directive.
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 the full burden. It discloses the return contents (header fields, timeline, documents) but does not mention whether the operation is read-only, required permissions, or error behavior for invalid IDs. For a retrieval tool, this is basic 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the action and list the return fields in a structured way. No unnecessary words or filler.
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?
The tool is simple (1 parameter, has an output schema), and the description provides a good overview of what is returned. It doesn't cover error handling or explicit read-only status, but the output schema likely fills in return-value details, making the description adequate though not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the single parameter by explaining it is an 'id interno' and giving a concrete example (25615). With schema description coverage at 0%, this fully compensates for the lack of schema-level parameter documentation.
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 opens/retrieves a process by internal ID and returns specific header fields and the timeline of movimentos with documents. The verb 'Abre' and resource 'processo do SPA-PMT' give a specific action and scope, distinct from siblings like buscar_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 implies the tool should be used when you have the internal ID and need process header and timeline details. It provides clear context but does not explicitly mention alternatives or when not to use it, so it lacks exclusions, aligning with a score of 4.
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 carries the full burden. It clearly indicates a read-only action ('Lista') and describes the output, implying no side effects. It does not mention auth, pagination, or rate limits, but for a zero-parameter list operation this is adequate and not misleading.
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 is front-loaded with the verb and object, then clarifies scope and output. There is no redundant or filler content; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is complete. It states what is listed, the user scope, the system, and the key output attribute (process count). The analogy to 'Meus Processos' adds helpful context, and with an output schema available, nothing else is needed.
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 tool has zero parameters, so the baseline per rubric is 4. The schema is empty and the description adds no parameter-level details, but none are needed. The description appropriately focuses on the list semantics and output content.
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 states a specific verb ('Lista') and resource ('caixas (fluxos)') with scope ('do usuário no SPA-PMT') and output content ('total de processos em cada uma'). It clearly distinguishes from sibling 'listar_caixa' by describing a user-level overview with counts, making its purpose unambiguous.
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 clear context by equating the tool to the 'Meus Processos' tabs, strongly implying when to use it (when an overview of all user's boxes with counts is needed). It does not explicitly name alternatives or exclusions, but the context is sufficient for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behavioral details: the `busca` parameter is applied client-side because server-side filtering triggers HTTP 500 (a bug), and with a search it downloads up to 500 lines and filters locally. It also lists specific known caixa IDs, adding useful context beyond the schema. This exceeds expectations for a simple list 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?
The description is compact and well-structured: a one-sentence summary, then a bulleted list of known caixas. Every line adds value — the list of IDs is practical, and the note about `listar_fluxos` is directly useful. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values are already documented), the description covers all necessary contextual aspects: the tool's purpose, how to specify a caixa, a critical bug behavior, and an alternative tool for getting the list of caixas. It is fully sufficient for an agent to select and invoke this tool correctly.
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?
All four parameters are described in the schema (100% coverage), so the baseline is 3. The description adds extra meaning for the `busca` parameter by explaining the client-side filter and the bug, which is not evident from the schema alone. This additional nuance justifies a 4.
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 'Lista os processos de uma caixa do SPA-PMT (fluxo)' — a specific verb ('Lista') and resource ('processos de uma caixa'). It also distinguishes itself from the sibling tool `listar_fluxos` by noting that `listar_fluxos` provides the updated list of caixas with totals, while this tool lists the processes inside a given caixa.
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 explains when to use this tool: to list processes in a known caixa, and points to `listar_fluxos` as the alternative for retrieving the list of caixas with totals. However, it does not explicitly state when not to use it versus other siblings like `buscar_processo`, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It explains truncation via max_chars, pagination via pagina_inicial, PDF caching for continuation, detection of PJe IDs, and the behavior for scanned attachments (empty response with a warning). This is rich, specific, and goes beyond basic operational 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?
The description is well-structured in three short paragraphs: purpose and ID source, long-document behavior, and scanned attachment edge case. Every sentence adds value, with no redundant repetition of schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete given the tool's complexity and lack of annotations. It covers edge cases (long documents, scanned attachments), explains key output behaviors (truncation, pagination, PJe detection), and provides alternatives. With an output schema present, detailed return values are not necessary here.
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, the description adds meaning to several parameters: max_chars is tied to truncation, pagina_inicial to continuation, and documento_id to the list function. It does not explain soap_setting_id, but it compensates well for the parameters that matter to the user.
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 function: extracting text from a judicial document without saving the file. It specifies the resource type (document in the case folder) and distinguishes it from siblings like baixar_documento_judicial (download) and listar_documentos_judiciais (list).
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 instructs to use listar_documentos_judiciais to obtain the document ID, and for scanned attachments without a text layer, it directs users to baixar_documento_judicial for OCR. This provides clear when-to-use and alternative guidance.
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:

[![MCP-SPA-PMT MCP server](https://glama.ai/mcp/servers/fxbarros/MCP-SPA-PMT/badges/card.svg)](https://glama.ai/mcp/servers/fxbarros/MCP-SPA-PMT)

Score Badge

Copy to your README.md:

[![MCP-SPA-PMT MCP server](https://glama.ai/mcp/servers/fxbarros/MCP-SPA-PMT/badges/score.svg)](https://glama.ai/mcp/servers/fxbarros/MCP-SPA-PMT)

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/fxbarros/MCP-SPA-PMT'

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