MPF: Processos, consulta em fonte oficial. Hospedado pela plataforma, sem credenciais da plataforma, pague por consulta com crédito pré-pago. Consulta informação de fontes e órgãos oficiais brasileiros (a mesma disponível ao cidadão), não é dado sigiloso. O cliente é o controlador dos dados e responde pela finalidade legítima (LGPD).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnly, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: no platform credentials needed, payment per query via prepaid credit, data is public and non-confidential, and LGPD compliance responsibilities. This provides significant insight into how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then adds necessary contextual details about payment, data nature, and LGPD. It's slightly verbose with legal disclaimers, but every sentence contributes meaning, making it appropriately structured for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and one ambiguous parameter, the description does not explain what the tool returns or how to format the query. It does clarify the data is public and from official sources, but missing return value and query format details leaves the tool incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'query' has zero description coverage in the schema, and the description does not elaborate on what format or content 'query' should take (e.g., process number, party name, court). Since the schema gives no hints and the description is ambiguous, this is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: consulting MPF processes from an official source ('MPF: Processos, consulta em fonte oficial'). The verb 'consultar' (consult) and resource 'processos' are explicit, and it distinguishes itself from unrelated siblings like authenticate or marketplace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about when to use the tool: to consult official Brazilian public source information, noting it's not confidential and requires prepaid credit. However, it does not explicitly mention alternatives or exclusion cases, though the sibling tools are unrelated, making the usage fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools are generally distinct, with the domain-specific consult tool clearly separated from platform utilities. However, 'marketplace' is a broad catch-all that overlaps with 'toolkit_info' for listing/installing capabilities, creating potential confusion.
Naming is inconsistent: verbs (authenticate, connect), nouns (marketplace), compound names with underscores (mpf_processos_consultar, toolkit_info). No consistent verb-noun or noun-verb pattern, mixing English and Portuguese.
With 7 tools, the count is moderate, but only one tool serves the stated domain (MPF Processos). The other six are generic platform management tools that belong to a separate server, making the set feel bloated and misaligned with its name.
The core consultation tool covers the primary need but offers no additional process-related operations (e.g., listing, detailing, or updating). The platform tools do not contribute to domain completeness, leaving the surface minimal but functional.