mcp-invoicenow-sg
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Logging level: DEBUG, INFO, WARNING, or ERROR | INFO |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_invoice_sgA | Build an SGInvoice from structured data and serialize it to UBL 2.1 XML.
|
| validate_invoice_sgA | Validate a UBL 2.1 XML invoice against IRAS's C5 acceptance-layer Schematron. Runs IRAS's own C5 acceptance layer (checks documents that IRAS
itself would still reject, e.g. a missing buyer/seller UEN). The CEN
EN16931 base ruleset, PINT-SG's own jurisdiction overlay, and SG
Peppol BIS Billing 3.0 are NOT checked — see Requires the optional |
| get_gst_category_codes_sgA | Return the IRAS GST category codes accepted on Singapore invoices. Source: IRAS e-Tax Guide Annex E (supply/output-tax side only — the
purchase-side codes are out of scope for sent invoices). |
| get_profile_urn_sgA | Return the CustomizationID (BT-24) and ProfileID (BT-23) for a Singapore profile. CustomizationID comes from mcp_einvoicing_core.profile_registry (registered at import time in models/invoice.py); ProfileID is a shared Peppol process identifier, not per-country, so it is returned from a local constant rather than the registry. PINT_SG is the recommended profile for new senders — SG Peppol BIS Billing 3.0 (BIS3) predates the PINT programme and is positioned as legacy (per the package's own compliance reference, "Supported wire formats and profile URNs" — user-supplied guidance, not independently verified against an IRAS/IMDA notice). Not enforced as a hard default here; callers choose explicitly. |
| peppol_lookup_participantA | Check whether a business is registered on the Peppol network. Performs a DNS-over-HTTPS U-NAPTR lookup followed by an SMP service-group request to determine registration status and the list of supported document type identifiers. |
| peppol_get_service_endpointA | Fetch the AS4 endpoint for a Peppol participant's document type. Resolves the SMP hostname via DNS, then fetches service metadata for
document_type_id. If the SMP returns a redirect, the result's
|
| resolve_peppol_dnsA | Resolve the SMP hostname for a Peppol participant via DNS only. Performs the raw U-NAPTR (SML) lookup without fetching the SMP service group, useful for diagnosing whether a participant is registered in the SML independently of SMP reachability. |
| peppol_sendA | Send a UBL/CII invoice to a Peppol participant via AS4. Looks up the recipient's AS4 endpoint (SMP), builds the ebMS3/AS4 envelope, and transmits it using the supplied signing credentials. |
| list_participant_id_schemesA | List Peppol participant identifier (ICD) schemes from the OpenPeppol eDEC code list. Requires EINVOICING_PEPPOL_CODELIST_DIR to point at a local copy of
the eDEC "Participant Identifier Schemes" GeneriCode export (not
bundled with this package, no confirmed redistribution rights, see
|
| list_document_type_idsA | List Peppol document type identifiers from the OpenPeppol eDEC code list. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| list_process_idsA | List Peppol process identifiers from the OpenPeppol eDEC code list. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| list_spis_use_case_idsA | List Peppol SPIS use case identifiers from the OpenPeppol eDEC code list. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| check_document_type_id_in_codelistB | Check whether a (scheme, value) pair is a recognized Peppol document type identifier. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| check_process_id_in_codelistB | Check whether a (scheme, value) pair is a recognized Peppol process identifier. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| check_participant_id_scheme_in_codelistA | Check whether a 4-digit ISO 6523 ICD code (e.g. "0208") is a recognized Peppol scheme. Requires EINVOICING_PEPPOL_CODELIST_DIR (see |
| get_peppol_codelist_versionA | Report the OpenPeppol eDEC code list release version(s) currently configured locally. |
| peppol_directory_searchA | Search the Peppol Directory for registered participants. Public, unauthenticated search (no relation to SMP lookup). At least one of q/participant/name/country/doctype must be supplied. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Most tools have clearly distinct purposes, and the descriptions carefully delineate the participant-lookup family (peppol_lookup_participant vs resolve_peppol_dns vs peppol_get_service_endpoint vs peppol_directory_search). The codelist check_* vs list_* pairs are also cleanly separated. The only mild residual overlap is the cluster of registration/SMP lookups, but prose disambiguates them.
Predominantly verb_noun (generate_invoice_sg, validate_invoice_sg, list_document_type_ids, check_process_id_in_codelist), which is readable. However the peppol_ prefix is applied inconsistently (peppol_send, peppol_get_service_endpoint, peppol_lookup_participant vs list_document_type_ids, check_process_id_in_codelist with no prefix), and the _sg suffix on some tools is uneven.
17 tools is slightly heavy but each earns its place across distinct concerns: codelist listing plus per-codelist checks, profile/GST metadata, generation, validation, and the Peppol transport chain. The four list_* codelist tools are individually justified by different identifier domains. It sits near the top of the reasonable band rather than being bloated.
The generate-validate-send Peppol pipeline is covered end to end, with participant lookup, endpoint resolution, codelists, GST codes, and profile URNs. The explicit absence of EN16931 base / PINT-SG overlay validation (documented as CORE-EN16931-BASE-SG-CROSSWALK-1) and no inbound/receive path are real but acknowledged gaps.