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.7/5 across 4 of 4 tools scored.
Each tool targets a distinct action: buying, canceling, checking status, and fetching config. There is no overlap in their purposes.
All tool names follow a consistent verb_noun pattern in snake_case. The naming is predictable and unambiguous.
With 4 tools, the server provides a focused and essential set for a swap service: configure, create, inspect, and cancel orders. This is well-scoped.
The tool set covers the complete lifecycle of a swap order: configuration, creation, status polling, and cancellation. There are no missing operations for the stated purpose.
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 within min/max from get_swap_config | |
| 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 indicate write operation and non-idempotent nature; description adds critical behavioral details: no funds moved, one-way (wrong amount not refunded), new order by default, and idempotency_key effect.
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 relatively long but every sentence is informative. Front-loaded with main action and result. Could be slightly tighter but no unnecessary repetition.
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?
Thoroughly explains the entire workflow: prerequisites (get_swap_config), what to do after (transfer exact amount, poll status, cancel if needed), and cautions about one-way nature. Covers all key aspects for a trading tool.
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 all 3 parameters fully; description reinforces amount constraint, explains idempotency_key purpose, and mentions address format. Adds slight 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?
Description clearly states the tool opens an order to buy EMC with USDT and returns deposit address and exact amount. It distinguishes from siblings by mentioning get_swap_config, cancel_order, and get_order_status.
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 tells when to use: after get_swap_config, and that this does not move funds. Provides next steps (transfer, poll, cancel) and alternatives (cancel_order for abandoning before payment, idempotency_key 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 limits and fixed rate for buying EMC with USDT:
min/max USDT per order and emc_per_usdt (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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds that neither creates nor changes an order, explains the rate calculation (EMC = amount_usdt × emc_per_usdt), and mentions support_email for manual cases. 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?
Three sentences: first states purpose and key outputs, second gives usage guidance, third adds extra context. No redundancy, each sentence earns its place.
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?
Tool has no params and has an output schema. Description explains the return values enough to choose a valid amount for buy_emc, plus extra context about support_email. Fully complete for this simple tool.
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?
No parameters exist, so schema coverage is 100%. Description adds meaning by explaining the output (min/max, rate) and calculation, which is beyond the schema. Baseline 4 for zero params.
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 limits and fixed rate for buying EMC with USDT, specifying exact outputs (min/max USDT per order, emc_per_usdt) and distinguishing itself by recommending it as a prerequisite for buy_emc.
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 instructs to call this first to choose a valid amount for buy_emc. Also notes it is read-only and does not create/change orders, helping avoid misuse. Lacks explicit 'when not to use' but sufficient for context.
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!