Cryptair MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation5/5
Each tool has a unique, well-defined purpose: single-party certification, two-party initiation, counterparty submission, status polling, public verification, and account registration. No two tools overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., certify_document, initiate_attestation), making the API predictable and easy to navigate.
Tool Count5/5
With 6 tools, the surface is lean and focused. Each tool serves a distinct step in the attestation workflow, and there are no extraneous or redundant tools.
Completeness4/5
The tool set covers the full lifecycle of document attestation: registration, single-party certification, two-party attestation (initiate, submit, poll), and public verification. Minor gaps like bulk listing or revocation are absent but not critical for the core workflow.
Average 4.5/5 across 6 of 6 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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 it returns a specific JSON structure, explains the certification logic (exact match), mentions SHA-256 hashing before sending, and states it's public. No contradictions. It lacks info on rate limits or error cases, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, structured with bullet points for use cases and return values. Every sentence adds value, with no wasted words. The format is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, simple return type), the description covers the main functionality well. It explains the return format and logic without an output schema. It could include error handling info, but overall it is sufficiently complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter with 100% schema coverage. The description adds meaning by specifying that the file_path is an absolute path and that it is SHA-256 hashed locally before sending, which goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks for a prior Cryptair attestation on Hedera Hashgraph. It uses specific verb 'verify' and mentions a specific resource. However, it does not explicitly differentiate from the sibling tool 'check_attestation', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a list of when to use the tool (confirm counterparty claim, detect alteration, look up original transaction). It also mentions it's public and no API key required. However, it does not specify when NOT to use it or suggest alternatives to other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses public access, return fields including status enum, and that it returns hedera_tx and certificate_url. Does not mention idempotency or side effects, but as a read-only check, these are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three bullet-like USE WHEN lines, one line for return shape, one line for access. No redundant sentences. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Single-parameter tool with return shape described in text. Sibling tools provide context. No output schema, but description covers statuses. Could mention error handling or pagination, but overall sufficient for expected usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description for session_id. Description does not add meaning beyond schema ('The session ID returned by initiate_attestation' is already in schema). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Verb 'Look up' and resource 'status of an attestation session' are specific. Distinguishes from siblings like initiate_attestation (initiation) and submit_attestation (submission) by clarifying it's for checking status and retrieving results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE WHEN' list with three scenarios (polling, certificate retrieval, checking expiration/tamper) provides clear context. Notes public nature (no API key). Lacks explicit when-not-to-use or alternative tool names, but implied by sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 attest_url contains a one-time token, email triggers auto-provisioning with silent API key storage, and return values. Lacks mention of any destructive behavior but covers core behaviors well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is fairly long but well-structured with bullet points and sections. Information is front-loaded with purpose. Could be slightly more concise but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description covers return values, constraints, and behavioral details comprehensively. It provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description adds context like the role of attest_url, file_path vs document_hash choice, and email auto-provisioning, but the schema already provides clear descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it completes a two-party attestation as the counterparty, using a specific verb and resource. It distinguishes from siblings like initiate_attestation and check_attestation by focusing on the counterparty role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists three specific use cases under 'USE WHEN you want to:' and explains that no Cryptair API key is needed, guiding proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden. It explains the step-by-step workflow, the fact that the counterparty does not need an account, the return values, the 7-day expiry, and the requirement for a Cryptair API key. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a one-line summary, bulleted use cases, numbered workflow steps, return value listing, and a note on API key. It is front-loaded with the purpose and every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values and references polling via check_attestation. It covers prerequisites and the flow adequately. Minor omission: no mention of what happens on timeout or failure, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters with 100% coverage. The description adds value by instructing to hash locally and not send file content for document_hash, and explaining counterparty_name is shown on the certificate. Metadata is mentioned as optional. The added context justifies a score above the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Start a TWO-PARTY attestation' and explains the tool's specific role in the workflow. It distinguishes from siblings like certify_document and check_attestation by detailing the initiation process and referencing polling via check_attestation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists explicit use cases ('Get a counterparty to formally acknowledge receipt', 'Lock in a mutual agreement') and describes the workflow. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: self-service with no email verification, immediate API key generation and persistence to ~/.cryptair/credentials.json, transparent future use (key not returned), and idempotency (existing account reuses key). This fully informs the agent of side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear introductory sentence, a 'USE WHEN' block, behavioral notes, and return value format. Every sentence adds essential information without redundancy. It is front-loaded with purpose and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is complete. It explains output (returns object with registered, email, account_status), side effects (persistence, no key returned), idempotency, and usage context. The agent has all needed information to decide and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description adds value by explaining the email's purpose for notifications and certificates, and provides context for defaults like 'exploring' and 'MCP integration'. While schema already describes parameters, the description enriches understanding, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Cryptair account for the agent and stores the API key locally. It specifies the action (create) and resource (account), and distinguishes from sibling tools like certify_document and initiate_attestation by focusing on registration and authentication setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'USE WHEN' section that explicitly tells the agent when to use this tool: before calling certify_document or initiate_attestation when no API key is configured, or when the user wants to start using Cryptair without manual account creation. This provides clear guidance on alternatives and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it is a single-party write operation to Hedera Hashgraph, hashes file locally (not sending file), and returns specific data (hash, transaction ID, timestamp, explorer URL). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with opening statement, bulleted use cases, behavioral details, return values, and prerequisites. Every sentence is informative; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely covers purpose, usage, behavior, parameters, and return values despite no output schema. Sibling tools are listed for context. All necessary information is present for an AI agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value: for file_path explains local SHA-256 hashing (file not sent), and for notify_email explains purpose (PDF certificate for human counterparty). Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a clear verb-phrase 'Create a tamper-evident, on-chain proof' specifying action and resource. Use cases listed explicitly. Distinguishes from sibling tool initiate_attestation by noting single-party vs. two-party operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (lock in contract, prove deliverable, anchor digital artifact) and when not to use (two-party agreements, directing to initiate_attestation). Also mentions prerequisite: requires Cryptair API key, with fallback to register_agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cryptair-mcp-server MCP server](https://glama.ai/mcp/servers/Syronius/cryptair-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Syronius/cryptair-mcp-server)

Score Badge

Copy to your README.md:

[![cryptair-mcp-server MCP server](https://glama.ai/mcp/servers/Syronius/cryptair-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Syronius/cryptair-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Syronius/cryptair-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server