Emercoin swap
Server Details
Emercoin swap exposes a keyless MCP exchanger at https://swap.emercoin.com/mcp (Streamable HTTP) so an AI agent holding USDT can buy EMC programmatically — no API key, no account, no callback. Tools: get_swap_config, buy_emc, get_order_status, cancel_order. Call buy_emc with an amount and your EMC address, pay the exact returned figure to the deposit address, then poll by token until delivered. Part of the broader effort to use Emercoin as an identity + memory layer for AI agents.
- 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.6/5 across 4 of 4 tools scored.
Each tool has a distinct purpose: creating an order, cancelling it, checking its status, and fetching configuration. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., buy_emc, cancel_order), making them predictable.
With 4 tools, the set is well-scoped for the specific domain of EMC-USDT swaps, covering all necessary actions without bloat.
The tools cover the full lifecycle: get configuration, create an order, check status, and cancel before payment. No obvious missing operations for this narrow domain.
Available Tools
4 toolsbuy_emcBuy EMC with USDT (open an order)AInspect
Open an order to buy EMC with USDT (TRC20) and get back a shared TRON
deposit_address plus the EXACT amount_usdt to send. This does NOT move funds:
you then transfer that exact figure (it is your order's matching tag) to the
deposit address; on confirmed payment, EMC (amount_usdt × rate) is delivered to
your address automatically. Keep the returned token and poll get_order_status
until 'notified'; to abandon before paying, call cancel_order. One-way — a wrong
amount cannot be matched and is NOT refunded. By default each call opens a NEW
order; pass a stable idempotency_key to make retries return the same order. Use
get_swap_config first to pick a valid amount.
| Name | Required | Description | Default |
|---|---|---|---|
| amount_usdt | Yes | USDT to pay; must be one of the allowed denominations from get_swap_config (currently 5 or 10) | |
| idempotency_key | No | optional: a stable string you choose; retrying buy_emc with the same key + address + amount returns the SAME order instead of opening a new one (use it so a retry after a timeout doesn't create a duplicate) | |
| destination_emc_address | Yes | your EMC address to receive EMC (legacy 'E…' or bech32 'em1…') |
Output Schema
| Name | Required | Description |
|---|---|---|
| token | Yes | opaque handle to poll this order |
| status | Yes | |
| order_id | Yes | |
| emc_amount | Yes | |
| expires_at | Yes | |
| amount_usdt | Yes | EXACT amount to send — pay this figure |
| deposit_address | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide hints but description adds critical behaviors: does NOT move funds (despite openWorldHint), one-way nature with no refund for wrong amount, default new order behavior, and idempotency key usage. Contradicts none.
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?
Moderately long but well-structured, front-loading purpose and adding details in logical order. No redundant sentences, but could be slightly trimmed.
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 output schema existence and sibling references, description covers the multi-step process (payment, delivery, polling) completely. References get_swap_config for valid amounts and get_order_status for status checks.
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. Description adds context by connecting parameters to the workflow (e.g., 'EXACT amount_usdt to send'), but does not significantly extend 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?
The description clearly states the verb ('open an order'), resource (buy EMC with USDT), and immediate output (deposit_address and amount_usdt). It distinguishes from siblings (cancel_order, get_order_status, get_swap_config) by explaining the workflow.
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 when-to-use: after get_swap_config for valid amounts, before transferring payment. When-not: wrong amount not refunded, one-way. Alternatives: poll get_order_status for status, cancel_order to abandon. Idempotency guidance for retries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_orderCancel an unpaid EMC orderADestructiveInspect
Cancel a still-unpaid buy_emc order by its token, expiring it now and freeing
its slot ahead of the TTL. Use this only before you pay; once a payment is in
flight or confirmed it is too late and this errors. A payment sent after
cancellation matches nothing and is NOT refunded. To only inspect an order without
changing it, use get_order_status.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | opaque order handle returned by buy_emc; pass it back unchanged |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| emc_txid | No | |
| order_id | Yes | human-quotable order number (DB id) |
| emc_amount | Yes | |
| expires_at | Yes | |
| amount_usdt | Yes | |
| deposit_address | Yes | |
| destination_emc_address | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses effects beyond annotations: expiring order, freeing slot, error if payment in flight, no refund for post-cancellation payments. Adds context to destructiveHint.
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, front-loaded with main action and effect, no fluff. Each sentence provides necessary information.
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 low complexity, full annotations, and presence of output schema, the description is complete—covers timing, errors, side effects, and alternatives.
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 covers 100% with clear description; description only briefly mentions token, adding minimal extra semantic value 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?
Clearly states action (cancel) and resource (unpaid buy_emc order). Distinguishes from sibling get_order_status by specifying inspection as alternative.
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 (before payment) and when not to (after payment, with consequences). Provides alternative tool for inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_order_statusGet EMC order statusARead-onlyIdempotentInspect
Return the current status of a buy_emc order by its token: the status, the
exact amount, the EMC amount and destination address, and the emc_txid once
delivered. Use this to poll after buy_emc — status progresses awaiting_payment →
confirmed → emc_delivered → notified (done). Read-only; to cancel an unpaid order
use cancel_order instead.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | opaque order handle returned by buy_emc; pass it back unchanged |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| emc_txid | No | |
| order_id | Yes | human-quotable order number (DB id) |
| emc_amount | Yes | |
| expires_at | Yes | |
| amount_usdt | Yes | |
| deposit_address | Yes | |
| destination_emc_address | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds behavioral context by detailing the status lifecycle (awaiting_payment → confirmed → emc_delivered → notified), which is valuable beyond the annotations.
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, front-loading the main purpose, then providing details on what is returned and usage context. Every sentence adds value with 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 both input and output schemas, the description covers the input parameter, return values, status progression, and usage pattern (polling after buy_emc). It is fully complete for this tool's complexity.
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 the schema already fully describes the token parameter. The description does not add new parameter information beyond what the schema provides, so 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 it returns the current status of a buy_emc order by token, listing specific returned fields. It distinguishes from siblings by explicitly mentioning cancel_order for cancellations.
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 to use this to poll after buy_emc and provides the status progression. It also directs to cancel_order for cancellation, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_swap_configGet EMC swap limits and rateARead-onlyIdempotentInspect
Return the current order denominations and fixed rate for buying EMC with USDT.
allowed_amounts is the exact set of USDT values buy_emc accepts (fixed
denominations, not a free range) — pick one of these; min_usdt/max_usdt are its
bounds and emc_per_usdt is the rate (EMC you receive = amount_usdt × emc_per_usdt).
Call this first to choose a valid amount for buy_emc. Read-only — it neither creates
nor changes an order. support_email is the operator contact for manual cases
(e.g. an order on aml_hold or a late/mismatched payment).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| max_usdt | Yes | |
| min_usdt | Yes | |
| emc_per_usdt | Yes | |
| support_email | No | operator contact for manual cases |
| allowed_amounts | No | the fixed USDT denominations a buyer may pick |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description reinforces 'Read-only — it neither creates nor changes an order', and adds valuable context about the fields (allowed_amounts, min_usdt, max_usdt, emc_per_usdt, support_email) and their role in the buy flow.
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 paragraph with clear sentences. It front-loads the primary purpose, then explains fields. The inclusion of 'support_email' is slightly extraneous but does not significantly harm conciseness.
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 input parameters and a likely rich output schema, the description fully explains the output fields (allowed_amounts, min_usdt, max_usdt, emc_per_usdt, support_email), their semantics, and how to use them in conjunction with 'buy_emc'. Annotations cover safety aspects completely.
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?
Tool has zero parameters, baseline is 4. No additional parameter semantics needed.
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 returns 'current order denominations and fixed rate for buying EMC with USDT', using specific verb 'Return' and resource language. It differentiates from sibling 'buy_emc' by positioning this as a prerequisite 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?
The description explicitly says 'Call this first to choose a valid amount for buy_emc', which indicates when to use the tool. However, it does not provide explicit when-not or alternative tools beyond the implied sequence.
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!