Vietnam Invoices (MISA meInvoice create, publish & query)
Server Details
Vietnam MISA meInvoice: AI agents create, publish and query e-invoices, stateless BYO.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 3 of 3 tools scored.
Each tool has a unique purpose: create_invoice creates a draft, publish_invoice publishes a signed invoice, and query_invoice checks status. No overlap in functionality.
All tool names follow a consistent verb_noun pattern (create_invoice, publish_invoice, query_invoice) using snake_case, making them predictable.
Three tools are appropriate for the focused workflow of creating, publishing, and querying invoices. The count is slightly minimal but covers the essential steps without being excessive.
The tool set fully covers the stated workflow: create draft, publish signed invoice, and query status. The external signing step is explicitly handled outside the server, so no missing tools within scope.
Available Tools
3 toolscreate_invoiceAInspect
STEP 1 of the MISA meInvoice flow: create a Vietnamese e-invoice (hóa đơn điện tử) draft on MISA — the POST /itg/invoicepublishing/createinvoice call. You supply seller, buyer and line items; this server computes the Vietnamese VAT (thuế GTGT) math locally in VND (integer đồng — no decimals) and forwards the payload. MISA returns a transaction_id, ref_id and invoice_data (an UNSIGNED invoice XML). This server does NOT sign: you then sign invoice_data MERCHANT-SIDE with your own digital signature / USB Token (chữ ký số) using the MISA local signing service, and pass the signed XML to publish_invoice (STEP 3). VAT rates: 10 (standard), 8 (temporary reduced), 5 (essentials), 0 (exports). Set withCode=true if you issue invoices WITH a tax-authority code (hóa đơn có mã); default false (không mã). Result accepted=true when MISA created the draft with no per-document error (check error_code). Required credential headers (set once in your MCP client, per-request, never stored): x-meinvoice-token (your MISA meInvoice access token) + x-meinvoice-taxcode (your company tax code / MST, sent as CompanyTaxCode). Optional header x-meinvoice-env: test (default = sandbox testapi.meinvoice.vn, no fiscal effect) | prod (production api.meinvoice.vn, real fiscal effect). Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools. All amounts are in VND (đồng, whole numbers — no decimals).
| Name | Required | Description | Default |
|---|---|---|---|
| buyer | No | The buyer (người mua). Use legalName+taxCode for a company (B2B) or fullName for an individual consumer. | |
| lines | Yes | Invoice line items. Each: { name, unit?, quantity, unitPrice, taxRate? }. taxRate is a VAT percentage (10 default / 8 / 5 / 0). unitPrice is in whole VND. | |
| refId | No | Your own reference id for this invoice (RefID). Optional — a UUID is generated if omitted. Reusing a RefID triggers InvoiceDuplicated. | |
| seller | Yes | The seller (người bán) = your company. Requires legalName + taxCode. | |
| invDate | No | Invoice date (ngày hóa đơn), ISO datetime. Default: now. | |
| withCode | No | true = invoice WITH tax-authority code (có mã, uses /code/itg path); false (default) = without code (không mã). | |
| invSeries | Yes | Invoice series / ký hiệu (e.g. "1C25MYT") — assigned when you register the invoice template with the tax authority. REQUIRED. | |
| invoiceName | No | Invoice type name, default "Hóa đơn giá trị gia tăng" (VAT invoice). | |
| currencyCode | No | Currency, default VND. VND is a 0-decimal currency; non-VND requires exchangeRate. | |
| exchangeRate | No | Exchange rate to VND (default 1 for VND). | |
| amountInWords | No | Optional total amount spelled out in Vietnamese (số tiền bằng chữ). | |
| paymentMethodName | No | Payment method, default "TM/CK" (cash/bank transfer). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds substantial behavioral details: VAT computation, local math, forwarding to MISA, unsigned invoice_data returned, no server-side signing, error handling (result accepted with error_code), and VND integer requirement. No contradictions 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 quite long and contains some redundant statements ('This server does NOT sign' appears twice). While it front-loads the purpose, the structure could be more concise with bullet points. It earns a 3 as it is informative but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return values (transaction_id, ref_id, invoice_data), error checking, credential headers, environment options, VAT rates, and the overall flow. It is complete enough for a developer to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema: guidance on when to use legalName vs fullName for seller/buyer, explanation of VAT rate values, default for withCode, and duplicate RefID error. This lifts the score to 4, though some info is redundant with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Vietnamese e-invoice draft on MISA, identifies it as step 1 of a flow, and distinguishes it from sibling tools (publish_invoice, query_invoice) by referencing the completion steps and the need for subsequent signing and publishing.
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 when-to-use context (step 1 of MISA meInvoice flow), indicates required credential headers, warns about RefID duplication causing error, and mentions alternatives (publish_invoice for step 3). It covers both required and optional headers and environment selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_invoiceAInspect
STEP 3 of the MISA meInvoice flow: publish an ALREADY-SIGNED e-invoice — the POST /itg/invoicepublishing call. After create_invoice returns invoice_data (unsigned XML) and you sign it MERCHANT-SIDE with your USB Token (chữ ký số) via the MISA local signing service, pass the signed XML back here with its transaction_id and ref_id. MISA submits it to the tax authority (Tổng cục Thuế) and returns the official inv_no (số hóa đơn), inv_code (mã cơ quan thuế, for coded invoices) and inv_series. This server does NOT sign — it only forwards the signed document. Set withCode to match how the invoice was created. Result accepted=true when MISA published with no per-document error (check error_code); common errors: SignatureEmpty, InvalidSignature, InvoiceNumberNotContinuous, InvoiceDuplicated. Required credential headers (set once in your MCP client, per-request, never stored): x-meinvoice-token (your MISA meInvoice access token) + x-meinvoice-taxcode (your company tax code / MST, sent as CompanyTaxCode). Optional header x-meinvoice-env: test (default = sandbox testapi.meinvoice.vn, no fiscal effect) | prod (production api.meinvoice.vn, real fiscal effect). Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools. All amounts are in VND (đồng, whole numbers — no decimals).
| Name | Required | Description | Default |
|---|---|---|---|
| refId | No | The RefID of the invoice (from create_invoice ref_id). | |
| withCode | No | true = có mã (/code/itg path); false (default) = không mã. Match how create_invoice was called. | |
| invoiceData | Yes | The SIGNED invoice XML — the invoice_data from create_invoice after you signed it merchant-side with your USB Token / digital signature. This server forwards it untouched. | |
| isSendEmail | No | Whether MISA emails the e-invoice to the buyer (default false). | |
| receiverName | No | Recipient name (when isSendEmail=true). | |
| receiverEmail | No | Recipient email (when isSendEmail=true). | |
| transactionId | Yes | The TransactionID returned by create_invoice. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool submits to the tax authority, returns official invoice numbers, requires credential headers, and lists possible errors. This adds significant value beyond the annotations which only indicate mutation and external effects.
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 well-structured with a clear opening (STEP 3), followed by process, parameters, errors, and headers. It is somewhat lengthy but all information is relevant and efficiently presented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, external API, no output schema), the description covers prerequisites, parameter semantics, error codes, headers, and environment. It provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds contextual information like the firewall of parameters (e.g., withCode must match create_invoice) but does not provide additional syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it is STEP 3 of the MISA meInvoice flow for publishing an already-signed e-invoice. It clearly distinguishes from siblings create_invoice (creates unsigned) and query_invoice.
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 explains exactly when to use (after signing merchant-side with USB token) and provides prerequisites (transaction_id, ref_id), common errors, and environment settings. It also warns that the server does not sign.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_invoiceARead-onlyIdempotentInspect
Look up the status of one or more published e-invoices — the POST /itg/invoicepublished/invoicestatus call (read-only). Pass the transaction_id(s) returned by create_invoice/publish_invoice. Result per invoice: publish_status (MISA SaveInvoiceStatus int — draft/published state), send_tax_status + send_tax_status_label = the tax-authority (cơ quan thuế) submission status. For invoices WITHOUT a code (không mã): 0=not sent, 1=sent, 2=accepted, 3=rejected, 4=send error. For invoices WITH a code (có mã, withCode=true): 0=awaiting code, 1=send error, 2=code issued, 3=code rejected. Also returns invoice_code, reference_type (0=original, 1=replacement, 2=adjustment), is_deleted and received_status (0=not received, 1=received). Set withCode to match the invoice type. Required credential headers (set once in your MCP client, per-request, never stored): x-meinvoice-token (your MISA meInvoice access token) + x-meinvoice-taxcode (your company tax code / MST, sent as CompanyTaxCode). Optional header x-meinvoice-env: test (default = sandbox testapi.meinvoice.vn, no fiscal effect) | prod (production api.meinvoice.vn, real fiscal effect). Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools. All amounts are in VND (đồng, whole numbers — no decimals).
| Name | Required | Description | Default |
|---|---|---|---|
| withCode | No | true = có mã (/code/itg path); false (default) = không mã. Match the invoice type. | |
| transactionId | No | A single TransactionID (convenience alternative to transactionIds). | |
| transactionIds | No | One or more TransactionID lookup codes to query. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations, including detailed return fields (publish_status, send_tax_status, etc.), status code tables for invoices with and without code, required and optional headers, and that amounts are in VND. The annot readOnlyHint, idempotentHint, and destructiveHint are consistent.
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 comprehensive but lengthy, containing extensive status code tables and header details. While well-structured, it could be more concise by referencing separate documentation for status codes. The front-loading of the main purpose is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains return values, including detailed status codes, credential requirements, and environment settings. It covers the tool's complexity and provides all necessary context 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 coverage is 100%, providing baseline. The description adds meaning by explaining the withCode parameter's role in distinguishing invoice types, and that transactionId is a convenience alternative to transactionIds. This enhances understanding beyond the schema.
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 looks up the status of published e-invoices, specifies the API call (POST /itg/invoicepublished/invoicestatus), and indicates it takes transaction IDs from sibling tools create_invoice and publish_invoice, distinguishing it from those creation 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 explains when to use the tool (after publishing invoices) and what inputs to pass (transaction IDs from create_invoice/publish_invoice). It does not explicitly state when not to use it, but the context is clear. No alternative tools for querying are mentioned, but the sibling tools are different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!