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.
| SDK | MCP | |
|---|---|---|
| How | Import @fidacy/sdk and call it in code | The host installs the server, no code change |
| Fits | You own the agent source | You run an MCP-native agent |
| Gives | Signed verdict | Signed verdict + payment firewall |
| Proof | Verifiable JWS | 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
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.
| Tool | Backend | What it does |
|---|---|---|
assess_action | engine | Returns a signed trust verdict (approve / review / deny) on a proposed action. The proof is a JWS, verifiable by anyone. |
request_payment | core | 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 | core | Returns the active mandate for a subject, the rules the agent is bound to. |
get_audit_proof | core | 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
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:
// 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.
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.
Copy-paste verification is on the Verify a Payload page.