Which integrations are available for this server?

Provides tools for managing invoice workflows on Temporal, including triggering, approving, rejecting, and checking status of long-running interactive processes.

How do I use temporal-invoice-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@temporal-invoice-mcp trigger an invoice workflow from a sample file" 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.

temporal-invoice-mcp

by Aslan11

Overview Schema Related Servers Score Discussions

Python

Local

Invoice Demo with Temporal + MCP

Video:

Watch the demo

Prerequisites:

Python3+
uv (curl -LsSf https://astral.sh/uv/install.sh | sh)
Temporal Local Setup Guide
Claude for Desktop

1. Clone & install

 git clone https://github.com/your-org/temporal-mcp-invoice-demo.git
 cd temporal-mcp-invoice-demo
 uv venv
 source .venv/bin/activate
 uv pip install temporalio fastmcp

Related MCP server: agent-invoice

2. Launch Temporal locally

 temporal server start-dev

3. Start the worker

 python worker.py [--fail-validate] [--fail-payment]

Quick demo boot

Instead of starting the server and worker manually you can launch them in a tmux session using the boot-demo.sh helper script:

 ./boot-demo.sh

Claude for Desktop Instructions (Sonnet 4)

1. Follow steps 1-3 above

2. Edit your Claude Config (Claude > Settings > Developer > Edit Config)

{
  "mcpServers": {
    "invoice_processor": {
      "command": "/Path/To/Your/Install/Of/uv",
      "args": [
        "--directory",
        "/Path/To/temporal-invoice-mcp",
        "run",
        "server.py"
      ]
    }
  }
}

3. Restart Claude for Desktop after editing your config

If successful you'll see invoice_processor under 'Search & Tools'

4. To kick off processing the mock invoice, run:

trigger <paste: samples/invoice_acme.json>

Use your MCP client (e.g., Claude Desktop) to call the trigger, approve, reject, and status tools. The trigger tool now returns both the workflow_id and run_id of the started workflow. Pass these values to the approve, reject, and status tools. The sample invoice lives at samples/invoice_acme.json. Inspect Temporal Web at http://localhost:8233. Kill and restart the worker at any time to observe deterministic replay.

5. Results

Claude submits the invoice workflow:

It can get status:

Claude + MCP can send inputs and updates to the process workflow such as approvals, or even do a combination of actions - all agentically, explaining in human analogies what's going on if you ask it to:

What's Cool About This:

Agents and applications connected by MCP can provide a powerful way for humans to interact with processes and applications
- (as long as the applications have an API to interact with)
MCP tools don't have to be just one API call - you can get process status and even send it more information as it proceeds
Temporal makes modeling a long-running, durable, interactive transaction simple to integrate with MCP

Available Tools

4 tools

approve_invoiceC

Signal approval for the invoice workflow.

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes
`run_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and description does not disclose side effects of approval (e.g., state change, irreversible actions, triggers). Output schema exists but description lacks behavioral context.

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?

Single sentence is concise and front-loaded, but could benefit from a bit more detail without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (2 params, output schema), the description is too minimal. It does not explain what approval entails, prerequisites, or expected outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning to the two string parameters (workflow_id, run_id). No format, source, or usage hints provided.

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?

Description clearly states the tool signals approval for the invoice workflow, distinguishing it from siblings like reject_invoice. However, it could be more specific (e.g., mark as approved).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives like reject_invoice or invoice_status. Usage is implicit from the name and description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

invoice_statusC

Return current status of the workflow.

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes
`run_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description bears full responsibility. It only states what the tool returns, but does not disclose that it is non-destructive, whether authentication is required, or how errors are handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but risks being too terse. It lacks contextual detail that could be added without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema, but the description does not explain what the status field contains. With two required parameters and no parameter documentation, the description is inadequate for agents to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides no information about the two parameters (workflow_id, run_id). The input schema also lacks descriptions (0% schema coverage). Without any guidance, an agent cannot determine how to populate these parameters meaningfully.

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 tool returns the status of a workflow. It is a specific verb-resource pairing and implicitly distinguishes from sibling mutation tools like approve_invoice and process_invoice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not mention that it is a read-only operation to check progress after submitting a workflow, nor does it exclude any scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

process_invoiceC

Start the InvoiceWorkflow with the given invoice JSON.

ParametersJSON Schema

Name	Required	Description	Default
`invoice`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry behavioral disclosure. Only states 'Start the InvoiceWorkflow' without explaining effects, validation, or what the workflow entails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely brief, but lacks necessary detail. Conciseness is good but at the expense of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (workflow initiation, one required object param) and existence of siblings, the description fails to explain workflow purpose, return value, or prerequisite state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'invoice' has zero schema description coverage (0%). Description merely repeats 'the given invoice JSON' without adding structure, required fields, or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Start the InvoiceWorkflow', a specific verb+resource combination. It distinguishes from siblings like approve_invoice (decision) and invoice_status (query).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings (approve, reject, status). Does not explain context such as invoice state prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reject_invoiceD

Signal rejection for the invoice workflow.

ParametersJSON Schema

Name	Required	Description	Default
`workflow_id`	Yes
`run_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description only says 'signal rejection' but doesn't disclose mutability, side effects, or permissions. Minimal behavioral info.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise but lacks substance and structured front-loading of key info. Acceptable for brevity but not helpful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-param tool with output schema but no annotations, the description fails to explain what the tool returns or any workflow context. Incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and description gives no explanation for parameters 'workflow_id' and 'run_id'. Agent must infer meaning from context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description says 'Signal rejection for the invoice workflow', which is vague. It doesn't specify the action's effect (e.g., status change, notification) nor distinguish from sibling 'approve_invoice'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like approve_invoice or invoice_status. No prerequisites or conditions stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: starting the workflow, checking status, approving, or rejecting. No overlap or ambiguity among the four tools.

Naming Consistency4/5

Three tools follow a verb_noun pattern (approve_invoice, process_invoice, reject_invoice), while invoice_status is noun_noun. However, all use consistent snake_case and are clear and descriptive.

Tool Count5/5

Four tools is perfectly appropriate for a simple invoice approval workflow: start, approve, reject, and check status. The scope is well-scoped without being too sparse or excessive.

Completeness4/5

The tools cover the core lifecycle of an invoice workflow (create, approve, reject, status). Minor gaps like update or cancel are not critical for a basic approval process.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

invoice-badger
com.invoicebadger
Invoicing you drive by talking to your AI: log time, raise invoices and track what's owed via MCP.
Finance Payments & Billing
2
inflow
ai.inflowpay.app
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
Agent Orchestration Autonomous Agents Payments & Billing
26
Wever Labs Agentic Rails C
com.weverlabs
Agentic rails for complex workflows with receipts, fees, and MCP tool access.
Agent Orchestration Autonomous Agents Payments & Billing
892
Jupiter Invoice
com.jupiterinvoice
Create and manage invoices and customers on Jupiter Invoice (MCP, API-key auth).
Payments & Billing Finance
2

Related MCP Servers

Invoice MCP Server
Payments & Billing Finance
morenoraf
A
license
Not graded
quality
D
maintenance
Enables invoice management through MCP, including customer, invoice, and report operations with CLI and web interfaces.
Updated 8 months ago (2026-01-09 11:41 UTC)
MIT
agent-invoice
Finance Payments & Billing
nyx-builds
A
license
Not graded
quality
A
maintenance
Enables agents to generate, track, and manage invoices via MCP tools, with CLI support for payment tracking and earnings summaries.
Updated 24 days ago (2026-08-10 21:09 UTC)
MIT
myinvois-mcp
Finance Payments & Billing
techtemplemy
A
license
Not graded
quality
B
maintenance
Enables issuing and managing validated Malaysian e-invoices via MyInvois (LHDN) directly from MCP clients, with tools for TIN validation, invoice drafting, submission, and document management.
Updated 2 months ago (2026-07-12 02:25 UTC)
19
2
Do What The F*ck You Want To Public
mcp-ledger-server
grzegorzkowalskigk-jpg
F
license
A
quality
B
maintenance
Exposes a ledger system (invoice queue, duplicate control, VAT register, contractor history, decision journal) as MCP tools for AI agents, enabling accurate invoice processing with deterministic validation.
Updated a month ago (2026-08-01 08:48 UTC)
7

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Aslan11/temporal-invoice-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server