Meridian Mcp

io.github.meridian-silkdevPublished by GitHub account meridian-silkdevv0.1.2Updated Oct 24, 2026

MCP server for Meridian: services, requests, workflow, payments, meetings for founders.

VerifiedSTDIODesktop onlyProductivity & WorkflowFinanceBusiness & Commerce

Overview

AI-generated overview

Local stdio MCP server for the Meridian business-services platform, letting an assistant browse services, manage service requests and workflow steps, check…

What you can do
  • List and inspect the service catalog: services, service details with form config, and categories
  • List, read and create service requests, and patch their status
  • Track and advance workflow steps, including current phase and ordered request steps
  • Check payment status and verify payments server-side via Flouci or Stripe
  • List, create and RSVP to meetings, including Teams meeting creation with invites
  • Check API connectivity and configuration, and read service catalog and workflow resources
When to use it
Useful when you work with a Meridian instance and want an assistant to look up services, create or follow service requests through their workflow, check payment state, or manage meetings without switching to the web app.
Requirements
Runs locally over stdio as an npm package, so Node.js is needed. Requires MERIDIAN_API_URL pointing at the Meridian app (defaults to and a MERIDIAN_API_KEY (mrd_ key) for real REST calls; without the key every tool only returns a dry-run placeholder hint. Optional DATABASE_URL fallback and MERIDIAN_MCP_LOG_LEVEL.
Before you install
The server asks for a long-lived MERIDIAN_API_KEY credential; keep it out of shared config files checked into git. Several tools write data: creating service requests, updating request status, advancing workflow steps, creating meetings with invites, and responding to meetings. Payment verification contacts Flouci or Stripe. Without the key it is safe to run in dry-run mode.

Installation

In SourceWeft

  1. Open Meridian Mcp in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

@meridiantoolkit/mcp

[meridian-mcp MCP server]

MCP server for the Meridian business-services platform. Exposes services, service requests, workflow steps, payments and meetings as Model Context Protocol tools and resources. MCP is a protocol, not a host-specific plugin format — this server runs unchanged in Claude Code, Codex CLI, Claude Desktop, pi, or any other MCP-compatible client.

Listed on the official MCP Registry as io.github.meridian-silkdev/meridian-mcp, and on Glama.

Install

bash
cd meridian-mcpnpm installnpm run build

Or once published:

bash
npx @meridiantoolkit/mcp

Configure

Copy .env.example or set env vars directly:

VarDescriptionDefault
MERIDIAN_API_URLMeridian app base URLhttp://localhost:3000
MERIDIAN_API_KEYmrd_ API key (Better Auth) for REST calls(none — tools return placeholder hint until set)
DATABASE_URLOptional direct DB access fallback
MERIDIAN_MCP_LOG_LEVELdebug/info/warn/errorinfo

More: /.well-known/agent-configuration exposes Agent Auth discovery (capability-based, short-lived JWTs, device-auth/CIBA approval). Agents can use either a long-lived mrd_ key or scoped Agent Auth grants — see meridian-skills meridian-api skill.

Without MERIDIAN_API_KEY every tool still responds — it explains what endpoint would be called and what to configure, so the server is safe to run in dry-run / demo mode.

Run

bash
npm start            # stdio MCP servernpm run dev          # watch mode via tsx

Claude Code

bash
claude mcp add meridian -- node /absolute/path/to/meridian-mcp/dist/index.js# or, once published:claude mcp add meridian -- npx -y @meridiantoolkit/mcp

Or drop a .mcp.json in your project root (shareable with a team, checked into git):

json
{  "mcpServers": {    "meridian": {      "command": "npx",      "args": ["-y", "@meridiantoolkit/mcp"],      "env": {        "MERIDIAN_API_URL": "http://localhost:3000",        "MERIDIAN_API_KEY": "..."      }    }  }}

Codex CLI

Codex reads MCP servers from ~/.codex/config.toml (or a project-scoped .codex/config.toml for a trusted project):

toml
[mcp_servers.meridian]command = "npx"args = ["-y", "@meridiantoolkit/mcp"]env = { MERIDIAN_API_URL = "http://localhost:3000", MERIDIAN_API_KEY = "..." }

Or via the CLI: codex mcp add meridian -- npx -y @meridiantoolkit/mcp. The same config is shared by Codex CLI, the IDE extension, and the ChatGPT desktop app.

Codex has no plugin/skill system (unlike Claude Code and pi) — its equivalent of meridian-plugin/meridian-skills is just this MCP server plus project guidance. Copy AGENTS.md.example into your project's AGENTS.md for the same tool-usage guidance the skills packages give elsewhere.

Claude Desktop / pi

Add to your MCP config (Claude Desktop: claude_desktop_config.json; pi: .pi/settings.json → mcpServers, or pi --mcp):

json
{  "mcpServers": {    "meridian": {      "command": "node",      "args": ["/absolute/path/to/meridian-mcp/dist/index.js"],      "env": {        "MERIDIAN_API_URL": "http://localhost:3000",        "MERIDIAN_API_KEY": "..."      }    }  }}
bash
pi --mcp meridian-mcp/dist/index.js# or via npx after publishnpx @meridiantoolkit/mcp

Tools

ToolDescription
meridian_statusCheck API connectivity/config and list available tools/resources. No params. Works the same in every client — this replaces the pi-only meridian_status extension tool from meridian-plugin so status-checking isn't tied to one host.
list_servicesList services (filter: categorySlug, isActive, countryCode)
get_serviceGet service by id/slug with formConfig
list_categoriesList service categories
list_service_requestsList requests (filter: status, customerId, providerId, limit)
get_service_requestGet request by id with steps
create_service_requestCreate request (serviceId, answers, customTitle)
update_request_statusPatch request status (prefer advance_step)
get_workflow_statusCurrent phase + all requestSteps
advance_stepComplete current step → next step
list_request_stepsAll RequestSteps in order
get_payment_statusPayment row for a request
verify_paymentServer-side verify with Flouci (Tunisia, local) or Stripe (international)
list_meetingsList meetings (filter: serviceRequestId, status)
create_meetingCreate Teams meeting + invites
respond_to_meetingRSVP ACCEPTED/DECLINED/PENDING

Resources

URIDescription
meridian://servicesService catalog JSON
meridian://workflowWorkflow backbone + phases

Development

bash
npm run typechecknpm run buildnpm test          # spawns the built server over stdio and exercises every tool/resource

Publish

First publish (manual, one-time — a scoped package can't use Trusted Publishing until it exists on the registry):

bash
npm login                     # once per machinenpm publish --access public

CI/CD

  • .github/workflows/ci.yml — every push to main and every PR: npm ci, typecheck, build, npm test (the real stdio smoke suite).
  • .github/workflows/publish.yml — fires on a published GitHub Release, re-runs the full test suite, checks the release tag matches package.json's version, then:
    1. npm publish --provenance via npm's Trusted Publishing (OIDC) — no NPM_TOKEN secret to create or rotate.
    2. Publishes/updates the listing on the official MCP Registry via mcp-publisher login github-oidc + mcp-publisher publish (also OIDC, no secret). server.json's version is synced to the release tag automatically. This step has continue-on-error: true — the registry is explicitly in preview, so a hiccup there never blocks the actual npm release.

mcpName requirement: package.json has an "mcpName": "io.github.meridian-silkdev/meridian-mcp" field — the registry's package validator needs this to confirm the npm package and the GitHub-verified server identity are published by the same owner. If you ever rename the server in server.json, update this field too or publishes will 400.

Known upstream bug, worked around: the interactive mcp-publisher login github device flow reliably 403s when publishing under a GitHub organization namespace (confirmed-public membership, Owner role, doesn't matter — see modelcontextprotocol/registry#1537, still open as of this writing). github-oidc from inside a GitHub Actions workflow running in the org's own repo sidesteps it entirely, since it verifies the workflow's repo identity rather than checking the human account's org list. That's why the registry publish step lives in CI, not as a manual local command.

One-time setup after the first manual publish: on the package's npmjs.com page → Settings → Trusted Publisher → GitHub Actions, and point it at meridian-silkdev/meridian-mcp, workflow publish.yml. After that, releasing a new version is just:

bash
npm version patch   # or minor/major — bumps package.json + creates a git taggit push --follow-tagsgh release create v0.1.3 --generate-notes   # publishing this release triggers both the npm and MCP Registry publish steps

Source: README.md at commit e6f1e07

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v0.1.2LatestSep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts