mcp-nfe-br

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.7.0
Disambiguation5/5
Each tool targets a distinct document type (NF-e, CT-e, NFS-e) and operation (generate, sign, submit, consult, cancel, correct, validate). Even similar consult tools are differentiated by specific document or service status. No two tools have overlapping purposes.
Naming Consistency5/5
All tools follow a consistent 'br__<verb>_<document>' pattern (e.g., br__generate_nfe, br__cancel_cte, br__validate_nfe_xml). The only minor deviation is br__build_access_key, but it still clearly describes the action. Overall, naming is highly predictable.
Tool Count4/5
22 tools cover multiple document types (NF-e, CT-e, NFS-e) with lifecycle operations plus validation and helper tools. While slightly high, each tool serves a distinct purpose and the count is appropriate for the domain's complexity.
Completeness2/5
Core workflows for NFS-e and CT-e are well-covered, but NF-e is missing essential operations like cancellation and correction (CC-e). Additionally, CT-e signing tool is not yet registered despite being mentioned. These are significant gaps that will hinder full lifecycle management.
Average 4.3/5 across 22 of 22 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 44 commits in the last 12 weeks
- Last stable release on August 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It states 'Validate' but does not disclose what validation entails (e.g., checksum, formatting, existence), nor what happens on validation failure. The agent is left guessing the tool's behavior beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple validation tool with one parameter and an output schema, the description is moderately complete. However, the lack of behavioral details (e.g., what validation steps are performed, return format) limits its completeness, especially given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter, including format details. The description adds no new information beyond what the schema gives, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Validate' and the resource 'Brazilian CPF (individual taxpayer ID)', directly distinguishing it from sibling tools like br__validate_cnpj.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a CPF needs validation, but provides no explicit guidance on when to prefer this tool over alternatives like validating CNPJ, nor any context on prerequisites or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses that cnf is generated if omitted and that the key is check-digit, but it omits behavioral traits like error handling, idempotency, or prerequisites (e.g., internet access). Adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with the primary purpose. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's purpose and returns. It could mention the check-digit algorithm or error scenarios, but it is sufficiently complete for a utility tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds minimal extra meaning beyond the schema, such as mentioning check-digit and returned dict. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assembles and check-digits a 44-character NF-e/NFC-e access key, specifying the output format (chave_acesso and cnf). This distinguishes it from siblings like br__generate_nfe (generating the full NFe) and validation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for building the access key, but it does not explicitly state when to use it vs. alternatives like br__generate_nfe or validation tools. Sibling names provide context, but the description itself lacks clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares the tool is read-only, explains that endpoint_override is required because no endpoint is embedded, and describes the return format (cStat/xMotivo) and the significance of cStat=107. This is good transparency for a tool with no annotations, though error handling or rate limits are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two main sentences plus a helpful parenthetical note. It front-loads the purpose and immediately adds critical usage context about endpoint_override.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters, complete schema descriptions, and an output schema that likely covers return structure, the description is reasonably complete. It explains the mandatory parameter and the return code. However, it could be improved by including a brief note on error scenarios or the expected behavior when the service is down.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying that endpoint_override is mandatory and why, and by noting the return pattern. However, it does not add significant meaning beyond the schema descriptions for other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it consults the availability of the SEFAZ CT-e webservice using CTeStatusServicoV4. The tool name also indicates CT-e, but it does not explicitly differentiate it from the similar sibling br__consult_sefaz_status (likely for NF-e).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is read-only and does not require confirmation, and that endpoint_override is mandatory. However, it does not provide guidance on when to use this tool versus alternatives like br__consult_sefaz_status or br__consult_cte, nor does it specify 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only covers input formats, not behavior on invalid inputs, side effects, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one param; description explains input variations adequately. Output schema exists, so no need to detail return values, but behavioral gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter with separator note; description adds valuable detail on two accepted formats (numeric and alphanumeric).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes validation of Brazilian CNPJ, clearly distinguishing from sibling br__validate_cpf (which validates CPF).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly when CNPJ validation is needed, but no explicit when-not or alternative tools guidance beyond sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description correctly identifies the tool as read-only and requiring no confirmation, adding safety context. However, it lacks details on rate limits, authentication requirements beyond schema, or error behavior. The '[Unverified]' note adds uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: two lines plus an informative note. No unnecessary words; front-loaded with primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It covers the core purpose and safety traits. However, it omits contextual details like error conditions or environment handling for the optional tp_amb parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to add parameter details. It only reiterates the ch_nfse key, adding no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Consultar o status de uma NFS-e pelo chave de acesso (chNFSe)', specifying verb (consult), resource (status of NFS-e), and identifier. This distinguishes it from sibling tools that cancel, generate, or submit invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Read-only, não requer confirmação', indicating safe usage. However, it does not explicitly state when to use this tool versus alternatives like br__consult_sefaz_status or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It states the tool is read-only, requires no confirmation, and returns cStat/xMotivo with the meaning of cStat=107. It does not discuss error behavior or dependencies, but for a simple query tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every word adds value. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and the tool's low complexity (read-only query), the description adequately covers the functionality. It explains the key return fields but does not discuss other possible cStat values or edge cases. Still, it is complete enough for the intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional detail beyond the schema for individual parameters. It does not explain parameter relationships or usage tips.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool consults the availability of the SEFAZ webservice NFeStatusServico4, and it is read-only. This distinguishes it from sibling tools that build, distribute, generate, sign, submit, or validate NFe documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking service status before NFe operations, but it does not explicitly state when to use versus alternatives, nor does it cover when not to use. No exclusions or context about prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the two-step confirmation requirement and the option to set BR_READ_ONLY=1, indicating potential side effects. However, it does not detail idempotency, error handling, or the exact nature of the 'distribution' mode, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear sentences, each serving a purpose: identifying the operation, explaining parameter selection, and noting behavioral constraints. The technical reference (NT2014.002_v1.30) is somewhat verbose but still acceptable. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, 100% schema coverage, output schema exists), the description adequately covers parameter logic and behavioral context. It does not explain the output schema or define DF-e, but the schema handles those details. The two-step confirmation and read-only mode are mentioned, providing sufficient operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the mutual exclusivity of ult_nsu, nsu, and ch_nfe, mapping them to distNSU, consNSU, and consChNFe respectively. This clarifies the parameter selection logic beyond individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool consults/distributes DF-e via a specific operation (NFeDistribuicaoDFe). It distinguishes from sibling tools like br__generate_nfe and br__submit_nfe, which are for different phases of the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that exactly one of three parameters must be provided, determining the mode. It also mentions the two-step confirmation and read-only mode, but does not explicitly state when to use this tool versus alternatives. However, the sibling context makes the usage area clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full transparency burden. It discloses irreversibility, two-step confirmation process, and unverified endpoint status. This is adequate, though it could elaborate on the exact effects beyond cancellation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences plus a note. It front-loads the primary purpose and adds critical behavioral warnings without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, 4 required, output schema present), the description covers core behavior but lacks explicit flow explanation for the two-step confirmation. The note about unverified endpoint adds caution. Adequate for an informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add meaning to individual parameters beyond what the schema provides, except implicitly linking confirmation_token to the two-step process. No extra syntax or format details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Solicitar cancelamento') and the resource ('NFS-e no ADN'), distinguishing it from sibling tools like br__submit_nfse or br__generate_nfse. The irreversible nature and two-step confirmation are also mentioned, reinforcing purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns that cancellation is irreversible and requires a two-step confirmation (ConfirmationGate), and suggests setting BR_READ_ONLY=1 to disable. It provides implicit guidance for safe usage but does not explicitly outline when to use or avoid this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden of transparency. It discloses that the XML is unsigned, the need for signing, the exclusion of submission, and the structure of the return dict (xml, chave_acesso, warnings). Minor omission: no mention of error behavior, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 lines), front-loaded with the main purpose, and every sentence adds value. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of generating NF-e XML, the description covers the essential aspects: output format, access key, warnings, and the need for signing. It assumes knowledge of BRInvoice schema, which is acceptable. Could mention more about error handling or constraints, but overall complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'invoice', so baseline is 3. The description adds no extra information beyond the schema; it only restates 'Invoice data matching the BRInvoice schema'. No additional semantics provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an unsigned NF-e/NFC-e XML, specifies modelo 55/65 and schema 4.00, and distinguishes itself from siblings like br__sign_nfe and br__submit_nfe by noting that the output lacks Signature and SEFAZ submission is not included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells users to sign the output with br__sign_nfe before submission and that SEFAZ submission is not in this phase, providing clear context for when to use this tool. However, it does not explicitly compare with other siblings like br__build_access_key or list when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the output lacks ds:Signature, describes the return value structure (xml, dps_id, warnings), and mentions the schema version. It does not mention authentication or side effects, but the tool is read-only generation, so no major gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one line for purpose, followed by essential details on unsigned signature and return values. Every sentence provides value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, an output schema (implied), and sibling tools, the description covers the workflow and return values. Could provide more detail on the dps nested object structure, but it's sufficient for an experienced user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the dps parameter described as 'DPS data matching the NFSeDocument schema'. The description adds only that it is for NFS-e Nacional and schema v1.01, which is already in the schema description. Minimal additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates an unsigned DPS for NFS-e Nacional, schema v1.01. It distinguishes from siblings br__sign_nfse and br__submit_nfse by specifying the unsigned nature and the subsequent workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to sign the DPS with br__sign_nfse before submitting via br__submit_nfse, providing a clear workflow. However, it does not explicitly state when not to use this tool or mention alternatives beyond the implied workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: synchrony, irreversibility in production, required two-step confirmation via ConfirmationGate, and the ability to disable with BR_READ_ONLY. Without annotations, it provides sufficient behavioral context, though rate limits or detailed authentication flows are not covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single-sentence purpose followed by a brief paragraph on important caveats. No redundant or filler content; front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of SEFAZ submission (irreversible, two-step confirmation), the description covers purpose, input, output, and critical warnings. Output schema exists but is not detailed here; however, the description mentions protNFe and error, which is sufficient for an agent. Sibling tools contextualize the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by linking xml_content to br__sign_nfe output and explaining confirmation_token as from a previous pending call. This extra context aids proper parameter use beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits signed NF-e/NFC-e to SEFAZ for authorization (NFeAutorizacao4, synchronous). It distinguishes from sibling tools like br__sign_nfe (signing) and br__consult_sefaz_status (consultation), making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns about irreversibility and the two-step confirmation gate, but does not explicitly state when to use this tool versus alternatives like br__consult_sefaz_status or br__distribute_dfe. The mention of BR_READ_ONLY to disable provides a conditional usage hint, but lacks direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return dict structure (valid, errors, warnings, schema_version) and schema selection behavior. Without annotations, it doesn't mention side effects, network calls, or permissions, but the core behavior is adequately described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—three short sentences that front-load purpose, then detail behavior and output. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, the description covers the validation logic, parameter choices, and return structure. It lacks details about performance or error handling, but is generally complete for a validation tool with an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, but the description adds value by clarifying that xml_content and xml_base64 are alternatives and explaining how the root element influences validation. This goes beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates DPS or NFSe against XSD v1.01, distinguishing it from siblings like br__validate_nfe_xml. It uses specific verbs and identifies the exact resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains automatic schema selection based on root element, providing context for when it applies. However, it does not explicitly exclude usage for other XML types like NFe, though this is implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: irreversible operation, two-step confirmation, requirement for endpoint_override, internal signing process, and return of cStat/xMotivo or error. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the main purpose. Every sentence adds value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, irreversible action), the description covers critical aspects: event code, mandatory endpoint, confirmation process, read-only guard, and return fields. Minor omission of output schema details, but output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 is appropriate. The description adds high-level context (event code, confirmation token usage) but does not significantly elaborate on individual parameters beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'cancelar' and the resource 'CT-e autorizado', specifying the event code (110111) and web service (CTeRecepcaoEventoV4). It is distinct from siblings like br__consult_cte or br__correct_cte.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides important context: cancellation is irreversible in production, requires two-step confirmation with ConfirmationGate, and endpoint_override is mandatory. Does not explicitly contrast with siblings but offers clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries the burden. It discloses the tool is a consultation (non-destructive), describes return fields (cStat, xMotivo, protCTe or error), and warns that no endpoint URL is embedded, making endpoint_override mandatory. This gives agents a clear behavioral model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences, front-loaded with the verb and resource. Every sentence adds value: what it does, scope, mandatory parameter, return format. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (4 required), no annotations, and an output schema, the description covers return values, behavioral constraints (read-only, mandatory override), and differentiation from sibling. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so each parameter is already documented. The description adds context that endpoint_override is mandatory (already in required) and explains that ch_cte is the access key. No significant extra meaning beyond the schema, thus baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool consults the situation of a specific CT-e using its access key. It specifies the operation (CTeConsultaV4), marks it as read-only, and distinguishes from sibling `br__distribute_dfe` by scope (single known CT-e vs batch).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates the tool is read-only and requires no confirmation. It contrasts with `br__distribute_dfe` and notes endpoint_override is mandatory. However, no explicit 'when to use' or 'when not to use' guidance beyond the sibling distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the process (builds, signs, submits), expected cStat=135, legal constraints, two-step confirmation, and return format. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet information-dense, front-loaded with the main action, and every sentence adds value. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 params, 7 required, no output schema issues), the description covers legal context, behavioral details, and return info, making it 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds some context (endpoint_override required, confirmation_token for pending calls) but does not significantly enhance parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool emits a Correção Eletrônica for a CT-e, specifying the event code (110110) and API reference. It distinguishes from sibling tools (e.g., cancel, generate) by being specifically for CC-e.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important context: CC-e cannot alter tax values, cadastral data, or dates (legal reference), and it mentions two-step confirmation with a disable option. It does not explicitly contrast with alternatives but clearly defines the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses detailed behavior: signing algorithm (RSA-SHA1, enveloped transform), placement (last child of <NFe>), and supported certificate types (A1 only, A3 not modeled). It also specifies return format (dict with xml or error).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the action, and includes necessary technical details without extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the signing operation and the presence of an output schema (implied by 'returns a dict with xml or error'), the description is complete. It covers the signing process, certificate limitations, and return format, leaving no major gaps considering the sibling tools are distinct operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not significantly add parameter-specific meaning beyond the schema; it provides overall context about signing and certificate support, but the parameters (cert_path, xml_content, xml_base64, cert_password) are adequately described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies an ICP-Brasil enveloped XML-DSig signature to an NF-e/NFC-e XML, specifying that it signs <infNFe> per MOC 7.0 Table 4-2. This distinguishes it from sibling tools like br__validate_nfe_xml or br__generate_nfe, which perform other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for signing NF-e/NFC-e XML and specifies supported certificate types (only ICP-Brasil A1). It does not explicitly state when not to use or provide alternatives, but the context is clear enough given the distinct operation from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it validates against a bundled XSD, automatically selects schema version based on signature, and returns a dict with keys valid, errors, warnings, and schema_version. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences covering purpose, behavior, and output. It uses a code block for return structure, making it easy to parse. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two optional parameters, no required fields, and an output schema implied by the description, the tool definition is complete. It explains validation logic, schema selection, and return format adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for both parameters. The description adds minimal extra semantic value beyond stating that one of the two should be provided, which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates CT-e XML against a specific XSD schema (modelo 57, schema 4.00). It distinguishes itself from sibling validation tools for NFe and NFSe by specifying the CT-e domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains schema selection logic based on signature presence, providing context for when the tool applies. However, it does not explicitly state when not to use it or compare to alternatives beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adequately discloses automatic schema selection and return structure (valid, errors, warnings, schema_version). Sufficient for a read-only validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with the main purpose, and clearly structured with a technical note in the second paragraph. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of schema selection and lack of annotations, the description fully explains behavior, inputs, and output. Output schema exists but description covers key fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by clarifying mutual exclusivity of xml_content and xml_base64, which is not explicit in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates NF-e/NFC-e XML against a specific XSD schema, distinguishing it from sibling tools like generation or signing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on schema selection based on presence of signature, linking to br__sign_nfe. Explicit usage context but no direct 'when not to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the algorithm (RSA-SHA1), signature placement (as last child of <DPS>), and return structure (dict with xml or error). It does not explicitly mention whether the tool is read-only or destructive, but signing is inherently a write operation. The details are sufficient for an agent to understand behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, followed by technical details and caveats. It is not overly verbose, though the bracketed notes (e.g., `[Unverified...]`, `[NEED: não modelado]`) add slight clutter. Still, every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (signing XML with certificate), the description covers essential aspects: algorithm, supported certificate types, input format, and return value. It references a sibling tool for input, acknowledges verification status, and provides enough context for an agent to use it correctly. The presence of an output schema reduces the need for detailed return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds value by noting that cert_path is a local file path, xml_content typically comes from br__generate_nfse, and cert_password is optional. This contextualizes the parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies an XML-DSig ICP-Brasil signature to the DPS element of NFS-e Nacional. It specifies the exact element (<infDPS>), signature type (enveloped ds:Signature), and library used. This distinguishes it from sibling tools like br__sign_nfe and br__generate_nfse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that only A1 certificates (PKCS#12 files) are supported, and A3 hardware tokens are not modeled. It also includes a warning that the tool is unverified for production, guiding cautious use. The input reference to br__generate_nfse provides context for the expected xml_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses automatic GZip + Base64 encoding, irreversible operation, two-step confirmation gate, absence of embedded endpoint URLs, and return format (protCTe or error). This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but each sentence provides necessary information. It is well-structured: purpose, encoding details, irreversibility, confirmation gate, return value. Could be slightly more concise but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description does not need to explain return values in full detail, but it mentions key parts (protCTe, nProt). For a tool with 8 parameters (3 required), it covers encoding, mandatory endpoint, confirmation process, and necessary context (e.g., no embedded endpoint). Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter has a description. The description adds context: xml_content is the output of br__sign_cte, endpoint_override is mandatory, and encoding details. It adds value beyond schema, especially clarifying the relationship between xml_content and xml_base64.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Submete um CT-e assinado' and the resource 'à autorização SEFAZ', specifying the operation as 'CTeRecepcaoSincV4, síncrono'. It distinguishes itself from siblings (e.g., br__submit_nfe, br__submit_nfse) by focusing on CT-e submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides when to use: after signing CT-e (from br__sign_cte). It mentions that submission is irreversible in production, requires two-step confirmation, and that endpoint_override is mandatory. It also gives a way to disable the tool. However, it does not explicitly mention when not to use it vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes critical behaviors: irreversibility, confirmation gate, and unverified endpoint. No annotations provided, so description fully bears the burden. Also specifies return fields (cStat, xMotivo, nfse_xml).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and front-loaded with the main purpose. Includes necessary warnings in a separate block. No fluff, but the warning could be slightly more integrated. Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: main action, irreversibility, two-step confirmation, input alternatives, environment parameter, optional endpoint override, and response fields. No output schema provided, but description sufficiently documents returns. Complete for a complex submission tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have detailed descriptions in the schema (100% coverage). The description adds value by clarifying the mutual exclusivity of xml_content and xml_base64, and the role of confirmation_token. Baseline is 3; the additional context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: submit a signed DPS to ADN to generate the NFS-e. Distinguishes from siblings like br__sign_nfse and br__generate_nfse by specifying 'assinado' (signed) and mentioning the ADN submission step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes irreversibility in production and a two-step confirmation process. Suggests disabling the tool with BR_READ_ONLY=1. Provides a warning about the endpoint being unverified. Could be clearer about when to use vs. alternatives, but the context implies usage after signing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: unsupported modals/CSTs cause errors, output lacks signature, and return dict structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, front-loaded with main purpose, followed by limitations, post-processing steps, and return fields in bullet format – no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter, output schema, and sibling context, the description is complete: it explains constraints, necessary next steps, and return values adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description (100% coverage), but the tool description adds value by specifying model, modal, and CST constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an unsigned CT-e XML (modelo 57, schema 4.00), specifies limitations (modal rodoviário, ICMS CST 00), and distinguishes from siblings like br__sign_cte and other generate tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use only for modal rodoviário and ICMS CST 00, errors others, and advises signing with br__sign_cte before SEFAZ submission, providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-nfe-br MCP server](https://glama.ai/mcp/servers/cmendezs/mcp-nfe-br/badges/card.svg)](https://glama.ai/mcp/servers/cmendezs/mcp-nfe-br)

Score Badge

Copy to your README.md:

[![mcp-nfe-br MCP server](https://glama.ai/mcp/servers/cmendezs/mcp-nfe-br/badges/score.svg)](https://glama.ai/mcp/servers/cmendezs/mcp-nfe-br)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cmendezs/mcp-nfe-br'

If you have feedback or need assistance with the MCP directory API, please join our Discord server