INTEGRATIONS

Use Fidacy as an MCP server

Rather not touch your agent’s code? Install Fidacy as an MCP server. An MCP-native host (Claude Desktop, Cursor, any MCP client) loads it and your agent gets the tools directly. One install wires two things: a signed verdict on any action, and the non-custodial payment firewall. Same engine, same signed proof as the SDK.

SDK or MCP?

Two surfaces onto the same engine. Pick by how you want to integrate, not by what you get.

How

Import @fidacy/sdk and call it in code (SDK), or the host installs the server with no code change (MCP).

Fits

You own the agent source → SDK. You run an MCP-native agent → MCP.

Gives

SDK: signed verdict. MCP: signed verdict + payment firewall.

Proof

Both emit the same verifiable JWS.

They are not exclusive. Use the SDK in one service and the MCP in another — both emit the same signed, verifiable artifacts.

Install

Add one server to your MCP host config. It speaks MCP over stdio. The only thing you need to start is an engine key for verdicts:

{
  "mcpServers": {
    "fidacy": {
      "command": "npx",
      "args": ["-y", "@fidacy/mcp"],
      "env": {
        "FIDACY_ENGINE_URL": "https://api.fidacy.com",
        "FIDACY_ENGINE_API_KEY": "fky_test_…"
      }
    }
  }
}

Use a fky_test_… key while you build (sandbox, never counts as live), then swap to fky_live_…. Mint one at app.fidacy.com scoped to assess:write.

Add the payment firewall

To also gate real payments, point the firewall tools at a firewall-core service you run (the live reference deployment is https://fidacy-core.vercel.app). Add three env vars to the same server:

"FIDACY_MODE": "http",
"FIDACY_API_URL": "https://your-core.example.com",
"FIDACY_API_KEY": "…"   // the MCP -> core shared secret

The tools

One install exposes four tools. assess_action calls the engine; the rest call your firewall core.

assess_action

Returns a signed trust verdict (approve / review / deny) on a proposed action. The proof is a JWS, verifiable by anyone.

request_payment

Gates a payment against a signed mandate. ALLOW mints a short-lived Ed25519 grant; DENY returns the violated rule. No money moves here.

verify_mandate

Returns the active mandate for a subject — the rules the agent is bound to.

get_audit_proof

Returns the append-only, hash-chained audit proof for a decision.

Moving the money is a separate, deliberate step. The companion @fidacy/executor exposes one tool, execute_payment, that you couple to your PSP. It refuses anything without a valid grant bound to that exact request, so a hijacked agent cannot pay past it.

A verdict, end to end

POST/v1/assess

{
  "decision": "approve",        // approve | review | deny
  "score": 0.12,
  "assessmentId": "…",
  "riskPayloadJws": "eyJ…",     // the signed receipt
  "signingKeyId": "…",
  "mandate": { /* carries risk_data */ },
  "outcome": { /* signals, reasons */ }
}

approve execute the action. review step up to a human before clearing — never a soft approve. deny block the action and surface the reasons. Fail safe: on any error, treat it as review, never approve.

Verify it yourself

The riskPayloadJws, and every firewall grant, is signed with the engine’s Ed25519 key. Any party verifies it offline against the public JWKS, with zero calls back to Fidacy. Copy-paste verification is on the Verify a Payload page.

GET/.well-known/jwks.json

← PREVIOUS
Agent Quickstart NEXT →
Verify a Payload