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.

SDKMCP
HowImport @fidacy/sdk and call it in codeThe host installs the server, no code change
FitsYou own the agent sourceYou run an MCP-native agent
GivesSigned verdictSigned verdict + payment firewall
ProofVerifiable JWSThe 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
Run bare, the firewall boots in a local dev mode with an ephemeral signing key, so you can try request_payment right away without a core, nothing production-grade yet. For production, either point it at a firewall-core with FIDACY_MODE=http (the env above), or self-host the signing key with FIDACY_SIGNING_KEY_B64. assess_action stays dormant until you set the engine key. The server boots fine with any combination.

The tools

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

ToolBackendWhat it does
assess_actionengineReturns a signed trust verdict (approve / review / deny) on a proposed action. The proof is a JWS, verifiable by anyone.
request_paymentcoreGates a payment against a signed mandate. ALLOW mints a short-lived Ed25519 grant; DENY returns the violated rule. No money moves here.
verify_mandatecoreReturns the active mandate for a subject, the rules the agent is bound to.
get_audit_proofcoreReturns 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

The agent proposes an action; assess_action returns the signed verdict it (and anyone) can act on and verify. It maps to one engine call:

POST/v1/assess
// the agent calls assess_action; the host returns structuredContent:
{
  "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 treat it as 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. The MCP hands you the same tamper-evident proof the SDK does.

GET/.well-known/jwks.json

Copy-paste verification is on the Verify a Payload page.