Jurisprudência

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

Annotations already declare idempotentHint=true and destructiveHint=false, and the description adds useful context beyond that: it describes the browser login flow, the token format (JWT), and the distinction between a permanent header connection and a session-only login. It does not contradict the annotations; it enriches them with specifics about behavior like 'get the link' when no args are provided.

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 run-on paragraph with several clauses, which reduces clarity. It front-loads the context 'MCP.AI for IDE agents (Cursor, etc.)' that could be trimmed, and the instructions about the header and session-login could be better separated. While all content is relevant, the structure could be more concise and better organized (e.g., bullets or distinct steps).

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

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

Given no output schema and minimal annotations, the description covers the essential aspects: how to authenticate, the two modes, and the token parameter. It explains the permanent config option and the session-only fallback, and it indicates what happens with no arguments (returns a link). It does not detail error cases or return formats, but that is acceptable for a simple tool; it is sufficiently complete for an agent to use.

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 provides only a parameter named 'token' with no description (0% coverage). The description fully compensates by explaining the token's meaning and usage: 'call with { token: "<jwt>" } after the user pastes' and 'or with no args to get the link.' This gives precise semantics for each call mode, making the parameter's purpose and optionality explicit.

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: authenticating the user via browser login to obtain an access token, and it offers two distinct operation modes (permanent config header or session-only token). It is specific about the resource and action, and it distinguishes itself from other tools like 'connect' by explaining its own unique workflow for IDE agents.

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 explicit usage instructions: 'Best: add it to this server's config as a header...' and 'Or paste it here for a session-only login...' It explains when to use each mode (permanent vs session), and how to call it (with or without token). It does not mention alternatives or exclusions, but the guidance is clear and sufficient for an agent to decide.

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 establish read-only, non-destructive, idempotent behavior, so the description's burden is lower. It adds valuable behavioral detail by specifying exactly what the response contains in connected versus missing-credential scenarios, including 'authenticated:true' and 'pending[]' semantics.

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?

Two sentences, front-loaded with the core purpose. The first sentence gives the high-level function and the second adds necessary conditional detail without any filler or redundancy.

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 zero-parameter, read-only status tool, the description fully covers invocation context, response semantics, and edge cases (missing credentials). No output schema exists, but the description compensates by describing the return values in both relevant states.

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 input schema is empty, so there are no parameters to explain; per the rubric, a 0-parameter tool receives a baseline of 4. The description does not need to add parameter-level semantics.

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 begins with a specific verb-resource pair: 'Returns connection status and URLs.' It then clarifies the two possible response states (authenticated:true with empty pending[], or connect_url with per-install URLs), making the tool's purpose unambiguous and distinct from sibling tools like authenticate.

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 clear conditional context: use this when checking connection status, especially to see whether all providers are connected or whether credentials are missing. It does not explicitly name alternatives or state when not to use it, so it stops just short of full guidance.

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 readOnly, idempotent, non-destructive, so the description adds value by specifying the returned fields (título, tipo, data, autoridade, ementa/descrição, URL) and the filtering option. This goes beyond the structured 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 concise sentences: first states purpose, scope, and return format; second explains filtering. No fluff or repetition, and it is front-loaded with the core purpose.

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 search tool with no output schema, it lists return fields but omits details about the 'max' parameter, pagination, default limits, or response structure beyond the field list. It is adequate for basic usage but leaves gaps for efficient agent selection.

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%, so description must compensate. It explains 'termo' (termo/tese) and 'tipo' (e.g., Acórdão, Súmula), but does not explain 'max' at all. It adds meaning for two of three parameters, but leaves one undocumented, so it only partially compensates.

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

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

Description clearly states the verb (Busca), resource (jurisprudência no acervo LexML), scope (tribunais superiores e demais), and return fields. It distinguishes from sibling jurisprudencia_sumulas by noting it covers multiple types and can filter by type, implying a broader search than just súmulas.

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?

Provides clear context: searches public LexML jurisprudence, can filter by type. However, it does not explicitly mention when to prefer this over jurisprudencia_sumulas or give exclusions, so it lacks explicit alternatives or when-not guidance.

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, and destructiveHint=false, covering safety. The description adds that it is a shortcut of jurisprudencia_buscar with type=Súmula, which is behavioral context. It does not describe pagination, rate limits, or output details, but with strong annotations, the additional context is limited.

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 only two sentences, both dense with information. It front-loads the core purpose and then adds the shortcut detail without any filler or redundancy.

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 search tool with no output schema, the description covers the main purpose and the shortcut nature. It lacks an explanation of the 'max' parameter and could mention the specifics of the search scope, but overall it is reasonably complete for the tool's simplicity.

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 compensate. It mentions 'por termo' which aligns with the 'termo' parameter, but does not explain 'max' at all. The description adds some meaning for the required parameter but leaves the optional parameter completely undocumented, which is insufficient for a 2-parameter tool.

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: searches SÚMULAS (including binding ones) by term in the LexML collection. It distinguishes itself from the sibling jurisprudencia_buscar by explicitly calling itself a shortcut with a fixed type, making its scope 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 as a shortcut for the main search tool, suggesting it is appropriate when the user specifically wants Súmulas. However, it does not explicitly state when NOT to use it or name alternative tools for other types, though the shortcut note provides reasonable context.

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 are present, but the description adds substantial behavioral context beyond them: invoke works even when MCP is not installed (one-off run), invoke returns connect/checkout links for auth/payment, and writes require owner/admin permissions. It also explains installed_in_toolkit vs workspace flags and the prompt library mechanics, all without contradicting 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 long but well-organized: it opens with the core purpose, then details the flow, invoke behavior, install vs invoke, other actions, and prompt library in a logical sequence. Every sentence adds valuable information, and the structure makes it easy to navigate despite its length.

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

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

Given the tool's complexity (23 params, 14 actions, no output schema), the description is remarkably complete. It covers the core flow, edge cases (auth, payment), permission requirements, and the prompt library. It provides enough context for the agent to select the right action and understand the overall behavior, even without parameter-level detail.

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%, so the description carries the burden. It explains the key parameters (action, mcp_id, tool_id, arguments) through the flow description and gives context for prompt-related params (prompt_vars, prompt_slug). However, many of the 23 parameters (e.g., limit, cancel_reason, report_context) are only implied by names and not explicitly elaborated, leaving some gaps.

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 is 'the official mcp.ai marketplace' and defines its dual role: catalog of every MCP/tool and the way to run them. It outlines the core flow (search → describe → invoke) and distinguishes it from siblings like 'authenticate' and 'jurisprudencia_buscar' by focusing on the marketplace functionality.

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?

Explicit when-to-use guidance is provided: the core flow is described step by step, with clear direction to 'prefer invoke for a single/occasional use' and 'Use install only to make an MCP PERMANENT'. It also explains when to use subscribe/cancel, report_bug, request_mcp, and the prompt library functions, giving concrete alternatives.

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 provide idempotentHint=true (safe to retry) and destructiveHint=false. The description adds that it sends a report and includes 'Include the conversation array with recent messages for reproduction', which is a useful behavioral detail beyond annotations. This helps the agent understand the expected input for better reproduction.

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 one sentence, front-loaded with the purpose, and includes a key usage hint. No wasted words, appropriately 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?

The tool is simple with 3 params (1 required) and no output schema, so the description covers the essential purpose. However, it does not specify what happens after reporting (e.g., acknowledgment), and the 'context' parameter is not explained. Given the low schema coverage and no annotations for param meanings, the description could be slightly richer, but it is adequate for a simple tool.

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

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

Schema has 0% description coverage, so the description must compensate. It explains 'message' implicitly and highlights the 'conversation' parameter's purpose, but does not clarify 'context'. The 'conversation' parameter is described as an array of recent messages, which adds meaning, but 'context' remains under-specified.

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 that the tool is for reporting bugs, missing features, or sending feedback, which aligns with the name 'report_bug'. It distinguishes itself from siblings, though it could be more specific about the intended audience or context, but it is clear enough.

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 when users encounter bugs or have feedback, but it does not explicitly state when not to use it or mention alternative tools. Siblings like 'show_version' and 'toolkit_info' could be alternatives for other purposes, but no such guidance 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully disclosed. The description adds minimal behavioral context beyond naming what versions are shown; 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 one short sentence that front-loads the action and object, with no filler or redundant phrasing. 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 no-parameter, read-only utility with comprehensive annotations, the description is fully adequate. It states exactly what versions are displayed, and no output schema is needed for such a simple informational 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 baseline is 4. The description does not need to explain parameter semantics, and the schema is trivially complete with 100% coverage.

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 ('Show') and a specific resource ('current MCP platform and adapter versions'), clearly distinguishing this from siblings like authenticate, connect, or jurisprudencia_buscar. It is unambiguous about what the tool does.

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 tool's purpose inherently signals when to use it: when version information is needed. It does not explicitly exclude alternatives or name sibling tools, but for a simple version-info utility, the context is clear and no exclusions are necessary.

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, and destructiveHint=false, so the safety profile is covered. The description adds valuable context about the specific output content (installed MCPs, statuses, accounts, tool counts), which goes beyond the structured data and gives the agent a concrete picture of the return value.

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, focused sentence that front-loads the purpose and lists the exact output components. Every phrase adds value with no redundancy or fluff.

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 read-only tool with no parameters and no output schema, the description fully explains what the agent will receive. It lists all the state components, making it complete for the agent to know what to expect.

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 there is nothing to document. Per the baseline for 0-param tools, a score of 4 is appropriate since no compensation is needed; the description doesn't need to add parameter details.

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 returns the current toolkit state with specific components (installed MCPs, connection status, accounts, and catalog tool counts). This is a specific verb 'returns' and resource 'toolkit state', distinguishing it from sibling tools like authenticate or connect.

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 clear context on what the tool does, indicating it's for inspecting overall toolkit status. It doesn't explicitly mention when not to use it or name alternatives, but the scope is evident from the description. No exclusions are present, so it meets the 'clear context, no exclusions' criterion.

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