AI Trading Co-Pilot MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Each tool targets a distinct resource/action (market data, account, orders, AI agents, rules, skills, prompts). The only potential confusion is between get_ticker and get_market_data, but the latter is derivatives-specific and the former covers all instruments. Overall clear separation.
Naming Consistency5/5
All tools share the okx_ prefix and use verb_noun (or verb_adj_noun) structure consistently, e.g., get_candles, place_order, list_rules, update_prompt. The single exception is technical_analysis which lacks a verb but is still readable. Pattern is predictable and easy to navigate.
Tool Count4/5
19 tools is on the heavier side but justified by the breadth of the domain: market data, account management, trading execution, AI agents, rules, skills, and configuration. Each tool maps to a distinct feature, so the count is appropriate for a comprehensive trading copilot.
Completeness4/5
Core trading lifecycle is covered: market data, analysis, balance, positions, place/close orders. The rule-based risk system and AI agent customization add depth. Missing order history and cancel order, but these are secondary gaps that don't break the core workflow.
Average 3.8/5 across 19 of 19 tools scored.
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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 full responsibility for disclosing behavioral traits. It mentions a limit of 300 candles but does not clarify read-only status, return format, ordering, or any rate limits. 'Fetch' implies read-only, but the description lacks explicit caveats or additional context.
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 concise sentences with no fluff. Every word contributes: the action, the resource, the use case, and the return cap. It is well-structured and immediately readable.
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 should describe the return structure and clarify the meaning of instType and instrument. It only states 'OHLCV candle data' and the maximum count, leaving the agent to guess the exact fields, ordering, and instrument semantics. This is insufficient for a tool with four parameters.
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?
Schema coverage is only 50%, with instType and instrument lacking descriptions. The description adds no detail about these parameters and merely restates the limit maximum already present in the schema. It fails to compensate for the undocumented parameters, providing minimal added meaning.
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 'Fetch' and resource 'OHLCV candle data' with a clear purpose 'for chart analysis'. This distinguishes it from sibling tools like okx_get_ticker and okx_technical_analysis, which target different data types or analyses.
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 hints at usage context with 'for chart analysis' but does not explicitly state when to use this tool over alternatives like okx_get_market_data or okx_get_ticker. There is no mention of exclusions or when not to use it, leaving only implied guidance.
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 of behavioral disclosure. It mentions the API key requirement but fails to disclose that the optional instType parameter (default SWAP) filters the results, contradicting the 'all open positions' phrasing. It also doesn't clarify scope (e.g., authenticated account) or any response limitations. This is a notable omission for a read 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 concise sentence that front-loads the primary action and key outputs. Every word adds value, and there is no redundant phrasing or filler. 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?
The tool is relatively simple (one optional parameter, no output schema, no annotations), but the description omits important contextual details such as the default filter behavior (SWAP) and whether 'all' means all for the authenticated account. The auth requirement is helpful, but the missing filter disclosure leaves the description incomplete for an agent making decisions.
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 only parameter (instType) with a description ('Position type') and enum values, so baseline is 3. The tool description adds no extra semantic detail beyond the schema; the meaning of 'SWAP' vs 'SPOT' is implied but not explained, which is acceptable given the schema coverage.
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 action ('Get all open positions') and includes specific data points (P&L, leverage, margin ratio) that distinguish it from siblings like okx_get_balance or okx_close_position. The verb is specific and the resource is well-defined.
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 given on when to use this tool versus alternatives. The only additional context is the auth requirement ('Requires OKX API key'), which is a prerequisite, not a usage guideline. There is no mention of scenarios where this tool is preferred over other OKX tools.
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 must disclose behavioral traits itself. It only states that it 'runs' the agent and returns a report, with no mention of side effects, permissions, costs, or limitations. This is insufficient for a tool that executes AI analysis agents.
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 with no fluff, front-loading the core action and then adding a benefit and output. Every sentence contributes value.
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?
For a tool with four parameters, a nested object, and no output schema, the description is too sparse. It omits how to construct enabledSkills, what instType/instrument refer to, and what the report contains. The lack of annotations further increases the need for a richer description.
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 description adds meaning by listing the three agent types (macro, technical, risk) which aligns with the agentId enum, but it does not explain instType, instrument, or enabledSkills. With only 50% schema description coverage, the description fails to compensate for the undocumented parameters.
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 'Run a single AI analysis agent' with the agent types parenthetically listed. It contrasts with 'full co-pilot', distinguishing it from the sibling okx_run_copilot. This satisfies a specific verb+resource+scope.
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 'Faster than full co-pilot' provides some context for when to prefer this tool over okx_run_copilot, but it does not specify when not to use it or mention alternative tools like okx_technical_analysis. The guidance is implied rather than explicit.
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 of behavioral disclosure. It mentions the scope (perpetual contracts) but does not state whether this is read-only, what the response format looks like, or any limitations or prerequisites. For a market data tool, more detail would be expected.
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 names the action and all key data points without any wasted words. It is well-structured and front-loaded.
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?
With one optional parameter, no output schema, and no annotations, the description is reasonably complete but does not explain whether all three data types are returned in a single response, nor does it mention the optionality/default of the instrument parameter. It falls short of full completeness but is adequate for a simple market data fetch.
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 100% coverage of the one parameter with a clear description and default value. The tool description adds no additional parameter semantics beyond what the schema specifies, 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 gets derivatives market data and specifies the exact data types: Open Interest, Long/Short Ratio, and Funding Rate, and scopes it to perpetual contracts. This distinguishes it from sibling tools like okx_get_ticker or okx_get_candles.
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 (when you need derivatives market data) but does not explicitly state when not to use it or provide alternatives. There is no mention of comparing with okx_get_ticker for spot data or other tools, so guidance is minimal.
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. It only discloses that configuration is saved persistently, but fails to mention whether the operation overwrites existing skills, whether it is destructive, or any permission requirements. 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 a single, concise sentence with an additional short clause. Every word earns its place, and the key information (purpose and persistence) is front-loaded without any fluff.
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 (2 params, complete schema coverage, no output schema), the description provides sufficient context for an agent to select and invoke it. It clearly states the purpose and persistence, and the schema covers the parameters. However, it lacks some behavioral details like overwrite semantics, but overall it is adequate.
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 agentId and enabledSkills clearly described in the schema. The description adds no additional parameter semantics beyond what is already structured, 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 ('enable or disable') and a clear resource ('specific skills for specific agents'), distinguishing it from sibling tools like okx_list_skills. It clearly states what the tool does without ambiguity.
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 (when you need to enable/disable skills) but provides no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It is not misleading but leaves the agent to infer 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 provided, so the description carries the full burden. It discloses the dependency on okx_run_copilot but does not clarify whether this tool executes orders, mutates state, or has other side effects. Given the phrase 'executable trading plan,' this omission is significant.
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 primary action, and every sentence adds necessary context. There is no filler or 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?
There is no output schema and no annotations. The description explains the prerequisite but does not describe return values, side effects, or how the optional instrument parameter should be used. For a tool with nested objects and a required input, these gaps leave the agent under-informed.
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 coPilotResult parameter is described in the schema as 'Result from okx_run_copilot,' and the description reinforces that. However, the optional instrument parameter lacks description and the description does not add meaningful details beyond what the schema already provides. With 50% schema coverage, this is adequate but not compensatory.
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 it generates a detailed executable trading plan from a co-pilot analysis result, using a specific verb and resource. It is easily distinguished from siblings like okx_run_copilot and okx_place_order.
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 explicitly instructs to run okx_run_copilot first and then pass the analysis result, providing clear usage context and a prerequisite. It does not mention alternatives or when not to use this tool, so it falls short of a 5.
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 must carry full behavioral disclosure. It discloses that the tool returns current price, 24h change, and volume, which is the core behavior, but it does not mention additional context such as rate limits, error handling, or whether it supports both spot and swap despite the schema indicating instType. This is adequate but not rich.
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 key outputs (current price, 24h change, volume) and provides instrument examples. There is no filler or redundancy, making it highly efficient.
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 tool with only two parameters and no output schema, the description is reasonably complete. It states the purpose, the data returned, and gives instrument examples. It does not enumerate all return fields, but the primary ones are covered, and the schema handles parameter details, so the description is sufficient for invocation.
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 with descriptions for both instType ('SWAP = perpetual futures, SPOT = spot') and instrument ('Trading pair, e.g. BTC-USDT, ETH-USDT, SOL-USDT'). The description adds example instruments (OKB-USDT) that are not in the schema, but this marginal addition does not exceed the baseline of 3 for high schema coverage.
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 retrieves current price, 24h change, and volume for an OKX instrument, which is a specific verb+resource combination with a clear scope. It does not explicitly differentiate from siblings like okx_get_candles or okx_get_market_data, but the focus on 'current' and specific data points makes its purpose distinct.
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 when a current market snapshot is needed, but provides no explicit guidance on when to use this tool over alternatives. There are no exclusions or references to sibling tools, leaving the selection decision partly to the agent's inference.
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 should disclose behavior. It mentions the output format ('Returns formatted report with bull/bear signal counts') but doesn't state whether the tool is read-only, requires any permissions, or has any side effects. It adds some context about the report but not enough for a full behavioral profile.
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, efficient, and includes the key indicators and output. No unnecessary fluff.
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?
With no output schema, the description provides a high-level overview of the return format (formatted report with signal counts). However, it doesn't describe the exact structure or whether raw indicator values are included. Given the tool's complexity (multiple indicators, optional parameters), slightly more detail would improve completeness, but the current description is adequate.
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?
Schema description coverage is only 33% (bar has a description, instType and instrument do not). The description does not explain how the parameters affect the analysis, such as how 'bar' controls the timeframe or what 'instrument' selects. With low coverage, the description must compensate, and it does not.
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 runs full technical analysis with specific indicators (RSI, MACD, Bollinger Bands, MAs) and reports bull/bear signals. This distinguishes it from sibling data tools like okx_get_candles.
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?
There is no explicit guidance on when to use this tool vs alternatives. It implies usage for comprehensive analysis but doesn't mention exclusions or alternative tools.
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 full burden. It discloses the order type (reduce-only market) and direction (opposite), which is helpful. However, it does not mention the confirm parameter's preview/execute behavior (though the schema covers it), nor does it state whether the entire position is closed or what happens if no open position exists. These gaps make it moderately transparent but not fully.
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 is direct and information-dense. It states the action, the resource, and the mechanism without any unnecessary words. Every word contributes to understanding.
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 tool with two parameters and no output schema, the description is mostly complete. It explains the core action and mechanism. It doesn't cover edge cases like missing positions or the preview/execute flow, but those are partially covered by the schema's confirm parameter description. Overall, it is adequate for the tool's 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 provides 100% coverage for both parameters (instrument and confirm) with descriptions. The tool description does not add any further meaning to the parameters; it only repeats the overall purpose. Thus 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 ('Close') and resource ('an open position') and explains the mechanism ('placing a reduce-only market order in the opposite direction'). This clearly distinguishes it from siblings like okx_get_positions (view) and okx_place_order (general order placement).
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 use when there is an open position to close, but it does not explicitly state when to use this tool over okx_place_order or other alternatives. No exclusions or comparative guidance is provided, so usage is inferred rather than explicitly clarified.
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 full burden of behavioral disclosure. It indicates the operation is non-mutating through 'Evaluate' and 'Returns', but it does not explicitly state that no orders are placed or that no state changes occur. It also omits potential dependencies on market data or error behavior, so transparency is adequate but not rich.
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 concise sentences with no filler. It front-loads the primary purpose and immediately communicates the return behavior. Every word contributes to understanding the tool's function.
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 tool with two simple parameters and no output schema, the description provides sufficient context about what the tool does and what it returns. It does not specify the exact return format (e.g., boolean vs string), but the core decision outcome is clear. Given the low complexity, this is nearly complete, with a minor gap around return value typing.
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 description clarifies that the 'signal' parameter represents the proposed trade direction, which aligns with the schema's enum and description. However, the 'instrument' parameter is not mentioned in the description, and schema coverage is only 50%. The description adds some interpretive value but does not fully compensate for the undocumented parameter.
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 ('Evaluate') and identifies the resource ('hard rules') and the outcome ('whether a proposed trade would be allowed or blocked'). It clearly distinguishes the tool from sibling tools like okx_list_rules and okx_add_rule by focusing on evaluation against current market state rather than listing or modifying rules.
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 the tool is used to check if a proposed trade signal is allowed by hard rules, but it does not explicitly state when to use it versus alternatives (e.g., running a copilot or generating a plan), nor does it provide exclusions or prerequisites. The usage context is apparent but not elaborated.
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 exist, so the description carries the burden. It implies a read-only operation and adds useful context about hard/soft rule semantics, but doesn't explicitly state side effects, permissions, or return structure.
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 tightly written sentences, front-loaded with the action and resource, no filler. Every sentence earns its place by defining the rule types.
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 list tool, the description is largely adequate, defining both rule categories for interpretability. However, without an output schema, it doesn't describe the shape of returned rules (e.g., fields, ordering, pagination), so slightly incomplete.
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?
Tool has zero parameters, and schema covers 100% by having an empty properties object. Baseline 4 applies; description adds no parameter detail needed.
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?
Description uses specific verb 'List' with clear resource 'user trading rules' and distinguishes the two rule types (hard vs soft). It differentiates from siblings like okx_add_rule and okx_evaluate_rules by focusing on read-only enumeration.
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 explicit when-to-use or alternative guidance is provided. The description defines rule types but doesn't state, for example, to view existing rules before adding or to use okx_evaluate_rules for validation.
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 carries the full transparency burden. It discloses the MiniMax-only support, which is a key behavioral limitation. However, it does not state whether settings are persisted, applied globally, or affect existing AI agent sessions, leaving some ambiguity about side effects.
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 purpose, and contains zero redundant content. The provider limitation is stated concisely without sacrificing clarity. This is an example of efficient, well-structured description.
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 configuration tool with 3 optional, self-descriptive parameters and no output schema, the description covers the essentials: what it does, what settings it configures, and the current provider limitation. It could mention persistence or immediate effects, but given the low complexity, the description is largely 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 has 100% coverage with descriptions for all three parameters. The tool description reinforces that these are the LLM settings and adds the MiniMax-only constraint relevant to the model parameter, but it does not add deeper semantics like default behavior or interaction between parameters. The schema carries the main burden, so a 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 action ('Configure LLM settings') and the specific resources (temperature, max tokens). It also discloses the v1 provider limitation (MiniMax only), which distinguishes this tool from potential provider-specific alternatives. The purpose is unambiguous and directly aligns with the tool name.
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 gives a clear usage constraint: v1 supports MiniMax only, implying use with other providers is not yet available. However, it lacks explicit guidance on when to use this tool versus sibling tools like okx_configure_skills or okx_run_copilot. No alternative tools are mentioned, so the context is limited.
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 full burden. It discloses the authentication requirement and the result scope, but it does not explicitly state that this is a read-only operation or describe error behavior. The 'get' verb implies non-mutating, but it is not made explicit.
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 a front-loaded purpose ('Get account balance') followed by a necessary prerequisite. It is concise and free of extraneous information.
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 balance query, the description adequately states what it does and the API key requirement. However, since there is no output schema, the description does not specify the return format, which would be helpful but is not critical for this simple read operation.
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 input schema fully covers parameter semantics. The description adds no parameter-specific details, but none are needed. Baseline 4 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 resource 'account balance', and clarifies scope with 'all currencies with USD equivalent'. This clearly distinguishes it from sibling tools like okx_get_ticker (market data) and okx_get_positions (positions).
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 provides a prerequisite ('Requires OKX API key configured') but does not explicitly state when to use this tool over alternatives or mention exclusions. Usage context is implied by the balance topic, but no direct comparison to siblings is offered.
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 carries the burden of behavioral disclosure. It adds important context: the number of agents, the return fields, and the API key requirement. However, it does not clarify side effects such as whether 'suggested action' remains advisory or could execute trades, nor does it mention rate limits or latency.
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 and front-loaded with the action and scope. It concisely lists return values and the critical prerequisite without 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 moderate-complexity tool with no output schema, the description covers purpose, output fields, and a key prerequisite. It is adequate for invocation, though it could explicitly state that it performs analysis only and does not place orders, distinguishing it from okx_place_order.
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 75%, so the description does not need to compensate heavily, but it also adds little parameter-level meaning. It does not explain how enabledSkills or disabledAgents affect the '4-agent' analysis, though the schema already describes those. The description's mention of the API key is a prerequisite, not a parameter.
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 a specific action ('Run full 4-agent AI analysis') and resource (macro, technical, risk, and portfolio manager agents). It also distinguishes from sibling tools like okx_run_single_agent by emphasizing 'full 4-agent', and lists concrete outputs (signal, conviction, summary, reasoning, suggested action).
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 clear usage context by defining the tool as 'full 4-agent AI analysis' and mentioning the prerequisite LLM API key (MINIMAX_API_KEY). It implies when to use this over single-agent tools, though it does not explicitly name alternatives or state 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?
With no annotations provided, the description carries the full burden. It discloses important runtime behaviors: the automatic appending of a JSON output format suffix and the reset behavior when prompt is an empty string. However, it does not disclose whether the change is persistent, reversible, or requires any permissions, so some gaps remain.
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 sentences and immediately front-loads the primary purpose. Each subsequent sentence adds unique value (suffix behavior and reset semantics) without redundancy or fluff. It is appropriately concise and 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?
For a two-parameter tool with no output schema, the description covers the core functionality, key behavior (suffix and reset), and parameter usage. It does not specify return values, but that is less critical given the simplicity. The only minor gap is a lack of clarity on success or error behavior, but overall it is sufficiently complete for an agent to use correctly.
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%, so the baseline is 3, but the description adds meaningful context beyond the schema. It explains that the prompt parameter will have a JSON output format suffix automatically appended, which directly affects how the agent behaves, and clarifies the reset semantics for empty strings. This enriches the parameter understanding beyond the raw schema.
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 purpose: customizing an agent's system prompt. It uses a specific verb ('Customize') and resource ('an agent's system prompt'), distinguishing it from sibling tools like okx_get_prompts (which reads prompts) and okx_set_llm_config (which sets model config).
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 the tool is used when you need to change an agent's system prompt, and provides a specific usage detail about resetting to default with an empty string. However, it does not explicitly state when not to use it or compare it to alternatives like okx_get_prompts, leaving the usage context only implied.
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 transparency burden. It fully discloses what the tool returns: exactly 6 skills, descriptions, agent applicability, and current enabled/disabled status. It implies a read-only operation, though it does not explicitly state side-effect-free behavior or authentication needs.
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 short sentences deliver all essential information without redundancy. The verb and object are front-loaded, and every clause adds value.
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 zero-parameter, no-output-schema list tool, the description is complete. It tells the agent exactly what will be listed and includes current status, which is all necessary context for invoking the tool correctly.
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, and the schema is trivially complete at 100% coverage. The description adds no parameter details because none are needed; the baseline of 4 for zero-parameter tools 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 ('List'), identifies the resource ('all 6 available analysis skills'), and specifies the exact content returned (descriptions, agent applicability, enabled/disabled status). It clearly distinguishes itself from sibling tools like okx_configure_skills and okx_list_rules.
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. Although the listing purpose implies inspection, the description does not explicitly note that configuration changes should go through okx_configure_skills or that rules are covered by okx_list_rules.
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 conveying safety and behavior. The word 'View' strongly implies a non-mutating, read-only operation. It also discloses that it returns both default and custom prompts, adding useful behavioral context beyond the schema.
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 extremely concise at two sentences, with no wasted words. Information is front-loaded: the main action and target are in the first sentence, and an important detail (default vs custom) is in the second.
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?
The tool is simple with one optional parameter and no output schema. The description clearly conveys what the tool does and the scope (all 4 agents). It omits the output format (e.g., plain text, JSON), but given the simplicity and clarity of the action, this is a minor gap rather than a significant deficiency.
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% parameter description coverage, including the 'agentId' parameter with enum values and a description. The tool description does not add any details about the parameter, so it provides no extra value beyond the schema, justifying the baseline score of 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 a specific verb ('View') and a clear resource ('current system prompts for all 4 AI agents'), and further specifies that it shows both default and custom prompts. This clearly distinguishes it from sibling tools like okx_update_prompt, which performs a different action.
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 implies when to use this tool (when you want to view prompts) and the read-only nature is clear. It does not explicitly mention alternatives or exclusions, but no competing tool exists for reading prompts, so the context is sufficiently clear.
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 full burden of behavioral disclosure. It reveals a key behavioral trait: the system auto-classifies rules as hard or soft. This goes beyond the simple 'Add' action and helps the agent anticipate how input will be processed. However, it does not mention persistence, activation, or any side effects, which would have been useful for such an operation.
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 succinct and well-structured. The first sentence states the purpose, the second clarifies the auto-classification and provides two concrete examples. Every sentence contributes information, and there is no redundant or fluff content.
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 tool with a single parameter and no output schema, the description is quite complete: it covers input format, behavior, and examples. It does not explain return values, but the absence of an output schema makes that less critical. It could have mentioned whether the rule is immediately active or if there are constraints, but overall it is sufficiently complete for its simplicity.
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 already documents the 'text' parameter with an example, so schema coverage is 100%. The description adds semantic value by providing different examples and clarifying the auto-classification behavior, which enriches the agent's understanding of what types of text are acceptable. This exceeds the baseline for full schema coverage.
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 ('Add a new trading rule') and the resource ('trading rule') using natural language. It distinguishes itself from sibling tools like okx_list_rules and okx_evaluate_rules by focusing on the creation aspect. The auto-classification detail adds specificity.
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 implies when to use this tool: when the user wants to add a trading rule in natural language. It provides clear context and examples, but does not explicitly mention when not to use it or explicitly compare with alternatives. The presence of sibling tools like 'list_rules' and 'evaluate_rules' suggests distinct uses, but no direct exclusion is stated.
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 full burden. It discloses key behaviors: it places market orders (not limit), SWAP orders set leverage and optional SL/TP, SPOT orders are simple, and the confirm parameter allows preview before execution. This is substantial but does not cover execution details or post-order behavior.
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 sentences, front-loaded with the purpose, no wasted words. It efficiently conveys the tool's core function and per-mode behavior.
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?
The description covers the essential modes and confirm behavior. Given no output schema, it might be expected to mention return values, but the essential functionality is clear. It is slightly abbreviated but complete enough for a place-order 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?
Schema coverage is 88%, so baseline is 3, but the description adds meaningful context by tying leverage, SL/TP to SWAP and SPOT simplicity, and explaining confirm's preview behavior. This goes beyond the schema's individual parameter descriptions.
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 'Place a market order on OKX', using a specific verb and resource. It further distinguishes behavior between SWAP and SPOT, making it distinct from sibling tools like okx_get_ticker or okx_get_balance.
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 gives clear context on when to use the tool (to place market orders) and differentiates between instrument types (SWAP with leverage/SL/TP, SPOT simple buy/sell). However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.
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:

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

Score Badge

Copy to your README.md:

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

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/foxisyw/trade-mcp-server'

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