Nigeria Invoices (FIRS / NRS MBS e-invoicing IRN)
Server Details
Nigeria FIRS/NRS MBS e-invoicing for AI agents - validate, sign, confirm invoices (IRN + QR).
- Status
- Healthy
- 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.4/5 across 3 of 3 tools scored.
Each tool has a distinct purpose: create_invoice signs/submits, query_invoice looks up by IRN, and validate_invoice pre-validates. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case (create_invoice, query_invoice, validate_invoice). No deviations.
Three tools are well-scoped for the Nigeria e-invoicing domain: validate first, then create, then query. Not too few or too many.
Covers the core workflow (validate, submit, query). A tool for cancellation or updating would be ideal but is not strictly necessary for the stated purpose.
Available Tools
3 toolscreate_invoiceAInspect
Sign and submit a Nigeria e-invoice to FIRS / NRS MBS — POST /invoice/sign. FIRS signs it server-side and returns the official IRN (Invoice Reference Number), CSID (Cryptographic Stamp Identifier) and QR code to print on the invoice. Bring your own credentials via headers x-firs-api-key AND x-firs-api-secret. The IRN format is InvoiceNumber-ServiceID-YYYYMMDD (e.g. ITW20853450-6997D6BB-20240703): pass irn directly if you already have it, otherwise this server builds it from invoice_number + service_id + issue_date. You send flat fields; the server builds the UBL-mapped JSON and computes VAT (7.5% Nigeria standard rate by default; override per line with vat_rate) into tax_total and legal_monetary_total. Recommended: call validate_invoice first.
| Name | Required | Description | Default |
|---|---|---|---|
| irn | No | Optional ready-made IRN, format InvoiceNumber-ServiceID-YYYYMMDD (e.g. ITW20853450-6997D6BB-20240703). If omitted, built from invoice_number + service_id + issue_date. | |
| items | Yes | Line items. Each: name, price (unit price in NGN, tax-EXCLUSIVE), optional quantity (default 1), vat_rate (percent, default 7.5), hsn_code, description, product_category. VAT is computed on top of price*quantity. | |
| issue_date | No | Invoice date YYYY-MM-DD. Defaults to today (UTC). | |
| service_id | No | Your FIRS-issued Service ID (the middle segment of the IRN, e.g. 6997D6BB). Used with invoice_number + issue_date to build the IRN. Not needed if you pass irn directly. | |
| business_id | Yes | Your FIRS business_id (UUID) from your NRSMBS Dashboard — identifies the taxpayer entity submitting the invoice. | |
| customer_tin | Yes | Buyer Tax Identification Number (TIN). | |
| supplier_tin | Yes | Seller Tax Identification Number (TIN), e.g. TIN-0099990001. | |
| customer_city | No | Optional buyer city_name. | |
| customer_name | Yes | Buyer (customer) legal party_name. | |
| supplier_city | No | Optional seller city_name. | |
| supplier_name | Yes | Seller (supplier) legal party_name as registered with FIRS. | |
| customer_email | No | Optional buyer email. | |
| invoice_number | No | Your own invoice/document number (used to build the IRN, unless you pass irn directly). E.g. INV001. | |
| supplier_email | No | Optional seller email. | |
| customer_street | No | Optional buyer street_name (postal_address). | |
| supplier_street | No | Optional seller street_name (postal_address). | |
| tax_category_id | No | Optional FIRS tax_category id for the VAT lines. Default VAT (value-added tax). Use another MBS tax-category code only if the goods fall under a different regime. | |
| invoice_type_code | No | FIRS invoice type code. Default 396 (commercial invoice). See the MBS GetInvoiceTypes list for others. | |
| customer_postal_zone | No | Optional buyer postal_zone (post code). | |
| supplier_postal_zone | No | Optional seller postal_zone (post code). | |
| document_currency_code | No | ISO currency of the invoice. Default NGN. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses all behavioral traits: server-side signing, IRN generation, VAT computation, credential headers. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).
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 and front-loaded, but slightly lengthy due to inline details. Every sentence adds value, though it could be more concise by structuring details separately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 21 parameters, no output schema, and important logic (IRN generation, VAT), the description covers all essential aspects: purpose, flow, credential handling, and pre-validation recommendation.
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 significant value by explaining IRN format construction, VAT defaults, and item structure beyond 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 verb 'sign and submit', the resource 'Nigeria e-invoice to FIRS / NRS MBS', and the endpoint. It distinguishes from siblings by mentioning validate_invoice first.
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 (to submit a signed e-invoice) and provides a recommendation to call validate_invoice first. It lacks explicit 'when not to use' but overall guidance is good.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_invoiceARead-onlyInspect
Look up a signed Nigeria e-invoice by its IRN at FIRS / NRS MBS — GET /invoice/confirm/{irn}. Returns the transmission / delivery status and the IRN/CSID. Safe to call anytime.
| Name | Required | Description | Default |
|---|---|---|---|
| irn | Yes | The IRN returned by create_invoice, format InvoiceNumber-ServiceID-YYYYMMDD (e.g. ITW20853450-6997D6BB-20240703). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds context by specifying it's a GET endpoint, naming the return values (transmission/delivery status and IRN/CSID), and confirming it's safe to call anytime, which aligns with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the purpose and includes key details (endpoint, return values, safety) in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and no output schema, the description is adequate: it explains the action, the key input, and the return. It could mention potential errors or limitations, but given the low complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'irn' is fully described in the input schema with format and example. The description does not add further meaning beyond what the schema provides, so it meets the baseline for high schema coverage.
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 a signed Nigeria e-invoice by IRN, specifying the endpoint and what it returns. The verb 'Look up' and the resource 'e-invoice by its IRN' are specific, and the sibling tools (create, validate) are distinct actions, so differentiation is clear.
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 does not explicitly state when to use this tool versus alternatives, but it implies usage after invoice creation by mentioning the IRN returned by create_invoice. 'Safe to call anytime' gives general guidance but no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_invoiceARead-onlyInspect
Pre-validate a Nigeria e-invoice against FIRS / NRS MBS (Merchant Buyer Solution) BEFORE signing — POST /invoice/validate. Returns pass, or the FIRS error list if the payload is rejected (so you fix it before spending a real submission). Bring your own credentials via headers x-firs-api-key AND x-firs-api-secret (generate them in your NRSMBS Dashboard -> API Integration; your business must be enabled for e-invoicing first). If your Dashboard issued a sandbox base URL, also send header x-firs-base-url. You send flat fields (business_id, supplier/customer party name + TIN, invoice_number, service_id, line items with price); this server builds the UBL-mapped JSON and computes VAT (7.5% default) into tax_total and legal_monetary_total. No fiscal effect — nothing is signed.
| Name | Required | Description | Default |
|---|---|---|---|
| irn | No | Optional ready-made IRN, format InvoiceNumber-ServiceID-YYYYMMDD (e.g. ITW20853450-6997D6BB-20240703). If omitted, built from invoice_number + service_id + issue_date. | |
| items | Yes | Line items. Each: name, price (unit price in NGN, tax-EXCLUSIVE), optional quantity (default 1), vat_rate (percent, default 7.5), hsn_code, description, product_category. VAT is computed on top of price*quantity. | |
| issue_date | No | Invoice date YYYY-MM-DD. Defaults to today (UTC). | |
| service_id | No | Your FIRS-issued Service ID (the middle segment of the IRN, e.g. 6997D6BB). Used with invoice_number + issue_date to build the IRN. Not needed if you pass irn directly. | |
| business_id | Yes | Your FIRS business_id (UUID) from your NRSMBS Dashboard — identifies the taxpayer entity submitting the invoice. | |
| customer_tin | Yes | Buyer Tax Identification Number (TIN). | |
| supplier_tin | Yes | Seller Tax Identification Number (TIN), e.g. TIN-0099990001. | |
| customer_city | No | Optional buyer city_name. | |
| customer_name | Yes | Buyer (customer) legal party_name. | |
| supplier_city | No | Optional seller city_name. | |
| supplier_name | Yes | Seller (supplier) legal party_name as registered with FIRS. | |
| customer_email | No | Optional buyer email. | |
| invoice_number | No | Your own invoice/document number (used to build the IRN, unless you pass irn directly). E.g. INV001. | |
| supplier_email | No | Optional seller email. | |
| customer_street | No | Optional buyer street_name (postal_address). | |
| supplier_street | No | Optional seller street_name (postal_address). | |
| tax_category_id | No | Optional FIRS tax_category id for the VAT lines. Default VAT (value-added tax). Use another MBS tax-category code only if the goods fall under a different regime. | |
| invoice_type_code | No | FIRS invoice type code. Default 396 (commercial invoice). See the MBS GetInvoiceTypes list for others. | |
| customer_postal_zone | No | Optional buyer postal_zone (post code). | |
| supplier_postal_zone | No | Optional seller postal_zone (post code). | |
| document_currency_code | No | ISO currency of the invoice. Default NGN. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true; the description reinforces this with 'No fiscal effect — nothing is signed.' It also discloses behavior: returns pass or error list, builds UBL JSON, computes VAT, and requires API keys. This adds valuable context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single coherent paragraph with no wasted words. It is front-loaded with purpose and covers authentication, parameters, and safety. Could be slightly more structured, but it's efficient and clear.
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 complexity (21 parameters, 6 required), the description thoroughly covers prerequisites (API keys, business enabled), parameter usage, return format, and safety. It is complete for an AI agent to use the tool correctly without additional information.
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% with detailed property descriptions. The description adds extra context, explaining how parameters are used together (e.g., 'You send flat fields; this server builds the UBL-mapped JSON'), and details IRN construction. 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's purpose: 'Pre-validate a Nigeria e-invoice against FIRS / NRS MBS BEFORE signing'. It specifies the resource (invoice), action (pre-validate), and endpoint, distinguishing it from sibling tools that are for actual creation or query.
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 indicates when to use it (before signing, to fix errors) and implies not for actual submission. It mentions it's a pre-check with no fiscal effect. However, it does not explicitly list alternatives like create_invoice for actual submission, but the context is clear.
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!