Malaysia Invoices (LHDN MyInvois submit, query & cancel)
Server Details
Malaysia LHDN MyInvois: AI agents submit, query and cancel 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.7/5 across 4 of 4 tools scored. Lowest: 4/5.
Each tool has a distinct and clearly defined purpose: building a draft, submitting a signed invoice, querying submission status, and cancelling an invoice. No overlapping functionality.
All tool names follow a consistent verb_noun pattern (build_invoice_draft, cancel_invoice, query_submission, submit_invoice). No mixing of styles.
With 4 tools covering the core workflow of draft building, submission, querying, and cancellation, the count is well-scoped and appropriate for the domain.
The tool set covers the stated purpose of submitting, querying, and cancelling invoices. The addition of a draft builder is helpful. A minor gap is the lack of a tool to list all submissions, but it's not critical for the intended workflow.
Available Tools
4 toolsbuild_invoice_draftARead-onlyIdempotentInspect
Local helper (NO network, NO credentials, NO signing): assemble an UNSIGNED UBL 2.1 invoice skeleton from line items and Malaysian SST tax, and compute the monetary totals (excl-tax, tax, incl-tax, payable). Use it to prepare a document you then complete (supplier/buyer TIN, MSIC code, etc.), XAdES-sign, hash, and pass to submit_invoice. It does NOT submit and has NO fiscal effect. In: lines [{ description, quantity, unitPrice, taxRate? (percent, e.g. 0/6/8/10) }], codeNumber, currency? (default MYR), issueDate? (default today). Out: computed totals + ubl_json skeleton. NOTE: it applies the taxRate you give per line (SST classification is your decision); it does not pick the rate for you.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | Yes | Line items. Each: { description, quantity, unitPrice, taxRate? }. taxRate is a percentage (0 = exempt/zero-rated; 6/8 = service tax; 5/10 = sales tax). | |
| currency | No | ISO currency code, default MYR. | |
| issueDate | No | Issue date YYYY-MM-DD, default today (UTC). | |
| codeNumber | Yes | Your internal invoice number / eInvoice code number (becomes the document cbc:ID). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds crucial context: no network, no credentials, no signing, no fiscal effect, and that it applies the given taxRate without picking the rate. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but packed with essential details. It front-loads key points (local, no network) and then explains input and output. While efficient for the information conveyed, it could be slightly more 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 4 parameters, nested objects, no output schema, the description covers input well and mentions output (computed totals + ubl_json skeleton). However, it does not detail the output fields or structure, which is a minor gap for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: explains the structure of the lines array, defaults for currency and issueDate, meaning of codeNumber, and clarifies taxRate percentages and SST classification responsibility. This adds value 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 assembles an unsigned UBL 2.1 invoice skeleton and computes totals. It explicitly distinguishes from siblings like submit_invoice by noting it does not submit and has no fiscal effect.
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 usage guidance: use to prepare a document before signing and submitting via submit_invoice. It also states it does not submit, has no fiscal effect, and that tax rate classification is the user's decision, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_invoiceADestructiveInspect
Cancel a previously-issued, VALID MyInvois document — the PUT /api/v1.0/documents/state/{uuid}/state call (body status=cancelled). Only allowed within the 72-HOUR window from the moment the document became valid; after that you must issue a credit/debit note instead. In: uuid (the document uuid from query_submission, NOT the submissionUid) + reason (why, max 300 chars). Result status "Cancelled" on success. Common errors: OperationPeriodOver (72h passed), IncorrectState (not cancellable), ActiveReferencingDocuments (referenced by another doc), Forbidden (you did not issue it). Required credential headers (set once in your MCP client, per-request, never stored): x-myinvois-client-id + x-myinvois-client-secret (your ERP OAuth2 credentials from the MyTax "Register ERP" self-service). Optional header x-myinvois-mode: sandbox (default = preprod, no fiscal effect) | prod (production, real fiscal effect). Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | The MyInvois document uuid to cancel (26 alphanumeric characters, from query_submission — NOT the submissionUid). | |
| reason | Yes | Reason for cancellation (mandatory, max 300 characters). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false. The description adds critical behavioral details: the 72-hour time constraint, that the document must be valid, error conditions, and header requirements. 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 front-loaded with the primary action but includes extensive details (headers, errors, time window). While each sentence adds value, the length could be slightly trimmed without losing clarity.
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 adequately describes the result status, error scenarios, and required/optional headers. It covers all necessary aspects for an AI agent to correctly invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context: uuid must come from query_submission (not submissionUid), reason max 300 chars, and details about optional headers. This goes beyond the schema descriptions.
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 cancels a valid MyInvois document via a PUT endpoint, with the result status 'Cancelled'. It distinguishes this from sibling tools (build_invoice_draft, query_submission, submit_invoice) which handle other stages of the invoice lifecycle.
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?
Explicitly defines when to use (within 72-hour window from validity) and when not to (must use credit/debit note after window). Also lists common errors (OperationPeriodOver, IncorrectState, etc.) and required credential headers, providing comprehensive context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_submissionARead-onlyIdempotentInspect
Get the validation status of a MyInvois submission — the GET /api/v1.0/documentsubmissions/{submissionUid} call. Use the submissionUid returned by submit_invoice to poll (MyInvois validates asynchronously; 3-5s polling is recommended). Result overall_status enum: "in progress" (still validating), "valid" (all documents valid), "partially valid" (some valid, some invalid), "invalid" (all invalid). document_summary lists each document with its own status (Submitted / Valid / Invalid / Cancelled), uuid and totals. Required credential headers (set once in your MCP client, per-request, never stored): x-myinvois-client-id + x-myinvois-client-secret (your ERP OAuth2 credentials from the MyTax "Register ERP" self-service). Optional header x-myinvois-mode: sandbox (default = preprod, no fiscal effect) | prod (production, real fiscal effect). Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools.
| Name | Required | Description | Default |
|---|---|---|---|
| pageNo | No | Optional page number when the submission has many documents. | |
| pageSize | No | Optional documents per page (max 100). | |
| submissionUid | Yes | The submissionUid returned by submit_invoice (26 alphanumeric characters). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it's a GET call, explains async validation, details response structure (overall_status, document_summary), and covers required/optional headers.
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 informative but verbose, including multiple details like headers, enums, and polling advice. Could be more concise without losing essential 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?
Despite no output schema, the description explains the response fields (overall_status, document_summary) adequately. Covers async nature, headers, and usage context, making it complete for a polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
100% schema coverage, so parameters are already well-documented in the schema. Description adds context about submissionUid coming from submit_invoice but does not significantly enhance parameter meaning beyond 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 'Get the validation status of a MyInvois submission' and specifies the API endpoint. It distinguishes itself from siblings like submit_invoice and cancel_invoice by focusing on status retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use the submissionUid from submit_invoice, polling recommended every 3-5s due to async validation. Does not explicitly state when not to use or alternatives, but the usage scenario is well-explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_invoiceAInspect
Submit an ALREADY-SIGNED Malaysian e-invoice (UBL 2.1) to LHDN MyInvois — the POST /api/v1.0/documentsubmissions call. This server does NOT sign: you XAdES-sign the UBL document merchant-side, compute its SHA-256 hash, and pass { format, document(base64), documentHash, codeNumber }. MyInvois validates asynchronously, so a successful submit returns a submissionUid plus accepted_documents (each with the assigned uuid) and rejected_documents — it does NOT yet mean the invoice is Valid; call query_submission with the submissionUid to poll the validation outcome. Result: accepted=true when at least one document was accepted for processing (HTTP 202); rejected_documents lists any structurally-rejected documents with their error. Required credential headers (set once in your MCP client, per-request, never stored): x-myinvois-client-id + x-myinvois-client-secret (your ERP OAuth2 credentials from the MyTax "Register ERP" self-service). Optional header x-myinvois-mode: sandbox (default = preprod, no fiscal effect) | prod (production, real fiscal effect). Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Document format: JSON (default) or XML — must match how you built and signed the document. | |
| document | Yes | The FULL signed UBL 2.1 document, base64-encoded. You XAdES-sign it merchant-side; this server forwards the bytes untouched. | |
| codeNumber | Yes | Your internal invoice number / eInvoice code number (cbc:ID of the document), e.g. INV-2026-000123. Used to correlate accepted/rejected results. | |
| documentHash | Yes | SHA-256 hash (hex) of the signed document bytes. Computed merchant-side; MyInvois re-checks it against the document. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains asynchronous validation, the meaning of a successful submit vs actual validation, credential headers, and optional mode header. 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?
Every sentence adds value, front-loaded with purpose, then details. Although long, it is efficiently structured and not verbose.
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?
Despite no output schema, the description fully explains return values (submissionUid, accepted_documents, rejected_documents, accepted flag), HTTP 202, and optional headers. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have full schema coverage, and the description adds crucial context: document must be signed client-side, documentHash for integrity check, format must match signing, codeNumber for correlation.
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 submits an already-signed Malaysian e-invoice to MyInvois, specifying the exact API call. It distinguishes from siblings like build_invoice_draft, cancel_invoice, and query_submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (with an already-signed document), what not to do (server does not sign), prerequisites (XAdES-sign), and alternatives (query_submission for polling).
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!