ocean-agent

Server Quality Checklist

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

Latest release: v0.3.8
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists between open_funding_position, open_pacifica_leg, and open_with_bracket (all open positions) and between scan_funding and plan_oi_hedge (both analyze funding rates). Descriptions are detailed enough to disambiguate with careful reading.
Naming Consistency3/5
Naming mixes verb-first (open_*, close_*, evaluate_*) with noun-style (account_status, print_status, top_setups) and participial (learned_winrates, learned_combos). The print_* group is consistent, but overall there is no single predictable pattern.
Tool Count3/5
22 tools is on the heavy side (16-25 range). The scope covers many features (funding farming, OI hedging, Prints, TA, risk, learning), so the count is defensible, but it pushes the upper bound of what feels scoped.
Completeness4/5
The surface covers account management, funding farming lifecycle, OI hedging, Prints, technical analysis, risk recommendations, and a feedback loop for predictions. Missing a general close-position tool for regular perps and order management, but these are minor given the focused domain.
Average 4.4/5 across 22 of 22 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 225 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Business Source License 1.1.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by explaining that it compares live funding rates, provides recommendations, and computes net carry APR. It also discloses a practical limitation (illiquid exotic/pre-market symbols) that goes beyond the structured 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 three sentences, each adding essential value: the main purpose, the analysis and recommendations, and a practical caution. It is front-loaded and free of filler, making it easy to scan and understand.
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 moderate complexity, the description covers the core functionality, output type (net carry APR), and a key risk (illiquidity). An output schema exists, so return-value details are not needed, but the description could have mentioned any prerequisites or data freshness limitations, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, and the description does not directly explain the 'top' or 'min_carry_apr' parameters. While 'min_carry_apr' is indirectly related to the carry APR concept, the description fails to clarify their meaning or how they affect results, forcing reliance on parameter names alone.
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 ('Plan') and resource ('OI farming on Pacifica with a cross-exchange hedge'). It details what it compares (funding rates across 10+ exchanges) and what it recommends (which side to hold, which exchange to hedge on, and net carry APR), effectively distinguishing it from siblings like scan_funding or open_funding_position.
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 conveys that this is a planning tool (not execution) and gives a caution about illiquid exotic symbols, implying when to use it. However, it does not explicitly name alternatives or state when not to use it, such as comparing against scan_funding for raw funding rates or open_funding_position for execution.
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?
The description adds useful behavioral context beyond the annotations by explaining that the results are empty until enough co-firing signals are graded and fill as the bot runs. This aligns with the openWorldHint and idempotentHint annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with each sentence adding value: purpose, significance/usage, and data availability. It is front-loaded with the main purpose, though the comparative sentence about scanner boosting could be seen as slightly tangential.
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 an output schema, the description covers the core purpose, market-regime context, and data-fill behavior. The main gap is the omitted explanation of the 'top' parameter, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'top' with 0% description coverage, and the description does not mention it at all. The meaning of 'top' (likely top N combos) is left to inference from the name and default, which is insufficient given low 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 shows COMBINATION signal win rates learned from live observation, using the specific verb 'Show' and resource 'combination signal win rates'. It also distinguishes from single-signal tools by emphasizing multiple indicators firing together (e.g., RSI-overbought + Bollinger-upper).
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 usage context by noting combos usually carry a stronger edge than any single signal and that the setup scanner boosts high-win-rate combos. However, it does not explicitly name alternatives like 'learned_winrates' or state when not to use the tool, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as a read-only, idempotent, non-destructive operation. The description adds valuable context: it uses ~9 years of hourly history, computes specific metrics, and discloses a known measured result as of a date. The mention of 'vol_gate()' introduces some ambiguity, but overall it enriches the behavioral picture beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and organized into two paragraphs. It is detailed but not bloated, though the 'print_eval's vol_gate()' reference is an abrupt aside that slightly breaks flow. Still, every sentence contributes meaningful context.
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 statistical complexity and the presence of an output schema, the description provides substantial context: input parameters, methodology, a historical finding, and an exception. It doesn't explain side/symbol semantics or the vol_gate() reference, but overall it is complete enough for an agent to understand the tool's purpose and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the sole source of parameter meaning. It explains shown_apy as the % in the Pacifica UI and distance_pct as distance from mark with a valid range, but leaves side and symbol undescribed. This partial compensation earns a 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 opens with 'Evaluate a Pacifica Print offer statistically,' clearly stating a specific verb and resource. It distinguishes itself from siblings like print_quote, print_order, and print_close by focusing on statistical evaluation rather than execution, and enumerates the computed metrics (fill probability, overshoot, breakeven APY).
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 explains when this tool is useful: to compute expected value for a Print offer given shown_apy and distance_pct. It provides a concrete measured result and an exception condition (ETH short at 2% distance under trailing vol <24.2%), implicitly guiding when favorable windows exist. However, it does not explicitly name alternatives or exclusions, so a 4 is appropriate.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds important context: 'Uses Pacifica's own simulator (undocumented web API, may change without notice)' warns about stability, and 'Free, no execution' clarifies no hidden costs or side effects. It also describes what the quote contains, adding behavioral detail beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the main purpose and then providing necessary context on Print mechanics, parameter semantics, and API caveats. It is moderately long but every sentence contributes to understanding. It is not bloated, though it could be condensed without losing essential 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?
An output schema exists, so explaining return values isn't needed. The description covers the core concept, explains the key parameter behavior (side, strike_price), and warns about API instability. Gaps remain for 'usd', 'game', and 'leverage' semantics, and explicit alternative tool usage, but for a read-only quote tool this is substantially 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 description coverage is 0%, so the description must compensate. It explicitly clarifies 'side' (buy/sell below/above market) and 'strike_price' (0 = auto 1% away from mark). However, 'usd', 'game', and 'leverage' are not directly explained; 'premium per 24h cycle' hints at their role but leaves ambiguity. The description partially compensates but not fully.
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 opens with 'Get a LIVE quote for a Pacifica Print order' and specifies the exact outputs (premium, implied volatility, liquidation price). It also explains the Print concept and clarifies 'Free, no execution', which distinguishes it from execution tools like print_order and evaluate_print.
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 explains when to use the quote mechanic implicitly by describing what a Print is and noting 'no execution', implying execution is a different tool. It also gives concrete guidance for side ('long = buy below market, short = sell above market') and strike_price ('0 = auto 1% away from mark'). However, it does not explicitly name alternative tools or provide a direct 'use this when' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by disclosing the measured (not backtested) win rate methodology, strict honesty gates, the possibility of zero setups being correct, the logging behavior via review_predictions, and the 1-2 minute scanning time. This is extensive behavioral disclosure and aligns with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: it front-loads the core purpose, then explains the measurement methodology and honesty gates. Every paragraph adds necessary context for a complex tool. It is slightly verbose but justified by the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers virtually everything an agent needs to know: exact output fields, timeframe selection, win rate methodology, honesty gates, side effects, and runtime. The only notable omission is the parameter semantics, which is already penalized separately; overall this is near-complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions for its two parameters (top and budget_usd), and the tool description never mentions these parameters or explains how they affect behavior. With 0% schema coverage, the description needed to compensate but did not, leaving the meaning and usage of these parameters entirely ambiguous.
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 opening sentence clearly states the tool scans top-volume Pacifica perps and returns the highest-probability setups with a specific list of output fields (entry, direction, leverage, etc.). It also distinguishes from a sibling tool by directing users to analyze_chart for specific timeframe needs.
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 this tool is for getting high-probability trading setups right now and explicitly tells users to use analyze_chart if they need a specific timeframe. It does not go as far as providing exhaustive when-not-to-use criteria, but it gives clear context and one direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false), the description richly explains the mechanism: it records every firing signal across top-volume coins, grades them against actual outcomes, builds a real-world database over time, and notes it's measured live performance, not backtest. This adds substantial value over the annotations and discloses the early-empty 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 two sentences, front-loaded with the core purpose, and every phrase adds value (e.g., 'whether or not it traded them', 'not backtest', 'Empty early on'). It packs substantial information into a compact, readable format 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?
The tool is a read-only informational query with low complexity, and the output schema presumably covers return structure. The description explains the data's provenance, reliability, and evolution over time. However, the missing explanation of the 'top' parameter leaves a small but real gap in the overall description's completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the only parameter 'top', and the description does not mention it at all. While 'top' likely relates to the number of win rates to return, the description does not clarify its meaning or effect. The default of 15 mitigates the issue, but the lack of any explanation is a notable gap.
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 shows signal win rates 'LEARNED from continuous observation' and explicitly contrasts with backtesting ('not backtest'), making it distinct from potential siblings like learned_combos. The verb 'Show' plus the resource 'signal win rates' is specific and unambiguous.
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 gives clear context on when to expect meaningful data ('Empty early on; fills up as the autonomous loop runs') and an explicit exclusion ('not backtest'), but it does not name alternative tools or provide when-not-to-use guidance beyond that. This is strong but not fully explicit about alternatives.
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 annotations already establish read-only, idempotent, non-destructive behavior. The description adds the qualifier 'active' indicating it returns only open positions, but it does not discuss ordering, pagination, or any edge cases. Since output schema likely covers return fields, the added value here is minimal beyond the annotation.
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 is front-loaded with 'List' and enumerates the included fields without any fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a zero-parameter tool with a clear output schema and annotations that convey safety, the description is sufficient to understand what the tool does and what it returns. It does not need to explain return values in detail because the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined, so there is nothing to describe. The baseline score of 4 is appropriate given zero parameters, meaning no confusion is possible.
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 'List' and clearly identifies the resource as 'my active Pacifica Print deposits' while enumerating the exact fields returned. This distinguishes it from sibling tools like account_status or check_position which likely serve different purposes.
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 (lists active deposits with specific fields) which implies it is for obtaining a snapshot of open print deposits. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of full 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds behavioral context by explaining how to interpret funding values ('Positive funding means shorts collect, negative means longs collect') and that results are ranked by absolute value. This goes beyond annotations to clarify output meaning, though it does not disclose potential rate limits or pagination 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 consists of three concise sentences, each adding value: the primary function, the interpretation of funding signs, and a parameter-specific usage tip. It is front-loaded with the main purpose and contains no redundant or filler content.
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 read-only scanner with rich annotations and an output schema, the description provides sufficient context. It explains the data scope, ranking logic, sign interpretation, and a specific use case. The only missing detail is the 'top' parameter, but the schema default and name make this self-explanatory, and the output schema covers return values.
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 0%, so the description must compensate for parameter meaning. It explicitly explains hedgeable_only ('Set hedgeable_only=true to only show coins that also have a spot market'), but does not explain the 'top' parameter. However, 'top' is an integer with a default of 10, and its meaning is inferable from the ranking context, so it is partially compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Scan funding rates across all Pacifica perp markets, ranked by annualized funding APR (absolute value).' The verb 'scan' and specific resource 'funding rates' provide a precise action and object. It also distinguishes itself from sibling tools like open_funding_position and close_funding_position by focusing on scanning rather than managing positions.
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 on when to use the tool by explaining the significance of positive/negative funding and the hedgeable_only parameter. It mentions a specific use case ('required for delta-neutral farming') but does not explicitly name alternative tools or state when not to use it. This is a minor gap, as the context strongly implies its role as a scanning/analysis tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations (destructiveHint, readOnlyHint, etc.) by explicitly warning that it 'moves funds' and explaining the behavioral difference between confirm=false (preview) and confirm=true (execute after user approval). This adds critical context about side effects and safety that annotations alone do not fully convey.
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 main purpose, and includes the most critical safety warning ('IMPORTANT: moves funds') in the second sentence. Every word earns its place with no redundant 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?
Given the tool has an output schema and annotations, the description provides sufficient context for safe invocation: it explains the purpose, the confirm workflow, and the fund-moving nature. The only gap is the undefined 'game' parameter, which prevents a perfect score. Overall, it is nearly complete for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain parameters. It clearly explains the 'confirm' parameter's behavior ('confirm=false previews, confirm=true executes after user approval'). However, the 'game' parameter is not explained beyond its name and default value, leaving ambiguity about what values it accepts or how it relates to the deposit being closed.
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 ('End a Pacifica Print deposit early and withdraw') with specific verb 'end' and resource 'Pacifica Print deposit', and distinguishes it from sibling tools by naming the exact mechanism ('signed end_game + withdraw_from_game'). The title 'Close Print Deposit' matches the description and is unambiguous.
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 for when to use the tool (to end a deposit early and withdraw) and includes explicit instructions for the confirm parameter ('confirm=false previews, confirm=true executes after user approval'). However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description warns 'moves real funds', explains the mechanics of earning premium per 24h cycle, the strike fill condition, and that the API is 'undocumented, may change'. This substantially enriches the agent's understanding of the tool's behavior and risks, with no contradiction to 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 dense but each sentence earns its place: definition, mechanics, and critical usage warning. The 'IMPORTANT' label front-loads the highest-risk aspect, and the instructions are sequentially actionable. 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?
Given the tool's complexity (mutating, real funds, six undocumented params) and the presence of an output schema, the description covers the essential workflow and risks well. However, the missing parameter definitions for game, side, and leverage leave some operational ambiguity. Still, the core usage and safety guidance are present, making it largely complete for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'usd' via 'Deposits usd', 'confirm' via the preview/confirm flow, and 'strike_price' via 'strike order', but completely omits 'game', 'side', and 'leverage'. For a financial tool with six parameters, this is a significant gap that leaves the agent without necessary guidance.
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 opens with a specific action: 'Place a Pacifica Print order via API', clearly identifying the resource and verb. It distinguishes itself from siblings like print_close, print_status, and print_quote by stating it is the first programmatic access and what the web UI does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage workflow is provided: run evaluate_print and print_quote first, call with confirm=false to preview, then confirm=true only after user approval. This clearly states when to use the tool and the necessary precursor steps, setting it apart from related 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?
Annotations already indicate destructive and non-idempotent behavior. The description adds valuable context beyond annotations: the triggers are enforced even offline, and the two-phase confirm workflow (preview with confirm=false, execute with confirm=true) is disclosed. It also clarifies what 'modifies live protection' entails.
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, structured, and front-loaded. The first sentence states the core action and scope. Subsequent sentences efficiently clarify parameter semantics, offline enforcement, and the confirmation workflow. No filler or redundant 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?
Given the tool's mutating nature, four parameters, annotations, and output schema, the description covers the essential aspects: purpose, open-position prerequisite, parameter semantics, offline enforcement, and the confirm workflow. It does not describe return values, but that is handled by the 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?
The schema has 0% description coverage, but the description compensates by explaining the percentage parameters are distances from the current mark price and that 0 disables that leg. It also explains the confirm parameter's role in the two-phase workflow. The symbol parameter is not explicitly described but is self-evident from the context.
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 specifies a clear action ('Attach EXCHANGE-NATIVE stop-loss / take-profit') and a specific resource ('a position that is ALREADY OPEN'). It explicitly distinguishes from sibling tools like open_with_bracket by emphasizing the position must already be open, regardless of where it was opened.
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 context on when to use: only for positions that are already open. It also gives an explicit workflow with confirm=false for preview and confirm=true after approval. However, it does not explicitly name alternatives or state when not to use beyond the 'already open' condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explicitly stating 'Read-only: it changes nothing, it only proposes,' which directly addresses the readOnlyHint. It also discloses the data sources (account balance, exchange specs, walk-forward validation over ~9 years) and the underlying sizing logic (leverage cancels out, uses minimum leverage). This provides deep behavioral insight that annotations alone do not offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but verbose. The first sentence is a strong front-loaded summary, but the long leverage-explanation paragraph could be condensed. Every sentence provides some value though, so it is not wasteful, but the overall length reduces the conciseness score.
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 an output schema present, the description need not detail return values. It provides enough context about inputs (none) and the reasoning methodology to make the tool's behavior understandable. It lacks details about error cases (e.g., no connected account), but that is not critical for the main usage.
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 zero parameters, so the baseline is 4 per the rubric. The description explains what the tool does without any parameter details, which is appropriate; no additional parameter semantics are needed or added.
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 'recommend' and identifies the resource ('how to size trading') with clear scope: risk per trade, number of positions, leverage, margin mode, and notional cap. It is immediately clear what the tool does and distinguishes itself from siblings like top_setups or open_with_bracket by focusing on advisory sizing calculations.
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 for when to use the tool: to get position sizing recommendations based on the connected account and market specs. It does not explicitly state when NOT to use it or mention alternatives, but the read-only, advisory nature is explicit, so an agent can infer it is for planning rather than execution. This meets 'clear context, no 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?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds value by specifying the return contents, including the unique detail 'any funding-farm position opened by this tool,' which is not in annotations or 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 a single, well-structured sentence that front-loads the action ('Get the connected Pacifica account') and then lists specific items. Every word contributes meaning with 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 simple read-only status tool with no parameters and strong annotations, the description fully covers the tool's purpose and return data. The presence of an output schema also means detailed return formatting is not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters and does not repeat schema information, avoiding redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'connected Pacifica account' and lists the exact data returned (USDC balance, equity, open positions, funding-farm position). This clearly distinguishes it from sibling tools like check_position or print_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 clearly implies when to use this tool (when account-level status is needed) but does not explicitly mention alternatives or when not to use it. The context is clear enough for an agent to select it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds useful behavioral context by listing exactly what status information is checked (live funding APR, price move, exit conditions), which is consistent with the annotations and gives the agent a clear picture of what the tool reports.
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. It front-loads the core purpose ('Check the health of the current farm position') and immediately lists what is checked, making it easy to scan and comprehend.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to explain return values. It fully covers the tool's purpose, the data it reports, and its intended usage. No missing context is apparent for a simple read-only health check 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 description carries no parameter burden. The baseline of 4 applies since there are no parameters to explain; the description focuses on what the tool does rather than inputs.
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 'Checks the health of the current farm position' with specific components (live funding APR, price move, exit conditions). This distinguishes it from sibling tools like open_funding_position and close_funding_position, which are about taking or closing positions.
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 advises 'Use this periodically to decide whether to close,' providing a clear when-to-use instruction. It does not mention alternatives or when-not-to-use, but for a read-only monitoring tool this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as destructive, non-read-only, but the description adds crucial context: 'this places a REAL order', the preview/confirm workflow, the API key requirement, and the builder code caveat. This goes well beyond the 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 structured into clear, focused sentences with line breaks, each adding essential information. The warning about real order placement is prominent and not buried. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with multiple modes, confirmation flow, API key, and a builder code, the description covers all necessary operational aspects. The output schema exists to handle return values, so not describing them is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains all three parameters: mode with its two values and implications, max_usd as a size cap, and confirm with its preview/execution semantics. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Open a funding-farming position' and explains the two modes. It does not explicitly differentiate from siblings like 'open_pacifica_leg' or 'open_with_bracket', but the verb-resource combination 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use hedged vs directional mode and provides a critical usage flow: preview with confirm=false, then confirm=true after explicit user approval. It does not mention alternatives or exclusions, but the context for using this tool is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral context beyond the annotations: it warns 'IMPORTANT: places a REAL order,' requires PACIFICA_API_KEY, describes the confirm=false preview flow, and notes that builder code 'mustache' is attached only if approved. These details are not present in the annotations (readOnlyHint: false, destructiveHint: true) and are essential for safe usage.
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 four sentences, front-loaded with purpose, then workflow, then the real-order warning, and finally builder code detail. Each sentence carries essential information with no redundancy or filler, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return-value details are not required. The description covers the tool's purpose, prerequisites (plan_oi_hedge, API key), side effects (real order, confirm flow), and behavioral constraints. It omits the meaning of max_usd and does not describe post-order actions, but the coverage is sufficient for correct selection and invocation in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies 'symbol' and 'side' by mentioning they represent the perp position's symbol and long/short direction. It also explains 'confirm' via the preview vs. execute flow. However, 'max_usd' is not described at all, and the description does not provide parameter-level details such as accepted values or units, leaving a gap in understanding.
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: 'Open the Pacifica leg of an OI-farming hedge: a perp position on the given symbol and side ('long' or 'short').' This is a specific verb+resource construction that singles out this tool from siblings like open_funding_position and plan_oi_hedge by explicitly naming the Pacifica side and mentioning the OI-farming hedge context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use plan_oi_hedge first to pick the symbol/side, and open the opposite position on the recommended exchange yourself, this tool only executes the Pacifica side.' It also instructs the user to call with confirm=false first and only confirm=true after approval, which is a clear procedural directive for safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond read-only annotations, it discloses that data is never estimated, takes ~30s in multi mode, filters signals by sample count and edge, and warns that win rates are historical not guarantees. These are valuable behavioral details not present in 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 dense but each sentence adds unique value: purpose, data source, interval modes, signal filtering, performance, and limitations. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers execution modes, indicator sets, historical win rates, and fallback guidance. It sufficiently prepares the agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description thoroughly explains the interval parameter, listing all valid values and their effects. It mentions 'a Pacifica market' but does not explicitly describe the symbol parameter's format or constraints, leaving a small gap.
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 performs technical analysis on Pacifica markets using real candle data, and distinguishes between multi-timeframe playbook and single-interval deep snapshot modes. It is specific and actionable.
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 guidance on when to use multi vs single interval, and explicitly suggests pairing with market_context for regime context. However, it does not explicitly exclude any alternatives or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnly/idempotent annotations by warning that 'dip-buying historically loses in extreme fear' and explaining that signal hit-rates depend on regime. This informs the agent about interpretation and risk, which annotations alone do not convey. No contradiction with 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 three sentences, front-loaded with the core content, and each sentence adds essential information: what it provides, when to use it, and its limitations. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with a defined output schema, the description fully explains the tool's purpose, content, and interpretation caveats. It covers the context needed for an agent to decide when to invoke it and how to use its output, making it 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 tool has zero parameters, so the description doesn't need to explain parameter semantics. Per the rubric, a baseline of 4 applies for zero-parameter tools. The description's content about the data provided is sufficient.
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 provides live market context (Fear & Greed index, headlines, funding-rate extremes) and explicitly pairs it with chart analysis. It distinguishes itself from news-chasing by noting the purpose is risk management and regime read, not entry signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage guidance: 'Use this before acting on any indicator signal' and clarifies it is not for 'news-chasing entries.' This tells the agent when to use it relative to other analysis tools, even without naming siblings explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond annotations: it flags a likely regime change when realized win rate falls 10 percentage points or more below predicted, and recommends re-measuring signal statistics. This gives the agent concrete expectations about outputs and side effects (recommendations), which the annotations' readOnly/idempotent hints do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the main purpose, then add actionable details and value. No filler words, and each clause contributes meaning. Well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema that likely details return fields, the description completely covers what the tool does, when to use it, and what behavioral triggers to expect. It also conveys the broader purpose of keeping recommendations honest. Nothing important seems missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the baseline is 4. The description correctly focuses on behavior rather than parameter details, and there are no parameters to explain. It adds value by clarifying what the tool does internally.
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 scores past setups from top_setups against actual outcomes, with specific outputs like hit/miss and calibration. It distinguishes itself from siblings like learned_winrates and top_setups by focusing on retrospective evaluation rather than setup generation or rate lookup.
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 implies when to use the tool—after setups have played out—and describes its role as a feedback loop. While it doesn't explicitly name alternatives or exclusions, the context is clear enough for an agent to know it is for periodic performance review rather than for setting up new trades.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, openWorldHint=true), the description discloses key behavioral traits: it places a real order, has a two-step confirmation flow, uses mark price for triggers, and remains safe even if the bot is offline. This adds significant behavioral context, with no contradictions to 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 concise and well-structured: it opens with the core purpose, then parameter explanations, then an important confirmation warning, and finally a note about builder code. Every sentence serves a purpose, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (six parameters, two-phase confirmation, external order placement), the description covers all essential aspects: the protected nature, trigger price, parameter semantics, and safety flow. An output schema exists, so return values need not be described. The description is complete enough for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the meaning of side ('long'/'short'), usd (notional size), stop_loss_pct/take_profit_pct (percent distance, 0 disables). This adds meaning beyond the schema, which has no property descriptions. Confirm behavior is also described in the usage note. Symbol is self-explanatory, so coverage is effectively complete.
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 primary purpose: opening a perp position with exchange-native take-profit and stop-loss protection. It uses a specific verb-resource pairing ('Open a perp position') and differentiates from sibling tools like open_funding_position and open_pacifica_leg by emphasizing the attached TP/SL brackets.
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: it explains the need to call with confirm=false first and then confirm=true after user approval, and it details parameter usage. However, it does not explicitly mention when to avoid this tool or recommend alternatives, so while guidance is present, exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that confirm=true approves builder code with the user's key, adding meaningful side-effect context beyond the annotations' idempotent and destructive hints. No contradictions with 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?
Three concise sentences deliver purpose, usage constraint, and parameter behavior 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?
For a one-parameter tool with output schema and annotations, the description fully equips an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single boolean parameter confirm is fully elaborated, defining true as acceptance and false as decline, which is absent from the schema's generic 'Confirm' label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it records the user's answer to the Terms of Use question, with a specific verb-resource pairing. It distinguishes from siblings by singularly addressing the Terms workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call only after the user has explicitly answered in chat, and notes the question is asked only once, preventing redundant calls. It sets clear timing and exclusivity conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive and non-idempotent behavior; the description adds critical context: 'places a REAL closing order', the requirement of an API key, and the preview/confirm workflow. This goes well beyond the annotations and informs the agent of real-world consequences.
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 that lead with the action, then cover prerequisites and safety. No filler; each clause adds necessary information for correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and the existence of an output schema, the description covers prerequisites, side effects, and the confirmation workflow. It is complete for agent decision-making, especially within the context of sibling trading tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'confirm' is fully explained: preview with false, execute with true. The schema only provides a default, so the description adds essential meaning and usage semantics, fully compensating for the 0% 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 uses a specific verb and resource: 'Close the funding-farm position previously opened by this tool'. It also clarifies scope ('both legs for hedged mode'), distinguishing it from siblings like open_funding_position, check_position, and print_close.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit step-by-step usage: 'Call with confirm=false first to preview; only confirm=true after the user approves.' Also states the prerequisite of PACIFICA_API_KEY, giving clear guidance on when and how to invoke the tool safely.
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:

[![ocean-agent MCP server](https://glama.ai/mcp/servers/oceanagent/ocean-agent/badges/card.svg)](https://glama.ai/mcp/servers/oceanagent/ocean-agent)

Score Badge

Copy to your README.md:

[![ocean-agent MCP server](https://glama.ai/mcp/servers/oceanagent/ocean-agent/badges/score.svg)](https://glama.ai/mcp/servers/oceanagent/ocean-agent)

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/oceanagent/ocean-agent'

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