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.2/5 across 6 of 6 tools scored.
Each tool has a unique and clearly defined purpose: registering actors, attesting work, rating attestations, recommending actors, discovering trusted actors, and verifying trust profiles. There is no overlap or ambiguity.
All tools follow the consistent verb_noun pattern with the 'mint_' prefix (e.g., mint_register, mint_attest). The naming is uniform and predictable.
With 6 tools covering registration, attestation, rating, recommendation, discovery, and verification, the set is well-scoped for a work attestation protocol. No tool feels excessive or missing.
The tool set covers the core lifecycle: identity registration, work attestation, trust updates via ratings and recommendations, and discovery/verification. Minor gaps like attestation revocation or dispute resolution are absent but the surface is sufficient for the stated purpose.
Available Tools
6 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.
Returns attestation_id, data_hash (off-chain proof), tx_signature with a Solscan verify_url, the new trust_score, and the reward minted. Always surface the verify_url so the caller can confirm on-chain. PRICING: 2¢.
| 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. | |
| 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?
With no annotations, the description fully discloses that the tool creates an on-chain record, updates trust, returns verification details and pricing (2¢). This covers core behavioral traits, though it omits permission or rollback info.
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 efficient sentences that front-load the action and output. Every part adds value, including the pricing note.
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 essential purpose, return values, and pricing. With an output schema present, the return details are sufficiently explained. Missing usage guidelines slightly reduce 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% with detailed descriptions for all 7 parameters. The description adds no additional parameter semantics beyond what is already in the schema, so a 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?
The description clearly states the tool attests completed work, anchoring a record on Solana and updating trust. It uses a specific verb and resource, and the context of sibling tools (mint_register, mint_verify) makes the distinction apparent.
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 guidance on when to use this tool versus alternatives like mint_register or mint_verify. The description only mentions surfacing the verify_url, but does not explain conditions or exclusions.
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_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_verifyAInspect
Look up an actor's trust profile: identity, trust score, total verified attestations, work-type breakdown, and recent on-chain attestations. FREE — reputation queries are never gated.
Provide EITHER mint_id directly, OR actor_name (optionally actor_type). NOTE: trust-read is rolling out; until it lands trust_score / total_attestations come back as "pending" rather than fabricated.
| 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. |
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 discloses that the trust-read feature is rolling out and that trust_score and total_attestations may return 'pending'. It also clearly states the tool is free and ungated, providing transparency on usage constraints.
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 well-structured: a clear first sentence defining purpose, followed by actionable usage instructions and an important behavioral note. 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 presence of an output schema (context signal), the description adequately covers input constraints and a behavioral nuance. No additional information about return values is 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?
The description adds the crucial constraint of mutual exclusivity between mint_id and actor_name, which is not encoded in the schema. This clarifies a key usage rule beyond the parameter descriptions.
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 looks up an actor's trust profile and lists specific fields (identity, trust score, total verified attestations, etc.), distinguishing it from sibling tools like mint_attest and mint_discover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies how to identify the actor (mint_id or actor_name with optional actor_type) and mentions that reputation queries are free. It does not explicitly compare with siblings but implies when to use based on purpose.
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!