What does Provely do when your agent calls an MCP server?

A server answers tools/list with one declaration per tool: a name and a JSON Schema for its arguments. One method, callTool({ name, arguments }), runs every tool. Provely reads that catalogue on connection, with no compiler run and no language model call.

An integration holds one completion contract for each completion level, the evidence channels each contract reads, the correlation strategy, the conformance results, and the certification. Provely signs the manifest with Ed25519, so a receipt names the version that judged an action.

Example: the Stripe integration holds 2 contracts, stripe.refund.created and stripe.refund.succeeded. Each one is a different completion level, and a lower level never proves a higher one. Read the Stripe integration.

An Agent Skill is the other object: one SKILL.md file in the Anthropic format that an agent loads and follows. Provely ships two kinds. The product skill provely-outcome-verification teaches any agent to verify before it claims done, and it renders for each host. Each integration also ships its own skill, for example provely-stripe, so an agent knows how to verify that provider. The machine plan stays in the signed manifest, and never in that file. An Agent Skill from someone else can call a provider itself, and Provely guards it at the call.

Provely publishes its own MCP server, with the four tools begin, verify, status, and receipt. Each handler reads the bearer token from the request, never from a tool argument. Read the Provely MCP server documentation.

deriveEnvelope reads the tool declarations of the server and the confirmed input, and it writes a policy. Every bound comes from a declaration: a value bound is a const on an argument whose declared name equals a confirmed input key. The comparison is exact, never a similarity.

The envelope is an allow list, not a checklist. A checklist asks whether the confirmed steps happened; an allow list also refuses everything else, so the policy states unlisted: 'refuse'. Provely closes each derived schema with additionalProperties: false, because an undeclared member is how a compromised server smuggles a payload past a check.

Every argument that no confirmed value bounds is marked REQUIRES_REVIEW. Provely never drops a part of a call in silence. The check compares two documents: it reads no text as an instruction, and it asks no language model. A schema that the checker cannot evaluate refuses the call, so the check fails closed.

A refusal happens before the provider call, and never after it. A control that reports a call after it ran is honest, and the money has already moved.

A tool schema states that a call takes an object and answers an object. It cannot state that a Shopify Refund object does not prove that money moved, or that a Square APPROVED payment is a hold.

A completion contract derived from a tool schema could assert only "the tool answered". That is an acknowledgement at evidence level E1, and safety rule 5 forbids an acknowledgement as terminal success. So Provely writes no contract from a tool schema, and it states UNVERIFIABLE. Read the UNVERIFIABLE definition and what each verdict obliges an agent to do.

Provely publishes 16 compiled integrations today. Each one states the levels it certifies and its last conformance run. Read the compiled integrations.

A call to a provider with no integration never reaches VERIFIED. Only a compiled provider reaches VERIFIED.

An MCP server is a transport. It is not an evidence channel. A verifier that reads a provider through the server that the agent used is no longer independent of the action path.

The evidence hierarchy rests on that independence. It runs from E0, a bare agent assertion, to E5, an outcome in an external system. E2 means a provider readback that the verifier made itself, and a reading that the action path returns is E1 at best. A compromised server would otherwise report a success and supply the evidence for it, which is a false VERIFIED.

1. Give the verifier a separate connection to the provider.
2. Make that credential read only, where the provider permits it. The agent never holds it.
3. The verifier calls the provider directly, and never through the server of the agent.
4. A provider that offers no direct read has no E2 channel, and the verdict is UNVERIFIABLE.

Never give an MCP server the credentials of the verifier. A hop on the action path is never new evidence. Read the evidence level definition.

Provely contains the consequence of an attack. It reads no prompt, and it judges no reason for an action. The contract states what a person authorised, the evidence states what happened, and the difference decides the verdict.

import { createToolGuard, deriveEnvelope, guardMcpClient, Provely } from '@provely/sdk';

const provely = new Provely();

// The declarations of the server. Provely reads them, and it reads no prose.
const declared = await client.listTools();

const envelope = deriveEnvelope({
  source: 'payments-mcp',
  tools: declared.tools,
  // The input that the person confirmed. Each name bounds the argument of that name.
  confirmed: { charge: 'ch_1001', amount: 500 },
});

// Every argument that no confirmed value bounds. A person reads each one.
for (const part of envelope.review) console.log(part.reason);

const guard = createToolGuard(provely, { policy: envelope.policy });
// The same client, with the one member replaced. The agent code does not change.
const guarded = guardMcpClient(guard, client);

The wrapper reads the tool name from each call, so one guard covers every tool of the server.