Poloniex MCP

by salleh

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct domain: market ticker, order book, and account balances. No overlap or ambiguity between them; an agent can easily select the right one.
Naming Consistency5/5
All tools follow a consistent 'get_[resource]' naming pattern, where the resource is ticker, orderbook, or balances. This is a predictable and uniform convention.
Tool Count5/5
With exactly 3 tools, the server is well-scoped and each tool serves a distinct, necessary purpose for accessing Poloniex data. This fits comfortably within the typical 3-15 range.
Completeness3/5
The server covers market data and balances, but lacks any trading operations like placing or canceling orders, or fetching open positions. Notable gaps exist for a full exchange integration, though the read-only scope is internally consistent.
Average 4/5 across 3 of 3 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 35 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
With no annotations, the description carries the burden of behavioral disclosure. It adds the prerequisite of POLONIEX_API_KEY and POLONIEX_API_SECRET, which is useful, but it does not explicitly state whether this is a read-only operation, describe pagination behavior, or indicate the response format. 'Fetch' implies reading, but important behavioral traits are left to 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 one sentence plus a requirement note, front-loaded with the core action and resource. It is concise, contains no filler, and every phrase adds value: the activity types, optional filters, and environment prerequisite.
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 7 optional parameters and no output schema, yet the description only gives a high-level summary. It does not explain what the returned data looks like, how filters interact (e.g., startTime/endTime, from/direction), or the meaning of activityType codes beyond examples. It is adequate for a basic understanding but leaves notable gaps given 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 input schema provides complete descriptions for all 7 parameters (100% coverage), so the description does not need to repeat them. The description's phrase 'optional filters' adds minimal semantic value beyond the schema. Baseline 3 is appropriate since the schema handles parameter meaning.
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 resource (account activity) and the verb (Fetch), and provides concrete examples (airdrops, rebates, staking, adjustments). It is clear enough to distinguish from many other get_* tools, though it does not explicitly name sibling tools or contrast with similar tools like get_wallet_activity.
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 for fetching account activity records with optional filters, and it notes the API key requirement. However, it provides no explicit when-to-use versus alternatives or exclusions, leaving the agent to infer usage from the resource name and examples.
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 discloses the need for POLONIEX_API_KEY and POLONIEX_API_SECRET, which is an important authentication requirement, and clarifies the scope as margin/lending. However, it does not describe pagination behavior, return format, or any potential rate limits or side effects. The auth disclosure adds some value, but the description remains minimal.
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 core purpose ('Fetch the account's interest history') before adding the scope and authentication details. Every word earns its place, with 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?
This tool has five parameters with pagination semantics (from, limit, direction, startTime, endTime) and no output schema. The description only gives a one-line purpose and auth requirement, leaving the agent without enough context about the response structure or how to correctly combine pagination and time filters. Given the complexity, the description is under-specified.
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 covers all five parameters with detailed descriptions, achieving 100% schema description coverage. The tool description adds no additional parameter-level meaning beyond what the schema already provides. Therefore, 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 verb 'Fetch' and the specific resource 'account's interest history' with the qualifier 'margin/lending'. This distinguishes it from sibling tools like trade history or account activity, as it is unambiguous about the focus on interest-related records.
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 alternatives, nor does it mention exclusions or alternative tools. It only mentions the authentication requirement, which is a prerequisite rather than a usage guideline. This is a clear gap given the many sibling data-fetching 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 burden of behavioral disclosure. It adds that the tool is public and requires no credentials, which is valuable. However, it does not explicitly state read-only semantics, response format, or other potential 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 every word earns its place. No fluff or repetition.
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?
For a simple one-parameter tool, the description is reasonably complete. However, without an output schema, it remains vague about what 'margin collateral information' actually includes, and it does not mention alternatives among the many sibling tools.
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 the description essentially rephrases the schema's parameter description ('Omit to return all', 'currency code'). It adds no new information beyond the schema.
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 fetches margin collateral information, using a specific verb and resource. It does not explicitly distinguish from sibling tools like get_account_margin, but the term 'collateral' is specific enough.
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 useful usage context (omit currency for all, pass one for a single currency, public no credentials required). However, it does not explain when to use this tool versus alternatives or when not to use it.
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 for behavioral disclosure. It adds the useful fact that the endpoint is public and requires no credentials, but does not mention return format, pagination, rate limits, or error behavior. This is minimal but not absent.
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 action and resource, and every word earns its place. It is efficient and free of verbosity.
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 that all parameters have schema descriptions and the tool is a simple read-only fetch, the description provides sufficient context. It states the purpose and the authentication requirement. Although there is no output schema, the phrase 'OHLC candlestick data' sufficiently implies the return type for an agent to understand the tool's output.
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%, so all 5 parameters are already documented in the schema. The description itself does not add parameter semantics beyond the schema, placing it at the baseline 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 the specific verb 'Fetch' with a clear resource, 'OHLC candlestick data', and scopes it to symbol and interval. This distinguishes it from sibling tools like get_ticker (current price) or get_market_trades (trades).
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 does not provide any guidance on when to use this tool versus alternatives such as get_ticker, get_price, or get_market_trades. It simply states what the tool does with no contextual usage direction.
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 mentions required API keys (POLONIEX_API_KEY, POLONIEX_API_SECRET) and scopes the operation to historical orders, adding meaningful context. However, it does not discuss pagination, rate limits, or other behaviors.
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, clearly front-loaded with the main action and then the prerequisite. Every word earns its place.
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 complexity of 11 parameters, no output schema, and no annotations, the description is too sparse. It covers purpose and auth but omits behavior like pagination, default state handling, or response format, leaving the agent under-informed for such a complex 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?
Schema description coverage is 100%, so the baseline is 3. The description does not add details beyond 'optional filters', relying on the schema's parameter descriptions. It does not compensate for any gaps because none exist, but also adds no supplementary 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 clearly states the tool fetches historical (closed/canceled) orders, using a specific verb and resource. This distinguishes it from siblings like get_open_orders and get_order.
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 clear context (historical, closed/canceled) but does not explicitly mention alternatives or when not to use this tool. Usage is implied rather than explicitly guided.
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?
The description adds the prerequisite of API keys in the environment, which is useful context. However, with no annotations provided, it does not explicitly confirm read-only behavior or describe the return format, leaving some transparency 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, concise two-sentence structure that front-loads the primary purpose and includes an important prerequisite. No wasted words.
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?
For a simple no-parameter getter, the description conveys the core purpose and auth requirement. However, it lacks usage guidance and does not specify what 'related fee information' includes, which would be helpful given there is no output schema.
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?
There are no parameters, so the description does not need to explain parameter semantics. The schema is empty, and the baseline for zero parameters is high; no additional parameter information is expected.
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 fetches the caller's trading fee rates and related fee information, using a specific verb and resource. This distinguishes it from sibling tools like get_borrow_rates_info, which are about different financial data.
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 only mentions an environment prerequisite (API keys) but gives no guidance on when to use this tool versus alternatives. It does not state exclusions or specify use cases beyond fetching fee information.
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. It discloses public access and the nature of the data (latest trade price), but does not describe response format, potential rate limits, or error behavior. This is minimal but not misleading.
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 concise sentences, front-loaded with the core action. Every phrase earns its place with no fluff or 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?
For a simple one-parameter tool with no output schema, it covers the essentials: purpose, invocation modes, and auth. However, the lack of a stated return value format for multi-symbol vs. single-symbol responses leaves a gap.
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%, so the baseline is 3. The description's note about omitting symbol for all essentially repeats the schema's own 'Omit to return all' instruction, adding no new meaning beyond what the schema already provides.
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 verb ('Fetch') and resource ('latest trade price'), with scope (all symbols or one). It is distinct enough, though it doesn't explicitly differentiate from sibling tools like get_ticker, which might also provide price data.
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?
Provides clear usage context: how to request all symbols vs. a single market, and notes that no credentials are required. However, it doesn't explicitly compare with alternatives like get_ticker or get_mark_price, so it lacks when-to-use-this-over-others 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, the description must carry the burden of behavioral disclosure. It appropriately mentions the required API keys and scope (caller's accounts), and 'fetch' implies a read-only operation. However, it does not disclose pagination defaults, result ordering, or any potential side effects, leaving some behavioral ambiguity.
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, front-loaded sentences. The first states the primary action and scope, the second covers the authentication requirement. No filler or redundant information.
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?
For a tool with no output schema and no annotations, the description leaves the return structure undefined and does not mention pagination behavior, even though pagination parameters exist. However, the schema covers all parameters and the purpose/scope are clear, making it adequate but with gaps.
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%, so the schema already explains all six parameters. The description adds only a general reference to 'optional filters' without enriching parameter meaning beyond what the schema provides. Baseline 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 the specific verb 'fetch' and clearly identifies the resource: 'records of transfers between the caller's accounts' with an example (spot <-> futures). This distinguishes it from sibling tools like get_subaccount_transfer_records, which deals with subaccount transfers.
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 'between the caller's accounts' implies the tool is for the user's own transfers, but it does not explicitly mention when to use this tool over alternatives such as get_subaccount_transfer_records or get_wallet_activity. No exclusions or alternative recommendations are provided.
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?
Without annotations, the description carries the full burden. It usefully discloses the authentication requirements (POLONIEX_API_KEY and POLONIEX_API_SECRET), but does not explicitly state read-only behavior, the SPOT-only restriction (left to schema), or any other limitations like rate limits or error handling.
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 purpose and adds an important prerequisite. There is no wasted text, and every element earns its place.
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 one optional parameter and no output schema, the description provides the core purpose and auth context. It relies on the schema for the accountType constraint, which is acceptable, and does not need extensive detail about return format or errors for this level of 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 single parameter accountType is fully described in the schema with default and allowed values. The description adds no extra meaning beyond the schema, so the baseline score 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 'Fetch' and identifies the resource as 'account's margin information', further listing equity, margin balance, and available margin. This clearly distinguishes it from sibling tools like get_balances or get_account_info.
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 margin information is needed, but provides no explicit when/when-not guidance or alternatives among the many sibling get_* tools. It only states the auth requirement, not when to prefer this tool over others.
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 transparency burden. It discloses the operation type ('Fetch' implies read-only) and the authentication prerequisite, but omits other behavioral details such as return format, failure modes, rate limits, or whether the status is a simple boolean. This is acceptable for a simple getter but not fully transparent.
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 with no wasted words. The first sentence front-loads the action and resource; the second adds a necessary authentication note. Every element earns its place.
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 low complexity (0 params, no output schema, simple read operation) and no annotations, the description covers the essential purpose and prerequisite. It could explicitly mention the output shape, but the name and simple nature make the return value predictable, so the context is sufficiently complete for an AI agent.
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 no parameters, and the schema coverage is trivially 100%. The rubric assigns a baseline of 4 for zero-parameter tools, and the description adds no parameter information because none is needed. It does not attempt to describe non-existent 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 the action ('Fetch') and the specific resource ('current status of the account's order kill switch'). It distinguishes itself from sibling tools, many of which also fetch data, by naming the unique kill-switch resource.
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 gives a prerequisite (API keys in environment) but provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it or any related tools, leaving usage context implicit (e.g., call when you need kill switch status).
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 of behavioral disclosure. It explicitly states that the call is public and requires no authentication, which is helpful. It does not describe return format or error behavior, but for a simple read/fetch operation this is adequate, though not rich in 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, concise sentence that front-loads the action (Fetch) and immediately specifies the resource. It contains no padding or redundant details, making it highly effective for quick agent comprehension.
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 parameter and no output schema, and the description states its purpose and authentication requirements. While it does not enumerate the actual components returned, this is not critical for the agent to select and invoke the tool correctly, making it sufficiently 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 schema already fully documents the single parameter 'symbol' with a description and example format. The tool description does not add any additional parameter-specific information, so the schema's high coverage (100%) carries the meaning, justifying the baseline score.
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 fetches components used to derive a mark price for a symbol, using the specific verb 'Fetch' and a precise resource. It distinguishes itself from the sibling get_mark_price by focusing on the components rather than the final price.
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 notes that the tool is public and requires no credentials, providing a clear usage condition. However, it does not explicitly state when to use this tool over alternatives like get_mark_price or offer exclusions, so guidance is implied but not fully expanded.
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 clearly states the operation is public and requires no credentials, and specifies the returned data (bids and asks). This adds useful behavioral context beyond the schema, though rate limits or response structure are not mentioned.
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 verb and resource. Every word adds value, with no redundancy or filler.
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 no output schema or annotations, the description covers the essential return value (bids and asks) and the public/auth context. It does not explain return structure in detail, but given the tool's simplicity, this 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%, so the baseline is 3. The description does not add meaning beyond the schema's parameter descriptions, which already explain limit, scale, and symbol format. No extra value is provided for parameter semantics.
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 fetches order book depth (bids and asks) for a Poloniex spot symbol, using a specific verb and resource. It distinguishes itself from siblings like get_ticker and get_balances by focusing on order book data.
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. The description only states it is public with no credentials required, but does not mention exclusions or contrast with get_ticker or get_balances.
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 for behavioral disclosure. It adds auth requirements (POLONIEX_API_KEY and SECRET) and clarifies the pending/active status. However, it does not disclose whether the operation is read-only, pagination behavior, or return format, which would be expected given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and contains no filler. Every word adds value, including the parenthetical clarifying order types and the auth requirement.
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 5 parameters with full schema coverage and the presence of sibling tools, the description is adequate for selecting and invoking the tool. It includes purpose and auth context, though it omits the response shape (no output schema) and explicit pagination guidance, which prevents a 5.
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%, so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema already provides; it just restates the tool's general purpose.
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 clearly identifies the resource: active (pending) smart orders (stop/stop-limit) for the account. This distinguishes it from siblings like get_open_orders (regular orders) and get_smart_orders_history (historical smart orders).
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 it (for active smart orders) but does not explicitly state when not to use it or name alternatives like get_open_orders or get_smart_orders_history. Context is clear but no exclusions are given.
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 burden of disclosing behavior. It adds 'Public — no credentials required' which is useful, but it does not explain return format, error behavior, or what 'trade-limit information' means in practice. 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?
Two concise sentences front-load the purpose and immediately address the key parameter behavior. Every word earns its place, with no filler or repetition.
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 low-complexity tool with one optional parameter, the description covers purpose, parameter usage, and authentication requirement. Lacks output format details and leaves 'trade-limit information' undefined, but given the simplicity, it is reasonably 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?
Schema coverage is 100%, and the description largely echoes the schema parameter description ('Omit to return all symbols' mirrors 'Omit to return all symbols'). No additional meaning is added beyond the 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?
Description uses specific verb 'Fetch' and resource 'trading symbols and their trade-limit information', clearly distinguishing this from sibling tools like get_ticker or get_currencies. The scope is immediately understandable.
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 clear parameter usage guidance ('Omit symbol for all symbols, or pass one for a single market') but does not explicitly state when to use this tool vs alternatives or mention any exclusions. The 'Public' note adds context but not tool-selection 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 carries the full burden for behavioral disclosure. It does mention the required environment variables (POLONIEX_API_KEY and POLONIEX_API_SECRET), which is valuable. However, it does not describe pagination behavior, result ordering, or the response structure, which are relevant for a fetch 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 two clear sentences with no redundant information. It front-loads the main action and immediately follows with the key prerequisite, making it efficient and easily scannable.
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 six-parameter tool with no output schema, the description provides enough context for an agent to understand its core function (account trade history with optional filters). It lacks explicit mention of pagination, but the schema covers the pagination parameters, and the overall purpose is sufficiently clear.
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?
All six parameters have descriptions in the schema (100% coverage), so the description adds little beyond the schema. The phrase 'optional filters' abstractly refers to the parameters but does not detail any of them; the schema already does that work.
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 'Fetch' and clearly identifies the resource as the account's trade history across orders. This distinguishes it from related tools like get_market_trades (public trades) and get_order_trades (trades for a specific order), making the purpose unambiguous.
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 retrieving account trade history with optional filters, but it does not explicitly state when to choose this tool over siblings like get_orders_history or get_account_activity. No alternatives or exclusions are mentioned, so the guidance is inferred rather than explicit.
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 (POLONIEX_API_KEY and SECRET) and implies a read-only operation via 'Fetch.' However, it does not mention pagination, default limits, or possible errors, which would be useful for a fully transparent description.
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 purpose and immediately followed by the key prerequisite. No wasted words; every sentence earns its place.
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 tool's simplicity and the rich schema, the description covers the main purpose and requirement. However, there is no output schema, so a brief mention of return value (e.g., a list of orders) or pagination behavior would improve completeness. The current description is adequate but has gaps.
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% for all 6 parameters, so the schema already provides full parameter meanings. The description adds no extra parameter-specific context, 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 the specific verb 'Fetch' and identifies the resource as 'active (open) orders for the account.' This clearly distinguishes it from siblings like get_orders_history (historical orders) and get_order (single 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?
The description states the tool fetches open orders, which implies it should be used for current account orders. It does not explicitly name alternatives or exclusions, but the 'open' qualifier and sibling names provide clear context. The auth requirement is also mentioned.
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. It discloses the authentication requirement (POLONIEX_API_KEY and POLONIEX_API_SECRET) and required inputs, but does not mention return format, pagination, or rate limits.
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 main purpose, and every word earns its place. No filler or redundant explanation.
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 description is adequate for a simple read tool but omits the optional activityType filter entirely and gives no indication of the output shape. With no output schema, more detail about the response would improve completeness.
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 describes all parameters with 100% coverage, including UNIX timestamp semantics and the activityType enum. The description only reiterates that start and end are required, adding no new meaning beyond the 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 fetches deposit and withdrawal activity within a time window, using the specific verb 'fetch' and resource 'wallet activity'. It distinguishes from siblings like get_account_activity by scoping to deposits and withdrawals.
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 context: it is used to fetch deposit/withdrawal activity in a time window, with both start and end required. It also states the API key prerequisites. However, it does not mention alternatives or when not to use this tool.
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 burden. It discloses the environment variable requirement, which is important behavioral context. However, it does not explicitly state that the operation is read-only, describe error behavior if keys are missing, or clarify what the response contains, 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 just two sentences, front-loaded with the main purpose and then a prerequisite. Every word earns its place with no redundancy or filler.
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?
This is a simple tool with one optional parameter and no output schema. The description covers the purpose and authentication requirement, which is adequate for an agent to invoke it correctly. It could add a hint about return values, but the tool name and purpose make that obvious.
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 description coverage is 100%, as the only parameter 'accountType' already has a clear description with examples. The tool description adds no additional semantic value beyond what the schema already provides, 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 'Fetch' and clearly identifies the resource 'authenticated account balances from Poloniex', which distinguishes it from sibling tools like get_ticker and get_orderbook that handle market data.
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 states the authentication prerequisite (POLONIEX_API_KEY and POLONIEX_API_SECRET), which provides clear context that this tool is for authenticated account data rather than public market data. However, it does not explicitly name alternatives or state when not to use it.
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 transparency burden. It discloses that the endpoint is public and does not require credentials, and that trades are 'recent,' which provides some recency context. However, it does not mention read-only behavior, rate limits, response format, or how the 'limit' parameter affects results beyond what the schema states.
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, with two short sentences totaling 11 words. It front-loads the action and essential qualifier 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?
The description provides a clear purpose, auth requirement, and recency qualifier, which is adequate for a simple public data fetch tool. It does not describe the return shape or differentiate from get_trade_history explicitly, but given the simple nature and full schema coverage, it is reasonably 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 schema fully describes both parameters with descriptions, so the description does not need to add parameter details. The description mentions 'for a symbol,' which aligns with the required 'symbol' parameter, but adds no extra semantics.
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: 'Fetch recent public trades for a symbol.' It uses a specific verb and resource, and distinguishes itself as 'public' from authenticated trade history tools like get_trade_history.
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 noting the tool is public and requires no credentials, which signals it can be used without authentication. It does not explicitly name alternative tools or exclusion criteria, but the public nature implies a distinction from authenticated trade endpoints.
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 burden of disclosing behavioral traits. It adds the authentication requirement ('Public — no credentials required') and the all-or-single market behavior. It does not mention rate limits or return format, but for a simple read-only price fetch, these gaps are minor.
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 core purpose, followed by parameter usage and auth context. Every word earns its place; no filler or 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 trivial tool with one optional parameter and no output schema, the description is nearly complete. It explains what it does, how to use the parameter, and the auth profile. The only potential missing piece is an explicit statement of the return shape, but that is not critical given the simplicity.
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 fully documents the single parameter 'symbol' with 'Omit to return all.' The description's 'Omit `symbol` for every symbol, or pass one for a single market' restates that same information without adding new meaning. Baseline 3 applies because schema coverage is 100%.
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 begins with a specific verb and resource: 'Fetch the current mark price.' It clearly distinguishes this from sibling tools like get_price (likely spot price) and get_mark_price_components (components of mark price) by using the term 'mark price'.
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?
It gives useful context: 'Public — no credentials required,' and explains how to select all vs. single market. However, it does not explicitly mention alternatives like get_price or get_ticker, nor does it explain when not to use this tool. Usage is implied rather than explicitly contrasted with siblings.
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 discloses the authentication requirement (POLONIEX_API_KEY and POLONIEX_API_SECRET) and implies a read operation through 'Fetch.' However, it does not describe behavior for error cases, what happens if both or neither id is provided, or any rate limits.
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, front-loaded with the action ('Fetch a single smart order'), and every sentence provides necessary information 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?
For a simple read tool with complete schema descriptions and no output schema, the description covers the essential purpose, parameter constraint, and auth requirement. It could add edge-case behavior (e.g., not found) but is otherwise adequately 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?
The input schema fully describes both parameters, but the description adds the critical "exactly one" constraint, which the schema does not enforce (since both are optional). This extra guidance helps avoid misuse and is valuable beyond the structured 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 function: 'Fetch a single smart order by its order id or client order id.' It uses a specific verb and resource, and the mention of 'smart order' distinguishes it from sibling tools for regular orders and smart order lists/history.
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 clear context for a single-order fetch and adds an explicit parameter constraint ('provide exactly one'), but it does not mention when to use this tool versus alternatives like get_smart_open_orders or get_smart_orders_history, nor does it state 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?
With no annotations, the description carries the transparency burden. It discloses an important behavioral requirement: POLONIEX_API_KEY and POLONIEX_API_SECRET must be present in the environment. It also clarifies that the tool returns historical data ('triggered/canceled'), implying a read-only operation. It does not mention rate limits or output format, but the key requirements and scope provide solid 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 exactly two sentences: the first gives the core purpose and capabilities, the second states authentication prerequisites. Every word earns its place; no filler or repetition. It is front-loaded and easy to parse.
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 11 parameters and no output schema, so the description should help the agent understand what to expect. It provides purpose and auth, but does not explain the return structure (e.g., a list of orders) or pagination behavior (despite parameters like 'from' and 'direction' existing in the schema). Given the rich schema, this is minimally viable but leaves room for more context.
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 description covers all 11 parameters (100% coverage), including enums and defaults, so the baseline is 3. The description only says 'optional filters' without elaborating on any specific parameter syntax or relationships. It adds no extra meaning beyond what the schema already provides.
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 verb ('Fetch') and resource ('historical (triggered/canceled) smart orders'), which distinguishes it from siblings like get_smart_open_orders and get_orders_history. The parenthetical about triggered/canceled adds specificity about the type of history.
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 need historical smart order data, not open or active orders. It clearly notes the availability of optional filters, giving context for use cases. However, it does not explicitly mention alternatives or exclusions (e.g., 'for open orders use get_smart_open_orders'), 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses a critical prerequisite (POLONIEX_API_KEY and POLONIEX_API_SECRET environment variables) and clarifies the optional-parameter behavior. It also indicates the returned data fields, giving the agent an idea of what to expect, though it does not describe error cases or output format beyond that.
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; the first states the core purpose and output data, and the second addresses the optional parameter and authentication requirement. It is front-loaded and contains no filler.
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 read-only tool with one optional parameter and no output schema, the description covers the essential aspects: purpose, returned data, parameter usage, and authentication. It does not explain the exact response structure or error handling, but these gaps are acceptable given the tool's simplicity.
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 fully describes the `currency` parameter (filter by currency, omit for all), and the description repeats this same guidance without adding new semantic detail. Since schema coverage is 100%, the description provides minimal added value for 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 the tool's function with a specific verb ('Fetch') and resource ('borrow status for margin currencies'), listing the returned data elements (borrowed amounts, rates, available amounts). This distinguishes it from sibling tools like get_borrow_rates_info or get_account_margin by its scope and output details.
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, noting that omitting `currency` returns all margin currencies, but it does not explicitly name alternatives or state when not to use this tool compared to siblings. The context is clear enough for basic usage.
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 discloses a key behavioral requirement: authentication via POLONIEX_API_KEY and POLONIEX_API_SECRET. The word 'Fetch' implies a read operation, but it does not explicitly describe the safety profile or output structure, 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?
Two sentences, with the core action first and the auth requirement second. No redundant phrases or filler.
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 one parameter, no output schema, and no annotations, the description covers the purpose, the margin context, and authentication requirements. It doesn't explain the response format, but for this simple tool the information is sufficient.
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 offers 100% coverage with an example ('BTC_USDT') for the single 'symbol' parameter. The description's mention of 'a symbol' adds no additional semantic value beyond the schema, so the baseline score 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 states a specific action: 'Fetch the maximum and available buy/sell amounts for a symbol on margin.' This clearly distinguishes it from sibling get_* tools by focusing on margin-specific size limits. The verb 'fetch' and resource 'buy/sell amounts' are 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'on margin' provides clear context for when this tool is appropriate, distinguishing it from other quote tools. However, it does not explicitly name alternative tools for when margin is not involved or state when not to use it.
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. It discloses the API key requirement and the exactly-one constraint. The verb 'Fetch' implies a read-only operation. However, it does not describe behavior for conflicting/missing IDs or error responses, leaving some transparency 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 two short sentences, front-loaded with the primary action and constraint. Every word contributes; there is no redundant or filler 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 low-complexity tool with only two parameters and no output schema, the description is largely sufficient: it covers purpose, identifier options, exclusivity, and authentication. It does not describe the return structure, but given the simplicity, this is acceptable.
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 already describes both parameters, giving a baseline of 3. The description adds meaningful constraint semantics ('provide exactly one') and clarifies how clientOrderId relates to the lookup, providing value beyond the 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 fetches a single order by order id or client order id, using the specific verb 'Fetch' and the resource 'single order'. This distinguishes it from sibling list tools like get_orders_history or get_open_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?
It provides clear context for using this tool (single-order lookup) and the constraint to provide exactly one identifier. However, it does not explicitly name alternatives or state when not to use it, so it misses the 'alternatives' aspect that would earn a 5.
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 compensates by disclosing time-window limits and default behavior, as well as authentication requirements. It does not explain pagination semantics or response structure, but those are partly covered by the schema and sibling 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 concise: three sentences with no fluff. It leads with the primary purpose, then adds essential constraints and environmental prerequisites. Every sentence carries useful 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 read-only list tool with 10 parameters and no required inputs, the description gives the key context: scope, time constraints, and auth. It does not mention output shape, but no output schema exists and the purpose makes the return type inferable. A brief note on pagination behavior would have made it 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?
Schema coverage is 90%, so the parameters are largely self-documenting. The description adds generic 'optional filters' but does not elaborate on individual parameter meanings or edge cases. This meets the baseline for high 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 'Fetch[s] transfer records among accounts in the account group,' which specifies both the action and the resource. This distinguishes it from the sibling `get_transfer_records` by emphasizing the subaccount/account-group scope.
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 concrete usage context: it mentions optional filters, the maximum 6-month interval, and the default 7-day window when no times are given. It also notes the required environment variables. However, it does not explicitly contrast with alternative tools like `get_transfer_records`.
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?
It discloses the required environment variables (POLONIEX_API_KEY/POLONIEX_API_SECRET) and implies a read-only operation via 'fetch', adding value beyond the schema. It doesn't mention rate limits 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?
Two concise sentences, front-loaded with the action, no filler.
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 single-optional-parameter getter, this description covers purpose, usage, and auth. The lack of output schema is acceptable given the simple resource.
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 fully documents the `currency` parameter with the same omit/pass behavior, so the description adds no new meaning beyond restating the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Fetch deposit addresses') and the account scope, clearly distinguishing it from sibling getter tools like get_balances or get_wallet_activity.
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 provides clear instructions for the optional parameter ('Omit currency for all currencies, or pass one for a single currency') and auth prerequisites, but doesn't explicitly contrast with alternative tools.
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 burden of behavioral disclosure. It transparently explains the two operational modes (all vs. single symbol), lists the returned fields, and states the auth requirement (none). This adds meaningful context beyond the bare function name, though it omits details like rate limits or error behavior, which are less critical for a simple read-only fetch.
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 extraneous content. The first sentence front-loads the purpose, the second covers usage and auth. Every word earns its place.
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 single-optional-parameter read-only tool with no output schema, the description provides sufficient information: what it returns, how to scope it, and its public nature. It is complete enough for an agent to select and invoke correctly without ambiguity.
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%: the schema already documents the parameter meaning and the omit behavior. The description reinforces this but does not add new parameter-level details. Baseline of 3 is appropriate since the schema fully covers the parameter semantics.
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 ('Fetch') and the specific resource ('24h ticker data') with key fields listed. It distinguishes itself from siblings like get_price and get_candles by focusing on the 24h ticker aggregate rather than a single price or historical candles.
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 context: omit `symbol` for all markets, pass one for a single market. It also notes the endpoint is public with no credentials required, which helps the agent decide when to use it. It does not explicitly name alternative tools, but the usage instruction is clear and sufficient for this simple tool.
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 key behavioral trait of being public and requiring no credentials, and 'Fetch' implies a non-mutating read. It does not mention rate limits or response format, but for a simple public data endpoint, this is adequate.
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 states the action, resource, and scope. The added note about being public is concise and unnecessary words are absent.
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, no-output-schema tool, the description is sufficiently complete. It explains what is fetched and that it requires no authentication. The only minor gap is no mention of what 'tiers' means or the exact response shape, but this is reasonable given the tool's 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 tool has zero parameters, so according to the guidelines the baseline is 4. The description appropriately omits parameter details since there are none to describe, and the schema already reflects this with 100% 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 uses a specific verb ('Fetch') and identifies the exact resource ('borrow rates for all tiers and currencies'). It clearly distinguishes from sibling tools like 'get_borrow_status' by focusing on rates across all tiers/currencies, not a specific status.
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 context that this is a public endpoint requiring no credentials, which helps the agent know when to use it. However, it does not mention alternatives or explicitly state when not to use it, missing the full 5-level guidance.
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?
No annotations are provided, but the description states 'Public — no credentials required', which is valuable authorization context. 'Fetch' implies a safe, read-only operation, and the mention of v2 format discloses a behavioral option, though it doesn't detail multi-chain behavior 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?
Two sentences deliver the purpose and key usage hints without wasted words. Front-loaded with the main action.
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 (3 parameters, no output schema), and the description covers purpose, key parameter behavior, and auth. It lacks explicit return-value detail beyond 'chain/network details', but that's sufficient for a low-complexity 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 100%, so the baseline is 3. The description adds value by explaining the effect of omitting 'currency' and setting 'v2', which goes beyond the schema's simple 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 uses the specific verb 'Fetch' with the resource 'supported currencies and their chain/network details', clearly distinguishing it from sibling tools like get_ticker or get_balances. It also explains the optional currency parameter for singular vs all.
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 provides clear context that omitting 'currency' returns all currencies and that setting 'v2' changes the response format. It does not explicitly name alternative tools for exclusion, but the context is sufficient for a distinct get_currencies function.
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?
No annotations are provided, so the description carries the full burden. It discloses authentication requirements and the primary-account restriction, adding valuable context. The word 'Fetch' implies a read-only operation, though it does not detail return format or potential side effects, which is acceptable for a simple 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 two sentences with no wasted words. It front-loads the purpose and then adds constraints, making it easy to parse quickly.
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 parameterless fetch tool, the description covers what it does, its scope, and prerequisites. There is no output schema, but the return is implied as balances. A minor gap is the lack of response structure detail, but overall it is sufficient for selection.
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 schema coverage is trivially 100%. Per the rubric, zero-parameter tools receive a baseline of 4. No further parameter explanation is 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?
The description clearly states 'Fetch balances by currency and account type (SPOT and FUTURES) for each account in the account group.' The verb 'Fetch' plus the resource and scope distinguishes it from sibling tools like get_balances, which likely target a single account.
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 notes 'Only functional for a primary account' and requires API keys, providing clear usage context. It does not name alternatives, but the account-group scope implies use when needing consolidated balances across the group rather than a single subaccount.
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 environment authentication requirements (POLONIEX_API_KEY and POLONIEX_API_SECRET) and the primary-account restriction, which are meaningful behavioral constraints. It doesn't describe the return format, but for a simple read-only fetch this is adequate.
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, no filler. The purpose is front-loaded, and the constraints follow immediately. Every word earns its place.
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 parameters and no output schema, the description covers the essential context: what it returns, the primary-account limitation, and required environment variables. It omits output structure, but this is a minor gap for a simple list-fetching 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, so the schema is trivially covered. The description adds no parameter information, which is appropriate since none exist. Baseline 4 for 0-parameter tools 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 states a specific verb ('Fetch') and resource ('accounts within the caller's account group (primary and subaccounts)'), clearly distinguishing it from sibling tools like get_subaccount_balances by scope. It immediately conveys what the tool does.
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 a clear when-to-use context (fetching all accounts) and a when-not-to-use condition ('Only functional for a primary account'). It does not name alternatives, but the primary-account restriction acts as an exclusion, so it earns a 4 rather than 5.
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 burden and provides useful context: it requires environment variables for authentication, and it returns specific fields (ids, types, state) for all accounts. It does not mention rate limits or pagination, but for a zero-parameter read operation with no output schema, this is reasonable.
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 with no filler. The first sentence states the action and scope, the second gives the authentication requirement. Every sentence earns its place.
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 and no output schema, the description is complete: it explains what is fetched (ids, types, state), the scope (all caller's accounts), and the auth requirement. The sibling list is large, but the clear purpose makes selection straightforward.
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 is trivial and the baseline is 4. The description adds context about what the account info includes, which is useful even though 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 uses a specific verb ('Fetch') and resource ('account information') with concrete details (ids, types, state) and scope ('all of the caller's accounts'). It clearly distinguishes from siblings like get_balances (balances) and get_account_activity (activity).
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 states a prerequisite (requires POLONIEX_API_KEY and POLONIEX_API_SECRET), which is helpful for usage. It does not explicitly name alternatives or exclusions, but the purpose is clear enough to infer when to use it, given the lack of ambiguity.
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?
No annotations are provided, so the description carries full burden. It discloses the required environment variables (POLONIEX_API_KEY and POLONIEX_API_SECRET) and the limitation on client order id. The word 'fetch' implies read-only. This adds meaningful context beyond the schema, though it doesn't mention rate limits or error 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?
The description is three concise sentences: purpose, limitation, and auth requirement. It is front-loaded and every sentence provides necessary information without redundancy.
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?
With a single simple parameter and no output schema, the description adequately covers what the tool does, what parameters it takes, and its constraints. It is complete for the tool's complexity.
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% with the id parameter described as 'The order id.' The description adds semantic value by clarifying that 'client order id is not supported', which disambiguates the expected id type and prevents misuse.
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 fetches trades that filled a specific order by order id. This is a specific verb+resource (fetch trades for an order) and differentiates from sibling tools like get_trade_history (all trades) or get_order (order details).
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 usage context is clear: use this when you need trades for a specific order id. It notes a limitation (client order id not supported) and auth requirements, but does not explicitly name alternatives or exclusion scenarios, which prevents a 5.
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 burden and discloses the key behavioral trait: it is a public, credential-free read operation. It doesn't explicitly state 'no side effects,' but the nature of fetching a timestamp implies it, making the disclosure adequate.
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, no filler. The purpose and auth requirement are both front-loaded. Every word earns its place.
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 tool with no output schema, the description is fully sufficient. It identifies what the tool returns (current server time), confirms public access, and requires no further elaboration.
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 accepts zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed; schema coverage is effectively complete since there are no properties to document.
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 clearly identifies the resource ('current Poloniex server time'). It is unambiguous and distinct from all sibling get_* tools, which focus on market data, account info, or order details.
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 explicitly notes 'Public — no credentials required,' which guides usage by indicating no authentication is needed. It does not mention alternatives or exclusions, but for a simple server-time utility, the context is clear enough.
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:

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

Score Badge

Copy to your README.md:

[![poloniex-mcp MCP server](https://glama.ai/mcp/servers/salleh/poloniex-mcp/badges/score.svg)](https://glama.ai/mcp/servers/salleh/poloniex-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/salleh/poloniex-mcp'

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