MPT (Ministério Público do Trabalho)

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare idempotent and non-destructive. The description adds context about session vs permanent login, browser login flow, and the no-args link generation. It does not over-explain, but the key behavioral aspects are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense run-on sentence with embedded options and instructions. It is informative but could be better structured with clearer separation of the two login methods. It is not fully concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple schema and annotations, the description covers what the tool does, how to invoke it, and both auth modes. The lack of an output schema is mitigated by 'get the link' and the explicit token usage. Minor absence of response details, but overall complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully explains the only parameter: token is a JWT, used for session-only login, and the tool can be called with no args to get the link. This is more than sufficient.

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 indicates an authentication action ('log in', 'access token', 'Authorize'), and the name 'authenticate' matches. It does not explicitly contrast with sibling tools like 'connect', but the purpose is clear.

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 gives two concrete usage paths: permanent via config header or session-only via token/no-args. It states which is 'best' and what each call does. It does not mention when to use other tools, but the usage guidance for this tool is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safe-read nature is known. The description adds valuable context by explaining conditional behavior: returns authenticated:true when all providers are connected and connect_url when credentials are missing. This goes beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose. It efficiently covers the key behavioral outcomes without redundancy. Every sentence provides useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple no-parameter tool with rich annotations, the description is quite complete. It explains the return values in two distinct states, which is the core functionality. While it doesn't detail partial connection states or URL formats, the tool's simplicity and the description's coverage make it sufficient. An explicit usage guideline would push it to 5.

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 tool has zero parameters, and the schema coverage is 100% (vacuously). With no parameters, the description has little to add, but it doesn't need to. The absence of params is inherently well-documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Returns') and clearly states the resource ('connection status and URLs'). It distinguishes this from sibling tools like 'authenticate' by focusing on status checking rather than performing authentication, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking connection status, describing different states. However, it lacks explicit when-to-use vs alternatives, such as noting 'Use authenticate to establish a connection.' While the conditionality is described, no direct comparison to siblings is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the minimal annotations (readOnlyHint false, etc.), the description discloses critical behaviors: invoke runs a tool one-off without installing or bloating the list, writes require workspace owner/admin, and the one-off install behind invoke. This adds substantial context about side effects and prerequisites, and it does not contradict any annotation.

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 long but every sentence contributes value. It is structured logically: core flow, invoke's special behavior, install vs invoke, admin permissions, and the prompt library. The most important information is front-loaded.

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?

For a highly complex tool with 23 parameters, no parameter descriptions, and no output schema, the description covers all major usage contexts: discovery, execution, installation, billing, reporting, and the prompt library. It even handles edge cases like missing credentials, empty wallet, and permission requirements.

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?

With 0% schema coverage, the description carries the full burden. It clearly explains the action parameter and its enum values, including the flow between search/describe/invoke and the prompt library actions. Key parameters like mcp_id, tool_id, and prompt_vars are given meaning, though many others (limit, cancel_reason, conversation, etc.) are not explicitly described but are inferable from context.

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 identifies the tool as the official mcp.ai marketplace: the catalog of MCPs/tools and the way to run them. It names the core actions (search, describe, invoke, install) and distinguishes itself from siblings by covering both discovery and execution, including the prompt library.

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 explicit guidance: prefer invoke for single/occasional use, use install only for permanent toolkit additions, request_mcp when nothing fits, and report_bug for feedback. It also explains what invoke does when credentials or payment are needed, telling the agent to return a link and retry.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds meaningful context: data is public, not private, and the client is responsible for LGPD compliance, which informs safe usage beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, covering purpose, payment, data nature, and legal responsibility in a few sentences without redundancy. It is front-loaded with the main function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the purpose, payment model, and data access level, but does not describe the response shape or clarify the 'completo' parameter. With no output schema, this leaves gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description mentions CPF, CNPJ, and region but omits the 'completo' parameter. It also says 'CPF ou CNPJ' while the schema requires both, creating ambiguity. This fails to adequately clarify parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it queries MPT records using CPF/CNPJ and region, distinguishing it from unrelated siblings like authenticate and marketplace. The verb 'Consulta' and resource are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It specifies that no credentials are needed and that queries are paid via prepaid credit, framing when to use it. It does not explicitly mention alternatives or exclusions, but sibling tools are functionally distinct, so context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds that the conversation array should be included for reproduction, which is helpful. However, it does not disclose what happens after submission (e.g., ticket creation, response time) or any side effects. Given annotation coverage, this is acceptable 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, tightly written with no filler. It front-loads the purpose and adds one crucial usage note. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with three parameters, the description covers the core purpose and the key reproduction instruction but omits guidance on the 'context' parameter and does not mention what the response/return behavior is. There is no output schema, so a note on return value would have helped. It is minimally complete for the most common use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must clarify all parameters. It mentions the 'conversation array' but the schema type is string, creating ambiguity (it likely expects a JSON-encoded string). The 'message' parameter is only implied by the purpose, and 'context' is not mentioned at all. This is insufficient for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Report') and clearly states the resource ('bug, missing feature, or send feedback'). It is easily distinguishable from sibling tools (authenticate, connect, etc.) which serve different purposes. The scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use the tool, i.e., when there is a bug, missing feature, or feedback. It also provides a concrete usage instruction about including the conversation array. Since no sibling tool offers similar functionality, explicit alternatives are unnecessary, though there is no explicit 'when not to use' statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that it reports 'current' versions, but does not elaborate on return format or whether live queries occur. Value added beyond annotations is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, highly concise, no filler. It immediately states the action and target resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple version query, the description adequately covers purpose and scope. However, with no output schema, it could mention the return structure (e.g., separate values for platform and adapter). Still, the simplicity means this is near-complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has zero parameters, so baseline is 4. Description does not need to compensate for schema gaps since there are none.

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 shows current MCP platform and adapter versions, using a specific verb and resource. It distinguishes itself from siblings like toolkit_info by being version-specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description is purely definitional and does not mention any context, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about the live nature of the state and the specific information returned, helping set expectations for a read-only introspection call. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the main action and uses a list for details. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero parameters and no output schema, the description fully covers what an agent needs to know: it's a read-only tool that returns a snapshot of toolkit state, including connection statuses and account associations. This is sufficient for a simple introspection tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the input schema is trivially complete. The description doesn't need to explain parameters; the baseline of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Returns' and clearly identifies the resource 'current toolkit state' with enumerated details (installed MCPs, connection status, accounts, catalog tool counts). This distinguishes it from siblings like 'show_version' which likely returns version info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies it is used to inspect the toolkit state, but does not explicitly state when to use it over siblings or provide exclusions. No alternative tools are mentioned, so guidance is mostly implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.