@ziffer-io/mcp 0.1.0

package/dist/tools.d.ts

@@ -0,0 +1,226 @@
+/**
+ * The five tools, as plain functions (ACP-197 section 6b point 2; ACP-213
+ * section 9.2 point 3 added the fifth).
+ *
+ * Every handler here takes its dependencies as arguments and returns a
+ * {@link ToolOutcome}. Nothing in this file imports the MCP SDK: `server.ts`
+ * adapts these to the protocol's content shape. That seam exists so the tests
+ * exercise the behaviour rather than the framing, and so the answer to "what
+ * does `propose` do when the key is unset" is one function call.
+ *
+ * # What is deliberately absent
+ *
+ * There is no approve tool, no simulated approval, and no tool that writes a
+ * file. The reason for the first two is worth carrying here rather than leaving
+ * in a ticket: **a simulated approval minted on a developer's laptop is a fake
+ * receipt factory**, and a receipt factory is the exact artifact this product
+ * exists to make impossible.
+ *
+ * Until ACP-213 this file also said there was no sandbox tool, and that a
+ * sandbox mode was "a follow-up with its own design". That follow-up landed and
+ * the design is the reason the sentence could change: a Ziffer sandbox is a
+ * SEPARATE TENANT with its own receipt signing identity, approved by a robot
+ * that walks the real quorum path with keys enrolled only in sandbox bundles
+ * (`services/sandbox-approver`, `docs/onboarding/sandbox.md`). Nothing about it
+ * is client-side, which is why {@link sandboxStatus} only ever REPORTS: it
+ * reads a name and asks the API about one decision. An approval on this side of
+ * the wire would still be a forgery, and there is still no tool for it.
+ *
+ * The third is a boundary rather than a danger: this server has no hands on the
+ * developer's machine. It serves knowledge and Ziffer-side calls; the coding
+ * agent talking to it is the thing that edits code. A file-writing tool here
+ * would make this process an editor with none of an editor's review surface.
+ */
+import { canon } from '@ziffer-io/verify';
+import { type Env } from './config.js';
+/**
+ * What a tool hands back.
+ *
+ * `isError` is the MCP protocol's flag for "this call did not do what it was
+ * asked", and it is set for every refusal — a configuration error, a gateway
+ * refusal, a receipt that does not verify. It is deliberately NOT set for a
+ * decision whose outcome is `DENY`: the tool was asked to get a decision and it
+ * got one. Marking a successful denial as a tool error teaches an agent to
+ * treat "the policy said no" as a malfunction to route around, which is the
+ * behaviour this whole system exists to prevent.
+ */
+export interface ToolOutcome {
+    readonly text: string;
+    readonly isError: boolean;
+}
+/**
+ * The §1 response to `POST /v1/proposals`, as the gateway sends it.
+ *
+ * Field names are §1's, in its spelling, because the tools return the response
+ * VERBATIM. A DTO with prettier names here would mean the agent reading our
+ * `docs/onboarding/sdk.md` sees one set of field names in the HTTP examples and
+ * a different set coming out of the tools, and would have to be told they are
+ * the same object.
+ */
+export interface SubmittedDecision {
+    readonly decision_id: string;
+    readonly status: 'pending' | 'decided';
+    readonly outcome?: string;
+    readonly clause?: string;
+}
+/** The §1 response to `GET /v1/decisions/{id}`: the above, plus the receipt
+ * when a signed one exists. `receipt` is `unknown` because this package never
+ * looks inside it — it is served to the agent as it arrived and handed to
+ * `@ziffer-io/verify` unparsed by anything of ours. */
+export interface DecisionRecord extends SubmittedDecision {
+    readonly receipt?: unknown;
+}
+/**
+ * The client surface, fixed by ACP-197 section 6, narrowed to what these tools
+ * call.
+ *
+ * Declared as an interface rather than imported as a class so that `tools.ts`
+ * has no dependency on the transport, and so the tests can drive every §1
+ * response shape — including the ones a stub HTTP server makes awkward to
+ * produce, like a gateway that is unreachable. `client.ts` is the one file that
+ * knows the concrete `ZifferClient`, and it is the one place a difference
+ * between §6's spelling and §1's would be reconciled.
+ */
+export interface DecisionClient {
+    propose(proposal: unknown): Promise<SubmittedDecision>;
+    decision(decisionId: string): Promise<DecisionRecord>;
+}
+/** How a tool gets a client, given the environment. Async and fallible: it
+ * resolves configuration, so an unset `ZIFFER_API_KEY` surfaces here. */
+export type ClientFactory = (env: Env) => Promise<DecisionClient>;
+/**
+ * `propose` — submit one wire Proposal and return the §1 response verbatim.
+ *
+ * The proposal is passed through untouched. This server does not fill in a
+ * `tenant_id`, and it must not: ACP-197 section 1 makes the KEY the tenant, and
+ * a body whose `tenant_id` disagrees is refused rather than rewritten, because
+ * the proposal is signed material downstream and a rewriter would have become
+ * its author. Helpfully "correcting" the field here would produce exactly the
+ * silent authorship the gateway's refusal exists to prevent.
+ */
+export declare function propose(clientFor: ClientFactory, env: Env, proposal: unknown): Promise<ToolOutcome>;
+/**
+ * `check_decision` — one decision by id, receipt included when present.
+ *
+ * The receipt is re-serialised as part of the response object rather than
+ * spliced in as text. That is safe HERE, and only here, because this output is
+ * for an agent to read: the copy that gets VERIFIED is the one
+ * `explain_receipt` is handed, and the hash it checks is recomputed from the
+ * proposal bytes, never from a re-encoding of the receipt. Nothing downstream
+ * of this tool treats its text as signed material.
+ */
+export declare function checkDecision(clientFor: ClientFactory, env: Env, decisionId: string): Promise<ToolOutcome>;
+/**
+ * `get_integration_guide` — `docs/onboarding/sdk.md`, for one language.
+ *
+ * The one tool that needs no configuration, deliberately: an agent should be
+ * able to read how to integrate before any credential exists. That is also why
+ * `config.ts` lets the server start unconfigured — a server that refused to
+ * boot without an API key could not answer the question a developer asks first.
+ */
+export declare function getIntegrationGuide(language: string): ToolOutcome;
+/**
+ * The marker's naming half (ACP-213). One spelling, and it is not the one that
+ * decides: `services/sandbox-approver/src/sandbox.rs` holds the rule that
+ * governs, against the tenant the SIGNED bundle names, beside an allowlist of
+ * receipt identities no client can see. This copy exists so a developer is told
+ * what they are pointed at before they send a proposal, and it says so.
+ */
+export declare const SANDBOX_SUFFIX = "-sandbox";
+/**
+ * Is this tenant id spelled as a sandbox?
+ *
+ * The suffix has to be attached to something: a tenant literally named
+ * `-sandbox` would be a tenant with an empty production name, which satisfies
+ * the convention while meaning nothing. Same rule, same words, as the Rust
+ * predicate and `tools/provision-sandbox.py`.
+ */
+export declare function isSandboxName(tenantId: string): boolean;
+/** What `sandbox_status` is handed. */
+export interface SandboxArgs {
+    /** The tenant id the caller's proposals carry. */
+    readonly tenantId: string;
+    /** A decision to ask the API about, for the approver's liveness. Optional:
+     * the naming half is answerable without one, and saying so is better than
+     * requiring an id a developer may not have yet. */
+    readonly decisionId?: string;
+}
+/**
+ * `sandbox_status` — say whether this tenant is a sandbox, and whether the
+ * robot approver has acted on one decision.
+ *
+ * # What it can establish, and what it cannot
+ *
+ * It reports the NAMING half of the marker over the tenant id the caller will
+ * actually send, and it names the half it cannot see. The binding half — that
+ * this tenant's receipt signing identity is registered in the robot's
+ * allowlist — is checked inside the deployment, against signed policy, on every
+ * `/v1/present`. There is no endpoint that exposes it and this tool does not
+ * invent one: a client-side "you are in a sandbox" that rested on nothing would
+ * be worse than no answer, because a developer would plan around it.
+ *
+ * Liveness is the same discipline. There is no health route on the gateway, so
+ * the honest signal is one decision's own status. **The signature of a stopped
+ * robot is `decided` with `outcome: "ATTEST"` and no receipt** — not `pending`,
+ * which is what this said until the 2026-09-03 live run of
+ * `tools/rehearse/03-loop.sh` showed a floor-HIGH sandbox proposal answering
+ * `decided`/`ATTEST` in the POST itself and never passing through `pending` at
+ * all. So the advice that could never fire moved to the branch that sees the
+ * real thing. A quorum-awaiting decision keeps that outcome and grows a
+ * RECEIPT; a decision that never grows one is the robot being stopped or
+ * mis-enrolled, and the text says which of the cases it saw rather than
+ * reducing them to a green tick.
+ *
+ * # Why the tenant is an argument and not configuration
+ *
+ * Because this server has never held a tenant name and must not start: ACP-197
+ * section 1 makes the KEY the tenant, and a `ZIFFER_TENANT` variable would be a
+ * second statement of it that could disagree with the key. The tenant id is a
+ * value the caller already writes into every proposal — where the gateway binds
+ * it, refusing `TenantMismatch` rather than rewriting it — so checking the
+ * string the caller is about to send is checking the thing that matters.
+ */
+export declare function sandboxStatus(clientFor: ClientFactory, env: Env, args: SandboxArgs): Promise<ToolOutcome>;
+/** What `explain_receipt` is handed. */
+export interface ExplainArgs {
+    /** The receipt, as parsed JSON. Passed to `@ziffer-io/verify` untouched. */
+    readonly receipt: unknown;
+    /** The EXACT proposal bytes the caller's own code hashed, base64. */
+    readonly proposalB64: string;
+    /** Overrides `ZIFFER_TRUST_ANCHOR` for this call. */
+    readonly trustAnchorPath?: string;
+}
+/**
+ * `explain_receipt` — verify a receipt and say `valid` or the named clause.
+ *
+ * **Zero verification logic of its own.** Every check is `@ziffer-io/verify`'s; this
+ * function reads a key file, decodes a base64 argument and formats an answer.
+ * A second verifier living in a developer-tools package would be a fourth
+ * implementation of §9.3 whose disagreements with the other three would be
+ * discovered by a customer.
+ *
+ * # Why the proposal arrives as bytes and not as an object
+ *
+ * Because `verifyReceipt` takes bytes, and this tool exists to reproduce the
+ * call the developer's own code makes. Accepting an object and encoding it here
+ * would put an encoding step between their input and the verifier that their
+ * production path does not have, and it would hide one real failure class
+ * outright: bytes that are not UTF-8 JSON at all — a truncated read, a
+ * double-encoded string, a compressed body — which the verifier refuses under
+ * `AT-8a`. Handed an object, this tool could never see that.
+ *
+ * What it is NOT for is key order. An earlier draft of this file, and of the
+ * guide, claimed the caller had to pass `canon(proposal)` and that
+ * `JSON.stringify` would produce a spurious `9.3-3`. That is false, and the
+ * check that showed it was running all three encodings through this function:
+ * `verifyReceipt` PARSES these bytes and canonicalises them itself, because the
+ * hash is defined over the canonical encoding rather than over the transport's
+ * spacing (`verify.ts` step 3; the Python SDK's `verify` does the same). Any
+ * JSON spelling of one object verifies. The hint below therefore names the
+ * cause that is real — a different object — rather than the one that reads
+ * plausibly.
+ */
+export declare function explainReceipt(env: Env, args: ExplainArgs): Promise<ToolOutcome>;
+/** Re-exported so `server.ts` and the tests name one canonicalisation. */
+export { canon };
+//# sourceMappingURL=tools.d.ts.map

package/dist/tools.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"tools.d.ts","sourceRoot":"","sources":["../src/tools.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AAGH,OAAO,EAAE,KAAK,EAA0B,MAAM,mBAAmB,CAAC;AAGlE,OAAO,EAA6B,KAAK,GAAG,EAAE,MAAM,aAAa,CAAC;AAGlE;;;;;;;;;;GAUG;AACH,MAAM,WAAW,WAAW;IAC1B,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,OAAO,EAAE,OAAO,CAAC;CAC3B;AAED;;;;;;;;GAQG;AACH,MAAM,WAAW,iBAAiB;IAChC,QAAQ,CAAC,WAAW,EAAE,MAAM,CAAC;IAC7B,QAAQ,CAAC,MAAM,EAAE,SAAS,GAAG,SAAS,CAAC;IACvC,QAAQ,CAAC,OAAO,CAAC,EAAE,MAAM,CAAC;IAC1B,QAAQ,CAAC,MAAM,CAAC,EAAE,MAAM,CAAC;CAC1B;AAED;;;uDAGuD;AACvD,MAAM,WAAW,cAAe,SAAQ,iBAAiB;IACvD,QAAQ,CAAC,OAAO,CAAC,EAAE,OAAO,CAAC;CAC5B;AAED;;;;;;;;;;GAUG;AACH,MAAM,WAAW,cAAc;IAC7B,OAAO,CAAC,QAAQ,EAAE,OAAO,GAAG,OAAO,CAAC,iBAAiB,CAAC,CAAC;IACvD,QAAQ,CAAC,UAAU,EAAE,MAAM,GAAG,OAAO,CAAC,cAAc,CAAC,CAAC;CACvD;AAED;yEACyE;AACzE,MAAM,MAAM,aAAa,GAAG,CAAC,GAAG,EAAE,GAAG,KAAK,OAAO,CAAC,cAAc,CAAC,CAAC;AA6ClE;;;;;;;;;GASG;AACH,wBAAsB,OAAO,CAC3B,SAAS,EAAE,aAAa,EACxB,GAAG,EAAE,GAAG,EACR,QAAQ,EAAE,OAAO,GAChB,OAAO,CAAC,WAAW,CAAC,CAOtB;AAED;;;;;;;;;GASG;AACH,wBAAsB,aAAa,CACjC,SAAS,EAAE,aAAa,EACxB,GAAG,EAAE,GAAG,EACR,UAAU,EAAE,MAAM,GACjB,OAAO,CAAC,WAAW,CAAC,CAOtB;AAED;;;;;;;GAOG;AACH,wBAAgB,mBAAmB,CAAC,QAAQ,EAAE,MAAM,GAAG,WAAW,CAajE;AAED;;;;;;GAMG;AACH,eAAO,MAAM,cAAc,aAAa,CAAC;AAEzC;;;;;;;GAOG;AACH,wBAAgB,aAAa,CAAC,QAAQ,EAAE,MAAM,GAAG,OAAO,CAEvD;AAED,uCAAuC;AACvC,MAAM,WAAW,WAAW;IAC1B,kDAAkD;IAClD,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC;IAC1B;;uDAEmD;IACnD,QAAQ,CAAC,UAAU,CAAC,EAAE,MAAM,CAAC;CAC9B;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AACH,wBAAsB,aAAa,CACjC,SAAS,EAAE,aAAa,EACxB,GAAG,EAAE,GAAG,EACR,IAAI,EAAE,WAAW,GAChB,OAAO,CAAC,WAAW,CAAC,CAuFtB;AAED,wCAAwC;AACxC,MAAM,WAAW,WAAW;IAC1B,4EAA4E;IAC5E,QAAQ,CAAC,OAAO,EAAE,OAAO,CAAC;IAC1B,qEAAqE;IACrE,QAAQ,CAAC,WAAW,EAAE,MAAM,CAAC;IAC7B,qDAAqD;IACrD,QAAQ,CAAC,eAAe,CAAC,EAAE,MAAM,CAAC;CACnC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,wBAAsB,cAAc,CAAC,GAAG,EAAE,GAAG,EAAE,IAAI,EAAE,WAAW,GAAG,OAAO,CAAC,WAAW,CAAC,CAuDtF;AAED,0EAA0E;AAC1E,OAAO,EAAE,KAAK,EAAE,CAAC"}

package/dist/tools.js

@@ -0,0 +1,330 @@
+/**
+ * The five tools, as plain functions (ACP-197 section 6b point 2; ACP-213
+ * section 9.2 point 3 added the fifth).
+ *
+ * Every handler here takes its dependencies as arguments and returns a
+ * {@link ToolOutcome}. Nothing in this file imports the MCP SDK: `server.ts`
+ * adapts these to the protocol's content shape. That seam exists so the tests
+ * exercise the behaviour rather than the framing, and so the answer to "what
+ * does `propose` do when the key is unset" is one function call.
+ *
+ * # What is deliberately absent
+ *
+ * There is no approve tool, no simulated approval, and no tool that writes a
+ * file. The reason for the first two is worth carrying here rather than leaving
+ * in a ticket: **a simulated approval minted on a developer's laptop is a fake
+ * receipt factory**, and a receipt factory is the exact artifact this product
+ * exists to make impossible.
+ *
+ * Until ACP-213 this file also said there was no sandbox tool, and that a
+ * sandbox mode was "a follow-up with its own design". That follow-up landed and
+ * the design is the reason the sentence could change: a Ziffer sandbox is a
+ * SEPARATE TENANT with its own receipt signing identity, approved by a robot
+ * that walks the real quorum path with keys enrolled only in sandbox bundles
+ * (`services/sandbox-approver`, `docs/onboarding/sandbox.md`). Nothing about it
+ * is client-side, which is why {@link sandboxStatus} only ever REPORTS: it
+ * reads a name and asks the API about one decision. An approval on this side of
+ * the wire would still be a forgery, and there is still no tool for it.
+ *
+ * The third is a boundary rather than a danger: this server has no hands on the
+ * developer's machine. It serves knowledge and Ziffer-side calls; the coding
+ * agent talking to it is the thing that edits code. A file-writing tool here
+ * would make this process an editor with none of an editor's review surface.
+ */
+import { ApiRefusal } from '@ziffer-io/client';
+import { canon, Refusal, verifyReceipt } from '@ziffer-io/verify';
+import { AnchorError, loadTrustAnchor } from './anchor.js';
+import { anchorConfig, ConfigError } from './config.js';
+import { asLanguage, integrationGuide, LANGUAGES } from './guide.js';
+/**
+ * Turn any thrown value into an agent-readable refusal.
+ *
+ * Every branch narrows with `instanceof`; there is no cast. That matters more
+ * than usual here because the input is a `catch` binding: the values this sees
+ * include the ones nobody planned for, and an `as` would read a `.clause` off a
+ * `TypeError` and report a protocol refusal that never happened
+ * (`.claude/rules/static-analysis.md`, and section 8 of the guide says the same
+ * thing to the reader).
+ */
+function refusal(error) {
+    if (error instanceof ConfigError) {
+        return { text: `${error.name}: ${error.message}`, isError: true };
+    }
+    if (error instanceof ApiRefusal) {
+        // The gateway's §1 NAME leads, not the class name. `ApiRefusal` carries
+        // that name in `.error` and sets `.name` to its own class, so the generic
+        // `Error` branch below would report every gateway refusal as "ApiRefusal"
+        // and the agent could not tell `TenantMismatch` from `ApiKeyUnknown` —
+        // which are different developer actions. The name is the contract; the
+        // status is context.
+        return { text: `${error.error}: ${error.message}`, isError: true };
+    }
+    if (error instanceof AnchorError) {
+        return { text: error.message, isError: true };
+    }
+    if (error instanceof Refusal) {
+        // The clause is the machine-readable half and is named first, because it is
+        // the value an agent should quote back to a human and the one that is
+        // spelled the same in all three implementations.
+        return { text: `refused: ${error.clause}\n${error.message}`, isError: true };
+    }
+    if (error instanceof Error) {
+        return { text: `${error.name}: ${error.message}`, isError: true };
+    }
+    return { text: `UnknownError: ${String(error)}`, isError: true };
+}
+/** JSON as an agent should read it: stable, indented, and never a bare value. */
+function asJson(value) {
+    return JSON.stringify(value, null, 2);
+}
+/**
+ * `propose` — submit one wire Proposal and return the §1 response verbatim.
+ *
+ * The proposal is passed through untouched. This server does not fill in a
+ * `tenant_id`, and it must not: ACP-197 section 1 makes the KEY the tenant, and
+ * a body whose `tenant_id` disagrees is refused rather than rewritten, because
+ * the proposal is signed material downstream and a rewriter would have become
+ * its author. Helpfully "correcting" the field here would produce exactly the
+ * silent authorship the gateway's refusal exists to prevent.
+ */
+export async function propose(clientFor, env, proposal) {
+    try {
+        const client = await clientFor(env);
+        return { text: asJson(await client.propose(proposal)), isError: false };
+    }
+    catch (error) {
+        return refusal(error);
+    }
+}
+/**
+ * `check_decision` — one decision by id, receipt included when present.
+ *
+ * The receipt is re-serialised as part of the response object rather than
+ * spliced in as text. That is safe HERE, and only here, because this output is
+ * for an agent to read: the copy that gets VERIFIED is the one
+ * `explain_receipt` is handed, and the hash it checks is recomputed from the
+ * proposal bytes, never from a re-encoding of the receipt. Nothing downstream
+ * of this tool treats its text as signed material.
+ */
+export async function checkDecision(clientFor, env, decisionId) {
+    try {
+        const client = await clientFor(env);
+        return { text: asJson(await client.decision(decisionId)), isError: false };
+    }
+    catch (error) {
+        return refusal(error);
+    }
+}
+/**
+ * `get_integration_guide` — `docs/onboarding/sdk.md`, for one language.
+ *
+ * The one tool that needs no configuration, deliberately: an agent should be
+ * able to read how to integrate before any credential exists. That is also why
+ * `config.ts` lets the server start unconfigured — a server that refused to
+ * boot without an API key could not answer the question a developer asks first.
+ */
+export function getIntegrationGuide(language) {
+    const known = asLanguage(language);
+    if (known === null) {
+        return {
+            text: `UnknownLanguage: ${JSON.stringify(language)} is not one of ${LANGUAGES.join(', ')}.`,
+            isError: true,
+        };
+    }
+    try {
+        return { text: integrationGuide(known), isError: false };
+    }
+    catch (error) {
+        return refusal(error);
+    }
+}
+/**
+ * The marker's naming half (ACP-213). One spelling, and it is not the one that
+ * decides: `services/sandbox-approver/src/sandbox.rs` holds the rule that
+ * governs, against the tenant the SIGNED bundle names, beside an allowlist of
+ * receipt identities no client can see. This copy exists so a developer is told
+ * what they are pointed at before they send a proposal, and it says so.
+ */
+export const SANDBOX_SUFFIX = '-sandbox';
+/**
+ * Is this tenant id spelled as a sandbox?
+ *
+ * The suffix has to be attached to something: a tenant literally named
+ * `-sandbox` would be a tenant with an empty production name, which satisfies
+ * the convention while meaning nothing. Same rule, same words, as the Rust
+ * predicate and `tools/provision-sandbox.py`.
+ */
+export function isSandboxName(tenantId) {
+    return tenantId.length > SANDBOX_SUFFIX.length && tenantId.endsWith(SANDBOX_SUFFIX);
+}
+/**
+ * `sandbox_status` — say whether this tenant is a sandbox, and whether the
+ * robot approver has acted on one decision.
+ *
+ * # What it can establish, and what it cannot
+ *
+ * It reports the NAMING half of the marker over the tenant id the caller will
+ * actually send, and it names the half it cannot see. The binding half — that
+ * this tenant's receipt signing identity is registered in the robot's
+ * allowlist — is checked inside the deployment, against signed policy, on every
+ * `/v1/present`. There is no endpoint that exposes it and this tool does not
+ * invent one: a client-side "you are in a sandbox" that rested on nothing would
+ * be worse than no answer, because a developer would plan around it.
+ *
+ * Liveness is the same discipline. There is no health route on the gateway, so
+ * the honest signal is one decision's own status. **The signature of a stopped
+ * robot is `decided` with `outcome: "ATTEST"` and no receipt** — not `pending`,
+ * which is what this said until the 2026-09-03 live run of
+ * `tools/rehearse/03-loop.sh` showed a floor-HIGH sandbox proposal answering
+ * `decided`/`ATTEST` in the POST itself and never passing through `pending` at
+ * all. So the advice that could never fire moved to the branch that sees the
+ * real thing. A quorum-awaiting decision keeps that outcome and grows a
+ * RECEIPT; a decision that never grows one is the robot being stopped or
+ * mis-enrolled, and the text says which of the cases it saw rather than
+ * reducing them to a green tick.
+ *
+ * # Why the tenant is an argument and not configuration
+ *
+ * Because this server has never held a tenant name and must not start: ACP-197
+ * section 1 makes the KEY the tenant, and a `ZIFFER_TENANT` variable would be a
+ * second statement of it that could disagree with the key. The tenant id is a
+ * value the caller already writes into every proposal — where the gateway binds
+ * it, refusing `TenantMismatch` rather than rewriting it — so checking the
+ * string the caller is about to send is checking the thing that matters.
+ */
+export async function sandboxStatus(clientFor, env, args) {
+    const tenant = args.tenantId.trim();
+    if (tenant === '') {
+        return {
+            text: 'TenantUnnamed: pass the tenant_id your proposals carry; this server holds no tenant of its own.',
+            isError: true,
+        };
+    }
+    const lines = [`tenant: ${JSON.stringify(tenant)}`];
+    if (isSandboxName(tenant)) {
+        lines.push(`sandbox: yes, by name — it ends in "${SANDBOX_SUFFIX}".`, '  What that guarantees: a sandbox tenant is a SEPARATE tenant whose bundle names its own', '  receipt signing identity, so receipts issued here are signed by a different key and a', '  production verifier refuses them (clause 9.3-1). You cannot get a production-valid', '  receipt out of a sandbox, by construction rather than by policy.', '  What it does NOT mean: the action is not performed for real by anything Ziffer runs, and', '  approvals here are made by a robot approver with no human in them. Treat every ALLOW as', '  "the path worked", never as "someone agreed".', '  What this tool cannot see: the other half of the marker is an allowlist of receipt', '  identities the robot approver reads out of signed policy inside the deployment. It is', '  checked there, on every approval, and no client can observe it.');
+    }
+    else {
+        lines.push(`sandbox: no, by name — it does not end in "${SANDBOX_SUFFIX}".`, '  Receipts for this tenant are production receipts and its approvals are made by whoever', '  its bundle enrols. Nothing here is auto-approved. If you meant to be in a sandbox, you', `  want the separate tenant "${tenant}${SANDBOX_SUFFIX}" and its own API key — the key`, '  determines the tenant, so pointing at a sandbox is a credential change, not a flag.');
+    }
+    const decisionId = args.decisionId?.trim();
+    if (decisionId === undefined || decisionId === '') {
+        lines.push('approver: not checked — pass decision_id to have this tool ask the API about one decision.');
+        return { text: lines.join('\n'), isError: false };
+    }
+    try {
+        const client = await clientFor(env);
+        const record = await client.decision(decisionId);
+        const outcome = record.outcome === undefined ? '' : ` outcome ${record.outcome}`;
+        const clause = record.clause === undefined ? '' : ` clause ${record.clause}`;
+        if (record.status === 'decided') {
+            lines.push(`approver: decision ${record.decision_id} is decided —${outcome}${clause}`.trimEnd());
+            if (record.receipt === undefined) {
+                lines.push('  No signed receipt is attached, so nothing here is verifiable: read the clause. A', '  decided path is evidence the deployment answered, not that a quorum formed.');
+                if (record.outcome === 'ATTEST') {
+                    lines.push('  ATTEST is the §8.6 quorum gate and not a refusal — this decision is waiting on', '  approvers, and in a sandbox that is the robot. The receipt attaches to THIS same', '  decision on a later check_decision while the outcome stays ATTEST, so poll for the', '  RECEIPT and never for a change of outcome. Do not re-propose: a second proposal is', '  a second action. A decided ATTEST that never grows a receipt is what a stopped or', '  mis-enrolled robot approver looks like from out here. There is no health endpoint;', '  this is the only liveness signal the API exposes.');
+                }
+            }
+            else {
+                lines.push('  A signed receipt is attached. Verify it with explain_receipt: this tool checked no', '  signature, and a status field is not a signature.');
+            }
+        }
+        else {
+            lines.push(`approver: decision ${record.decision_id} is still pending.`, '  Pending means the deployment has not answered this decision yet. It is NOT the', '  signature of a stopped approver: a decision waiting on its quorum reads decided with', '  outcome ATTEST and no receipt, never pending. Ask again in a moment.');
+        }
+        return { text: lines.join('\n'), isError: false };
+    }
+    catch (error) {
+        // The naming half already held, and losing it would make a gateway blip
+        // read as "your tenant is not a sandbox". The refusal is appended, with its
+        // own name intact, rather than replacing what was established.
+        const failed = refusal(error);
+        return { text: `${lines.join('\n')}\napprover: not established — ${failed.text}`, isError: true };
+    }
+}
+/**
+ * `explain_receipt` — verify a receipt and say `valid` or the named clause.
+ *
+ * **Zero verification logic of its own.** Every check is `@ziffer-io/verify`'s; this
+ * function reads a key file, decodes a base64 argument and formats an answer.
+ * A second verifier living in a developer-tools package would be a fourth
+ * implementation of §9.3 whose disagreements with the other three would be
+ * discovered by a customer.
+ *
+ * # Why the proposal arrives as bytes and not as an object
+ *
+ * Because `verifyReceipt` takes bytes, and this tool exists to reproduce the
+ * call the developer's own code makes. Accepting an object and encoding it here
+ * would put an encoding step between their input and the verifier that their
+ * production path does not have, and it would hide one real failure class
+ * outright: bytes that are not UTF-8 JSON at all — a truncated read, a
+ * double-encoded string, a compressed body — which the verifier refuses under
+ * `AT-8a`. Handed an object, this tool could never see that.
+ *
+ * What it is NOT for is key order. An earlier draft of this file, and of the
+ * guide, claimed the caller had to pass `canon(proposal)` and that
+ * `JSON.stringify` would produce a spurious `9.3-3`. That is false, and the
+ * check that showed it was running all three encodings through this function:
+ * `verifyReceipt` PARSES these bytes and canonicalises them itself, because the
+ * hash is defined over the canonical encoding rather than over the transport's
+ * spacing (`verify.ts` step 3; the Python SDK's `verify` does the same). Any
+ * JSON spelling of one object verifies. The hint below therefore names the
+ * cause that is real — a different object — rather than the one that reads
+ * plausibly.
+ */
+export async function explainReceipt(env, args) {
+    try {
+        const config = anchorConfig(env, args.trustAnchorPath);
+        const anchor = await loadTrustAnchor(config.anchorPath, config.suiteFloor);
+        let proposalBytes;
+        try {
+            proposalBytes = Uint8Array.from(Buffer.from(args.proposalB64, 'base64'));
+        }
+        catch {
+            return {
+                text: 'ProposalBytesMalformed: proposal_b64 is not base64.',
+                isError: true,
+            };
+        }
+        // Node's base64 decoder is lenient: it drops characters it does not
+        // recognise rather than throwing, so a caller who passed hex, or a JSON
+        // string, gets silent garbage and a 9.3-3 refusal blaming the receipt.
+        // Re-encoding and comparing is the cheap way to catch that, and the refusal
+        // names the argument rather than the receipt.
+        if (Buffer.from(proposalBytes).toString('base64') !== args.proposalB64.trim()) {
+            return {
+                text: 'ProposalBytesMalformed: proposal_b64 did not survive a base64 round trip, so it is not the encoding it claims.\n' +
+                    '  Pass the bytes your code passes to verify, base64-encoded.',
+                isError: true,
+            };
+        }
+        const verified = verifyReceipt(args.receipt, proposalBytes, anchor);
+        return {
+            text: `valid: bound to ${verified.proposalHash}\n` +
+                `  suite floor ${config.suiteFloor}, anchor ${config.anchorPath}\n` +
+                `  receipt expires at ${new Date(verified.receiptExpiresAt * 1000).toISOString()}\n` +
+                '  This receipt verified. It says nothing about whether it was already used:\n' +
+                '  replay is a claim against a ledger this process cannot reach (guide section 6, item 2).',
+            isError: false,
+        };
+    }
+    catch (error) {
+        const outcome = refusal(error);
+        if (error instanceof Refusal && error.clause === '9.3-3') {
+            // The one refusal worth a hint, because the obvious suspect is the wrong
+            // one. Appended to the named clause, never substituted for it.
+            return {
+                text: `${outcome.text}\n` +
+                    '  The receipt is bound to a DIFFERENT proposal. It is not key order or whitespace:\n' +
+                    '  the verifier parses these bytes and canonicalises them itself, so any JSON spelling\n' +
+                    '  of one object hashes the same. Look for a changed field value, a field added or\n' +
+                    '  dropped after the proposal was submitted, or the receipt of another decision.',
+                isError: true,
+            };
+        }
+        return outcome;
+    }
+}
+/** Re-exported so `server.ts` and the tests name one canonicalisation. */
+export { canon };
+//# sourceMappingURL=tools.js.map

package/dist/tools.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"tools.js","sourceRoot":"","sources":["../src/tools.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AAEH,OAAO,EAAE,UAAU,EAAE,MAAM,mBAAmB,CAAC;AAC/C,OAAO,EAAE,KAAK,EAAE,OAAO,EAAE,aAAa,EAAE,MAAM,mBAAmB,CAAC;AAElE,OAAO,EAAE,WAAW,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAC3D,OAAO,EAAE,YAAY,EAAE,WAAW,EAAY,MAAM,aAAa,CAAC;AAClE,OAAO,EAAE,UAAU,EAAE,gBAAgB,EAAE,SAAS,EAAE,MAAM,YAAY,CAAC;AA8DrE;;;;;;;;;GASG;AACH,SAAS,OAAO,CAAC,KAAc;IAC7B,IAAI,KAAK,YAAY,WAAW,EAAE,CAAC;QACjC,OAAO,EAAE,IAAI,EAAE,GAAG,KAAK,CAAC,IAAI,KAAK,KAAK,CAAC,OAAO,EAAE,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;IACpE,CAAC;IACD,IAAI,KAAK,YAAY,UAAU,EAAE,CAAC;QAChC,wEAAwE;QACxE,0EAA0E;QAC1E,0EAA0E;QAC1E,uEAAuE;QACvE,uEAAuE;QACvE,qBAAqB;QACrB,OAAO,EAAE,IAAI,EAAE,GAAG,KAAK,CAAC,KAAK,KAAK,KAAK,CAAC,OAAO,EAAE,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;IACrE,CAAC;IACD,IAAI,KAAK,YAAY,WAAW,EAAE,CAAC;QACjC,OAAO,EAAE,IAAI,EAAE,KAAK,CAAC,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;IAChD,CAAC;IACD,IAAI,KAAK,YAAY,OAAO,EAAE,CAAC;QAC7B,4EAA4E;QAC5E,sEAAsE;QACtE,iDAAiD;QACjD,OAAO,EAAE,IAAI,EAAE,YAAY,KAAK,CAAC,MAAM,KAAK,KAAK,CAAC,OAAO,EAAE,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;IAC/E,CAAC;IACD,IAAI,KAAK,YAAY,KAAK,EAAE,CAAC;QAC3B,OAAO,EAAE,IAAI,EAAE,GAAG,KAAK,CAAC,IAAI,KAAK,KAAK,CAAC,OAAO,EAAE,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;IACpE,CAAC;IACD,OAAO,EAAE,IAAI,EAAE,iBAAiB,MAAM,CAAC,KAAK,CAAC,EAAE,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;AACnE,CAAC;AAED,iFAAiF;AACjF,SAAS,MAAM,CAAC,KAAc;IAC5B,OAAO,IAAI,CAAC,SAAS,CAAC,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC;AACxC,CAAC;AAED;;;;;;;;;GASG;AACH,MAAM,CAAC,KAAK,UAAU,OAAO,CAC3B,SAAwB,EACxB,GAAQ,EACR,QAAiB;IAEjB,IAAI,CAAC;QACH,MAAM,MAAM,GAAG,MAAM,SAAS,CAAC,GAAG,CAAC,CAAC;QACpC,OAAO,EAAE,IAAI,EAAE,MAAM,CAAC,MAAM,MAAM,CAAC,OAAO,CAAC,QAAQ,CAAC,CAAC,EAAE,OAAO,EAAE,KAAK,EAAE,CAAC;IAC1E,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,OAAO,OAAO,CAAC,KAAK,CAAC,CAAC;IACxB,CAAC;AACH,CAAC;AAED;;;;;;;;;GASG;AACH,MAAM,CAAC,KAAK,UAAU,aAAa,CACjC,SAAwB,EACxB,GAAQ,EACR,UAAkB;IAElB,IAAI,CAAC;QACH,MAAM,MAAM,GAAG,MAAM,SAAS,CAAC,GAAG,CAAC,CAAC;QACpC,OAAO,EAAE,IAAI,EAAE,MAAM,CAAC,MAAM,MAAM,CAAC,QAAQ,CAAC,UAAU,CAAC,CAAC,EAAE,OAAO,EAAE,KAAK,EAAE,CAAC;IAC7E,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,OAAO,OAAO,CAAC,KAAK,CAAC,CAAC;IACxB,CAAC;AACH,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,mBAAmB,CAAC,QAAgB;IAClD,MAAM,KAAK,GAAG,UAAU,CAAC,QAAQ,CAAC,CAAC;IACnC,IAAI,KAAK,KAAK,IAAI,EAAE,CAAC;QACnB,OAAO;YACL,IAAI,EAAE,oBAAoB,IAAI,CAAC,SAAS,CAAC,QAAQ,CAAC,kBAAkB,SAAS,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG;YAC3F,OAAO,EAAE,IAAI;SACd,CAAC;IACJ,CAAC;IACD,IAAI,CAAC;QACH,OAAO,EAAE,IAAI,EAAE,gBAAgB,CAAC,KAAK,CAAC,EAAE,OAAO,EAAE,KAAK,EAAE,CAAC;IAC3D,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,OAAO,OAAO,CAAC,KAAK,CAAC,CAAC;IACxB,CAAC;AACH,CAAC;AAED;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,cAAc,GAAG,UAAU,CAAC;AAEzC;;;;;;;GAOG;AACH,MAAM,UAAU,aAAa,CAAC,QAAgB;IAC5C,OAAO,QAAQ,CAAC,MAAM,GAAG,cAAc,CAAC,MAAM,IAAI,QAAQ,CAAC,QAAQ,CAAC,cAAc,CAAC,CAAC;AACtF,CAAC;AAYD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AACH,MAAM,CAAC,KAAK,UAAU,aAAa,CACjC,SAAwB,EACxB,GAAQ,EACR,IAAiB;IAEjB,MAAM,MAAM,GAAG,IAAI,CAAC,QAAQ,CAAC,IAAI,EAAE,CAAC;IACpC,IAAI,MAAM,KAAK,EAAE,EAAE,CAAC;QAClB,OAAO;YACL,IAAI,EAAE,iGAAiG;YACvG,OAAO,EAAE,IAAI;SACd,CAAC;IACJ,CAAC;IAED,MAAM,KAAK,GAAa,CAAC,WAAW,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,EAAE,CAAC,CAAC;IAC9D,IAAI,aAAa,CAAC,MAAM,CAAC,EAAE,CAAC;QAC1B,KAAK,CAAC,IAAI,CACR,uCAAuC,cAAc,IAAI,EACzD,0FAA0F,EAC1F,yFAAyF,EACzF,sFAAsF,EACtF,oEAAoE,EACpE,4FAA4F,EAC5F,2FAA2F,EAC3F,iDAAiD,EACjD,sFAAsF,EACtF,yFAAyF,EACzF,mEAAmE,CACpE,CAAC;IACJ,CAAC;SAAM,CAAC;QACN,KAAK,CAAC,IAAI,CACR,8CAA8C,cAAc,IAAI,EAChE,0FAA0F,EAC1F,0FAA0F,EAC1F,+BAA+B,MAAM,GAAG,cAAc,iCAAiC,EACvF,uFAAuF,CACxF,CAAC;IACJ,CAAC;IAED,MAAM,UAAU,GAAG,IAAI,CAAC,UAAU,EAAE,IAAI,EAAE,CAAC;IAC3C,IAAI,UAAU,KAAK,SAAS,IAAI,UAAU,KAAK,EAAE,EAAE,CAAC;QAClD,KAAK,CAAC,IAAI,CACR,4FAA4F,CAC7F,CAAC;QACF,OAAO,EAAE,IAAI,EAAE,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,OAAO,EAAE,KAAK,EAAE,CAAC;IACpD,CAAC;IAED,IAAI,CAAC;QACH,MAAM,MAAM,GAAG,MAAM,SAAS,CAAC,GAAG,CAAC,CAAC;QACpC,MAAM,MAAM,GAAG,MAAM,MAAM,CAAC,QAAQ,CAAC,UAAU,CAAC,CAAC;QACjD,MAAM,OAAO,GAAG,MAAM,CAAC,OAAO,KAAK,SAAS,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,YAAY,MAAM,CAAC,OAAO,EAAE,CAAC;QACjF,MAAM,MAAM,GAAG,MAAM,CAAC,MAAM,KAAK,SAAS,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,WAAW,MAAM,CAAC,MAAM,EAAE,CAAC;QAC7E,IAAI,MAAM,CAAC,MAAM,KAAK,SAAS,EAAE,CAAC;YAChC,KAAK,CAAC,IAAI,CAAC,sBAAsB,MAAM,CAAC,WAAW,gBAAgB,OAAO,GAAG,MAAM,EAAE,CAAC,OAAO,EAAE,CAAC,CAAC;YACjG,IAAI,MAAM,CAAC,OAAO,KAAK,SAAS,EAAE,CAAC;gBACjC,KAAK,CAAC,IAAI,CACR,oFAAoF,EACpF,+EAA+E,CAChF,CAAC;gBACF,IAAI,MAAM,CAAC,OAAO,KAAK,QAAQ,EAAE,CAAC;oBAChC,KAAK,CAAC,IAAI,CACR,kFAAkF,EAClF,oFAAoF,EACpF,sFAAsF,EACtF,sFAAsF,EACtF,qFAAqF,EACrF,sFAAsF,EACtF,qDAAqD,CACtD,CAAC;gBACJ,CAAC;YACH,CAAC;iBAAM,CAAC;gBACN,KAAK,CAAC,IAAI,CACR,sFAAsF,EACtF,qDAAqD,CACtD,CAAC;YACJ,CAAC;QACH,CAAC;aAAM,CAAC;YACN,KAAK,CAAC,IAAI,CACR,sBAAsB,MAAM,CAAC,WAAW,oBAAoB,EAC5D,kFAAkF,EAClF,wFAAwF,EACxF,wEAAwE,CACzE,CAAC;QACJ,CAAC;QACD,OAAO,EAAE,IAAI,EAAE,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,OAAO,EAAE,KAAK,EAAE,CAAC;IACpD,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,wEAAwE;QACxE,4EAA4E;QAC5E,+DAA+D;QAC/D,MAAM,MAAM,GAAG,OAAO,CAAC,KAAK,CAAC,CAAC;QAC9B,OAAO,EAAE,IAAI,EAAE,GAAG,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,iCAAiC,MAAM,CAAC,IAAI,EAAE,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;IACpG,CAAC;AACH,CAAC;AAYD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,MAAM,CAAC,KAAK,UAAU,cAAc,CAAC,GAAQ,EAAE,IAAiB;IAC9D,IAAI,CAAC;QACH,MAAM,MAAM,GAAG,YAAY,CAAC,GAAG,EAAE,IAAI,CAAC,eAAe,CAAC,CAAC;QACvD,MAAM,MAAM,GAAG,MAAM,eAAe,CAAC,MAAM,CAAC,UAAU,EAAE,MAAM,CAAC,UAAU,CAAC,CAAC;QAE3E,IAAI,aAAyB,CAAC;QAC9B,IAAI,CAAC;YACH,aAAa,GAAG,UAAU,CAAC,IAAI,CAAC,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,QAAQ,CAAC,CAAC,CAAC;QAC3E,CAAC;QAAC,MAAM,CAAC;YACP,OAAO;gBACL,IAAI,EAAE,qDAAqD;gBAC3D,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QACD,oEAAoE;QACpE,wEAAwE;QACxE,uEAAuE;QACvE,4EAA4E;QAC5E,8CAA8C;QAC9C,IAAI,MAAM,CAAC,IAAI,CAAC,aAAa,CAAC,CAAC,QAAQ,CAAC,QAAQ,CAAC,KAAK,IAAI,CAAC,WAAW,CAAC,IAAI,EAAE,EAAE,CAAC;YAC9E,OAAO;gBACL,IAAI,EACF,kHAAkH;oBAClH,8DAA8D;gBAChE,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QAED,MAAM,QAAQ,GAAG,aAAa,CAAC,IAAI,CAAC,OAAO,EAAE,aAAa,EAAE,MAAM,CAAC,CAAC;QACpE,OAAO;YACL,IAAI,EACF,mBAAmB,QAAQ,CAAC,YAAY,IAAI;gBAC5C,iBAAiB,MAAM,CAAC,UAAU,YAAY,MAAM,CAAC,UAAU,IAAI;gBACnE,wBAAwB,IAAI,IAAI,CAAC,QAAQ,CAAC,gBAAgB,GAAG,IAAI,CAAC,CAAC,WAAW,EAAE,IAAI;gBACpF,+EAA+E;gBAC/E,2FAA2F;YAC7F,OAAO,EAAE,KAAK;SACf,CAAC;IACJ,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,MAAM,OAAO,GAAG,OAAO,CAAC,KAAK,CAAC,CAAC;QAC/B,IAAI,KAAK,YAAY,OAAO,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,EAAE,CAAC;YACzD,yEAAyE;YACzE,+DAA+D;YAC/D,OAAO;gBACL,IAAI,EACF,GAAG,OAAO,CAAC,IAAI,IAAI;oBACnB,sFAAsF;oBACtF,yFAAyF;oBACzF,qFAAqF;oBACrF,iFAAiF;gBACnF,OAAO,EAAE,IAAI;aACd,CAAC;QACJ,CAAC;QACD,OAAO,OAAO,CAAC;IACjB,CAAC;AACH,CAAC;AAED,0EAA0E;AAC1E,OAAO,EAAE,KAAK,EAAE,CAAC"}

package/package.json

@@ -0,0 +1,64 @@
+{
+  "name": "@ziffer-io/mcp",
+  "version": "0.1.0",
+  "description": "A local MCP server over stdio so a coding agent can integrate the ZIFFER SDK and drive a live decision loop.",
+  "author": "code75 SASU",
+  "license": "SEE LICENSE IN LICENSE",
+  "comment-license": "The SDK is proprietary (code75 SASU). \"license\" is the SPDX escape hatch for exactly this case: there is no SPDX identifier for these terms, so the field points at the file that states them, and LICENSE ships in the tarball beside THIRD-PARTY-NOTICES. Do not put an OSI identifier here -- Apache-2.0 stood in these four files until ACP-214 and was wrong the whole time.",
+  "type": "module",
+  "main": "./dist/index.js",
+  "types": "./dist/index.d.ts",
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    }
+  },
+  "bin": {
+    "ziffer-mcp": "./dist/bin.js"
+  },
+  "sideEffects": false,
+  "files": [
+    "dist",
+    "!dist/**/*.test.*",
+    "THIRD-PARTY-NOTICES"
+  ],
+  "engines": {
+    "node": ">=22"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/ziffer-hq/ziffer.git",
+    "directory": "packages/mcp"
+  },
+  "homepage": "https://ziffer.io",
+  "publishConfig": {
+    "access": "public"
+  },
+  "comment-no-provenance": "There is deliberately no \"provenance\": true here, and it was removed rather than never added. npm generates a provenance attestation only from a recognised CI runner, and its documentation states plainly that provenance is NOT SUPPORTED for private repositories (docs.npmjs.com/trusted-publishers, read 2026-09-03) -- ziffer-hq/ziffer is private (`gh api` says so). Setting the flag does not degrade to a warning: npm attempts the attestation and the publish FAILS, so the field would have broken the operator's very first publish from a laptop and every CI publish after it. tools/release-npm.sh asserts the field stays absent, and that assertion is the thing to delete on the day this repository becomes public -- at which point trusted publishing generates provenance on its own, with no flag at all.",
+  "ziffer": {
+    "enginePin": "fed43d10b427e0a4435a8f04e474334d88a5aa6e"
+  },
+  "comment-enginePin": "The engine commit this server's verifier and wire types come from, through @ziffer-io/verify and @ziffer-io/client. A COPY of the rev in Cargo.toml, which is the one authority tools/guard.sh reads; tools/release-npm.sh refuses to release when the two differ, by name. tools/bump-pin.sh does not move this field -- see packages/types/package.json for why and what closing it costs.",
+  "comment-private-removed": "`private: true` is gone (ACP-214). It was here because the whole point is `npx @ziffer-io/mcp` and this package depended on two workspace packages that had no public home, so publishing it would have handed a developer a command that installs and then cannot start. All four now publish together, in dependency order, from tools/release-npm.sh -- @ziffer-io/types, then verify, then client, then this. NOTE WHAT REMOVING THE FLAG DOES AND DOES NOT DO: it makes publication POSSIBLE, not done. Nothing is on the registry until the operator runs the publish lines the release script prints and never executes, and packages/mcp/README.md's 'What does not work yet' says so in those words rather than leaving a reader to infer it from this file.",
+  "comment-deps": "@modelcontextprotocol/sdk is a new dependency and it IS the protocol -- an MCP server that hand-rolls JSON-RPC framing over stdio is a second implementation of a wire format someone else owns (ACP-197 runbook section 6b point 1 justifies it by name). zod is NOT a fourth choice: it is that SDK's declared peer dependency and the type its registerTool input schemas are written in, so it arrives with the SDK or the SDK does not work. It is confined to the tool-schema layer, which is this package's contracts layer, exactly as .claude/rules/typescript.md requires. @ziffer-io/verify is the ONE home of receipt verification (runbook section 6b point 2: zero verification logic of our own) and @ziffer-io/client the one home of the HTTP surface.",
+  "dependencies": {
+    "@modelcontextprotocol/sdk": "1.30.0",
+    "zod": "4.5.4",
+    "@ziffer-io/client": "0.1.0",
+    "@ziffer-io/verify": "0.1.0"
+  },
+  "comment-devdeps": "@noble/curves and @noble/post-quantum are TEST-ONLY here and ship in nothing: explain_receipt's positive path and its 9.3-3 hint both sit BEHIND signature verification, so a test that cannot sign can only ever assert the refusal it stops at first, and those two branches would go to a customer unexercised. They are the versions services/approval and packages/acp-verify already pin, so this adds no new code to the tree -- and the alternative considered and rejected was re-deriving test keys locally, which would be two definitions of one identity. `files: [dist]` is what keeps them out of the tarball; they still appear in the PUBLISHED package.json, because pnpm pack does not strip devDependencies (measured), and that is cosmetic rather than a resolution a consumer performs.",
+  "devDependencies": {
+    "@noble/curves": "2.3.0",
+    "@noble/post-quantum": "0.7.0",
+    "@types/node": "^22.15.0",
+    "typescript": "^5.9.2"
+  },
+  "scripts": {
+    "embed": "node scripts/embed-guide.mjs",
+    "build": "pnpm run embed && tsc -b",
+    "typecheck": "pnpm run embed && tsc -b",
+    "test": "pnpm run embed && tsc -b && node scripts/check-tests-built.mjs && node --test \"dist/**/*.test.js\""
+  }
+}