okx_get_non_tradable_assets
Retrieve non-tradable assets from OKX to identify which holdings cannot be actively traded.
Instructions
[L:READ] CAT:[资金] | → 请先调用 agent_catalog
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Retrieve non-tradable assets from OKX to identify which holdings cannot be actively traded.
[L:READ] CAT:[资金] | → 请先调用 agent_catalog
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It only mentions read operation and category, omitting any details about side effects, required permissions, or data scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short but not wasteful. However, its brevity leads to under-specification; it fails to earn its place by providing meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and description does not explain return values or distinguish this tool from numerous similar siblings. It is incomplete for the complexity of the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so schema coverage is 100%. Description adds no parameter information beyond what schema already shows, but baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description indicates read operation and category 'funds' but does not clearly state what 'non-tradable assets' are or what the tool returns. It vaguely references a prerequisite (agent_catalog) but lacks a specific verb-resource combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a prerequisite ('call agent_catalog first') but no guidance on when to use this tool vs alternatives among many sibling tools. No exclusion criteria or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/okx-wallet-H/hvip-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server