Skip to main content
Glama
Invompt

Invompt MCP

by Invompt

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.2 for the next channel 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 https://mcp.invompt.com/mcp

You explicitly choose a server-issued pseudonymous local credential.

OAuth

Native HTTPS MCP at https://mcp.invompt.com/mcp

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 oauth

For 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 oauth

Use 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 5xx responses are temporary failures; do not loop or silently retry credential issuance.

  • 401 means a Guest credential is invalid or revoked; use deliberate reset/recovery before another setup attempt, especially when the recorded secret backend is unavailable.

  • 429 respects Retry-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 check

The 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 tool
create_invoiceCreate InvoiceB

Create an Invompt invoice from raw IML YAML. Read invompt://spec/iml/v1 first if you need schema guidance.

ParametersJSON Schema
NameRequiredDescriptionDefault
imlYesRaw Invoice Markup Language (IML) YAML.
templateIdNoOptional template override.

Output Schema

ParametersJSON Schema
NameRequiredDescription
urlYes
invoiceIdYes

TDQS

B3.2/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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

B3.2/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap with other tools, making disambiguation perfect.

Naming Consistency5/5

A single tool inherently has consistent naming, as there are no other tools to compare it against for patterns or deviations.

Tool Count2/5

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.

Completeness1/5

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

ActivityMaintained
ResponsivenessSyncing

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

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables 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
  • A
    license
    B
    quality
    D
    maintenance
    Enables 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.
    3
    29
    2
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    InvoiceXML 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 n
    5
    MIT

Latest Blog Posts

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