Invompt MCP
This server enables you to create invoices using the Invompt platform by submitting raw Invoice Markup Language (IML) YAML through the create_invoice tool. You can optionally specify a template from available options (professional, minimal, or modern) to influence the visual style. Upon successful creation, you receive a unique invoiceId and a direct url to access the invoice. A schema resource (invompt://spec/iml/v1) is available for reference when writing IML.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Invompt MCPCreate a professional invoice for 8 hours of design work at $125 per hour"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Invompt MCP
Invompt MCP is a pre-1.0, local-beta package for onboarding Claude Code and Codex to Invompt invoice tools. It provides portable skills, a setup CLI, and a Guest stdio bridge; Invompt retains invoice rules, persistence, rendering, and hosted document links.
This source prepares
invompt-mcp@0.11.2for thenextchannel only. It makes no release, production, registry-availability, or fresh-host compatibility claim. Verify external state independently before relying on any registry artifact.
Supported local-beta hosts
Local beta is scoped to macOS Claude Code and Codex. Their package manifests expose skills only; they do not install a static MCP transport because the user must choose the connection mode first.
Mode | Transport | Use when |
Guest | Local stdio bridge to | You explicitly choose a server-issued pseudonymous local credential. |
OAuth | Native HTTPS MCP at | You explicitly choose browser sign-in. |
The local loopback development endpoint is http://localhost:3101/mcp; it is for development, not a public host-default configuration. Gemini CLI and Qwen Code files are templates only and are not supported local-beta runtimes.
ChatGPT web is separate: it is remote OAuth-only at https://mcp.invompt.com/mcp. It must never run local status/setup, use a Guest bridge, or inspect local device state.
This repository's CLI is a separate local-beta distribution. It configures only invompt-local-beta; setup, logout, reset, and reconciliation never remove or modify invompt. The Workspace Hub global consumer remains one hosted HTTPS OAuth-only invompt provider.
Related MCP server: Invoices Generator MCP Server
Setup
Before an Invompt MCP call, the onboarding skill checks redacted status. If the mode is undecided, it asks exactly whether you want Guest or OAuth in the current conversation language and waits for your explicit choice.
For Codex, run one chosen command:
npx --yes invompt-mcp@0.11.2 setup --host codex --mode guest
npx --yes invompt-mcp@0.11.2 setup --host codex --mode oauthFor Claude Code, use the same pinned package CLI rather than assuming an installed-cache path:
npx --yes invompt-mcp@0.11.2 setup --host claude-code --mode guest
npx --yes invompt-mcp@0.11.2 setup --host claude-code --mode oauthUse status --json through the same current-host command to inspect redacted state. There is no postinstall prompt and no credential in a manifest or host configuration.
The resulting MCP server is named invompt-local-beta on both hosts. Keep the normal global invompt provider separate and OAuth-only.
Plugin and skill discovery use the same isolated namespace: plugin invompt-local-beta, with skills invompt-local-beta-onboarding and invompt-local-beta-invoice. The package does not discover as global plugin invompt or as global skill invompt-invoice, invompt-export, or invompt-health.
Guest is Keychain-first on macOS (com.invompt.invompt-mcp / guest-credential). Only when you explicitly permit the fallback may setup add --allow-file-fallback; the fallback is restricted-permission plaintext at ~/.invompt/guest-credential (mode 0600). Non-secret local state is ~/.invompt/auth-state.json (mode 0600 in a 0700 directory).
Switching Guest to OAuth leaves the Guest secret dormant. It is never auto-converted, claimed, or merged into an account. Use logout --host codex or logout --host claude-code for a deliberate host logout. reset --yes removes local state and attempts Guest revocation; if revocation cannot reach the service, copied credentials may remain valid and the CLI reports that warning.
Transport mode is separate from account type: hosted OAuth Guest and legacy credential Guest are both Guest principals. An explicit account-claim request calls the claim tool once; the backend decides eligibility. After an OAuth Guest claim, the grant remains connected and revalidates registered state; after a legacy Guest claim, the old credential fails with GUEST_ACCOUNT_CLAIMED.
Migration and rollback
0.11.2 adds nullable update-link recovery: a committed update_invoice can report url: null with linkState: unavailable when capability lookup loses a renewal race, so renew the link without repeating the update. It does not migrate an existing global OAuth-only consumer. Select one local-beta mode deliberately. --allow-file-fallback is valid only with setup --mode guest, and unknown or duplicate flags are rejected. To roll back local-beta state, first run logout --host …; use reset --yes only when you also intend to remove local authentication state and attempt Guest revocation. Restore the Workspace Hub consumer through its own OAuth-only installer, not this CLI.
Failures and privacy
Offline/network failures and
5xxresponses are temporary failures; do not loop or silently retry credential issuance.401means a Guest credential is invalid or revoked; use deliberate reset/recovery before another setup attempt, especially when the recorded secret backend is unavailable.429respectsRetry-After; do not retry before it.A host CLI error leaves setup needing reconciliation; do not claim the host is configured.
Invompt MCP derives no hardware or device fingerprint and collects no serial data or MAC addresses. The server-issued Guest credential is the sole pseudonymous local identity; it is stored in Keychain by default and is never used to derive device identity. It has no runtime dependencies after bundling, opens no listener, and does not execute invoice business logic. It forwards JSON-RPC only through the explicitly selected transport and rejects HTTP redirects.
Development verification
Use Node.js 22.22.0 and npm 11.11.0 for the canonical package gates:
npm ci
npm run checkThe checks build, typecheck, lint, test, scan source and packed artifacts for secrets/privacy regressions, verify the exact package allowlist, and test an isolated tarball-only consumer. Local checks do not prove an external release or fresh-host installation.
Available Tools
1 toolcreate_invoiceCreate InvoiceB
Create an Invompt invoice from raw IML YAML. Read invompt://spec/iml/v1 first if you need schema guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| iml | Yes | Raw Invoice Markup Language (IML) YAML. | |
| templateId | No | Optional template override. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| invoiceId | Yes |
TDQS
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 mentions creating an invoice but doesn't disclose behavioral traits like permissions needed, whether the operation is idempotent, error handling, or what the output contains. The reference to external documentation adds some context but insufficiently compensates for the lack of built-in transparency.
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 concise with two sentences, front-loading the main action and following with guidance. There's no wasted text, but it could be slightly more structured by explicitly separating purpose from prerequisites.
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 has an output schema, the description doesn't need to explain return values. However, with no annotations and a mutation operation (create), the description lacks completeness in areas like behavioral context and usage prerequisites, making it adequate but with clear gaps for an agent to use effectively.
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 description coverage is 100%, so the schema already documents both parameters fully. The description adds minimal value beyond the schema by hinting at the need for schema guidance but doesn't provide additional semantics for the parameters. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('Create an Invompt invoice') and the input source ('from raw IML YAML'), providing specific verb+resource information. However, it doesn't differentiate from siblings since there are none, and the mention of 'invompt://spec/iml/v1' adds helpful context but doesn't fully clarify the purpose beyond the basic action.
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 implies usage by referencing external schema guidance ('Read invompt://spec/iml/v1 first if you need schema guidance'), which suggests when to prepare inputs. However, it lacks explicit when-to-use guidance, alternatives, or exclusions, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
With only one tool, there is no possibility of ambiguity or overlap with other tools, making disambiguation perfect.
A single tool inherently has consistent naming, as there are no other tools to compare it against for patterns or deviations.
One tool is too few for a server named 'Invompt MCP', which suggests a broader invoicing domain; this feels thin and likely incomplete for typical invoicing workflows.
The server appears focused on invoicing, but with only a create_invoice tool, it lacks essential operations like retrieving, updating, listing, or deleting invoices, making it severely incomplete.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Validate, extract, repair and generate French Factur-X / EN16931 invoices via AgentForge API
Create and manage invoices and customers on Jupiter Invoice (MCP, API-key auth).
Validate, generate & convert EU e-invoices (UBL, CII, XRechnung, Factur-X) — EN 16931 pre-validated.
Generate invoice and receipt PDFs from JSON. Agent-callable document API with a free demo quota.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables creation and management of invoices with JSON storage and LaTeX-based PDF rendering. Supports draft creation and professional PDF generation through customizable LaTeX templates.Apache 2.0
- AlicenseCqualityDmaintenanceProvides access to the Invoices Generator API to create professional, customizable invoices with detailed buyer, seller, and service information. It supports multiple languages, currencies, and tax configurations through a standardized tool interface.1MIT
- AlicenseBqualityDmaintenanceEnables the generation of professional PDF invoices and their distribution via email using customizable templates. It allows users to create, manage, and send invoices with standard business fields like tax rates and line items through natural language.3292MIT

InvoiceXMLofficial
AlicenseNot gradedqualityCmaintenanceInvoiceXML brings e-invoice compliance to your AI agent. Create, validate, convert, render, and extract structured invoices across UBL (Peppol BIS Billing 3.0, used worldwide), CII, Factur-X, ZUGFeRD, and XRechnung, all checked against the EN 16931 standard and official Schematron rules. Ask your assistant to generate a compliant invoice, validate one for errors, or convert between formats, with n5MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Invompt/invompt-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server