Nota Fiscal

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

Discloses that calling with no args returns a link, and with token sets session state. Aligns with annotations (idempotentHint=true, destructiveHint=false) and adds detail beyond 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?

Two sentences pack all essential info without verbosity. Front-loaded with purpose and method.

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?

Fully covers tool behavior for a single-parameter authentication tool, including usage scenarios and parameter meaning, despite lack of output schema.

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 description coverage, description fully compensates: explains token parameter as JWT from browser, its optionality, and behavior when omitted.

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 authentication purpose with specific actions: login, copy token, provide token or get link. Distinguishes from sibling tools which are unrelated (connect, marketplace, etc.).

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 for two usage methods (permanent via config vs session via token) and tells user when to call with token vs no args. Lacks explicit exclusion of alternatives but sufficient 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?

Adds value beyond annotations by detailing two specific scenarios: connected state (authenticated:true, empty pending[]) and missing credentials (returns connect_url).

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 with no waste: first sentence states purpose, second covers key behavioral scenarios.

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?

Complete for a simple status-check tool with no params. Description explains return behavior well, despite absence of output schema.

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?

No parameters, schema coverage 100%. Baseline 4 is appropriate as description doesn't need to add parameter info.

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 returns connection status and URLs, distinguishing it from sibling tools like 'authenticate' which likely performs authentication rather than checking status.

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?

Implied usage for checking connection status, but lacks explicit guidance on when not to use or comparison with siblings. Still provides clear 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?

The description discloses key behaviors: invoke works even if MCP not installed, returns connect link if credential needed or checkout link if payment needed, and that writes require workspace owner/admin. This adds context beyond the annotations (which are minimal). No contradictions.

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-structured, starting with the purpose and core flow, then diving into action-specific guidance. It is efficient given the complexity, though some redundancy exists (e.g., repeating 'key' points).

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 complex meta-tool with 15 parameters and many actions, the description covers the essential workflow, credential/paid scenarios, and action contexts. It is missing detailed parameter explanations but overall provides sufficient context for the agent to use the tool correctly.

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 should explain parameters, but it only mentions 'action=search' and high-level concepts without detailing the 15 parameters (e.g., query, limit, mcp_id, tool_id, arguments, etc.). This leaves the agent needing to infer parameter meanings 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 states it is the official marketplace and catalog of MCPs/tools, and explains the core flow (search → describe → invoke/install). It distinguishes itself from siblings by specifying to use this tool first before external registries.

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 explicitly says to use this tool first for capability queries. It provides detailed guidance on when to use invoke vs install, mentions that writes require owner/admin, and covers other actions like subscribe, cancel, list_tools, report_bug, and request_mcp.

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, covering safety. The description adds context about returning links and bulk execution, but does not disclose additional behavioral traits beyond that.

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 with no wasted words. First sentence states core purpose, second sentence adds bulk capability. Front-loaded and efficient.

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 0% schema coverage, the description adequately conveys the return type (links) and the main parameter (invoice_id/invoice_ids). It misses details like error handling or optional company parameter, but is largely complete for a simple retrieval tool with safe annotations.

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%, placing full burden on the description. It explains invoice_ids for batch, but does not describe company, the distinction between invoice_id and invoice_ids, or any parameter constraints. This is insufficient.

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 PDF and XML links of an issued NFS-e, using a specific verb 'returns'. It distinguishes from siblings like emit, cancel, consult, and list, which have different purposes.

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 notes bulk support via invoice_ids, giving a hint about when to use batching. However, it lacks explicit when-to-use or when-not-to-use guidance, and no mention of prerequisites or 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 destructiveHint:true, and the description adds important behavioral context: 'IRREVERSÍVEL' (irreversible), subject to municipal deadline, and support for batched execution via invoice_ids. No contradiction with 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?

Two sentences, each essential. The first sentence states the primary action and its key traits, the second adds bulk support. No unnecessary 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?

The description lacks details about the output or return values, and the optional 'company' parameter is unexplained. Given the tool's complexity (destructive, bulk support) and no output schema, more context would be helpful.

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 description coverage, the description must clarify parameters. It explains that 'invoice_ids' enables bulk support, but does not describe 'company' or 'invoice_id' beyond their presence in the schema. This adds some value but leaves 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 explicitly states 'Cancela uma NFS-e emitida' (cancels an emitted NFS-e), clearly identifying the verb and resource. It distinguishes from sibling tools like 'notafiscal_emitir_nfse' (emit) and 'notafiscal_consultar_nfse' (consult) by focusing on cancellation.

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 includes 'Confirme antes de chamar' (confirm before calling) and mentions irreversibility and municipal deadline, guiding the agent to use caution. However, it does not explicitly state when not to use this tool or list 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it queries status/detail and supports bulk, consistent with 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?

Two terse sentences with no wasted words. First sentence states primary function, second adds bulk support. Efficiently conveys key 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 read-only query tool with three parameters and no output schema, the description covers the main functionality and bulk support. Missing details on return format or company parameter, but sufficient for agent usage.

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?

Although schema has 0% description coverage, the description explains that invoice_id is for single query and invoice_ids for batch, adding meaning. However, the company parameter remains unexplained.

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 queries status/detail of a NFS-e by invoice_id. It differentiates from siblings like notafiscal_baixar_nfse, notafiscal_cancelar_nfse, and notafiscal_listar_nfse.

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?

Specifies using invoice_id for single query and invoice_ids for batched execution. Does not explicitly mention when not to use, but sibling names suggest 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 indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that it creates a real fiscal document and warns to confirm data. It also notes idempotency via external_id, which compensates for idempotentHint=false. No contradiction.

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 concise with bullet-like structure, covering key points in a few lines. It could be more structured (e.g., separate sections) but is efficient without waste.

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 mentions return of id and status but lacks details on response structure. The 'bulk support' line is vague. Given no output schema and moderate complexity, additional info on return format and error handling would improve completeness.

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 description coverage, the description explains nfse (required inner fields), external_id (idempotency), and external_ids (bulk). However, the 'company' parameter is unexplained, and the exact format of nfse string is not detailed. Overall adds significant meaning.

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 verb 'Emite' (issues) and the resource 'NFS-e (nota fiscal de serviço)'. It specifies it creates a real fiscal document, distinguishing it from sibling tools like cancelar, consultar, listar.

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 advises to confirm data before calling, provides idempotency guidance via external_id, and mentions bulk support with external_ids. It implicitly differentiates from siblings by context, but lacks explicit 'when not to use' instructions.

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, destructiveHint=false, and idempotentHint=true, which the description does not contradict. The description adds context about the returned fields but does not disclose additional behavioral traits such as pagination, performance, or error handling. Given the annotations, the description provides adequate but not extensive transparency.

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 concise sentence with no wasted words. It front-loads the purpose and efficiently conveys the tool's action and output.

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 list operation with no parameters and no output schema, the description covers the main aspects: what is listed (connected companies) and what fields are returned. It could mention if the result is an array or object, but overall it is fairly complete given 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?

There are no parameters, and schema description coverage is 100%. The description adds meaning beyond the empty schema by explaining what the tool returns (a list of companies with specific fields). This is valuable 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 states the verb 'Lista' (lists) and the specific resource 'empresas (CNPJs) conectadas a este install', with explicit output fields (company_id, razão social, município, validade do certificado). It distinguishes from sibling tools like notafiscal_listar_nfse which list NFSes, not companies.

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 one needs to see the connected companies, but does not explicitly state when to use this tool versus alternatives or specify any prerequisites or context. No exclusions are mentioned.

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 destructiveHint=false, so the description needs only to add context. It mentions pagination, but that is already implied by the page_count and page_index parameters. It adds no information about authentication, rate limits, or return format.

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 sentence that front-loads the verb and resource, with no unnecessary words. It is appropriately sized for a straightforward listing tool.

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 has three parameters and no output schema, the description is minimal but covers the core purpose. However, it lacks parameter details and usage context, which would be needed for complete understanding.

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%, so the description must compensate. It mentions 'por uma empresa' which hints at the company parameter, but does not explain page_count and page_index at all. Parameter meaning beyond schema is minimal.

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 action 'Lista' (lists), the resource 'NFS-e' (invoices), and scope 'por uma empresa (paginado)' (by company, paginated). It effectively distinguishes from sibling tools like notafiscal_emitir_nfse (issue) and notafiscal_cancelar_nfse (cancel).

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 explicit guidance on when to use this tool versus alternatives such as notafiscal_consultar_nfse for individual invoices. The description does not state when not to use it or any prerequisites.

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 indicate the tool is idempotent and not destructive. The description adds context that the conversation array helps with reproduction, but does not elaborate on side effects, expected behavior, or confirmation of receipt. 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 consists of two concise sentences. The first sentence clearly states the purpose; the second provides critical usage guidance. It is front-loaded and efficiently communicates the essential information without extraneous text.

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 simplicity of a bug-report tool, the description is adequate but not comprehensive. It does not describe the return value, confirmation, or asynchronous nature. However, for its intended use (sending feedback), this may be sufficient. An explicit note on response behavior would improve completeness.

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 description coverage, the description is the sole source for parameter meaning. It mentions 'message' and 'conversation array' but does not explain the 'context' parameter or clarify that 'conversation' expects a JSON string representation of an array. This leaves ambiguity for two of three parameters.

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: reporting bugs, missing features, or sending feedback. It uses a specific verb ('Report') and specifies the type of content. Among siblings, none overlap with bug reporting, making the tool easily distinguishable.

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 a clear usage hint: include the conversation array for reproduction. It implicitly suggests when to use this tool (when providing bug context). However, it does not explicitly mention when not to use or provide alternatives, but this is not critical given the sibling list lacks similar tools.

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 its safety profile. The description adds the specific return value (platform and adapter versions) but doesn't disclose additional behavioral traits 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 a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's 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 simple informational tool with no parameters or output schema, the description fully covers what it returns and its purpose. No additional context is necessary.

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 zero parameters and 100% schema coverage, the description doesn't need to add parameter meaning. Baseline of 4 is appropriate as the schema fully documents the absence of parameters.

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 effectively distinguishes from sibling tools, which cover authentication, connection, and NFe operations.

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 context is clear: use this tool to retrieve version information. While there's no explicit when-not or alternatives, no sibling tool serves a similar purpose, making usage straightforward.

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 the tool is read-only, idempotent, and non-destructive. The description adds value by detailing what the state includes (installed MCPs, connection status, catalog tool counts), which is behavioral context beyond the annotations. No contradictions.

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?

A single, well-structured sentence that immediately conveys the tool's purpose and output. Every word adds value; no redundancy or filler. The most critical 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?

Given no input parameters and no output schema, the description adequately explains the return value in reasonable detail. It specifies three aspects of the state, though it could optionally mention other potential fields like version. Overall, it is sufficiently complete for an info 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 and schema coverage is 100% (trivially). The description does not need to add parameter meaning; baseline for 0 params is 4. No parameter details are required.

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, specifying three concrete pieces of information: installed MCPs, connection status, and catalog tool counts. The verb 'returns' and specific resource 'toolkit state' make it distinct from sibling tools like authenticate or connect, which are action-oriented.

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 obtaining state information but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it or prerequisites. The agent can infer its role as a read-only status check, but explicit context is missing.

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