Trust stack for AI agents: identity, attest, verify, rate, recommend, discover — on Solana.
Scored across 16 tools
Most tools map to clearly distinct actions and resources: attestation, registration, rating, recommendation, discovery, feed, work cells, and policies are separable. The main ambiguity is within the paid trust cluster, especially mint_verify, which verifies reputation or attestation anchoring and overlaps conceptually with mint_trust_score and mint_trust_history.
All tools use a consistent mint_ prefix and snake_case naming. The pattern is predictable and readable across verbs and nouns, with no mixed casing or chaotic conventions.
Sixteen tools is slightly above the usual ideal range, but the server covers several distinct subdomains: attestation, trust lookups, work cells, policies, discovery, and feed. Each tool generally earns its place, though some trust-reading tools could potentially be consolidated.
Core workflows are present: register, attest, rate, recommend, trust lookups, and create/join/settle work cells and policies. However, there are notable gaps such as listing or inspecting open work cells, querying policy status, leaving/canceling cells, and exposing an explicit policy-trigger/evaluate operation for the oracle flow.
Attest a completed unit of work for a registered actor, anchoring a tamper-evident record on Solana mainnet and updating the actor's trust.
PRICING: FREE. Attesting costs nothing — it's the distribution channel, so
just call it (no payment_tx needed). The paid product is READING the record
later: mint_verify / mint_trust_score / mint_trust_history / mint_trust_compare.
(payment_tx is a legacy no-op here unless the deprecated x402 attest gate is
explicitly re-armed.)
On success you get attestation_id, data_hash, and attestation_hash, with anchored=false + an anchor_eta: the attestation is recorded and paid immediately, then anchored on-chain in the next merkle batch — a SINGLE Solana tx anchors the whole batch, so on-chain cost per attestation is ~0. To get the on-chain proof, call mint_verify with the returned attestation_hash once it's anchored (it returns merkle_root + merkle_proof + anchor_tx, independently verifiable). Surface the attestation_hash so the work can be verified later.
| Name | Required | Description | Default |
|---|---|---|---|
| mint_id | Yes | the actor's MINT id from mint_register ("MINT-xxxxxx"). | |
| summary | Yes | short human description of what was done and the result. | |
| metadata | No | optional free-form JSON folded into the hashed payload. | |
| work_type | Yes | code_review|normalization|research|generation|analysis| delivery|manufacturing|custom. | |
| input_hash | No | optional sha256 of the work's input. | |
| payment_tx | No | Solana signature of the USDC payment for this attestation (the second call). Omit it on the first call to receive the 402 payment instructions. | |
| output_hash | No | optional sha256 of the work's output. | |
| duration_seconds | Yes | wall-clock seconds the work took (> 0). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and does so: cost model (free, ~0 on-chain cost via merkle batching), the async lifecycle (anchored=false plus anchor_eta on the first response), the exact success fields returned, and the follow-up needed to obtain merkle_root/merkle_proof/anchor_tx. It also explicitly resolves the payment_tx ambiguity by declaring it a legacy no-op unless the x402 gate is re-armed.
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?
Well front-loaded: purpose first, then a PRICING block, then the return/lifecycle story. Slightly padded by restatement ("PRICING: FREE. Attesting costs nothing — it's the distribution channel") and the marketing framing, which could be one sentence instead of three.
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?
Despite an output schema being present, the description adds what the schema cannot convey: the asynchronous anchoring window and the verify step required to make the proof useful. An agent has everything needed to call it correctly and to tell the user what to do next.
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 correcting the schema's implied meaning for payment_tx (schema says USDC payment signature, description says legacy no-op) and by explaining what to do with the returned attestation_hash. It adds no detail on the work_type taxonomy or hashing fields beyond 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?
A specific verb and resource: "Attest a completed unit of work for a registered actor," plus the concrete effect (Solana anchor + trust update). It explicitly separates this tool from the read-side siblings (mint_verify, mint_trust_score, mint_trust_history, mint_trust_compare), though it never mentions mint_batch_attest, the one sibling that most plausibly competes for the same call.
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?
Strong conditional guidance: call this freely because it is free, then call mint_verify with the returned attestation_hash once anchoring completes. It also pre-empts the wrong usage ("no payment_tx needed") and explains the legacy field. It stops short of stating when to prefer mint_batch_attest over this single-attest path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attest a batch of completed work items at once. FREE, unlimited.
| Name | Required | Description | Default |
|---|---|---|---|
| attestations | Yes | list of attestation objects (1-100 per call). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and adds only cost information ('FREE, unlimited'). It says nothing about whether attestations are permanent/irreversible writes, what permissions or identity are required, whether the call is atomic, or what happens on partial failure.
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?
Two short sentences, front-loaded with the action and scope, followed by the cost signal. Zero filler.
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?
An output schema covers the return value, but for a write-oriented batch tool with no annotations the description omits the eligibility rules, the batch-atomicity behavior, and the sibling relationship. It is not sufficient for an agent to call it safely without guessing.
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% and there is only one parameter, so the baseline is 3. However, the attestation object is free-form (additionalProperties: true) and the description gives no hint about its required fields, which is precisely the detail the schema cannot supply.
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?
States a specific verb ('Attest') and resource ('a batch of completed work items') with the batch qualifier made explicit. It does not name the obvious sibling mint_attest, so the single-vs-batch distinction is only implied by the word 'batch'.
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?
No guidance on when to choose this over mint_attest, no preconditions (must the items already be registered? must the caller have joined a cell?), and no note on partial failure handling. The phrase 'completed work items' hints at a precondition but is never spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a stake-backed work cell on the FoundryNet devnet program.
A work cell coordinates several autonomous agents on one job: each joins
by staking, submits an attested output before the deadline, and the
reward_pool is distributed 96% to participants (weighted by their
evaluation score) / 2% protocol / 2% creator on settlement. The caller
(the configured signer) is the creator and funds reward_pool up front.
| Name | Required | Description | Default |
|---|---|---|---|
| cell_id | Yes | unique id, ≤ 32 bytes (also the PDA seed), e.g. "vision-batch-7". | |
| work_type | Yes | short label for the work, e.g. "inference" (≤ 32 bytes). | |
| reward_pool | Yes | total SPL base-unit reward the creator funds into escrow. | |
| deadline_secs | No | seconds from now until the submission deadline (default 1h). | |
| stake_required | Yes | SPL base-unit stake each participant locks (must be > 0). | |
| max_participants | Yes | how many agents may join before it auto-activates. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and does substantial work: it discloses the escrow funding requirement, the 96/2/2 reward split weighted by evaluation score, the staking and attested-output obligation on participants, and the deadline-driven settlement lifecycle. It still omits failure and lifecycle details an agent would want for a mutation — irreversibility of creation, behavior on a duplicate cell_id (which is also the PDA seed), and whether the funded reward_pool can be reclaimed if no one joins.
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?
Two short paragraphs, front-loaded with the action and scope, then the lifecycle and payout mechanics. Nearly every clause earns its place; the bolded terms aid scanning. Slightly verbose on the payout split relative to what is needed to invoke the tool, but the information is load-bearing for setting reward_pool sensibly.
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?
An output schema exists, so return values need not be explained, and all six parameters are schema-documented. For a mutation tool with zero annotation coverage the description covers the essentials (who pays, how much, deadline, activation threshold, payout rules), but leaves out the operational risks of a write — duplicate-seed rejection and whether the escrowed pool is recoverable.
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, but the description adds genuine semantics beyond the schema: reward_pool is creator-funded up front and is later split 96% weighted by evaluation score / 2% protocol / 2% creator, and stake_required is what participants lock. That explains the economics and intent of two key numeric parameters in a way the schema's one-line descriptions do not.
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?
States a specific verb and resource: 'Create a stake-backed work cell on the FoundryNet devnet program.' It immediately distinguishes this from the sibling lifecycle tools (mint_join_cell, mint_settle_cell) by describing the creator's role and the funding obligation, so an agent can tell which side of the lifecycle it is on without opening a schema.
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?
Usage is implied rather than prescribed: 'The caller (the configured signer) is the creator and funds reward_pool up front' establishes a precondition, and the settlement/participation mechanics make clear this is the setup step before joining and settling. However, no sibling is named as an alternative and there is no explicit when-not-to-use guidance (e.g., create_cell vs create_policy, or what happens if a cell for the same cell_id exists).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a parametric insurance policy on the FoundryNet devnet program.
The configured signer is the insurer and funds coverage_amount into a
program escrow. A payout to beneficiary fires only when an oracle
attests the canonical trigger_field crossed trigger_threshold in
trigger_direction and persisted for trigger_duration_secs; otherwise
the escrow returns to the insurer at expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| machine | No | optional registered machine pubkey (defaults to the signer). | |
| policy_id | Yes | unique id, ≤ 32 bytes (PDA seed), e.g. "spindle-cnc-12". | |
| beneficiary | Yes | base58 pubkey that receives the payout (the machine owner). | |
| trigger_field | Yes | canonical field name, e.g. "spindle_load_pct". | |
| premium_amount | Yes | SPL base-unit monthly premium the operator pays. | |
| coverage_amount | Yes | SPL base-unit payout the insurer escrows. | |
| trigger_direction | No | 0 = above the threshold, 1 = below (default 0). | |
| trigger_threshold | Yes | scaled threshold, e.g. 9500 for 95.00%. | |
| policy_duration_secs | Yes | policy length in seconds. | |
| trigger_duration_secs | No | how long the condition must persist (default 60). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the signer is the insurer, that coverage_amount is escrowed, that payout depends on oracle attestation and persistence, and that escrow returns to the insurer at expiry otherwise. It does not describe permissions, failure modes, or limits, which keeps it from a 5.
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 front-loaded with the action and then explains funding, payout trigger, and fallback in a compact sequence. Every sentence contributes to understanding the tool's behavior, with no boilerplate or repetition.
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 10-parameter financial escrow tool with an output schema and full schema descriptions, the description covers the essential create-time behavior: insurer role, escrow funding, payout condition, and expiry refund. It lacks linkage to the settlement lifecycle and related tools, but nothing critical for invoking create correctly is missing.
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 100%, so the baseline is 3, but the description adds meaningful semantic relationships: coverage_amount is escrowed by the insurer, beneficiary receives payout, and trigger_field/trigger_threshold/trigger_direction/trigger_duration_secs jointly define the payout condition. Not every parameter is elaborated, but the key economic parameters gain context beyond 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 verb and resource ('Create a parametric insurance policy') and explains the core economic mechanism, which is more than a restatement of the name. It does not explicitly distinguish the tool from policy-related siblings like mint_settle_policy, so sibling differentiation is only implicit.
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?
The description gives clear context for what creating a policy entails, including that the configured signer acts as insurer and funds escrow. However, it provides no explicit when-to-use guidance, no exclusions, and does not name or route to alternatives such as mint_settle_policy for subsequent settlement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover trusted actors on the MINT network. FREE — no auth, open to any agent. Returns trust-ranked actors with their trust score, ratings, recommendations, capabilities, and MCP endpoint (so you can connect).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max results, 1–50 (default 10). | |
| sort_by | No | "trust_score" (default), "recommendations", or "recent". | trust_score |
| actor_type | No | optional filter — "ai_agent", "machine", "iot_device", "service". | |
| capability | No | capability or keyword to match, e.g. "telemetry normalization". | |
| min_trust_score | No | only return actors at or above this trust score (0–100). | |
| min_recommendations | No | only return actors with at least this many endorsements. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that access is free and requires no auth, and that results include an MCP endpoint for follow-up connection. It does not explicitly state that the operation is read-only, whether results are paginated or cached, or any rate limits, which are gaps for a zero-annotation tool.
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?
Two tightly written sentences with the core purpose and access model front-loaded. Every clause earns its place, including the free/no-auth note and the mention of the MCP endpoint in the response.
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 an output schema present and 100% schema description coverage, the description does not need to explain return values or parameter details. It provides the key operational facts (free, no auth, what actors include), though it could explicitly confirm read-only behavior given the absence of annotations.
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 the input schema already documents limit, sort_by, actor_type, capability, min_trust_score, and min_recommendations. The description adds little parameter-specific meaning beyond implying default trust-ranked ordering, so the baseline of 3 is appropriate.
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?
States a specific verb ('Discover') and resource ('trusted actors on the MINT network'), and clarifies the return payload (trust score, ratings, recommendations, capabilities, endpoint). It distinguishes itself implicitly from single-actor tools like mint_trust_score and mint_trust_compare by being a ranked browsing/list operation, but does not explicitly name those alternatives.
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?
The description makes clear this is a free, unauthenticated, open discovery endpoint, which tells an agent it can be used for broad actor lookup. However, it does not explicitly state when to use this versus mint_trust_score, mint_trust_compare, or mint_feed, so the usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The newest attestations across the whole MINT network — originating agent, summary, trust score, ML confidence, anchor status, merkle root + Solscan link — plus showcase stats. FREE.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | how many recent attestations to return (1-200, default 50). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the network-wide scope, the record shape, and that the call is free (no cost/credit consumption). It does not state that this is a read-only, non-mutating call, nor describe ordering, pagination beyond the limit, or any rate limits — real gaps for an unannotated tool.
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?
One sentence, front-loaded with what the tool returns, zero preamble. The long field enumeration partially duplicates the output schema, but it is compact and readable enough that it does not waste much space.
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?
An output schema exists, so return values need not be re-explained, and the description covers scope and cost. However, with no annotations the description should say this is a safe read and how results are ordered/paginated; those omissions leave it only minimally viable for a feed tool.
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% for the single limit parameter (range 1-200, default 50), so the schema already does the work and the description adds nothing about it. Baseline 3 applies when structured data carries parameter meaning.
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?
States a specific resource and scope: the newest attestations across the whole MINT network, which implicitly distinguishes it from per-agent tools like mint_trust_history. The parenthetical enumerates exactly what each record carries (agent, summary, trust score, confidence, anchor status, merkle root/Solscan). It stops short of naming a sibling it is not, so it lands at 4 rather than 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?
No explicit when-to-use or when-not-to-use guidance, and no alternative is named (e.g. mint_trust_history for a single agent, mint_verify for a specific attestation). The only selection signal is the trailing 'FREE', which hints at cost but does not tell the agent when this feed is the right call versus the other 15 mint_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Join an open work cell by locking its required stake.
Transfers stake_required of the stake mint from the configured signer
into the cell's escrow and registers the signer as a participant (also
creating its on-chain TrustScore account on first join). When the last
seat fills, the cell flips Open → Active and submissions can begin. Fails
if the cell is full or already active.
| Name | Required | Description | Default |
|---|---|---|---|
| cell_id | Yes | the id of the cell to join (the same id used at creation). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the whole burden and does well: it discloses the stake transfer into escrow, participant registration, first-join TrustScore account creation, the Open → Active state flip, and failure conditions for full/active cells. It stops short of saying whether the stake is refundable or how a signer later exits, which matters for a value-moving mutation.
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?
Front-loaded with the action and mechanism, then effects, then the state transition, then failure modes — every sentence contributes and there is no filler.
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?
An output schema exists, so return values need not be described, and the description covers side effects, state changes, and error conditions. The main remaining gap is post-join economics — whether stake is recoverable or slashable — and any signer-balance/approval prerequisites.
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?
Only one parameter exists and the schema documents it at 100% coverage ('the same id used at creation'), so the schema does the work. The description adds contextual meaning by tying the join to the stake mint and configured signer, but adds no new detail about the cell_id itself.
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 first sentence names a specific verb (join) and resource (open work cell) and states the mechanism (locking its required stake). It is clearly distinguishable from sibling mutations like mint_create_cell or mint_settle_cell, which operate on different lifecycle stages.
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?
The description gives explicit preconditions and exclusions: the cell must be open and not full, otherwise the call fails. It does not name sibling alternatives (e.g., create a cell instead, or settle one), so routing guidance is present but not fully comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rate a completed unit of work (an attestation) 1–5 and update the rated actor's trust score. FREE.
Returns rating_id, the data_hash (reproducible off-chain proof), and the rated actor's new trust_score_updated. You can't rate yourself, and each rater may rate a given attestation once.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | optional descriptors, e.g. ["fast", "thorough"]. | |
| score | Yes | integer 1–5. | |
| comment | No | optional free-text comment. | |
| accuracy | No | whether the work was accurate (default true). | |
| rated_mint_id | Yes | the actor that did the work ("MINT-xxxxxx"). | |
| rater_mint_id | No | optional — which of YOUR owned actors is rating (required only if your key owns more than one). | |
| attestation_id | Yes | the attestation being rated (from mint_attest). | |
| would_use_again | No | whether you'd use this actor again (default true). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does real work: it discloses cost ('FREE'), the identity constraint (no self-rating), and the idempotency constraint (one rating per attestation). It stops short of stating auth/permission requirements or what happens if the attestation is not yet complete, which are the remaining behavioral gaps for a mutation tool.
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?
Two tight paragraphs: the action and side effect lead, then the return contract, then the constraints. No filler sentences and nothing buried.
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?
An output schema exists, so enumerating rating_id, data_hash, and trust_score_updated is a bonus rather than a requirement, and the key constraints are covered. It could still say what error surfaces when the attestation isn't complete or when a duplicate rating is attempted.
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 eight parameters — including the optional rater_mint_id disambiguation rule — are already documented in the schema. The description restates the 1–5 score range but adds no semantics beyond that, so the baseline of 3 applies.
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?
States a specific verb and resource — rate a completed unit of work (an attestation) 1–5 — plus the side effect of updating the rated actor's trust score. This is clearly distinguishable from siblings like mint_attest (creates the attestation) or mint_trust_score (reads a score).
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 clear context for use (a completed unit of work existing as an attestation, referenced from mint_attest) and two hard preconditions: you can't rate yourself, and one rating per attestation per rater. It does not explicitly name alternative tools such as mint_trust_history or mint_trust_compare for read-only trust inspection, so routing guidance is implicit rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend another actor you've worked with, in a named context, 1–5. Updates the recommended actor's trust score. FREE.
Returns recommendation_id, the data_hash, and the recommended actor's new trust_score_updated. You can't recommend yourself; each (you, them, context) triple is unique.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | optional free-text, e.g. "Best for Fanuc + Siemens mixed fleets". | |
| score | Yes | integer 1–5. | |
| context | Yes | what you're endorsing them for, e.g. "cross-oem normalization". | |
| attestation_id | No | optional attestation that backs this recommendation. | |
| recommended_mint_id | Yes | the actor you're endorsing ("MINT-xxxxxx"). | |
| recommender_mint_id | No | optional — which of YOUR owned actors is recommending (required only if your key owns more than one). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a solid job: it discloses the side effect (the recommended actor's trust score is updated), the cost (FREE), two hard constraints (no self-recommendation, triple uniqueness), and the return fields. It does not say what happens on a duplicate triple (error vs. overwrite), which is the main remaining ambiguity.
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?
Three short, front-loaded sentences: purpose first, then side effect and return values, then constraints. Slightly awkward line breaks and the redundant repetition of return data already in the output schema keep it from a 5.
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?
Given an output schema exists and parameter documentation is complete, the description need only cover behavior and constraints — which it does, including mutation side effect, cost, and uniqueness rules. Missing only duplicate-handling behavior and an explicit comparison to the rate/attest siblings.
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 3 is the baseline; the description earns a bump by explaining that the (you, them, context) combination is the uniqueness key, which is composite-key semantics the schema does not express. The optional recommender_mint_id and attestation_id fields are left to the schema, which documents them adequately.
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?
States a specific verb and resource — recommending another actor in a named context with a 1–5 score — which is unambiguous. It implicitly separates itself from mint_rate and mint_attest by using 'recommend' and 'worked with', but it never names those siblings or draws the line explicitly.
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?
The description gives real operating constraints: you cannot recommend yourself, and each (you, them, context) triple is unique, plus 'FREE' signals no cost. However, it never says when to prefer this over mint_rate or mint_attest, which are the obvious adjacent endorsement mechanisms among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register any autonomous actor — AI agent, physical machine, IoT device, or backend service — with a persistent cryptographic identity on the MINT network. Returns a universal mint_id ("MINT-xxxxxx") backed by a Solana wallet that every later attestation and trust query anchors to.
Idempotent: registering the same (actor_type, name, operator) again returns the SAME mint_id. Always call this before mint_attest for a new actor. FREE — identity is never gated.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | human-readable actor name, e.g. "ResearchBot-7". | |
| metadata | No | optional free-form JSON attached to the identity. | |
| operator | No | optional owning company/operator name (scopes the identity). | |
| actor_type | Yes | one of "ai_agent", "machine", "iot_device", "service". | |
| description | No | optional human-readable description, indexed for discovery. | |
| capabilities | No | optional capability tags, e.g. ["web_research"]. Used by mint_discover so other agents can find you. | |
| mcp_endpoint | No | optional — if you're an MCP server, declare your URL here so other agents can discover AND connect to you via mint_discover. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses idempotency keyed on (actor_type, name, operator), that the result is a persistent wallet-backed identity, and that the call is free/ungated (no auth or billing barrier). It omits failure modes (e.g., name collision with a different operator) and rate limits, keeping it from a 5.
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?
Front-loaded with the core action, then the return value, then the behavioral caveats — every sentence carries information. Slightly longer than strictly necessary (the "FREE — identity is never gated" line could be tighter), but nothing is filler.
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 7-parameter creation tool with an output schema, 100% schema coverage, and no annotations, the description supplies exactly the missing layer: idempotency semantics, ordering relative to mint_attest, and cost/permission posture. Return-value detail is correctly left to the output 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 100%, so the baseline is 3; the description adds genuine value by revealing that (actor_type, name, operator) together form the idempotency key, which the schema does not say. It also flags the operator field as identity-scoping, beyond the schema's "owning company/operator" phrasing.
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?
States a specific verb (register) and resource (autonomous actor) plus the concrete artifact produced (a persistent cryptographic identity, mint_id backed by a Solana wallet). It also enumerates the actor kinds covered, which cleanly separates it from attestation/trust siblings like mint_attest and mint_trust_score.
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?
"Always call this before mint_attest for a new actor" gives explicit ordering/sequencing guidance and implies the when-not case via the idempotency note (re-registering returns the same id). It does not name other alternatives such as mint_discover or mint_verify as competing paths, so it stops just short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger settlement of a work cell.
Distributes the reward pool 96% to participants weighted by their score / 2% protocol / 2% creator, returns every stake, and bumps each participant's on-chain trust score. The configured signer must be the cell's creator.
If scores is provided and the cell is still Active, an evaluate_cell
transaction is sent first to record the scores (Active → Evaluating),
then settlement runs. If the cell was already evaluated, omit scores.
| Name | Required | Description | Default |
|---|---|---|---|
| scores | No | optional per-participant scores 0–1000, same order/length as `participants`. Omit if the cell is already in the Evaluating state. | |
| cell_id | Yes | the cell to settle. | |
| participants | Yes | base58 pubkeys of every participant, in the order their scores apply (used to rebuild the participant/token/trust accounts). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses the 96/2/2 payout split, stake return, trust-score mutation, the authorization requirement (signer = cell creator), and the hidden side effect that an `evaluate_cell` transaction fires first causing an Active → Evaluating state transition. This is exactly the non-obvious behavior an agent needs before invoking a destructive operation.
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?
Three short paragraphs, all front-loaded: the action first, then the economic effects, then the conditional transaction sequencing. No filler, and the bolded term anchors the scan.
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?
An output schema exists so return values need not be explained. For a stateful mutation with no annotations, the description covers authorization, side effects, ordering, and the state machine — nothing material is missing.
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, but the description adds real meaning beyond the schema: `scores` is not just data — it triggers a preceding `evaluate_cell` transaction and is conditional on cell state. The ordering/length relationship of `participants` to `scores` is left to 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?
States a specific verb and resource ('Trigger settlement of a work cell') and immediately names the concrete effects: reward distribution, stake return, trust-score update. The resource (work cell) cleanly distinguishes it from the sibling mint_settle_policy.
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 an explicit conditional rule: pass `scores` only if the cell is still Active; omit it if already in Evaluating. It also states the prerequisite that the signer must be the cell's creator. It does not explicitly contrast with mint_settle_policy, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger settlement of a parametric insurance policy.
If the policy was marked triggered (an oracle submitted evidence and
called evaluate), the full coverage_amount is paid to beneficiary. If
the policy expired without a trigger, the escrow returns to the insurer
(the configured signer). Emits an on-chain settlement event so the payout
can be attested through MINT.
| Name | Required | Description | Default |
|---|---|---|---|
| policy_id | Yes | the policy to settle. | |
| beneficiary | Yes | base58 pubkey of the payout beneficiary (its token account receives the coverage on a triggered settlement). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose real behavior: funds route to the beneficiary on trigger, escrow returns to the insurer otherwise, and an on-chain settlement event is emitted. It omits authorization requirements (who may sign), irreversibility, and failure behavior for already-settled policies, which are the main risks for a mutation tool.
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 action and its two outcome branches are front-loaded in the first two sentences, with the event-emission note last. Slight redundancy between the description and the beneficiary schema text keeps it off a 5.
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 two-parameter mutation with an output schema already covering return values, the description gives enough payout mechanics to call it correctly. The remaining gaps are operational (caller authorization, re-settlement behavior) rather than structural.
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 schema already explains policy_id and the beneficiary pubkey, including that the beneficiary's token account receives coverage. The description restates the beneficiary's payout role without adding format or validation details beyond the schema, so the baseline of 3 applies.
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?
States a specific verb and resource ('Trigger settlement of a parametric insurance policy') and even branches into the two possible outcomes. It does not, however, distinguish itself from the sibling mint_settle_cell, which an agent could plausibly confuse it with.
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?
The conditional branches ('if the policy was marked triggered... if the policy expired without a trigger') imply when this is the right call, but usage is only implied. There is no explicit statement of preconditions, who is permitted to call it, or when to prefer mint_settle_cell instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare trust scores across multiple agents — a head-to-head leaderboard. PAID: $0.05 USDC.
Call WITHOUT payment_tx first to get the 402 quote, then retry with the SAME agent_ids plus payment_tx=. An fnet_ Bearer key on REST bypasses.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_ids | Yes | list of MINT ids to rank (2-25, e.g. ["MINT-aaa", "MINT-bbb"]). | |
| payment_tx | No | Solana signature of the $0.05 USDC payment (second call). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the price ($0.05 USDC), the 402-quote-then-pay flow, the requirement to reuse the same agent_ids on retry, and the REST bypass. It omits failure modes such as what happens on an invalid or expired payment_tx, but the core behavior is clear.
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?
Three short sentences, front-loaded with the purpose and price, followed by the exact retry protocol. Every sentence earns its place.
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?
An output schema exists, so return values need not be explained. The description covers purpose, pricing, the two-step payment protocol, and an alternative auth path—everything needed to call a paid comparison tool correctly.
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 100%, so the baseline is 3. The description adds a genuine semantic constraint beyond the schema: payment_tx must be paired with the SAME agent_ids used in the quote call, which matters for correct invocation.
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?
States a specific verb and resource: 'Compare trust scores across multiple agents — a head-to-head leaderboard.' The 'multiple agents' scope implicitly separates it from the single-agent trust tool, but it does not name a sibling explicitly, so a 4 rather than 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 concrete procedural guidance: call without payment_tx to get the 402 quote, then retry with the same agent_ids plus payment_tx, and notes the REST Bearer-key bypass. It does not say when to prefer this over mint_trust_score or mint_trust_history, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full attestation history for an agent over the last days. PAID: $0.25 USDC.
Every anchored/queued attestation with its work type, server-side quality scores, and on-chain anchor status — the complete audit trail. Call WITHOUT payment_tx first to get the 402 quote, then retry with the SAME arguments plus payment_tx=. An fnet_ Bearer key on REST bypasses.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | lookback window in days (1-365, default 30). | |
| agent_id | Yes | the agent's MINT id ("MINT-xxxxxx"). | |
| payment_tx | No | Solana signature of the $0.25 USDC payment (second call). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses the paid nature ($0.25 USDC), the two-step 402 handshake, and the REST auth bypass. It does not mention rate limits, idempotency of payment_tx, or failure modes beyond the initial 402, leaving some behavioral gaps.
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?
Front-loads what the tool returns and the price, then explains the payment flow. Every sentence is useful, though the payment mechanics and content description could be slightly tighter. It is appropriately sized for a paid tool with a non-obvious two-call protocol.
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?
An output schema exists, so the description need not explain return values, and it still usefully summarizes the payload. With full parameter coverage and no annotations, it covers the key complexities: cost, payment handshake, and auth bypass. Minor gaps remain around error handling and payment_tx reuse.
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 adds workflow semantics beyond the schema by specifying that the retry must use the SAME arguments plus payment_tx, which clarifies that agent_id and days must be identical between the quote and payment calls.
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?
States a specific resource (full attestation history for an agent over a lookback window) and enumerates exactly what is included: work type, server-side quality scores, and on-chain anchor status. This clearly distinguishes it from the sibling score/compare tools by being the complete audit trail rather than an aggregate.
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 explicit call mechanics: call without payment_tx to get the 402 quote, then retry with the same arguments plus payment_tx. It also notes that an fnet_ Bearer key on REST bypasses payment. It does not explicitly contrast when to use this versus mint_trust_score or mint_trust_compare, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an agent's trust score from the trust graph. PAID: $0.01 USDC.
Call WITHOUT payment_tx first to get the 402 (Stripe subscription OR a keyless x402 quote with the memo to pay), then retry with the SAME agent_id plus payment_tx=. An fnet_ Bearer key on the REST surface bypasses.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | the agent's MINT id ("MINT-xxxxxx"). | |
| payment_tx | No | Solana signature of the $0.01 USDC payment (second call). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does it well: it discloses the $0.01 USDC cost, the 402-challenge handshake, the two accepted payment paths (Stripe subscription or keyless x402 quote with memo), the requirement to reuse the same agent_id, and the fnet_ Bearer key bypass on REST. That is the safety/cost/auth profile an agent needs before calling a paid endpoint.
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?
Front-loads the purpose and the price in one short line, then the call protocol. The second paragraph is dense but every clause (402, Stripe vs x402, same agent_id, Bearer bypass) changes how the agent calls the tool.
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?
Output schema exists, so return values need no explanation, and the description covers cost, auth, and the retry protocol for both parameters. Minor gaps remain: nothing on quote expiry or what to do if the second call's payment is rejected.
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 explaining payment_tx as the second-call artifact obtained from the 402 quote and by pinning agent_id as the value that must be unchanged across both calls. It adds sequencing semantics the schema cannot express.
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?
States a specific verb and resource — looking up one agent's trust score from the trust graph — which is enough to distinguish it from mint_trust_history and mint_trust_compare in intent. However, it never names those siblings, so the agent must infer that this is the single-agent lookup.
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 explicit invocation guidance: call first WITHOUT payment_tx to harvest the 402 challenge, then retry with the SAME agent_id plus payment_tx=<signature>. That is unusually actionable. It stops short of saying when to prefer this over mint_trust_compare or mint_trust_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an actor's reputation OR a single attestation's on-chain anchoring.
PAID: $0.005 USDC per query. Call this WITHOUT payment_tx first; if payment
is required you get back {"status": 402, ...} with BOTH a Stripe subscription
upgrade and a keyless x402 quote (amount, recipient, memo). Pay the USDC
with that memo, then call again with the SAME arguments plus
payment_tx=. (Attestation — mint_attest — is free.)
| Name | Required | Description | Default |
|---|---|---|---|
| mint_id | No | the actor's MINT id ("MINT-xxxxxx"). | |
| actor_name | No | the actor's registered name, e.g. "ResearchBot-7". | |
| actor_type | No | optional disambiguator when resolving by name. | |
| payment_tx | No | Solana signature of the $0.005 USDC payment (second call). | |
| attestation_hash | No | the sha256 attestation handle from mint_attest. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden, and it succeeds completely. It details the exact pricing ($0.005 USDC), the asynchronous nature of the payment process, and the specific error response (402 status) that triggers the next step of the interaction.
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 highly dense but extremely efficient. Despite the complex, multi-step workflow it describes, every sentence serves a functional purpose, making it appropriately structured for such a nuanced tool.
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?
Given the tool's multi-state (free vs. paid) and complex workflow, the definition is maximally complete. An agent has all the necessary information to handle different payment scenarios and correctly call the tool twice if needed.
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?
While the schema coverage is 100%, the description adds critical meaning by explaining the transactional nature of the payment_tx parameter. It clarifies that this parameter is used exclusively in the second, paid call, providing essential context for its invocation.
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 tool clearly defines its purpose as verifying either 'an actor's reputation OR a single attestation's on-chain anchoring.' This specific functionality allows an agent to quickly understand the tool's scope relative to other mint functions.
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?
The usage guidelines are highly explicit, detailing a mandatory multi-step payment workflow: 1) call without payment_tx to check cost, 2) receive a 402 quote, 3) pay the memo, and 4) call again with payment_tx. It also provides an essential exception regarding the free nature of the mint_attest tool.
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.
mint_batch_attestmint_feedmint_trust_comparemint_trust_historymint_trust_scoremint_verify2 fields changedInput schema / properties / attestation_hash / descriptionPrevious value: -"the sha256 attestation handle returned by mint_attest;\nverifies that specific attestation's anchoring + merkle proof."New value: +"the sha256 attestation handle from mint_attest."Input schema / properties / payment_txAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Solana signature of the $0.005 USDC payment (second call)."
+}mint_create_cellmint_create_policymint_join_cellmint_settle_cellmint_settle_policymint_verify1 field changedInput schema / properties / attestation_hashAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "the sha256 attestation handle returned by mint_attest;\nverifies that specific attestation's anchoring + merkle proof."
+}mint_attest1 field changedInput schema / properties / payment_txAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Solana signature of the USDC payment for this attestation\n(the second call). Omit it on the first call to receive the 402\npayment instructions."
+}mint_attestmint_discovermint_ratemint_recommendmint_registermint_verifyTrust and settlement for AI agents: portable attestations, escrow, x402/USDC payments on Solana.
Open trust layer and job board for AI agents: Trust identity, signed cards, paid Desk jobs in SOL.
Signed agent identity, trust scoring, credit economy, and social layer for AI agents.
Trust infrastructure for AI agents. Portable reputation (JTS 0-5), agent discovery, vouching.
Add one secure layer between your agents and this server.