MINT Protocol — Universal Work Attestation
Server Details
Trust stack for AI agents: identity, attest, verify, rate, recommend, discover — on Solana.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 16 of 16 tools scored. Lowest: 3.5/5.
Each tool has a distinct purpose: attestation (individual/batch), work cell management, policy creation and settlement, trust queries, ratings, recommendations, registration, discovery, and verification. No two tools overlap in functionality; even related tools like mint_trust_score, mint_trust_history, and mint_trust_compare are clearly differentiated.
All tools follow the 'mint_' prefix followed by a verb_noun pattern (e.g., mint_attest, mint_create_cell, mint_trust_compare). The pattern is consistent across the entire set, making it easy for an agent to predict tool names.
16 tools is slightly above the typical 3-15 range but remains well-scoped given the server covers multiple sub-domains (attestation, trust, work cells, insurance, discovery). Each tool serves a specific function without excessive redundancy.
The tool surface covers the core attestation and trust lifecycle well, including registration, attestation, ratings, recommendations, and multiple trust queries. Work cell and policy features have creation, joining/settling, and settlement. Minor gaps exist (e.g., no explicit 'leave cell' or 'cancel policy'), but the primary workflows are complete.
Available Tools
16 toolsmint_attestAInspect
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: tamper-evident record on Solana, trust update, immediate recording with delayed anchoring, and what return fields contain. Lacks details on error states or idempotency but given no annotations, it covers the core behavioral traits well.
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-structured with clear sections (PRICING, process explanation). Front-loaded with core action. Every sentence adds value, no fluff. Length is appropriate for the complexity of 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?
Given the complex scenario (blockchain anchoring, pricing model, verification step), the description is complete. It explains return values, anchoring process, and how to obtain proof. Output schema exists, so return format details are covered.
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 already has 100% coverage with good descriptions. Description adds critical context about payment_tx being a no-op and the pricing model, enhancing understanding beyond schema alone. However, schema descriptions are already strong, so bar is met.
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?
Clearly states the tool attests completed work for a registered actor, anchoring on Solana. Distinguishes from sibling tools like mint_verify (for reading) and mint_batch_attest (batch). The verb 'attest' combined with resource 'unit of work' and context of anchoring provides high specificity.
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?
Explicitly states when to use (attesting work), emphasizes pricing is free so no payment_tx needed, and directs to mint_verify for on-chain proof. Provides clear usage guidance, including handling of legacy payment_tx and the two-step anchoring process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_batch_attestAInspect
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions 'FREE, unlimited' but does not disclose side effects (e.g., immutability of attestations, permission requirements, or what 'attest' entails). This is insufficient for a mutation 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?
The description is extremely concise, using only two brief phrases. It is front-loaded and contains no unnecessary words.
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 simplicity (one parameter) and presence of an output schema, the description is minimally adequate. However, it omits required fields within attestation objects and does not explain the return value or error conditions.
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 baseline is 3. The description adds no further meaning beyond the schema's parameter description, which already states 'list of attestation objects (1-100 per call)'. No improvement or clarification.
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 clearly states the verb 'Attest' and the resource 'batch of completed work items'. It distinguishes from the sibling 'mint_attest' by implying batching, and mentions 'FREE, unlimited' as additional context.
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 implies batching ('at once') and mentions 'FREE, unlimited' about cost, but it does not explicitly specify when to use this tool versus alternatives like 'mint_attest' for single items, nor any prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_create_cellAInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses funding requirement, distribution mechanics (96/2/2), and the staking process. Does not mention failure modes or authorization details beyond the caller being the configured signer.
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-structured with front-loaded purpose. The first paragraph is slightly wordy but every sentence adds value.
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 complexity (6 parameters) and presence of an output schema, the description is comprehensive. It explains the work cell concept, distribution ratios, and roles, making it sufficient for an agent.
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 baseline is 3. The description adds minimal extra meaning beyond the schema, such as clarifying that reward_pool is funded by the creator.
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 clearly states the verb 'Create' and the resource 'work cell on the FoundryNet devnet program'. It explains the purpose of a work cell and distinguishes from sibling tools like mint_join_cell and mint_settle_cell by being the creation step.
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?
Provides clear context that the caller is the creator and funds the reward_pool. Implicitly contrasts with sibling tools but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_create_policyAInspect
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the behavioral flow: the insurer funds escrow, payout triggers upon oracle attestation of crossing thresholds with persistence, and fallback return to insurer at expiry. This exceeds the minimal transparency requirement.
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 concise (approx. 100 words), front-loaded with the primary action, and every sentence adds meaningful detail without redundancy or fluff.
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 complexity (10 parameters, output schema present), the description adequately covers the policy creation process, including escrow, trigger conditions, and return logic. The existence of an output schema reduces the need to describe return values.
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 high-level context about the trigger mechanism but does not provide additional per-parameter semantics beyond what the input schema already describes.
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 explicitly states 'Create a parametric insurance policy', providing a specific verb and resource. It distinguishes itself from sibling tools like 'mint_attest' or 'mint_settle_policy' by clearly defining its unique purpose.
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 clearly implies when to use the tool (to create a policy with parametric conditions). While it does not explicitly list alternatives or when-not-to-use, the context of sibling tools and the detailed condition explanation provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_discoverAInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral context: no authentication required, free of charge, and returns specific fields (trust score, ratings, etc.). No contradictions.
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 two sentences, each adding significant value. The first sentence states the core purpose, and the second adds key details (free, no auth, return fields). No superfluous text.
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 that an output schema exists (context signal true) and parameters are fully documented in the schema, the description adequately covers the tool's purpose, permissions, and return structure. It lacks guidance on when not to use, but that is a minor gap.
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 each parameter has a clear description in the schema. The tool description adds no additional meaning beyond what the schema already provides, so the baseline score 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?
The description clearly states the action ('Discover trusted actors') and the resource ('MINT network'). It distinguishes from sibling tools by focusing on discovery, which is unique among mint_attest, mint_rate, etc.
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 explicitly notes 'FREE — no auth, open to any agent,' indicating it can be used freely without prerequisites. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_feedAInspect
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It highlights that the tool is 'FREE' (no cost) and lists the output fields, but does not mention rate limits, authentication requirements, or whether the data is real-time. The description adds some context beyond the schema but lacks depth on behavioral traits.
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 a single, concise sentence that efficiently communicates the tool's purpose and output. It uses a dash to enumerate fields, maintaining readability without unnecessary verbosity.
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 simplicity (one optional parameter, no nested objects, and an output schema), the description is nearly complete. It specifies the output fields and includes a note on cost ('FREE'). However, it could mention pagination behavior or whether results are sorted, but these are minor gaps.
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?
The input schema has 100% description coverage for the 'limit' parameter, so the schema itself already documents the parameter well. The tool description does not add extra semantic meaning beyond what the schema provides, meeting the baseline expectation for a well-documented parameter.
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 clearly specifies that the tool returns 'the newest attestations across the whole MINT network' and enumerates the fields returned, making the purpose unambiguous. It distinguishes itself from sibling tools like mint_attest or mint_create_cell, which are write operations, by being a read-only feed.
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 implies use for browsing recent attestations, but does not provide explicit guidance on when to use it versus alternative tools (e.g., mint_discover, mint_trust_history). No exclusions or specific context are given, so usage is implied but not thoroughly clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_join_cellAInspect
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: transfers stake, registers participant, creates TrustScore account, flips cell state. It also mentions failure scenarios. This is comprehensive.
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 concise, with no unnecessary words. It is front-loaded with the main action and uses bullet-like sentence structure for clarity.
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 complexity (one parameter), the description is complete. It explains the process, side effects, and failure conditions, and an output schema exists (though not shown).
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?
The single parameter 'cell_id' is described in the schema as 'the id of the cell to join (the same id used at creation).' The description does not add additional semantic meaning beyond this, so baseline score 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?
The description explicitly states the action ('Join an open work cell') and the resource ('work cell'), with specific details like locking stake. It clearly distinguishes from sibling tools like mint_create_cell and mint_settle_cell.
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 explains when to use the tool (to join a cell) and includes failure conditions (cell full or active). It does not explicitly state when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_rateAInspect
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool updates trust scores, is free, and has self-rating/duplicate constraints. It also explains the rater_mint_id parameter's optionality. However, it does not mention permissions, rate limits, or whether ratings can be reversed.
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 three sentences: first sentence states the core action, second lists return values, third provides constraints. No filler words; every sentence adds value.
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?
The tool has 8 parameters with schema coverage, and an output schema exists. The description covers the main function, constraints, and return fields. It lacks mention of required permissions or error cases (e.g., invalid attestation_id), but given the schema richness, it is adequate.
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% with all parameter descriptions provided. The description adds extra context: the constraint on self-rating (affects rated_mint_id and rater_mint_id) and the uniqueness rule (affects attestation_id). It also explains the return fields, which go beyond the raw 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 clearly states the verb 'rate' and the resource 'completed unit of work (an attestation)' with a scale 1–5. It also mentions updating the trust score, which differentiates it from sibling tools like mint_attest (create) and mint_register (register).
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 explicitly says 'FREE' and includes constraints like 'can't rate yourself' and 'each rater may rate a given attestation once'. However, it does not explicitly compare to alternatives or state when not to use this tool, though the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_recommendAInspect
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool updates the recommended actor's trust score, cannot self-recommend, and is FREE. It also mentions return fields. However, it does not discuss permissions, side effects beyond the score update, or any rate limits. This is decent but not exhaustive.
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 composed of four concise sentences, front-loaded with the core action. It includes constraints, effects, and return fields without unnecessary detail. Every sentence contributes meaning, making it efficient for an AI agent.
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 complexity (6 parameters, 3 required) and presence of an output schema, the description covers purpose, usage, behavioral effects, and return fields. It mentions the uniqueness constraint and self-prohibition. Missing elements like example usage or more explicit error conditions are not critical but would improve completeness.
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 baseline is 3. The description adds some value: for note it provides an example, for recommender_mint_id it clarifies when it's required ('required only if your key owns more than one'). However, most parameter descriptions are already in the schema, and the description does not significantly enhance understanding beyond that.
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 clearly states the tool's purpose: 'Recommend another actor you've worked with, in a named context, 1–5.' It also specifies the action (recommend), the resource (actor), and constraints (must have worked with them, cannot self-recommend, unique triple). This differentiates from sibling tools like mint_attest or mint_rate, which serve different 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 description provides implicit usage guidance: you should only recommend actors you've worked with, and each (you, them, context) triple must be unique. It also mentions that the tool updates the trust score, which informs when to use it. However, it does not explicitly compare to sibling tools or state when not to use it, which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_registerAInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses idempotency, return format (mint_id), and freedom. Missing operational details like network dependencies or failure modes, but covers key behavioral traits.
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?
Description is four sentences, front-loaded with the core purpose. Every sentence adds value: registration action, return value, idempotency, ordering, and cost. No wasted words.
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 7 parameters with full schema coverage and an output schema present, the description adequately covers purpose, idempotency, and interaction with sibling mint_attest. Could briefly mention integration with other siblings like mint_discover, but overall complete.
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 baseline is 3. Description does not add new parameter semantics beyond highlighting actor_type, name, and operator in the idempotency note. Minimal added value.
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 clearly states the verb 'Register' and the resource 'autonomous actor' with a specific outcome: persistent cryptographic identity on MINT network. It distinguishes from sibling mint_attest by specifying the ordering requirement.
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?
Explicitly states 'Always call this before mint_attest for a new actor', providing clear context for when to use. Lacks explicit alternatives or when-not-to-use, but idempotency implies repeated calls are safe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_settle_cellAInspect
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: distribution percentages (96% participants, 2% protocol, 2% creator), state transition (Active→Evaluating when scores provided), return of stakes, and trust score bump. This is comprehensive.
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 moderately concise, front-loading the core purpose. It uses clear formatting with bullet points for distribution. Minor redundancy could be trimmed, but overall well-structured.
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 complexity (state machine, optional scores), the description covers prerequisites, conditional behavior, and distribution. It omits error handling or edge cases (e.g., already settled cells), but is sufficient for typical use.
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%, but the description adds value by explaining that `scores` triggers an evaluate_cell transaction, participants order matters, and scores range 0–1000. This exceeds the schema's basic info.
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 clearly states the tool triggers settlement of a work cell, distributing rewards, returning stakes, and bumping trust scores. It distinguishes itself from siblings like mint_settle_policy by detailing specific actions and conditions.
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 explains when to use the tool (cell settlement) and when to include or omit scores based on the cell's state. It also notes the signer must be the cell's creator. However, it does not explicitly state when not to use this tool or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_settle_policyAInspect
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description outlines the two payout outcomes and mentions an on-chain event, but lacks details on authorization, reversibility, and failure modes. Without annotations, the description partially informs but leaves 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?
The description is compact with four sentences, each serving a purpose. It front-loads the action then explains outcomes. Minor room for better structure, but largely effective.
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?
The description covers the core settlement logic and links to attestation, but omits prerequisites, error states, and authorization. An output schema exists, so return value description is not needed, yet additional context would improve completeness.
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 baseline is 3. The description adds meaning by explaining the beneficiary's role in triggered vs expired scenarios, enriching the schema description.
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 clearly identifies the tool as triggering settlement of a parametric insurance policy, distinguishing between two scenarios (triggered or expired). It uses specific verbs and references the resource 'policy', differentiating it from siblings like mint_settle_cell.
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 explains the conditions under which settlement occurs (after oracle trigger or expiry) and links to mint_attest for attestation. It provides context on prerequisites but could be more explicit about when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_trust_compareAInspect
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the $0.05 USDC payment requirement, the two-step retry protocol, and the Bearer key bypass. Does not discuss rate limits or safety (likely read-only), but covers essential behavioral traits.
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 sentences: purpose, payment info, usage steps. Front-loaded, no redundant words, efficient structure.
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?
Covers the core two-step invocation and payment bypass. Output schema exists, so return values are omitted. Could mention error handling for failed payments, but sufficient for correct invocation.
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% with descriptions for agent_ids (2-25 MINT ids) and payment_tx (Solana signature). Description adds context: retry with same agent_ids, and payment_tx is for second call. Value added beyond schema is moderate.
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?
Clearly states the tool compares trust scores across multiple agents as a leaderboard, distinguishing it from siblings like mint_trust_score (single score) and mint_trust_history (history).
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?
Explicitly describes the two-step payment process: call without payment_tx for a 402 quote, then retry with payment_tx. Also notes that an fnet_Bearer key bypasses payment. Does not mention when not to use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_trust_historyAInspect
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses payment requirement ($0.25 USDC), retry logic, and output contents (work type, quality scores, anchor status). No contradictions, though read-only nature is implied but not stated.
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?
Four sentences, each serving a distinct purpose: purpose, cost, content, usage. Front-loaded with main action. No wasted words.
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 presence of an output schema, description adequately covers input parameters, payment flow, and output contents. No gaps for agent invocation.
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% with parameter descriptions. Description adds value beyond schema by explaining the two-step payment flow involving payment_tx and the retry-with-same-arguments pattern, which is not evident from schema alone.
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?
Clearly states the tool retrieves full attestation history for an agent, specifying time window and content. Distinguishes from siblings like mint_trust_score and mint_trust_compare by focusing on audit trail rather than scores.
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?
Provides explicit two-step payment process: first call without payment_tx to get quote, then retry with payment_tx. Also mentions alternative bypass with Bearer key. Does not explicitly contrast with sibling tools but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_trust_scoreAInspect
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). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the full burden. It discloses that the tool requires a $0.01 USDC payment, the two-call protocol involving a 402, x402 quote with memo, and the bearer key bypass. While it doesn't detail error states or return values, the core behavioral traits are well-covered.
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 moderately concise but each sentence serves a purpose: first states the core function, then explains the paid nature and protocol, finally mentions the bypass. Could potentially be tightened, but no redundant sentences.
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 paid lookup tool with an output schema (present but not shown), the description covers all essential aspects: purpose, payment mechanism, parameter usage, and authentication alternatives. The existence of the output schema reduces the need to describe return values. Minor gaps in error handling are acceptable.
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% with both parameters described. The description adds value by explaining the payment flow context: payment_tx is used only in the second call and must match the agent_id from the first call. This goes beyond the schema's mere field types.
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?
Description clearly states the tool looks up an agent's trust score from the trust graph, which is a specific verb+resource. It naturally distinguishes from sibling tools like mint_trust_compare and mint_trust_history that serve different purposes.
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?
Provides explicit step-by-step instructions: first call without payment_tx to get a 402 response, then retry with the same agent_id and payment_tx. Also mentions the bypass option with an fnet_ Bearer key. This is comprehensive guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_verifyAInspect
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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fully discloses the paid nature ($0.005 USDC), the two-step call flow, and the possibility of a 402 response. It also mentions that attestation anchoring is free. However, it does not describe the successful return value or any side effects, though an output schema exists (not shown) to cover return format.
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 concise and front-loaded with the core purpose. It packs significant procedural information into a single paragraph. While efficient, it could benefit from bullet points or clearer separation of the two-step flow for easier parsing by an AI agent.
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 complexity (paid, two-step flow, dual purpose), the description covers the essential behavioral and procedural aspects. It explains the payment flow, free attestation, and parameter requirements. The existence of an output schema compensates for missing return value details, but edge cases (e.g., payment failure beyond 402) are not addressed.
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% with adequate descriptions for all 5 parameters. The tool description adds value by explaining the role of payment_tx in the two-step payment flow, which is not in the schema's parameter description. This extra context helps the agent understand the parameter's usage beyond its type and default.
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 clearly identifies the tool's dual purpose: verifying an actor's reputation OR a single attestation's on-chain anchoring. It uses specific verbs ('verify') and distinguishes between two distinct resources ('reputation', 'attestation anchoring'). The sibling list includes related tools like mint_attest and mint_trust_score, but the description's purpose is precise enough to avoid confusion.
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 provides explicit procedural guidance: call first without payment_tx, handle a 402 response with payment instructions, then call again with payment_tx. It notes that attestation verification is free. However, it does not explicitly differentiate from siblings like mint_trust_score or mint_trust_history, leaving some ambiguity for the agent about when to use this specific verification tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!