Allows AI agents to certify documents, verify attestations, and initiate two-party agreements with on-chain receipts on Hedera Hashgraph.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Cryptair MCP Server Certify ~/Documents/contract.pdf to get a timestamped receipt."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Cryptographic attestation for AI agents, exposed as native MCP tools.
Lets any MCP-capable agent (Claude Desktop, Cursor, Cline, Windsurf, Zed, …) prove agreements, certify documents, and verify counterparty claims with on-chain receipts on Hedera Hashgraph. Works zero-config out of the box: agents can self-register and start using attestation immediately, with no email verification or human-in-the-loop signup.
Cryptair lets two agents (or an agent and a human) prove they agreed on the same digital artifact at a specific moment. Every confirmed agreement is written as a SHA-256 hash to Hedera Hashgraph, producing a permanent, third-party-verifiable receipt.
This MCP server exposes six tools that map cleanly to how agents think:
Tool | When to call |
| "I want to prove this file existed at this moment." |
| "Has this document been attested before? Is it tampered?" |
| "I want my counterparty to confirm they have the same document I do." |
| "I received an attestation link from someone — confirm I have the matching file." |
| "What's the status of this attestation session?" |
| "Create a Cryptair account for me so I can authenticate." |
Related MCP server: DocImprint
npm install -g @cryptair/mcp-serverOr run directly via npx (no install needed):
npx -y @cryptair/mcp-serverEdit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"cryptair": {
"command": "npx",
"args": ["-y", "@cryptair/mcp-server"]
}
}
}Edit ~/.cursor/mcp.json:
{
"mcpServers": {
"cryptair": {
"command": "npx",
"args": ["-y", "@cryptair/mcp-server"]
}
}
}All MCP-capable clients use the same config shape. Point them at npx -y @cryptair/mcp-server.
If you already have a Cryptair API key, you can supply it via env so the agent skips registration:
{
"mcpServers": {
"cryptair": {
"command": "npx",
"args": ["-y", "@cryptair/mcp-server"],
"env": {
"CRYPTAIR_API_KEY": "ctr_live_..."
}
}
}
}Otherwise, the agent will call register_agent the first time it needs authentication, and the API key is silently stored at ~/.cryptair/credentials.json for future use.
After installing, try prompts like:
"Certify the contents of
~/Documents/proposal-v3.pdfso we have a timestamped receipt."
"Send
~/Documents/contract.pdfto Acme Corp and get them to formally acknowledge receipt — generate the link."
"Acme sent me this Cryptair link:
https://www.cryptair.io/attest/abc...?token=xyz. Confirm~/Downloads/contract.pdfmatches what they sent."
"What's the status of attestation session
abc-123?"
The agent will pick the right tool and handle credential bootstrapping automatically.
Single-party (certify_document)
The MCP server hashes the file locally with SHA-256.
The hash is sent to Cryptair, which writes it to a Hedera Consensus Service topic.
You get back a Hedera transaction ID, consensus timestamp, and a public certificate URL.
Anyone can verify by re-hashing the file and calling verify_document — the file content never has to leave your machine.
Two-party (initiate_attestation + submit_attestation)
Agent A initiates with a document hash and counterparty name. Cryptair returns a shareable URL.
Agent A sends the URL to Agent B via any channel (email, Slack, etc.).
Agent B opens the URL and submits the file they have. Their MCP server hashes it locally.
Cryptair compares hashes server-side:
Match → both parties' agreement is written to Hedera. Permanent record.
Mismatch → tamper event is written to Hedera. Both parties are notified.
Agent B does not need a Cryptair account to participate. If Agent B supplies an email when submitting, an account is auto-provisioned for them and the API key is silently persisted by their MCP server — so they can initiate their own attestations later without any signup friction.
This server is cross-vendor by design. Anthropic Skills are Claude-only; MCP works across Claude Desktop, Cursor, Cline, Windsurf, Zed, and any future MCP-capable client. One install, every agent ecosystem.
Variable | Purpose | Default |
| Pre-configured API key. Skips | (none) |
| Email used for | (none) |
| API base URL. Override for self-hosted or staging. |
|
git clone https://github.com/Syronius/cryptair-mcp-server
cd mcp-server
npm install
npm run build
npm startThe server speaks JSON-RPC over stdio. To test manually, send tools/list to confirm all six tools are registered.
The Cryptair free tier currently lets every account originate a small number of attestations per month. Counterparty completion (submit_attestation) is always free. Heavy users can top up with prepaid credits — see cryptair.io/pricing for details.
MIT
Create a tamper-evident, on-chain proof that a document exists in this exact state right now.
USE WHEN you want to:
Lock in a contract, proposal, or agreement at a specific moment
Prove a deliverable existed before a deadline
Anchor a code commit, report, or any digital artifact to an immutable timestamp
Generate a receipt that anyone can verify (no Cryptair account required to verify)
This is a SINGLE-PARTY operation. It writes a SHA-256 hash of the file to Hedera Hashgraph. For two-party agreements where both sides must confirm a matching document, use initiate_attestation instead.
Returns: SHA-256 hash, Hedera transaction ID, consensus timestamp, and a HashScan explorer URL anyone can open to independently verify the on-chain record.
Requires a Cryptair API key. If none is configured, call register_agent first.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the file to certify. SHA-256 hashed locally before sending. | |
| notify_email | No | Optional. If set, Cryptair emails a PDF certificate to this address. Useful when a human counterparty needs the receipt. |
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.
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.
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.
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.
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.
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.
Look up the current status of an attestation session.
USE WHEN you want to:
Poll whether the counterparty has completed an attestation you initiated
Retrieve the certificate URL after certification
Check whether a session has expired or been tampered
Returns: { status: 'pending' | 'certified' | 'tampered', hedera_tx, certificate_url, expires_at, ... }
This endpoint is public — no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID returned by initiate_attestation. |
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.
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.
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.
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.
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.
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.
Start a TWO-PARTY attestation. Use when you need both sides of an agreement to confirm a matching document.
USE WHEN you want to:
Get a counterparty (another agent or a human) to formally acknowledge receipt of a contract, proposal, or deliverable
Lock in a mutual agreement that's only valid if both sides see the same content
Create an audit-grade record that two parties agreed on this exact document
How it works:
You initiate with a document hash. Cryptair returns a shareable URL.
You send the URL to your counterparty (out of band — email, Slack, etc.).
They open it, submit the document they have, and Cryptair compares hashes.
If hashes match: certified on Hedera. If not: tamper recorded on Hedera.
The counterparty does NOT need a Cryptair account. They can complete for free.
Returns: session_id, attest_url (give this to the counterparty), expires_at (7 days). Poll with check_attestation to see when the counterparty completes.
Requires a Cryptair API key. Call register_agent first if you don't have one.
| Name | Required | Description | Default |
|---|---|---|---|
| metadata | No | Optional. Arbitrary JSON object stored with the session (e.g., contract type, reference IDs). | |
| document_hash | Yes | 64-character lowercase hex SHA-256 of the document. Hash locally first; do not send the file content. | |
| counterparty_name | Yes | Human-readable name of the counterparty (e.g., 'Acme Corp', 'jane@example.com'). Shown on the certificate. Max 256 chars. |
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.
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.
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.
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.
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.
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.
Create a Cryptair account for this agent and store the API key locally so future tool calls are authenticated.
USE WHEN:
You're about to call certify_document or initiate_attestation and there is no API key configured
The user installed the Cryptair MCP server and wants to start using it without manually creating an account
Self-service: no email verification, no magic link, no human-in-the-loop. The API key is generated immediately and persisted to ~/.cryptair/credentials.json. The key is NOT returned to you — future tool calls will use it transparently.
Returns: { registered: true, email, account_status } If an account already exists for this email, the existing key is reused (no duplicate accounts).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email for the account. Used as the agent identity. Welcome notifications and certificates may be sent here. | ||
| company | No | Optional. Company or organization name. | |
| framework | No | Agent framework being used. Default: custom (suitable for MCP-based agents). | custom |
| planned_use | No | Primary use case. Default: exploring (good choice if unsure or for first-time setup). | exploring |
| what_building | No | Free-text description of what this agent is building. Helps Cryptair understand usage patterns. Default: 'MCP integration'. | MCP integration |
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.
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.
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.
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.
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.
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.
Complete a two-party attestation as the COUNTERPARTY. You received an attest_url from someone who initiated.
USE WHEN you want to:
Confirm that you have the same document an initiator claimed to send you
Acknowledge an agreement, proposal, or deliverable on-chain
Detect tampering — if the document you received differs from what was initiated, this records a tamper event
You do NOT need a Cryptair API key to submit. The attest_url contains a one-time token that authorizes you.
If you supply an email, Cryptair will auto-provision a Cryptair account for you (no signup form, no verification step). The MCP server will silently store the API key locally so you can initiate your own attestations later.
Returns: { status: 'certified' | 'tampered', hedera_transaction_id, certificate_url }
'certified' = hashes matched, agreement recorded on Hedera
'tampered' = hashes did not match, tamper event recorded on Hedera
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional. If supplied and you don't have a Cryptair account yet, one will be auto-provisioned for you and stored locally. Recommended for agents that may want to initiate their own attestations later. | ||
| file_path | No | Absolute path to the file you received. Will be SHA-256 hashed locally. Provide this OR document_hash. | |
| attest_url | Yes | The full URL the initiator sent you (e.g. https://www.cryptair.io/attest/<id>?token=<jwt>). | |
| document_hash | No | 64-character hex SHA-256 of the document, if you already have it. Provide this OR file_path. |
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.
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.
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.
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.
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.
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.
Check whether a document has a prior Cryptair attestation on Hedera Hashgraph.
USE WHEN you want to:
Confirm a counterparty's claim that a document was certified
Detect whether a file has been altered since it was attested
Look up the original Hedera transaction for a given file
This is PUBLIC — no API key required. Anyone can verify any document.
Returns: { certified: bool, hash, attestations: [{ transactionId, consensusTimestamp }] } If the file matches an existing attestation exactly, certified=true and the original transaction is returned. If not, certified=false (either the file was never attested, or it has been modified since).
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the file to verify. SHA-256 hashed locally before sending. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1certify_documentcheck_attestationinitiate_attestationregister_agentsubmit_attestationverify_documentEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Issue signed receipts for AI agent actions; verify any receipt offline - free, no account.
Privacy-first document verification anchored to the public ledger.
Verified memory for AI agents. Signed assertions, billing attestation, session continuity.
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
