LLM Pulse MCP Serverofficial
A
licenseA
qualityB
maintenanceMonitors brand mentions, citations, sentiment, competitor share of voice, and GEO performance across AI search engines.
Last updated
1
MIT
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.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.7/5.0
Tool DescriptionsA
Average 4.6/5 across 4 of 4 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a distinct purpose: creating an order, cancelling it, checking its status, and fetching configuration. No overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., buy_emc, cancel_order), making them predictable.
Tool Count5/5
With 4 tools, the set is well-scoped for the specific domain of EMC-USDT swaps, covering all necessary actions without bloat.
Completeness5/5
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.
ParametersJSON Schema
| 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
ParametersJSON 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
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clarifies that the tool does NOT move funds, describes the payment flow, and idempotency behavior. It does not contradict annotations (readOnlyHint=false, etc.) and adds beyond them.
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?
The description is front-loaded with the core action and process. It is somewhat lengthy but each sentence adds value. Could be slightly more concise, but well-structured.
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 complexity (financial transaction, multiple steps), the description covers the flow, safety warnings, idempotency, and ties to siblings. Output schema exists but is not shown; still fairly 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?
Schema coverage is 100%, but the description adds meaning: amount_usdt must be from allowed denominations, idempotency_key explanation for retries, destination_emc_address format examples.
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 explicitly states 'Open an order to buy EMC with USDT' and outlines the complete process, distinguishing it from sibling tools like cancel_order, get_order_status, and get_swap_config.
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?
It advises to use get_swap_config first to pick a valid amount, explains idempotency for retries, and warns that wrong amounts are not refunded. It covers when to use but could be more explicit about when not to use.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | opaque order handle returned by buy_emc; pass it back unchanged |
Output Schema
ParametersJSON 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
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. Description adds that it errors if payment is in flight/confirmed and that payments after cancellation are not refunded. No contradiction.
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?
Three sentences, front-loaded with the core action and effect. Every sentence is essential and free of fluff.
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 the simple one-parameter input and the presence of annotations and output schema, the description fully covers usage context, prerequisites, consequences, and error scenarios.
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?
Only one parameter (token) with 100% schema coverage. The description does not add new detail beyond what the schema provides (opaque handle, from buy_emc). Baseline 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?
Clearly states it cancels an unpaid buy_emc order by token, expiring it and freeing its slot. Distinguishes from sibling get_order_status for inspection.
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 says use only before payment, warns against using after payment is in flight/confirmed, and notes that post-cancellation payments are not refunded. Provides alternative tool get_order_status 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | opaque order handle returned by buy_emc; pass it back unchanged |
Output Schema
ParametersJSON 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
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the status lifecycle, the specific returned fields (amount, EMC amount, destination address, emc_txid), and that it is used for polling. This adds meaningful context beyond annotations.
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?
Two dense sentences plus a brief note after a dash. The first sentence covers purpose and return values, the second explains usage and status progression. No superfluous 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?
Given one parameter, high schema coverage, existing annotations, and an output schema, the description fully explains when to use (polling after buy_emc), what it returns, and how statuses evolve. It also provides cancellation guidance. Completeness is excellent.
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 a clear description for the token parameter. The tool description echoes the schema's 'by its token' but adds no new meaning. Baseline 3 is appropriate as the schema already documents it well.
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 states 'Return the current status of a buy_emc order by its token', specifying the verb (return), resource (buy_emc order), and key parameter (token). It distinguishes from siblings by mentioning cancel_order for cancellation and implies buy_emc as preceding step.
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 says 'Use this to poll after buy_emc' and describes the status progression (awaiting_payment → confirmed → emc_delivered → notified). Also states 'to cancel an unpaid order use cancel_order instead', providing clear context and alternative.
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).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON 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
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds that it 'neither creates nor changes an order' and explains the support_email for manual cases, going beyond annotations.
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?
Every sentence adds value. Well-structured: purpose, field explanations, usage guidance, read-only note, support contact. No fluff.
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 zero parameters, rich annotations, and low complexity, the description fully covers what the tool does and how to use it. Output schema exists but description complements it.
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?
No parameters, so baseline is 4. Description adds value by explaining output fields, which helps in understanding the tool's result.
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?
Clearly states it returns current order denominations and fixed rate for buying EMC with USDT. It distinguishes itself from sibling buy_emc by implying it's a prerequisite.
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?
Explicitly says 'Call this first to choose a valid amount for buy_emc.' Provides clear context for when to use it relative to siblings.
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!
Related MCP Servers
- Alicense-qualityAmaintenanceProvides regulatory and compliance intelligence from free government sources, including rules, recalls, enforcement actions, and comment deadlines, classified by industry and severity.Last updatedMIT
- AlicenseAqualityAmaintenanceCompetitive intelligence platform with 24 tools. Monitor competitor pricing, content, positioning, tech stacks, and AI visibility — track how ChatGPT, Claude, and Gemini rank your brand.Last updated332MIT
- Flicense-qualityCmaintenanceEnables users to monitor and analyze competitor LinkedIn posts, extract insights, generate original post concepts, and create graphics-ready content with metadata.Last updated