edgex-mcp

Server Quality Checklist

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

Latest release: v0.2.8
Disambiguation5/5
Each tool targets a distinct resource and action: market data (ticker, depth, kline), account (balances, positions), order management (get_active, get_status, cancel). Even similar tools like cancel_order vs cancel_all_orders are clearly differentiated by scope.
Naming Consistency5/5
All tools follow the edgex_verb_noun pattern consistently: get_* for queries, set_leverage, place_order, cancel_order. The uniform prefix and verb usage make the tool set predictable and easy to navigate.
Tool Count4/5
With 17 tools, the server is on the higher end of the ideal range, but each tool maps to a clear trading or data function. The count is justified by the breadth of exchange operations, though slightly heavy.
Completeness4/5
Core lifecycle coverage for trading is present: market data, account info, order placement/cancellation, leverage. Minor gaps exist such as no explicit historical order/trade retrieval, but the surface is otherwise complete for active trading workflows.
Average 3.6/5 across 17 of 17 tools scored. Lowest: 2.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

Behavior2/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 of explaining behavior. It merely states 'Get candlestick/kline data' without disclosing return format, default parameters, pagination, or any side effects. It does not describe what OHLCV data looks like or whether historical data is available, leaving the agent with minimal guidance.
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 a single concise sentence, front-loads the core action, and contains no filler. Every word contributes to the purpose, making it appropriately sized for a simple data retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what the returned data represents, but it only says 'candlestick/kline data.' It also does not clarify when to use this tool versus siblings like get_ticker or get_depth, leaving gaps in understanding the tool's role in the broader toolkit.
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?
The schema descriptions cover all three parameters with clear explanations (symbol example, interval enum, count bounds and default). The description adds no additional parameter-level meaning beyond the schema, so the baseline 3 is appropriate.
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 identifies the tool as one that retrieves candlestick/kline data, which distinguishes it from sibling tools like get_ticker or get_depth. The phrase 'for technical analysis' adds context, but it does not explicitly differentiate from other market data tools, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage hint is 'for technical analysis,' which implies when the tool might be used but provides no explicit guidance on choosing it over alternatives, no prerequisites, and no examples. There is no mention of when not to use this tool or how it compares to siblings like get_ticker or get_depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only says 'Get active/pending orders,' implying a read-only operation but does not disclose any further behavioral details such as pagination, response structure, or how the optional symbol filter behaves. The agent is left with minimal transparency beyond the basic action.
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 a single concise sentence: 'Get active/pending orders.' It uses no redundant words, front-loads the verb, and is immediately clear. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description leaves out critical context. It does not explain what the response looks like, whether the symbol filter is required or how it affects results, or any edge cases like empty order lists. For a tool with only one optional parameter, the description is too incomplete to fully guide an agent.
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?
The input schema documents the optional 'symbol' parameter with the description 'Filter by symbol', providing 100% coverage. The tool description adds no extra meaning beyond the schema, but the schema itself is adequate for a simple optional filter. The baseline of 3 applies since the schema carries the semantic weight.
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 action 'Get' and the resource 'active/pending orders' with a specific scope. It distinguishes itself from sibling tools like get_order_status and get_positions by focusing on orders with active/pending statuses, though it does not explicitly compare to those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings such as get_order_status or get_positions. There are no mentions of alternative tools, prerequisites, or scenarios where this tool should be preferred, leaving the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It simply says 'Get status' without disclosing read-only behavior, error handling (e.g., order not found), or whether the full order object is returned or only the status field. This is minimal transparency.
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 a single, clear, front-loaded sentence with no wasted words. It is appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is incomplete. It does not explain return values, behavior on missing orders, or how this tool fits with siblings like edgex_get_orders. Missing key context for a complete understanding.
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% (orderId is clearly described). The description adds no additional meaning beyond the schema, but the schema already adequately documents the parameter, so 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?
The description clearly states the tool gets the status of a specific order by ID, with a specific verb and resource. It distinguishes from siblings like edgex_get_orders (which likely lists orders) by emphasizing 'specific order by ID'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as edgex_get_orders for multiple orders. The description gives no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 of behavioral disclosure. It does mention the requirement for EDGEX_ACCOUNT_ID and EDGEX_STARK_PRIVATE_KEY, which is useful. However, it does not explicitly state the read-only nature or any other side effects, though the name implies a getter.
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 a single sentence with no wasted words. It front-loads the purpose and then states the key requirement. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description states purpose and credential requirement, but does not describe the return structure or error behaviors. Given the simplicity and the fact that the description covers the core function, it is minimally viable but lacks completeness.
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 has zero parameters, so the baseline is 4. The description adds context about external credential requirements, which is helpful beyond the empty schema. This clarifies that account selection is handled via environment variables or context, not parameters.
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's action and resources: 'Get account balances, positions, and equity.' This is a specific verb and resource combination. However, it does not explicitly distinguish from the sibling edgex_get_positions, which also deals with positions, so it lacks full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It only mentions required credentials but does not explain context, exclusions, or alternatives like edgex_get_positions. No when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action (get summary) without mentioning whether data is real-time, the return format, or any other behavioral characteristics. For a read operation, this is a notable gap.
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 a single, concise sentence that conveys the core purpose without fluff. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty input schema and no output schema, the description is the sole source of information. 'Volume and trading summary' is somewhat vague—it could include price, changes, or other metrics—but it is minimally adequate for a zero-parameter summary tool.
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 tool has zero parameters, which sets a baseline of 4. The description doesn't need to explain parameters, and there are none to clarify.
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 'Get market-wide volume and trading summary' clearly states the verb (Get) and resource (market-wide volume and trading summary). It distinguishes itself from siblings like get_ticker or get_depth by emphasizing the market-wide scope, though it lacks detail on what 'summary' includes.
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 implies usage for obtaining an aggregate market overview, but provides no explicit guidance on when to use this tool versus alternatives like get_ticker or get_kline. There are no exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It notes cross-margin mode but fails to mention prerequisites, effects on existing positions, reversibility, or response behavior. This is a significant gap for a mutation tool.
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 exceptionally concise, using two short sentences. It is front-loaded with the primary action and includes only essential context about margin mode, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the absence of annotations and output schema leaves important contextual gaps. The description does not explain what happens after setting leverage, whether it affects open positions, or what the tool returns, making it incomplete for a mutation operation.
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% with both 'symbol' and 'leverage' documented. The description adds no parameter-level details beyond the schema, so the baseline of 3 applies.
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 verb 'Set' and the resource 'leverage for a contract', making the purpose unambiguous. It also adds context that EdgeX uses cross-margin mode, which helps differentiate it from other trading operations among the sibling tools.
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 implies this tool is used to set leverage, but it does not explicitly state when to use it versus alternatives or provide exclusions. Since no other sibling tool sets leverage, the usage context is clear but not explicitly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Cancel...' without mentioning side effects (e.g., irreversibility), whether only open orders can be cancelled, behavior on invalid IDs, or any response format. This is insufficient for a mutation tool.
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 a single, front-loaded sentence with no redundant words. It states exactly what the tool does without any fluff, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple one-parameter schema with complete coverage, but no output schema and no annotations. The description clearly explains the core functionality, yet leaves out information about return values, error handling, or edge cases. For a simple cancellation operation, this is minimally viable but not fully complete.
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?
The input schema already provides a complete description for the single parameter (orderIds: 'Array of order IDs to cancel'), achieving 100% schema coverage. The tool description adds no additional meaning, such as ID format or semantics beyond what the schema already states, so the 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?
The description clearly states the action ('Cancel'), the resource ('orders'), and the scope ('one or more... by ID'). This distinguishes it from sibling tools like edgex_cancel_all_orders, which cancels all orders instead of specific ones.
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 phrase 'by ID' implies that this tool should be used when you have specific order IDs to cancel, but it does not explicitly mention alternatives or exclusions. No comparative guidance is given despite the presence of edgex_cancel_all_orders as a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions the returned data (bids and asks) but omits authentication requirements, rate limits, response structure, and any read-only side-effect guarantees. The verb 'Get' implies non-mutating behavior, but that is not explicitly disclosed.
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 a single, front-loaded sentence with no filler. It immediately states the core purpose and includes the key qualifier 'bids and asks' without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and its schema is well documented, but there is no output schema and no annotations. The description does not specify the response format, the meaning of depth levels, or default behavior beyond what the schema already provides, leaving some gaps for an agent.
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% and both parameters have descriptive definitions: symbol gives examples, level defines enum choices and default. The description adds no additional parameter context, so the 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?
The description uses a specific verb ('Get') and a clear resource ('order book depth (bids and asks) for a contract'). This distinguishes it from sibling tools like ticker, kline, and funding, which serve different data purposes.
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 intended use is implied by the description: an agent should call this when it needs order book depth. However, there are no explicit when-to-use/when-not-to-use instructions and no alternatives are named, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for disclosing behavioral traits. It does not mention read-only status, authentication requirements, side effects, or return format. The dependency on balance and leverage is mentioned but without explaining how these factors influence the result or what happens if data is unavailable.
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 a single, concise sentence that front-loads the action and resource. No unnecessary words or redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify what the returned maximum order size represents (e.g., units, base vs quote asset). The description is brief and leaves ambiguity, and with no annotations to supplement context, an agent may not know how to interpret the result.
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?
The input schema has 100% coverage for the only parameter 'symbol', with an example provided. The description adds no additional meaning to this parameter, so the baseline score of 3 applies since the schema sufficiently documents it.
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's function: retrieving the maximum order size for a contract. The verb 'Get' and specific resource 'maximum order size' make it distinct from sibling get_* tools, which focus on other data like ticker, depth, or balances.
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 phrase 'given current balance and leverage' implies the tool is used to assess order capacity based on account state, but no explicit guidance is provided on when to use this tool versus alternatives. Exclusions or alternative tool references are absent, leaving usage only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the burden; it adds the aggregation behavior across exchanges but doesn't disclose auth requirements, pagination, or response format.
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?
One concise sentence, front-loaded with the action and resource, with no wasted words.
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?
For a simple getter with one parameter and no output schema, the description covers the core purpose and data scope, but lacks explicit return value details; acceptable given the low complexity.
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?
The schema fully describes the single 'symbol' parameter with examples, and the description doesn't add further semantic detail, so 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 uses the specific verb 'Get' with the resource 'long/short ratio' and specifies aggregation across exchanges, clearly distinguishing it from sibling data tools like get_ticker or get_depth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose this tool over siblings; the description doesn't mention alternatives or conditions, leaving the agent to infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal a key restriction (limit-only during market closure for stocks) and the confirmation requirement, but does not describe consequences of placing an order (e.g., funds locked, order lifecycle, potential errors) or return behavior. This is partial disclosure, not 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 two sentences, front-loaded with the core purpose, and every word earns its place. It includes a condition and a critical warning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, no output schema, no annotations) and its high-stakes nature (placing financial orders), the description is too sparse. It does not explain order type selection rationale, TP/SL interaction, expected response, failure modes, or what the user should confirm. This is a significant gap for a transaction-executing tool.
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?
The schema already provides 100% coverage for all parameters, including notes like 'required for limit orders' in the price field. The description adds no additional parameter semantics beyond the schema, so the 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?
The description clearly states the tool's function: 'Place a limit or market order.' This is a specific verb (place) with a resource (order) and distinguishes it from sibling tools that are all read/cancel/set operations. Even without the name, the description identifies the core action precisely.
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 provides explicit usage guidance: 'For stock contracts during market closure, only limit orders are allowed' and 'ALWAYS confirm with the user before calling this tool.' It gives a conditional rule for order type selection and a mandatory user confirmation step, but does not explicitly contrast with alternative tools (though no alternative order-placing tool exists among siblings).
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 disclosure burden. It adds valuable context: the sign interpretation (positive = longs pay shorts) and the cache-based behavior when symbol is omitted. However, it does not describe the return format or potential errors.
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 three short sentences, each providing distinct information. It is front-loaded with the primary purpose and does not waste words.
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 tool's simplicity and lack of output schema, the description covers the essential aspects: purpose, sign convention, and cache behavior. It omits return structure details but is largely adequate for a straightforward getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a description for the optional symbol parameter, and the tool description attempts to add cache behavior details. However, the phrase 'Omit symbol for first N contracts from cache' appears to contradict the schema's 'Omit for all,' leading to confusion about the default behavior. This undermines reliable parameter usage.
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 retrieves current and predicted funding rates, with a specific sign convention. This distinguishes it from other get_* tools like get_ticker or get_ratio. The cache behavior adds further specificity.
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 implies when to use the tool but does not explicitly contrast with alternatives like edgex_get_ratio or edgex_get_summary. The note about omitting the symbol for cached results offers a usage hint, but lacks explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the transparency burden. It discloses the empty-array return behavior when no positions exist, but does not explicitly confirm read-only status or any other behavioral traits. It adds some value beyond the raw tool name.
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 a single front-loaded sentence that directly states what the tool does and a key edge case. Every word is informative, with no 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?
For a zero-parameter read-only tool with no output schema, the description provides sufficient context: it names the return type (open positions) and the special empty-array behavior. It does not detail the position object structure, but this is acceptable given the tool's simplicity and the lack of parameters.
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 tool has zero parameters, so the schema already fully describes the surface. The description appropriately omits parameter details. Baseline 4 is assigned since no parameter explanation is required.
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 retrieves open positions and specifies the key detail of unrealized PnL. It is distinct from sibling tools like edgex_get_orders and edgex_get_balances, leaving no ambiguity about its purpose.
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 implies usage for checking current open positions and their unrealized PnL, but does not explicitly contrast with sibling tools such as edgex_get_orders or edgex_get_balances. No clear guidance on when to prefer this over alternatives is provided.
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 the cached contract list and potential subset behavior, which is significant. It also clarifies the omission behavior, but does not explicitly state read-only nature, though 'Get' implies it.
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?
A single, front-loaded sentence that efficiently communicates the tool's purpose, key data fields, and an important caveat. No wasted words; structure is exemplary.
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?
For a one-optional-parameter tool with no output schema, the description adequately covers purpose, return fields, and parameter semantics, including a notable caveat about caching. It is self-sufficient for the complexity involved.
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 schema covers the symbol parameter with examples (100% coverage), but the description adds crucial semantics: symbol is optional and omitting it returns all contracts, with a caching caveat. This goes beyond the schema's minimum.
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 gets a 24h ticker with specific fields (price, volume, open interest, funding rate). It lacks explicit differentiation from sibling tools like edgex_get_funding, which also covers funding rate, so it does not fully distinguish itself.
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?
Provides a useful parameter behavior note about omitting symbol to get all contracts, including a caching caveat. However, it does not offer guidance on when to choose this tool over alternatives such as edgex_get_funding or edgex_get_kline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral impact. It does state the destructive action ('Cancel all active orders') and the optional symbol filter, which conveys that omitting the symbol cancels all active orders. However, it does not elaborate on side effects, permissions, or confirmation requirements, leaving some gaps.
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 a single sentence that front-loads the verb and scope, with no unnecessary words. It is concise and well-structured.
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?
For a simple tool with one optional parameter and no output schema, the description fully covers the purpose, scope, and filtering behavior. The schema handles parameter details, so nothing essential is missing.
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?
The schema fully documents the 'symbol' parameter with 'Only cancel orders for this symbol,' and the description adds no new meaning beyond that. Since schema coverage is 100%, the baseline of 3 applies.
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 uses a specific verb 'Cancel' with an explicit resource and scope: 'all active orders.' It also mentions the optional filter by symbol, which clearly distinguishes this tool from the sibling edgex_cancel_order that handles single orders.
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 clearly states when to use the tool: when you need to cancel all active orders, optionally filtered by symbol. It provides clear context but does not explicitly mention alternatives such as edgex_cancel_order for single-order cancellation, so it lacks explicit exclusions.
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?
Without annotations, the description carries the burden of disclosing behavior. It clearly indicates this is a read operation ('Get') and specifies the expected return components, which is sufficient for a simple, parameterless getter. However, it does not explicitly state that the tool has no side effects or whether it makes a network call, but the simplicity mitigates the need for such detail.
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 a single, well-structured sentence that front-loads the core action ('Get current MCP environment') and then lists the specific return fields. Every word serves a purpose, and there is no unnecessary information.
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?
For a tool with zero parameters, no output schema, and low complexity, the description is complete. It clearly enumerates what the agent can expect to receive (baseUrl, testnet/mainnet, auth status), which is all the context needed to use the tool correctly. The absence of an output schema is compensated by this explicit enumeration.
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 tool has zero parameters, so the baseline score is 4. The description cannot add parameter-level meaning because there are none to describe, and the schema confirms no parameters exist.
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 gets the current MCP environment and explicitly lists the three components: baseUrl, testnet/mainnet, and auth status. This uses a specific verb ('Get') and resource ('MCP environment') and distinguishes it from sibling tools by focusing on the environment as a whole rather than individual metrics or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives, such as the closely related edgex_get_auth_status, which also returns auth status. The description does not mention exclusions, prerequisites, or contexts where this tool is preferred or avoided.
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 provided, the description carries the transparency burden. It discloses that the tool checks authentication and returns two distinct pieces of information (credential status and available tools), implying a read-only status operation. While it doesn't explicitly state 'read-only' or mention rate limits, the low-risk nature of the operation is adequately conveyed.
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 two sentences long, with the core purpose front-loaded. The usage directive 'CALL THIS FIRST' is concise and impactful, and every word adds value 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 the tool's simplicity (no parameters, no output schema), the description covers the essential aspects: purpose, when to call, and the return value. It could be more specific about the output format (e.g., whether it returns a boolean or an object), but for a zero-parameter status check, this is sufficiently 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?
This tool has zero parameters, and the schema coverage is 100% (vacuously), so the description needn't explain parameters. The baseline for no parameters is 4, and the description does not need to compensate for any missing parameter details.
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 'Check if authentication is configured,' using a specific verb and resource. It also mentions the return value (credential setup and available tools), making it distinguishably different from sibling getters like edgex_get_environment or edgex_get_ticker.
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 instructs 'CALL THIS FIRST at the start of every session,' providing clear when-to-use context. It implies this tool is a prerequisite for other operations, eliminating ambiguity about its role in the session flow.
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:

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

Score Badge

Copy to your README.md:

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

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/realnaka/edgex-mcp'

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