DF-e

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

Annotations already mark the tool as idempotent and non-destructive. The description adds useful behavioral context: no args yields a login link, token-based auth is session-only, and config-header auth is permanent. 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?

The description is compact and front-loaded with purpose, then organized around the two authentication paths using 'Best' and 'Or'. It is slightly dense with setup instructions, but every sentence contributes useful guidance.

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 one-optional-parameter tool with no output schema, the description covers invocation modes, session persistence, and the no-arg link flow. It omits response/error details, but those are largely unnecessary given the annotations and simple 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?

Schema description coverage is 0%, so the description carries the burden. It defines the `token` parameter as a pasted JWT for session-only login and explicitly documents the optional no-arg usage. Some format constraints could be added, but the core semantics are clear.

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 authenticates MCP.AI access for IDE agents, with browser login and a pasted access token. It distinguishes the no-argument flow from the token flow, though it does not explicitly contrast itself with sibling tool `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?

Provides explicit invocation guidance: call with no args to get a login link, or pass `{ token: "<jwt>" }` after the user pastes a token. It also notes the permanent config-header alternative, but does not discuss when to prefer alternative sibling 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 establish readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral detail: the authenticated:true/pending[] response shape and the connect_url outputs when credentials are missing.

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 deliver both core purpose and conditional behavior with no filler. The main result is front-loaded and each clause adds necessary 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?

The description covers the all-connected and missing-credentials cases clearly, and the annotations already cover safety. It does not explicitly describe a partial-connection state or explain what pending[] entries mean, which leaves a small gap for a tool with no 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?

The tool has zero parameters and the input schema is an empty object, so the description does not need to explain parameter behavior. The provided conditional return information replaces what would normally be parameter guidance.

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 states a specific verb and resource: it returns connection status and URLs. It further clarifies the two main output conditions, making the tool's purpose unmistakable even though the bare name 'connect' could be ambiguous.

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 clear conditional behavior for fully connected and missing-credential states, so an agent can anticipate the result. However, it never mentions when to prefer connect over the sibling authenticate tool, nor does it state 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.

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

Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral constraints beyond the annotations, such as the 90-day window and the exclusion of own-issuance documents. No contradiction with annotations exists.

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 tight sentences: the first states the core purpose, and the second front-loads the critical limits. Every word earns its place, with no filler or redundant restatement of the tool name.

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 is adequate for a simple lookup tool and covers the primary search key and constraints. However, with no output schema and no explanation of the 'account' parameter, an agent may not know what the tool returns or how the optional account affects the query.

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 does add meaning for the required 'chave' parameter by specifying its 44-digit format. However, the optional 'account' parameter is not mentioned at all, so the description only partially compensates for the lack of schema documentation.

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 states a clear, specific action: searching for a document by its 44-digit access key. This distinguishes it from sibling dfe_consultar_nsu, which searches by a different identifier, and from the other sibling tools.

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 limitations: only documents that reached the National Environment in the last 90 days and never documents where the CNPJ is the issuer. This gives clear context about when the tool is usable, though it does not name alternative tools or explicitly say when not to use it.

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 provide readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds useful context about the recovery use case and single-item scope, but it does not disclose return format, error behavior, or prerequisites. It adds some value without fully describing behavior.

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 short sentences with no filler. The core action is front-loaded, followed by a precise usage boundary and sibling reference, making every word earn 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?

The tool is simple, annotations cover safety and idempotency, and the description explains purpose and usage boundaries. However, there is no output schema and no mention of return value shape or the optional account parameter, so an agent still lacks complete context for all invocation scenarios.

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 carry parameter meaning. It clarifies that NSU identifies the specific document to fetch, which covers the required parameter, but the optional account parameter is never mentioned. This leaves a material gap for callers trying to understand all inputs.

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 opens with a specific verb 'Busca' and a scoped object: 'UM documento específico pelo NSU.' It also explicitly contrasts itself with dfe_sincronizar, so an agent can distinguish it from the main sibling without opening the schema.

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 explicitly states when to use the tool: to recover an item that failed decompression during synchronization. It also says it is not for sweeping the queue and names dfe_sincronizar as the alternative, giving clear when/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?

Beyond the readOnly/idempotent annotations, it discloses side-effect-like costs ('gasta uma das consultas da hora'), a success precondition (completo: true), and the response shape (download link in files[]). It even warns the agent not to read the file because it is binary, which is genuinely useful runtime guidance.

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 definition is front-loaded with the purpose, then organized into usage guidance, constraints, and output handling. No sentence is filler; warnings and conditions earn their 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?

Even without an output schema, it tells the agent what to do with the result (hand the files[] download link to the user, do not read binary content) and covers all relevant success/failure conditions. The only minor omission is the account parameter, which does not materially undermine the call path.

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 carries the burden and does explain xml, chave, and nsu in terms of when to use each and their SEFAZ cost. The account parameter is not mentioned at all, leaving a gap; otherwise the parameter guidance is strong.

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 opens with a concrete action and resource: 'Gera o DANFE (o PDF da nota) a partir do XML.' It also clarifies that SEFAZ supplies XML, not PDF, which distinguishes this tool from the sibling retrieval/consultation tools like dfe_sincronizar and dfe_consultar_chave.

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 provides explicit COMO USAR instructions: pass the xml field from dfe_sincronizar to avoid consuming a SEFAZ query, or fall back to chave/nsu while acknowledging the query cost. It also states the hard precondition that only documentos with completo:true can be used and explains why resumo documents fail.

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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context by specifying the scope ('neste install') and the returned fields, but it does not disclose details like pagination, authentication, or what happens when no CNPJs are connected.

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 entire description is a single concise, front-loaded sentence. It immediately states the action and the resource, then adds the returned fields without any wasted words or redundant restating of the tool name.

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 list tool, the description covers the core purpose and output fields, and the annotations cover safety and idempotency. However, the unexplained 'account' parameter and lack of any output structure or edge-case behavior leave a meaningful gap for an agent deciding whether and how to call it.

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 one optional parameter, 'account', with no description, and schema description coverage is 0%. The description does not mention or explain this parameter at all, leaving the agent without any indication of how 'account' affects the listing behavior.

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 states a clear verb ('Lista') and resource ('CNPJs conectados neste install'), and even enumerates the returned fields: razão social, CNPJ e UF. This distinguishes it from sibling tools like dfe_consultar_chave or dfe_gerar_danfe, which target different 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 description makes clear that the tool lists CNPJs connected to the current install, which implies when to use it. However, it provides no explicit guidance about when not to use it or how it relates to sibling tools such as dfe_consultar_nsu or dfe_sincronizar.

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 and idempotent, and the description adds useful context: it does not consume a quota and the limit is shared across client systems. This goes beyond what annotations alone provide.

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?

Three short sentences, each earning its place: the result is front-loaded, the crucial non-consuming note follows, and usage guidance ends. 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?

For a simple one-parameter read-only tool with no output schema, the description covers the return concept (remaining queries and blocked status), the non-consuming behavior, and the best time to call it. It is complete enough for an agent to use it 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?

The description references a CNPJ and the schema has a single 'account' string parameter, so the mapping is inferable. However, with 0% schema description coverage, the description should more explicitly state that 'account' is the CNPJ. It adds some meaning but does not fully compensate for the missing schema guidance.

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 reports remaining quota and block status for a CNPJ. It is specific and distinguishes itself from siblings by explicitly noting it does not consume a query, unlike tools like dfe_consultar_chave.

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 an explicit recommendation: 'Chame isto antes de uma carga grande'. It also explains the context behind the recommendation, the SEFAZ per-CNPJ limit. It does not discuss exclusions or alternatives, but the intended usage is clear.

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 annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description discloses critical behavior: continuing to poll after fim_da_fila causes a 1-hour SEFAZ block, documents may come as full XML or summary depending on manifestação, and the response contains cursor fields. This materially helps the agent avoid a harmful misuse.

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?

Although longer than average, the description is densely structured with labeled sections (COMO USAR, ATENÇÃO) and every sentence carries actionable information. The critical warning about SEFAZ blocking earns its place, and the purpose statement 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 paginated synchronization tool with no output schema, the description covers the full lifecycle: initial call, cursor advancement, stop condition, response fields, and the difference between complete XML and summary data. The only notable gaps are the undocumented account and forcar_nsu parameters.

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 description thoroughly explains ult_nsu semantics and response cursor usage, which adds real meaning beyond the bare schema. However, schema description coverage is 0% and the description does not clarify the meaning of account or forcar_nsu, leaving the agent to infer those two 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 opens with a specific verb and resource: it fetches NEW fiscal documents issued against this CNPJ (NFeDistribuicaoDFe), listing document types. It also differentiates itself by explicitly stating it returns only received documents, not ones the user emitted, which helps distinguish it from siblings.

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 an explicit step-by-step protocol: start with ult_nsu '0', pass proximo_nsu back unchanged, repeat until fim_da_fila is true. It also provides an exclusion rule: for auditing your own emissions, get the XML from the ERP instead of this tool.

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 annotations, the description discloses that writes require owner/admin, that invoke runs uninstalled MCPs one-off without bloating the tool list, and that auth or payment gaps produce connect or checkout links with a retry instruction. This is substantial behavioral context beyond readOnlyHint=false and openWorldHint=true.

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 dense, and most sentences carry operational value. The core flow and key caveats are placed early, though a bulleted structure per action family would improve scannability.

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 tool with 14 actions, 23 parameters, no output schema, and no schema-level field descriptions, the description covers high-level behavior, permissions, and some return cases (connect/checkout links, prompt links). However, it omits per-action parameter requirements and response shapes for search, describe, list_tools, and similar actions, leaving notable gaps for correct invocation.

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 does not explain the 23 parameters beyond naming actions and the overall flow. It mentions tool_id, arguments, and prompt variables conceptually, but it never maps parameters to specific actions or states required formats, so the agent cannot reliably construct calls without guessing.

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 marketplace as both a catalog and execution layer for MCPs/tools, then lays out the core search → describe → invoke flow. It names concrete capability requests and distinguishes it from sibling tools that are mostly DFe/authentication utilities.

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 gives explicit usage guidance: prefer invoke for occasional one-off runs, use install only for permanent toolkit addition, and use list_tools to see what is currently callable. It also explains when request_mcp, report_bug, and prompt-library actions are appropriate.

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=false, idempotentHint=true, and destructiveHint=false. The description adds the useful detail that conversation context is expected for reproduction, but it does not explain side effects, response behavior, or whether the report is actually submitted to an external system.

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 short sentences with the primary purpose front-loaded and no filler. It is concise, though the second sentence could better align with the schema's actual parameter types.

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?

This is a simple tool with no output schema, but the description still omits key invocation details: what 'message' should contain, how 'context' is used, and how the 'conversation' string is expected to be formatted. The missing parameter semantics make it incomplete for correct invocation.

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 explains the 'conversation' parameter's purpose but calls it an 'array' while the schema types it as a string with default '[]'. It says nothing about the required 'message' parameter or the 'context' parameter, leaving important semantics unclear.

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 specific verbs ('Report', 'send') and names the exact resources: bug, missing feature, and feedback. It clearly distinguishes this tool from the DFe-focused siblings and communicates the full scope of the operation.

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 concrete use cases (bug, missing feature, feedback) and tells the agent to include conversation data for reproduction. It does not explicitly state when not to use it or name alternatives, but no sibling tool overlaps this purpose.

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, fully covering the side-effect profile. The description adds no behavioral information beyond stating it 'shows' versions, but it is consistent with the annotations, so no contradiction or hidden behavior is present.

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, tightly worded sentence that front-loads the action and the exact resource. There is no redundant explanation or filler.

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 informational tool with rich annotations, the description is fully sufficient. No output schema exists and no return format is promised, but the description tells an agent exactly what information this tool surfaces.

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 correctly implies that no inputs are needed, and the schema confirms this with an empty properties object. There is no parameter ambiguity to resolve.

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 names a specific verb ('Show') and a precise resource ('current MCP platform and adapter versions'), making the tool's function immediately clear. It is specific enough to distinguish itself from the sibling list despite the presence of a broad 'toolkit_info' sibling.

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 given about when to use this tool versus alternatives such as 'toolkit_info' or 'report_bug'. An agent must infer from the name that this is for version checking; there is no explicit context or exclusion.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about what information is returned but does not disclose additional behavioral traits such as freshness, caching, or connection overhead.

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 sentence that front-loads the result and then enumerates exactly what is included. Every phrase earns its place, with no tautology or redundant elaboration.

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 information tool with no output schema, the description sufficiently explains the return value: installed MCPs, statuses, connected accounts, and catalog tool counts. Nothing necessary for an agent to invoke it correctly is missing.

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 fully covers this with an empty properties object. Per baseline for zero-parameter tools, a 4 is appropriate; the description correctly avoids inventing parameter-related expectations.

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 names a specific verb ('Returns') and resource ('current toolkit state') and enumerates the exact contents: installed MCPs, connection status, connected accounts, and catalog tool counts. It is clear and concrete, though it does not explicitly distinguish itself from overlapping siblings like show_version or dfe_list_accounts.

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 intended use is implied by the content: call this to inspect overall toolkit state. However, there is no explicit guidance about when to prefer this over siblings such as dfe_list_accounts or show_version, and no 'when not to use' note.

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