Check before you pay. Prove to get paid. Signed answers on any agent, against your own bar.
Scored across 4 tools
The four tools target distinct phases of a proof-before-payment workflow: require defines the bar, check verifies a counterparty, prove generates your own record, and more serves as a discovery gateway for all other operations. The boundaries are clear, though the catch-all nature of 'more' and the dense descriptions could occasionally lead an agent to consider it instead of a direct tool.
Three tools (check, prove, require) are single lowercase verbs, and 'more' fits the same stylistic pattern despite not being a verb. The set is internally consistent and readable, with only a minor deviation from a strict verb_noun convention.
Four tools is well-scoped for the core proof-before-payment loop (require → check → prove), with 'more' acting as a gateway to the broader surface. The count is reasonable, though the true surface is larger than what is directly exposed, which is a minor trade-off.
The core CRUD-like lifecycle of defining a requirement, checking a counterparty, and proving oneself is fully covered. Additional operations (credential verification, linking, public log, agreements) are accessible via 'more' but not directly exposed, representing minor gaps that agents can work around.
Call before you pay, hire, or allocate to any agent, service or company. Returns one signed verdict (mizan.verdict/1): decision ALLOW or REFUSE first, then the grade earned, the bar met or one stable reason code, the rule and its hash, what was measured, and a compact token (mzv1.…) the payee verifies offline with MIZAN's published key. Proceed only on ALLOW. Free. Without a rule MIZAN's default bar applies: a passing record in good standing (never DECLARED); with a rule (a published req_…@v, the rule require() wrote, or plain words with confirm=true) your rule decides. payee (+ bind.amount) binds the token to one payment. A REFUSE carries next.proof_request: a request you can send the party so it proves itself. subject = an agent id, a company domain, a service URL (API, MCP or A2A endpoint), a credential id, or a public AI model (model:/). compat=true returns the previous, longer check shape for one version. Errors come back as {error, field, got, reason, fix} and are never an ALLOW.
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | Optional: seconds the verdict stays valid (default 3600). | |
| bind | No | Optional: bind the signed answer to one payment, so it cannot be reused for another. With a nonce, the same (payer, nonce) returns the same answer until it expires. | |
| rule | No | Optional: your bar. A published requirement id ("req_…@v"), the JSON rule require() returned (schema: https://studio.mizan.market/app/schemas/requirement-rule-v2.schema.json), or plain words (then confirm=true after reading the read-back from require()). Without a rule, MIZAN's default bar applies. | |
| payee | No | Optional: the party you will pay (its id or address). The token is then bound to it (bound_to.payee) and the payee or rail checks that offline; a payee that is not the subject is a REFUSE (payee_mismatch). | |
| compat | No | true = the previous, longer check shape, kept for one version (clients that validate outputSchema: use https://studio.mizan.market/mcp/legacy). | |
| api_key | No | Optional MIZAN key (mzn_…): the check counts toward your record as a careful counterparty. | |
| confirm | No | Only for a rule in plain words: true once its read-back says what you mean. | |
| subject | Yes | Who you are about to pay, hire or allocate to: an agent id, a company domain (example.com), a service URL (an API, MCP or A2A endpoint), a MIZAN credential id, or a public AI model (model:<org>/<name>; its huggingface.co URL or plain <org>/<name> name the same model; models MIZAN counted: find(capability="model")). |
| Name | Required | Description |
|---|---|---|
| kid | Yes | |
| met | No | ALLOW only: the bar met, in plain words. |
| next | No | |
| rule | Yes | |
| as_of | Yes | |
| grade | No | Present on ALLOW only; never higher than earned. |
| known | No | Present on an answer with no counted record (additive, 2026-11-04): facts MIZAN measured itself about the subject (grade RECORDED, measured by MIZAN, with the window they cover), the service's identity graded by the same rules as identity, and the rule that allows on recorded reliability (mizan.reliability/1). Facts, not a judgment; an empty services list means unknown, never zero. It never changes the decision under the default rule. |
| token | Yes | |
| issued | Yes | |
| reason | No | REFUSE only: one stable reason code (see reason_codes), or a documented rule-specific code. |
| record | No | |
| schema | Yes | |
| status | Yes | |
| details | Yes | |
| expires | Yes | |
| subject | Yes | Canonical id: credential:…, ag:…, evm:…, dns:…, web:…; otherwise the subject as given. |
| bound_to | No | |
| decision | Yes | |
| identity | No | Who stands behind the agent, graded. grade = the highest grade any one evidence item earned; nothing a caller sends sets it. Every item states what it does not check. |
| measured | No | Only earned fields; an unknown field is omitted, never zero. |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations it discloses the verdict contract (ALLOW/REFUSE first, then grade, bar or stable reason code, rule and hash, measurements, offline-verifiable mzv1 token), the default bar when no rule is given, and that errors return {error, field, got, reason, fix} and are 'never an ALLOW'. It also flags the compat escape hatch and that a non-matching payee yields payee_mismatch. This is materially more than the annotations carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The essentials are front-loaded in the first two sentences, and every sentence does carry information. However, the body collapses into a comma-spliced run-on ('Free. Without a rule … your rule decides.') with stacked parentheticals, which makes the rule/precedence logic harder to parse than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with a nested bind object, the description covers decision semantics, rule precedence, binding, and error shape well enough to call correctly. Since an output schema exists, the lengthy return-shape recital is partly redundant, and the interaction between ttl and bind.nonce reuse is left to the schema rather than being stated here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns above that by adding relational meaning the schema lacks — that payee plus bind.amount binds the token to a single payment, that payee differing from subject is a REFUSE, and that confirm=true applies only after reading require()'s read-back. It does not restate ttl or bind field internals, which the schema already handles well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and scope: 'Call before you pay, hire, or allocate to any agent, service or company', then names the artifact returned ('one signed verdict (mizan.verdict/1)'). The subject types enumerated (agent id, domain, service URL, credential id, model:<org>/<name>) make it distinguishable from siblings prove and require, which are referenced by their own roles rather than duplicated here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear invocation context ('before you pay, hire, or allocate') and an explicit action rule: 'Proceed only on ALLOW'. It also routes a REFUSE into next.proof_request, which is the hand-off to prove, and explains that require() supplies the rule object. It stops short of an explicit 'use X instead when…' statement against the three siblings, so it is strong context rather than full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call when check, require, prove and claim_identity are not the job: verify a credential someone shows you, the published standard and its gates, the public log and receipts, linking your identifiers, agreements that settle on proof, watching a counterparty. Returns every other tool grouped by job; each is callable at this same address (full list: https://studio.mizan.market/mcp/full). more("problems") gives the problems MIZAN solves. Every reply carries explain and next; errors come back as {error, field, got, reason, fix}.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional: narrow to one group (e.g. "verify", "identity", "standard", "log") or "problems". Leave out for everything. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add what they do not: results are grouped by job, every reply carries explain and next, and errors return a structured {error, field, got, reason, fix}. That is genuinely useful runtime behavior. It does not indicate response size or whether the full catalog can be truncated, which is a notable omission for an all-tools index.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a compact definition with the when-to-use clause in the first clause and the alternative-routing information immediately after. The job list is long but earns its place by letting an agent predict whether its task is covered without calling the tool. A slightly dense read, but nothing is redundant with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an index/meta tool with one optional parameter and no output schema, the description covers what is returned (tools grouped by job), the auxiliary reply fields (explain, next), the error contract, and the pointer to the full list URL. Only the discovery-to-invocation mechanics remain slightly under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the single optional topic parameter is already documented with group examples and the 'problems' special case. The description reinforces 'problems' but adds no new semantics such as matching behavior for unknown topics or whether values are case-sensitive. Baseline 3 is appropriate where the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific behavior: it returns every other MIZAN tool grouped by job, with each callable at the same address. It also distinguishes itself from siblings by naming check, require, prove and claim_identity as the things it is not. The list of jobs it covers (credential verification, standard/gates, public log, identifier linking, agreements, counterparty watching) clarifies scope, though it reads as a run-on enumeration rather than a crisp purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing guidance is given: call this when check, require, prove and claim_identity are not the job, and use more("problems") to get the problems MIZAN solves. What is missing is guidance on how to move from a discovered group to the actual call – 'each is callable at this same address' is ambiguous about whether that means this endpoint or a separate per-tool dispatch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call when you want to get paid or hired: counterparties who check you then see a record instead of no_record. Prove the claim, never the method: your model, code and prompts never leave your machine, and every attempt is counted (free private previews included). claim_type trading: one position per bar on a canonical market; a free private verdict first, then (mint=true, with the key from claim_identity) a credential backed by a zero-knowledge proof; minting is free today. Only trading records get a zero-knowledge proof today. claim_type forecast or service: a record MIZAN reads and counts (every forecast, every probe), graded RECORDED; a service endpoint is linked first with link() (see more()). Call with no arguments for the guide and the markets. Every reply carries explain and next; errors come back as {error, field, got, reason, fix}.
| Name | Required | Description | Default |
|---|---|---|---|
| op | No | forecast: the 1h close is >= or < level. | |
| mint | No | trading: false = a free, private verdict with every gate; true (with api_key) = a credential others see when they check you. | |
| alias | No | trading: a public name for a minted credential. | |
| asset | No | forecast: a Binance USDT pair, e.g. BTCUSDT. | |
| level | No | forecast: the price level. | |
| at_utc | No | forecast: the hour it resolves, 'YYYY-MM-DDTHH:00' UTC, at least 1 h ahead. | |
| api_key | No | Your MIZAN key: needed to mint, to commit a forecast, or to enroll a service. claim_identity() gives one. | |
| dataset | No | trading: the market key (call prove(claim_type="trading") for the list). | |
| model_id | No | trading: your label for the model (never its code). | |
| positions | No | trading: one position per bar-move, exactly bars-1 of them. | |
| claim_type | No | trading: your positions on a canonical market; minted, a zero-knowledge proof (PROVEN). forecast: a probability committed before the hour resolves (a reading, graded RECORDED). service: your linked endpoint, probed unannounced (a reading, graded RECORDED). Leave out for the guide. | |
| identifier | No | service: the endpoint you linked by proof of control (link() first). | |
| probability | No | forecast: your probability that it happens. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavior: model, code, and prompts never leave your machine; every attempt is counted, including free private previews; minting is free today; only trading records get a zero-knowledge proof; and replies carry explain and next, with a structured error shape. These details are consistent with the non-read-only, non-idempotent annotations and add substantial context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and semicolon-heavy, packing multiple modes, caveats, and workflow steps into long sentences. The length is somewhat justified by the tool's complexity, but it is not well structured or front-loaded for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multi-mode tool with 13 parameters and no output schema, the description covers the main modes, privacy guarantees, free-preview behavior, no-argument guide access, and error format. It is largely complete for invocation, though it could better explain sibling-tool routing and some edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 13 parameters are already documented in the input schema. The description adds some workflow meaning, such as mint=true with api_key and linking a service endpoint first, but most per-parameter semantics are already supplied by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: proving your own record so counterparties see a record instead of no_record, with concrete claim types for trading, forecast, and service. It is clear what the tool does, though it does not explicitly distinguish itself from sibling tools such as check, more, and require.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear when-to-use guidance: call when you want to get paid or hired, call with no arguments for the guide and markets, and use different claim types for trading, forecast, or service. It also explains the free private verdict versus minting path, but it does not explicitly route agents from sibling tools like check or require.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call when you know what you need from a counterparty and want it as an exact rule before you check anyone. Write the bar in plain words (words=...) or as structured JSON (rule=..., schema: resource mizan://schemas/requirement-rule-v2.json or https://studio.mizan.market/app/schemas/requirement-rule-v2.schema.json); both give the same rule and the same hash. Returns the exact rule, a read-back in plain English to confirm it means what you meant, its hash, whether it can be published, and suggestions when some words were not understood. Ready-made bars: the library resources (mizan://library/...). Then call check(subject, rule=). Free. Every reply carries explain and next; errors come back as {error, field, got, reason, fix}.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | A name for a published rule (stored beside the rule, outside its hash). | |
| rule | No | Or the same bar as structured JSON: {"core": "mizan-req-core/2", "rule": {...}}. Schema: https://studio.mizan.market/app/schemas/requirement-rule-v2.schema.json (also the MCP resource mizan://schemas/requirement-rule-v2.json). Words and JSON for the same bar give the same rule and the same hash. | |
| words | No | Your bar in plain words, e.g. "forward record 180 days, sharpe at least 1.3, max drawdown at most 25%, company domain". Words MIZAN cannot read are refused with the reason and suggestions, never guessed. | |
| api_key | No | Your MIZAN key (mzn_…), only to publish. claim_identity() gives one in one call. | |
| publish | No | Publish the rule as a versioned requirement others can adopt (needs api_key). Publishable says first whether it can be published today. | |
| visibility | No | public |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say it is a non-read-only, idempotent, non-destructive, closed-world write; the description goes well beyond that by disclosing the return payload (exact rule, plain-English read-back, hash, publishable flag, suggestions), the publishing path and its api_key requirement, cost ('Free'), and the exact error shape {error, field, got, reason, fix}. The 'same rule and the same hash' claim is consistent with idempotentHint=true and nothing contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The trigger is reasonably front-loaded, but the description is one dense run-on that re-states schema URLs and resource URIs already present in the input schema and tacks on error-format and 'explain and next' details. Most content earns its place, but the packaging makes it harder to scan than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six optional parameters, nested JSON, and no output schema, the description carries the burden well: it explains both input encodings, what is returned, the conditional publish flow and its credential requirement, and the error contract. An agent can call this correctly without opening the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 83%, but the description adds real meaning: words= and rule= are two encodings of the same bar producing the same hash, unreadable words are refused rather than guessed, and api_key is needed only for publishing. It does not clarify name or visibility beyond the schema, keeping it below 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb and artifact: turn a requirement ('bar') expressed in words or JSON into a canonical rule with a hash. It explicitly routes to the sibling check for the next step. It does not differentiate itself from the other siblings (more, prove), so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear trigger ('Call when you know what you need from a counterparty and want it as an exact rule before you check anyone') plus sequencing ('Then call check(subject, rule=<the rule>)') and a ready-made alternative (library resources). No explicit when-not-to-use or contrast with prove/more, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check1 field changedOutput schema / properties / knownAdded value: +{
+ "additionalProperties": true,
+ "description": "Present on an answer with no counted record (additive, 2026-11-04): facts MIZAN measured itself about the subject (grade RECORDED, measured by MIZAN, with the window they cover), the service's identity graded by the same rules as identity, and the rule that allows on recorded reliability (mizan.reliability/1). Facts, not a judgment; an empty services list means unknown, never zero. It never changes the decision under the default rule.",
+ "properties": {
+ "about": {
+ "type": "string"
+ },
+ "identity": {
+ "properties": {
+ "evidence": {
+ "type": "array"
+ },
+ "grade": {
+ "enum": [
+ "NONE",
+ "DECLARED",
+ "RECORDED",
+ "PROVEN"
+ ]
+ }
+ },
+ "required": [
+ "grade"
+ ],
+ "type": "object"
+ },
+ "rule": {
+ "properties": {
+ "id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "schema": {
+ "const": "mizan.record/1"
+ },
+ "services": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "error_rate_pct": {
+ "type": "number"
+ },
+ "grade": {
+ "const": "RECORDED"
+ },
+ "latency_ms": {
+ "type": "object"
+ },
+ "measured_by": {
+ "const": "MIZAN"
+ },
+ "protocol": {
+ "type": "object"
+ },
+ "record": {
+ "type": "string"
+ },
+ "since": {
+ "type": "string"
+ },
+ "subject": {
+ "type": "string"
+ },
+ "tools": {
+ "type": "integer"
+ },
+ "uptime_pct": {
+ "type": "number"
+ },
+ "window": {
+ "type": "object"
+ }
+ },
+ "required": [
+ "subject",
+ "grade",
+ "measured_by"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "unknown": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "services",
+ "identity"
+ ],
+ "type": "object"
+}check1 field changedOutput schema / properties / identityAdded value: +{
+ "additionalProperties": false,
+ "description": "Who stands behind the agent, graded. grade = the highest grade any one evidence item earned; nothing a caller sends sets it. Every item states what it does not check.",
+ "properties": {
+ "agent": {
+ "type": "string"
+ },
+ "evidence": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "checked_at": {
+ "type": "string"
+ },
+ "expires": {
+ "type": "string"
+ },
+ "grade": {
+ "enum": [
+ "NONE",
+ "DECLARED",
+ "RECORDED",
+ "PROVEN"
+ ]
+ },
+ "kind": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ },
+ "what_it_does_not_check": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "value",
+ "grade",
+ "checked_at",
+ "what_it_does_not_check"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "grade": {
+ "enum": [
+ "NONE",
+ "DECLARED",
+ "RECORDED",
+ "PROVEN"
+ ]
+ },
+ "legal_entity": {
+ "properties": {
+ "grade": {
+ "enum": [
+ "NONE",
+ "DECLARED",
+ "RECORDED",
+ "PROVEN"
+ ]
+ },
+ "lei": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "lei",
+ "grade"
+ ],
+ "type": "object"
+ },
+ "principal": {
+ "properties": {
+ "grade": {
+ "enum": [
+ "NONE",
+ "DECLARED",
+ "RECORDED",
+ "PROVEN"
+ ]
+ },
+ "id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "grade"
+ ],
+ "type": "object"
+ },
+ "what_it_does_not_check": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "grade",
+ "evidence"
+ ],
+ "type": "object"
+}check4 fields changedInput schema / properties / compatAdded value: +{
+ "default": false,
+ "description": "true = the previous, longer check shape, kept for one version (clients that validate outputSchema: use https://studio.mizan.market/mcp/legacy).",
+ "type": "boolean"
+}Input schema / properties / payeeAdded value: +{
+ "description": "Optional: the party you will pay (its id or address). The token is then bound to it (bound_to.payee) and the payee or rail checks that offline; a payee that is not the subject is a REFUSE (payee_mismatch).",
+ "maxLength": 200,
+ "type": "string"
+}Input schema / properties / ttlAdded value: +{
+ "description": "Optional: seconds the verdict stays valid (default 3600).",
+ "maximum": 86400,
+ "minimum": 60,
+ "type": "integer"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$id": "https://mizan.market/verdict/mizan-verdict-1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "allOf": [
+ {
+ "if": {
+ "properties": {
+ "decision": {
+ "const": "ALLOW"
+ }
+ }
+ },
+ "then": {
+ "not": {
+ "anyOf": [
+ {
+ "required": [
+ "reason"
+ ]
+ },
+ {
+ "required": [
+ "next"
+ ]
+ }
+ ]
+ },
+ "required": [
+ "met",
+ "grade"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "decision": {
+ "const": "REFUSE"
+ }
+ }
+ },
+ "then": {
+ "not": {
+ "anyOf": [
+ {
+ "required": [
+ "met"
+ ]
+ },
+ {
+ "required": [
+ "grade"
+ ]
+ }
+ ]
+ },
+ "required": [
+ "reason",
+ "next"
+ ]
+ }
+ }
+ ],
+ "description": "One signed answer to: may I pay this party under this rule? Fields absent when unknown; never null.",
+ "properties": {
+ "as_of": {
+ "additionalProperties": false,
+ "properties": {
+ "head": {
+ "pattern": "^[0-9a-f]{64}$",
+ "type": "string"
+ },
+ "ledger_size": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "ledger_size",
+ "head"
+ ],
+ "type": "object"
+ },
+ "bound_to": {
+ "additionalProperties": false,
+ "properties": {
+ "amount": {
+ "pattern": "^[0-9]+(\\.[0-9]+)? [A-Z0-9]{1,12}$",
+ "type": "string"
+ },
+ "payee": {
+ "type": "string"
+ },
+ "rule": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "payee",
+ "rule"
+ ],
+ "type": "object"
+ },
+ "decision": {
+ "enum": [
+ "ALLOW",
+ "REFUSE"
+ ]
+ },
+ "details": {
+ "format": "uri",
+ "type": "string"
+ },
+ "expires": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "grade": {
+ "description": "Present on ALLOW only; never higher than earned.",
+ "enum": [
+ "DECLARED",
+ "RECORDED",
+ "PROVEN"
+ ]
+ },
+ "issued": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "kid": {
+ "type": "string"
+ },
+ "measured": {
+ "additionalProperties": false,
+ "description": "Only earned fields; an unknown field is omitted, never zero.",
+ "properties": {
+ "counted_before_outcome": {
+ "type": "boolean"
+ },
+ "metric": {
+ "type": "string"
+ },
+ "tries": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "met": {
+ "description": "ALLOW only: the bar met, in plain words.",
+ "type": "string"
+ },
+ "next": {
+ "properties": {
+ "proof_request": {
+ "type": "object"
+ },
+ "what_would_pass": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "proof_request",
+ "what_would_pass"
+ ],
+ "type": "object"
+ },
+ "reason": {
+ "description": "REFUSE only: one stable reason code (see reason_codes), or a documented rule-specific code.",
+ "type": "string"
+ },
+ "record": {
+ "additionalProperties": false,
+ "properties": {
+ "entry": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "id": {
+ "type": "string"
+ },
+ "verify": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "entry",
+ "verify"
+ ],
+ "type": "object"
+ },
+ "request_id": {
+ "type": "string"
+ },
+ "rule": {
+ "additionalProperties": false,
+ "properties": {
+ "hash": {
+ "pattern": "^sha256:[0-9a-f]{64}$",
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "schema": {
+ "const": "mizan.verdict/1"
+ },
+ "status": {
+ "format": "uri",
+ "type": "string"
+ },
+ "subject": {
+ "description": "Canonical id: credential:…, ag:…, evm:…, dns:…, web:…; otherwise the subject as given.",
+ "type": "string"
+ },
+ "token": {
+ "pattern": "^mzv1\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+$",
+ "type": "string"
+ }
+ },
+ "required": [
+ "schema",
+ "decision",
+ "subject",
+ "rule",
+ "issued",
+ "expires",
+ "as_of",
+ "request_id",
+ "token",
+ "kid",
+ "status",
+ "details"
+ ],
+ "title": "mizan.verdict/1",
+ "type": "object"
+}claim_identityrequest_proofcheck1 field changedInput schema / properties / subject / descriptionPrevious value: -"Who you are about to pay, hire or allocate to: an agent id, a company domain (example.com), a service URL (an API, MCP or A2A endpoint), or a MIZAN credential id."New value: +"Who you are about to pay, hire or allocate to: an agent id, a company domain (example.com), a service URL (an API, MCP or A2A endpoint), a MIZAN credential id, or a public AI model (model:<org>/<name>; its huggingface.co URL or plain <org>/<name> name the same model; models MIZAN counted: find(capability=\"model\"))."request_proof1 field changedInput schema / properties / subject / descriptionPrevious value: -"The counterparty you want to pay or hire: an agent id, company domain, service URL or credential id."New value: +"The counterparty you want to pay or hire: an agent id, company domain, service URL, credential id, or a public AI model (model:<org>/<name>)."check16 fields changedInput schema / additionalPropertiesAdded value: +trueInput schema / properties / agentRemoved value: -{
- "title": "Agent",
- "type": "string"
-}Input schema / properties / amountRemoved value: -{
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "title": "Amount"
-}Input schema / properties / api_key / defaultRemoved value: -""Input schema / properties / api_key / descriptionAdded value: +"Optional MIZAN key (mzn_…): the check counts toward your record as a careful counterparty."Input schema / properties / api_key / titleRemoved value: -"Api Key"Input schema / properties / bindAdded value: +{
+ "additionalProperties": false,
+ "description": "Optional: bind the signed answer to one payment, so it cannot be reused for another. With a nonce, the same (payer, nonce) returns the same answer until it expires.",
+ "properties": {
+ "amount": {
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "pattern": "^(0|[1-9][0-9]*)(\\.[0-9]+)?$",
+ "type": "string"
+ }
+ ],
+ "description": "The amount, as you state it (labelled unverified)."
+ },
+ "currency": {
+ "description": "e.g. USD, USDC.",
+ "maxLength": 12,
+ "type": "string"
+ },
+ "nonce": {
+ "description": "At least 128 bits: 32+ hex or 22+ base64url characters.",
+ "maxLength": 200,
+ "minLength": 22,
+ "type": "string"
+ },
+ "payer": {
+ "description": "You, the payer (your id, domain or address).",
+ "maxLength": 200,
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Input schema / properties / confirmAdded value: +{
+ "default": false,
+ "description": "Only for a rule in plain words: true once its read-back says what you mean.",
+ "type": "boolean"
+}Input schema / properties / currencyRemoved value: -{
- "default": "USD",
- "title": "Currency",
- "type": "string"
-}Input schema / properties / policy_idRemoved value: -{
- "default": "",
- "title": "Policy Id",
- "type": "string"
-}Input schema / properties / purposeRemoved value: -{
- "default": "",
- "title": "Purpose",
- "type": "string"
-}Input schema / properties / requirementRemoved value: -{
- "default": "",
- "title": "Requirement",
- "type": "string"
-}Input schema / properties / ruleAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "object"
+ }
+ ],
+ "description": "Optional: your bar. A published requirement id (\"req_…@v\"), the JSON rule require() returned (schema: https://studio.mizan.market/app/schemas/requirement-rule-v2.schema.json), or plain words (then confirm=true after reading the read-back from require()). Without a rule, MIZAN's default bar applies."
+}Input schema / properties / subjectAdded value: +{
+ "description": "Who you are about to pay, hire or allocate to: an agent id, a company domain (example.com), a service URL (an API, MCP or A2A endpoint), or a MIZAN credential id.",
+ "maxLength": 500,
+ "minLength": 1,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "agent"
-]New value: +[
+ "subject"
+]Input schema / titleRemoved value: -"checkArguments"claim_identitymore5 fields changedInput schema / additionalPropertiesAdded value: +trueInput schema / properties / topic / defaultRemoved value: -""Input schema / properties / topic / descriptionAdded value: +"Optional: narrow to one group (e.g. \"verify\", \"identity\", \"standard\", \"log\") or \"problems\". Leave out for everything."Input schema / properties / topic / titleRemoved value: -"Topic"Input schema / titleRemoved value: -"moreArguments"prove29 fields changedInput schema / additionalPropertiesAdded value: +trueInput schema / properties / alias / defaultRemoved value: -""Input schema / properties / alias / descriptionAdded value: +"trading: a public name for a minted credential."Input schema / properties / alias / titleRemoved value: -"Alias"Input schema / properties / api_key / defaultRemoved value: -""Input schema / properties / api_key / descriptionAdded value: +"Your MIZAN key: needed to mint, to commit a forecast, or to enroll a service. claim_identity() gives one."Input schema / properties / api_key / titleRemoved value: -"Api Key"Input schema / properties / assetAdded value: +{
+ "description": "forecast: a Binance USDT pair, e.g. BTCUSDT.",
+ "type": "string"
+}Input schema / properties / at_utcAdded value: +{
+ "description": "forecast: the hour it resolves, 'YYYY-MM-DDTHH:00' UTC, at least 1 h ahead.",
+ "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:00$",
+ "type": "string"
+}Input schema / properties / claim_typeAdded value: +{
+ "description": "trading: your positions on a canonical market; minted, a zero-knowledge proof (PROVEN). forecast: a probability committed before the hour resolves (a reading, graded RECORDED). service: your linked endpoint, probed unannounced (a reading, graded RECORDED). Leave out for the guide.",
+ "enum": [
+ "trading",
+ "forecast",
+ "service"
+ ],
+ "type": "string"
+}Input schema / properties / dataset / defaultRemoved value: -""Input schema / properties / dataset / descriptionAdded value: +"trading: the market key (call prove(claim_type=\"trading\") for the list)."Input schema / properties / dataset / titleRemoved value: -"Dataset"Input schema / properties / identifierAdded value: +{
+ "description": "service: the endpoint you linked by proof of control (link() first).",
+ "type": "string"
+}Input schema / properties / levelAdded value: +{
+ "description": "forecast: the price level.",
+ "type": "number"
+}Input schema / properties / mint / descriptionAdded value: +"trading: false = a free, private verdict with every gate; true (with api_key) = a credential others see when they check you."Input schema / properties / mint / titleRemoved value: -"Mint"Input schema / properties / model_id / defaultRemoved value: -""Input schema / properties / model_id / descriptionAdded value: +"trading: your label for the model (never its code)."Input schema / properties / model_id / titleRemoved value: -"Model Id"Input schema / properties / opAdded value: +{
+ "description": "forecast: the 1h close is >= or < level.",
+ "enum": [
+ ">=",
+ "<"
+ ],
+ "type": "string"
+}Input schema / properties / positions / anyOfRemoved value: -[
- {
- "items": {
- "type": "integer"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]Input schema / properties / positions / defaultRemoved value: -nullInput schema / properties / positions / descriptionAdded value: +"trading: one position per bar-move, exactly bars-1 of them."Input schema / properties / positions / itemsAdded value: +{
+ "enum": [
+ -1,
+ 0,
+ 1
+ ],
+ "type": "integer"
+}Input schema / properties / positions / titleRemoved value: -"Positions"Input schema / properties / positions / typeAdded value: +"array"Input schema / properties / probabilityAdded value: +{
+ "description": "forecast: your probability that it happens.",
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+}Input schema / titleRemoved value: -"proveArguments"request_proofrequireBefore an agent pays, get a verdict and a keepable receipt. Not insurance. Not custody.
Agents pay for work and prove what happened.
Free agent identity and signed US supplier-payment decisions. Inspect first; verify portable proof.
Verify a business before an agent pays, signs or buys: registry-cited decision and signed receipt.
Add one secure layer between your agents and this server.