WhereItGoes

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description usefully discloses the UTC-day bucketing, which is behavioral information not in the schema. However it says nothing about the time span covered, whether the calendar is sparse or dense, or whether any limits apply — modest gaps against a lowered bar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, and the return contents are front-loaded before the usage cue. Every clause carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only aggregate with a fully documented single parameter and an explicit statement of returned metrics, the description is largely self-sufficient. It could be complete with one more clause on the time range covered or the absence of date filtering.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single optional profile parameter is fully documented in the schema, including the list_profiles prerequisite. The description adds no parameter information beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific resource (activity heatmap) along with its aggregation granularity (per-UTC-day) and the exact metrics returned (trade/movement counts, USD volume, realized P&L). This distinguishes it from sibling aggregates like get_pnl_overview, get_movements, and get_portfolio_history without requiring the schema to be opened.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete usage cue in the user's own phrasing ("my busiest days / when was I most active"), which is enough for an agent to route activity-frequency questions here. It stops short of naming an explicit alternative or a when-not condition, so it is a 4 rather than a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description's only added signal is 'configured', which hints these are alert settings rather than fired alert events — useful but minimal, with nothing about scoping or result shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the resource definition and followed by the usage cue, with no filler. It is arguably too terse rather than too verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only tool with full annotation and schema coverage, the essentials are present. However, with no output schema, the description does not describe what an alert record contains (symbol, threshold, direction, trigger state), which would help the agent interpret and present results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single 'profile' parameter is explained thoroughly in the schema, including the fallback behaviour and the advice to call list_profiles first. The description adds nothing about the parameter, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

It names the specific resource — the user's configured price/threshold alerts — which is enough to separate it from every sibling (all of which cover activity, PnL, transfers, profiles, etc.). It lacks an explicit verb like 'list', so it reads more like a noun phrase than an action, but the intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The quoted user-intent phrase ('what alerts do I have set') gives an explicit trigger for selecting this tool. There is no statement of exclusions or of how it differs from alert history/trigger notification behaviour, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful scope with "all-time" and names the metrics returned, but it does not clarify whether results are for all assets or a single asset, nor does it describe aggregation or output shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero waste. The core resource and time scope are front-loaded, and the usage example is compact and directly useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only stats tool with one optional, fully documented parameter, the description covers the basics. However, the phrase "per-asset" combined with "how much have I traded asset X" implies asset-specific filtering even though no asset parameter exists, leaving a meaningful ambiguity about what the tool actually returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one optional parameter, profile, and schema description coverage is 100%, so the schema fully documents it. The description adds no parameter-level meaning beyond the schema and does not mention the profile option at all, making baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource and metrics: per-asset trade stats covering buys, sells, and volume, all-time. It is distinguishable from siblings such as get_pnl_overview or get_fiat_stats, though it does not explicitly name alternatives to differentiate itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear usage trigger with the example question "how much have I traded asset X", which tells the agent when this tool is appropriate. It lacks explicit exclusions or named alternatives, but the intended context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds real context beyond them: results are pre-valued in USDT and broken down by asset per bucket, so the agent knows it must not perform its own price conversion. It does not cover pagination or precision, keeping it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler. The output shape and the dollar-valuation fact are front-loaded, and the disambiguation instruction follows immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so by naming the two breakdown keys and the USDT unit. All three parameters are documented in the schema. Minor gaps remain around pagination/limits and numeric precision for a potentially large historical series.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the bucket, period, and profile parameters are fully described in the schema, including defaults and enum meaning. The description only echoes the 'per time bucket' concept and adds no syntax or constraint detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and result: deposits and withdrawals valued in USDT, broken down by asset per time bucket, and even names the return keys (depositsByAsset / withdrawalsByAsset). It is clearly distinguishable from the many sibling reporting tools, notably get_movements.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the alternative (/api/movements, i.e. get_movements) and the condition that selects this tool instead: the user wants a dollar-valued deposit/withdrawal breakdown. It also tells the agent it does not need to convert token amounts, which removes a common reasoning detour.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds real behavioral value: results are pre-ranked and USD-valued, so the agent knows the output is a prioritized digest rather than raw records. It does not cover pagination or response shape, but no output schema exists to compensate for, so this is a modest gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: one dense content inventory, one usage cue. Front-loaded and free of filler, though the content enumeration is long enough that it reads as a list rather than a crisp summary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only digest tool with a fully described two-param schema and no output schema, the description supplies exactly what is missing: what categories of change are returned and that they are ranked and USD-normalized. An agent has enough to call it correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with both parameters fully documented, including the enum window semantics and the list_profiles prerequisite for the profile param. The description contributes nothing about parameters beyond what the schema already states, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource precisely — a 'what changed' log for a window — and enumerates its contents (USD flows, allocation shifts, drawdowns, newly-seen sources, reconciliation to-dos). That content signature distinguishes it from sibling point-query tools like get_capital_flow or get_alerts without naming them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use for "what changed / anything unusual / notable moves"' gives a clear triggering intent that maps to how an agent would route a user question. It stops short of naming when NOT to use this or pointing at specific alternatives among the many get_* siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real context about what data the call yields (three rolling windows, P&L and capital-flow figures, activity counts), though it says nothing about result size, sorting, or whether all three windows are always present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the returned metric set, then the routing hint. Every clause carries information and nothing is repeated from the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description summarizes the return payload precisely enough to decide whether the call answers the question. The one parameter is covered by the schema and the safety profile by annotations, so nothing material is missing for a read-only single-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single `profile` parameter is fully documented in the schema, including the fallback to the connection default and the list_profiles prerequisite. The description adds no parameter semantics beyond that, which is the expected baseline for a one-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource (portfolio movement over time) and enumerates the returned metrics: percent and USD change for 24h/7d/30d, net capital in, cash deployed/withdrawn, and trade/movement counts. It also explicitly distinguishes itself from get_portfolio by pointing to /api/portfolio for current total value, so the agent can separate it from its closest sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names concrete user questions ("how much am I up today / this week", "how has my portfolio moved") that select this tool and explicitly routes the contrasting need (current total value) to another endpoint. Both the when-to-use and the alternative are stated, not inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds useful content disclosure (classification fields and native quantity), but says nothing about ordering, pagination, result volume, or whether unclassified deposits are included by default.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the returned payload then the use case. No redundant restatement of the title and no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only listing tool with full schema coverage and annotations, the description covers what the tool returns and when to reach for it. Output schema is absent but the field list in the description compensates adequately; only result ordering/filtering behavior is left unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one optional parameter and schema coverage is 100%, so the schema already explains the profile default and the list_profiles guidance. The description adds no further parameter meaning; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names the resource (deposits) and the specific payload it returns — cost-basis/reconciliation classification plus native quantity — which is more informative than the title's bare 'Get deposits'. It implicitly separates itself from siblings like get_transfers and get_movements by resource type, though it never explicitly contrasts them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The quoted scenario ('which deposits still need a cost basis / classifying') gives a concrete trigger for selecting this tool. It stops short of naming an alternative or stating when not to use it, so no exclusions or routing are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds the fee taxonomy and grouping dimensions, but says nothing about currency, whether results are pre-aggregated vs. per-transaction, or how buckets interact with the period window.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the first delivers the content scope and breakdown axes up front, the second supplies usage triggers. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, zero-required-parameter analytics tool with full schema coverage and no output schema, the description gives enough to call it correctly. Minor gap: no hint about the result's currency/units or whether a grand total is included.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the period enum already explains last_24h/all semantics and the 30-day default, so the schema carries the burden. The description contributes no additional parameter guidance, which is acceptable but earns only the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States precisely what is aggregated (total fees) plus the fee categories covered (trading, on-chain, withdrawal, fiat spread) and the decomposition axes (venue, asset, type). That is enough to distinguish it from siblings like get_fiat_stats or get_income_by_source, though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The two quoted user intents ("what am I paying in fees", "which exchange costs me the most") give concrete triggering contexts and map nicely onto the venue breakdown. No explicit when-not-to-use or sibling routing is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as a read-only, non-destructive, closed-world operation, so the description need not restate safety behavior. The description adds the metric set but does not mention data freshness, pagination, scope limitations, or any behavioral constraints 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler: the first states the metrics, and the second supplies the user-facing use case. Information is front-loaded and appropriately sized for a simple stats tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with one optional parameter, annotations covering safety, and no output schema, the description gives enough detail about what data is returned (money in/out, latest rate, all-time net). It could clarify the time window for money-in/out figures, but the overall picture is complete enough to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one optional parameter (profile), and schema description coverage is 100%, so the schema already explains how to specify the portfolio. The description adds no additional parameter-level meaning, which is acceptable given the high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (fiat cash-flow stats) and lists the concrete metrics returned: money in/out in local currency, latest rate, and all-time net. It is clearly distinct from general movement or transfer tools, though it does not explicitly contrast itself with siblings like get_deposits or get_transfers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a clear usage scenario: "Use for 'how much fiat have I put in / cashed out'." That makes the intended query context explicit, but it does not state when to avoid this tool or name a specific alternative for related fiat queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds the useful clarification of what counts as income, but says nothing about aggregation granularity, currency/denomination of results, or empty-period behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the return content and then the usage cue. Nothing redundant and nothing padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple read-only aggregation with zero required params, full schema coverage, and annotations covering safety — the description is sufficient to call it correctly. Minor gap: no output schema exists, and the description doesn't characterize the response shape beyond 'grouped by source' (e.g., per-source amounts vs. counts).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters (period, profile) carry thorough descriptions, including enum guidance and the list_profiles cross-reference. The description adds nothing beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States precisely what is returned: income (with concrete examples — yield, staking rewards, airdrops) grouped by source. The grouping dimension implicitly separates it from get_income_timeseries, but no sibling is named explicitly, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete trigger phrase ('where does my income come from') that maps a user intent to this tool, which is more than most siblings offer. It does not state when to prefer get_income_timeseries or get_pnl_overview instead, so no explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that results are bucketed over time; it says nothing about currency/unit normalization, whether empty buckets are returned, or what happens for accounts with no income.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the resource scope front-loaded. The second sentence is slightly redundant with the first but does supply a concrete user-phrasing trigger, so it earns most of its space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-required-param read tool with no output schema, the definition is minimally adequate but leaves the return shape implicit: an agent cannot tell whether buckets are rows of {timestamp, amount} or aggregated totals, nor what the amounts are denominated in.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both enums are documented in-schema, including bucket and period defaults. The description adds no meaning beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource – income received, bucketed over time – which reads clearly against siblings like get_income_by_source (breakdown by source) or get_portfolio_history (value, not income). It doesn't name those siblings explicitly, so the differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The quoted use case "how much yield/rewards over time" implies when to reach for this tool, but there is no exclusion rule and no pointer to get_income_by_source as the alternative when the user wants a per-source breakdown rather than a time series.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the read-only safety profile, and the description adds genuinely useful context beyond them: amounts are in native token units (not USD) and results include items[] plus facet counts. It stops short of disclosing pagination or truncation behavior when limit is exceeded.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with the core identity and the important native-units caveat front-loaded, then the return shape, then the use case. Nearly every clause earns its place, with only mild redundancy between the opening list and the closing use-case list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does the necessary work of explaining that results come back as items[] with countsBySource/countsByVenue/countsByStatus facets. The main outstanding gap is guidance on default period behavior and behavior when many rows match.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are fully documented structurally. The description adds a small amount of interpretive value by naming the breakdown dimensions (source, venue, asset), but adds no syntax or default guidance beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource ('the raw money-movement ledger') and enumerates the movement types it covers (deposits, withdrawals, transfers, income, trades). It does not, however, distinguish itself from close siblings like get_deposits and get_transfers, which cover overlapping ground.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The quoted use case ('list/break down my deposits...') gives an implied trigger, but it never says when to prefer this tool over get_deposits, get_transfers, or get_capital_flow, even though those siblings overlap heavily. The agent must infer the choice rather than being routed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds the meaningful qualifier that results are *realized* only, but says nothing about the reporting period, whether symbols with zero realized P&L appear, or how many rows default without a limit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero filler, with the core definition front-loaded before the usage hint. Nothing could be removed without losing signal, and it is small enough that the phrasing is not lost in the agent's context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 100% schema coverage and no output schema, the main burden on the description is to convey what comes back, and it does at a high level (realized P&L per symbol). The notable gap is time scope: there is no date parameter and the description never states the period covered, which is the single fact an agent most needs to avoid overstating the answer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so limit, quote, and profile are fully documented in the schema, including the 200-row cap and the list_profiles hint. The description adds no meaning beyond the schema — it does not explain how quote conversion affects the P&L figures or how limit interacts with the per-symbol breakdown.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and breakdown dimension: realized P&L aggregated per traded symbol. This implicitly separates it from the portfolio-level get_pnl_overview, but the description never names that sibling or any other, so differentiation is left to inference from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Use for "which coins made or lost me the most (realized)"' gives a concrete user question that maps to this tool, which is strong positive routing guidance. There are no exclusions, however: it never says when to prefer get_pnl_overview, nor that unrealized P&L is out of scope for this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, non-destructive, closed-world), yet the description adds high-value behavior: values are end-of-day marks off the daily history series, not live quotes, and will not match the live total. It also discloses the non-obvious calculation (deposits/withdrawals stripped out), which no structured field conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and scope are front-loaded, and the warning sentence is load-bearing rather than filler. It runs slightly long with the parenthetical about startValueAsOf/endValueAsOf, but no sentence is expendable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-param read tool with full schema coverage and no output schema, the description supplies the missing piece an agent would otherwise get wrong: what the returned values mean and what they must not be reported as. Alternatives and intent triggers are covered, leaving no material gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the period enum and profile resolution note are already documented in the schema. The description adds no parameter-level detail of its own; its startValue/endValue guidance concerns return values, not inputs. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource with an unusual qualifier: "TRUE profit and loss ... with the user's own deposits and withdrawals stripped out," then enumerates the components (realized vs unrealized, net flows, income, fees, top gainers/losers). That is enough to separate it from siblings like get_pnl_by_symbol and get_portfolio without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete user-intent triggers ("am I actually up or down", "how much have I made") and an explicit exclusion with a named alternative: do not use endValue as current value, use get_portfolio instead. Both the when and the when-not are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish this as a safe, read-only, closed-world read, so the description is not obligated to restate safety. It earns credit for describing the return shape (portfolio total plus per-asset quantity/value/weight) and for framing the result as a present-state answer rather than a time series; the remaining gap is that it says nothing about data freshness or whether the snapshot is live versus last-synced (get_sync_status exists as a sibling, hinting staleness is a real concern).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the return shape and then the routing guidance; the quoted user-intent list is dense but performs real disambiguation work. Minor waste in the redundant "current value / net worth / how much do I have" clustering, but nothing that harms selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly takes on the burden of describing return values and does so at a useful level of detail (portfolio total, per-asset fields, weights). It falls just short of complete because it does not clarify relationship to the two nearest siblings or note whether the numbers are live or cached.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single profile parameter is already well documented in the schema, including the "call list_profiles first" advice. The description adds no additional meaning about profile resolution or default-connection behavior, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-and-resource framing and enumerates the returned fields (totalUsdt, per-asset quantity, USD value, weight), so the agent knows exactly what a call yields. However, the phrase "Current holdings snapshot" sits uncomfortably close to the sibling tool get_portfolio_snapshot, and the description never acknowledges that sibling, leaving a real disambiguation gap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete user-intent triggers ("how is my portfolio", "net worth", "biggest positions") and explicitly excludes the P&L use case, which is strong routing guidance. But the exclusion is by vague reference ("the P&L tool") rather than by name, and it is silent about get_portfolio_snapshot and get_portfolio_history, which are the more confusable alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish that this is a safe read operation. The description adds the payload-size profile: the full response carries a value and a quantity for every asset on every day, which is genuinely useful cost information not in the annotations. It says nothing about latency or caching, but the main behavioral risk, a heavy response, is covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with what is returned, then when to use it, then the key calling hint. Each sentence carries distinct information, with no repetition of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is no output schema, the description names the fields returned and flags the payload difference between modes, which is enough to call the tool correctly. It doesn't mention the default period's effect on result shape or how gaps or missing days appear in the series, a minor omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema defines all three parameters. The description adds the reason behind the `slim` recommendation (avoiding the per-asset payload), which goes beyond the schema's bare 'recommended' label, and the prompting guidance makes the tradeoff actionable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

It names the resource and its contents specifically: the daily series of total value, net capital in, and opening capital per day. This is clearly a historical time-series tool, distinguishable from snapshot siblings such as get_portfolio_snapshot in what it returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete user-intent triggers, e.g. 'how has my portfolio grown', 'what was I worth in June', and 'chart my history', so the agent can match a request to this tool. It doesn't state exclusions against the sibling tools, such as when to use get_portfolio_snapshot or get_dashboard instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare it as a safe read-only operation with no open-world access. The description adds a meaningful behavioral constraint (requires a Pro plan) and lists the return contents (health score plus diversification, risk, activity, cost grades), though it does not describe score range or format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste: front-loaded return description, then example usage, then prerequisite. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with no output schema, the description adequately covers purpose, usage, plan requirement, and return components. It stops short of specifying score format or grade semantics, but overall it is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States the specific resource returned (portfolio health score and component grades) and gives natural-language use cases. It distinguishes itself from general portfolio or risk-metric tools by naming component grades, but does not explicitly contrast with the closest sibling, get_risk_metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear example user phrases ('how healthy is my portfolio', 'rate my portfolio') that indicate when to invoke it. It also states the Pro plan requirement, but does not 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish that this is a safe read-only operation. The description adds important context beyond annotations by disclosing that risk metrics, health score, and ranked findings are included only on a Pro plan, preventing false expectations about returned data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, follows with usage routing, and ends with a concise plan-gating caveat. Each sentence carries useful information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex aggregate tool with no output schema, the description sufficiently enumerates the returned data and notes plan-gated exclusions. Combined with the fully documented optional parameter, an agent has enough information to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the single profile parameter is fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: it summarises the whole portfolio in one call. It enumerates the exact contents (total value, allocation, concentration, P&L, target drift, BTC/ETH context) and distinguishes itself from drill-down tools by positioning itself as the starting point.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to START HERE for broad questions like "how is my portfolio doing" and to use specific tools afterwards to drill in. This gives clear usage context, though it does not name the exact sibling tools an agent should switch to.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds real semantic context by defining drawdown as 'flow-honest' (deposits/withdrawals excluded from losses) and disclosing the Pro-plan requirement. It stops short of noting data-availability constraints such as how short windows affect Sharpe/beta reliability.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the resource, then the metric list, then the non-obvious caveat and the plan requirement. No filler or repeated field names beyond what is needed for orientation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully enumerates the returned metrics, which is the main thing an agent needs. It is slightly incomplete on return shape/precision and on how window length affects metric validity, but nothing required to invoke the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains period, profile, and benchmark including defaults and the list_profiles hint. The description only restates that the benchmark is BTC or ETH for beta/correlation, adding no syntax or edge cases beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific resource and scope: 'RISK metrics for a window', then enumerates the exact metrics produced (max drawdown in % and USDT with peak/trough dates, volatility, Sharpe, beta, correlation). This clearly separates it from siblings like get_pnl_overview or get_portfolio_score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the metric list rather than stated: an agent can infer it should call this for drawdown/volatility/Sharpe/beta questions. There is no explicit when-to-use/when-not guidance and no named alternative for adjacent questions (e.g., performance vs risk). The Pro-plan prerequisite is the only concrete gating statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is fully covered upstream. The description's real contribution is the temporal constraint 'right now', signalling this is a live point-in-time check rather than a history lookup — useful, but it leaves unanswered what is returned when no sync exists and whether a sync can be triggered from here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, with the substantive answer ('whether a sync is running or queued, and its queue position') front-loaded before the usage hints. Every clause carries information an agent would otherwise have to infer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does sketch the return shape (running vs queued, plus queue position), which is the minimum an agent needs to interpret results. The only gap is the no-active-sync case and the absence of any indication that this is not a trigger tool; both are minor for a read-only, single-optional-param call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single optional parameter and the schema already documents it at 100% coverage, including the 'omit to use the connection default' behaviour and the list_profiles fallback. The description only echoes 'for this profile' and adds no format or lookup detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact state being read (whether a sync is running or queued) plus a second dimension (queue position), which is concrete enough that an agent can distinguish it from the surrounding portfolio-data siblings like get_changes or get_portfolio_snapshot. It does not explicitly contrast itself with any of them, which keeps it out of 5 territory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives two natural-language triggers ('is my data up to date', 'is it still syncing') that map user intent directly onto this tool, which is strong routing guidance. It stops short of naming an alternative or stating when not to call it (e.g. for historical sync runs or for a full data refresh), so no exclusions are covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description goes well beyond them by disclosing the null case (never set a target), the two possible dimension axes, and the precise semantics of bandPct as percentage POINTS with a worked 40%±5 example. That resolved-ambiguity detail is exactly the kind of behavior an agent cannot infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core definition, then scope semantics, then usage routing — a sensible order with almost no filler. The parenthetical ticker/sector examples and the caps emphasis are slightly verbose, but they carry real disambiguating value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully carries the return contract (rows, dim, targetPct, bandPct units, null) plus the boundary with the drift tool. Nothing an agent needs to call or interpret this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With one optional parameter and 100% schema description coverage, the schema already explains `profile` and its default-connection behavior, so baseline 3 applies. The description adds no parameter-level detail of its own, which is acceptable but does not improve on the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (the user's target allocation) with an explicit framing that distinguishes it from actual holdings: 'the plan they MEANT to hold'. The return-shape notation (`set.rows` of {subject, targetPct, bandPct}, or `set: null`) and the `set.dim` explanation of what a subject is make the scope unambiguous against siblings like get_portfolio_snapshot.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete trigger phrases ('what is my target allocation', 'what was my plan', 'am I off my targets') and an explicit exclusion with the correct alternative: drift lives in get_portfolio_snapshot, which scores intention vs. actual together. An agent can route between the two without opening either schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnly, non-destructive, closed-world behavior, so the description's job is to add domain semantics — and it does, by explaining that results are matched pairs (withdrawal linked to deposit), which tells the agent what the records mean rather than just that they exist. It says nothing about ordering, pagination, or completeness of matching, which would be the next useful layer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste, with the definition of the resource front-loaded before the usage trigger. Nothing to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-optional-param read tool with full annotation coverage, the description supplies enough to call it correctly. The notable remaining gap is the absence of an output schema combined with no description of result shape or whether a date range is implicitly bounded.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one optional parameter (profile) and schema coverage is 100%, including guidance to call list_profiles first. The description adds no further meaning about the parameter, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific resource with a precise definition: internal transfers are withdrawals paired to deposits between the user's own venues/wallets. That definition meaningfully separates it from unpaired deposit/withdrawal listings. It stops short of naming the confusable siblings (get_movements, get_deposits), so it doesn't reach full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It supplies an explicit user-intent trigger in quotes ('show my transfers between exchanges/wallets'), which maps cleanly onto a request an agent will encounter. There is no when-not guidance or named alternative for overlapping tools like get_movements or get_deposits.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the response contains names only and never credentials, which matters for how the agent reports results. It doesn't mention the empty/not-connected case.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with no waste: the resource and its output constraint come first, the usage trigger second. Nothing could be removed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with full annotation coverage and a fully documented parameter, the description supplies the output shape (names only) and the intent trigger. Only the behavior when no exchanges are connected is unaddressed, a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the single profile parameter is thoroughly documented with default and list_profiles guidance. The description adds nothing about profile semantics, so the baseline 3 applies since the schema does all the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and scope: the connected exchanges/venues, returning names only and never keys. This is clearly distinguishable from data-heavy siblings like get_portfolio or get_transfers, though it doesn't explicitly contrast with get_wallets, which is the nearest ambiguous neighbor.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit trigger phrase ("which exchanges am I connected to") that tells the agent exactly what user intent maps here. It gives no exclusions or alternatives, but for a simple read tool the positive routing cue is sufficient context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, non-destructive, and closed-world behavior, so the description need not repeat safety. It adds useful scope by saying these are the user's tracked on-chain wallets and lists returned fields, but it does not cover pagination, ordering, or empty-result behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact sentences with the resource and use case front-loaded. There is no redundant or filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one optional fully documented parameter and no output schema, the description covers the resource, returned fields, and primary use case. It is nearly complete, with only minor gaps around result scope or ordering.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single optional profile parameter is fully described in the schema, including the fallback to the connection default and the suggestion to call list_profiles first. The description adds no parameter detail beyond the schema, which is acceptable given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the resource: the on-chain wallets the user tracks, including address, label, and chains. It distinguishes the contents from many portfolio-oriented siblings by emphasizing wallet tracking, though it does not explicitly name alternative tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a direct intended use case: answer the question “which wallets am I tracking.” This is clear context for invocation, but it does not state when not to use the tool or mention alternatives such as get_venues or portfolio tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds the return payload shape and the fact that this is a prerequisite lookup, not a data-heavy read. It doesn't discuss cost, caching, or whether results reflect live sync state, but nothing misleading is present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with what is returned, then the calling rule, then the exception. No filler or restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description compensates by naming the returned fields and the active-portfolio indicator. For a zero-parameter, read-only lookup tool, nothing an agent needs to call it or interpret its result is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4; the schema is empty and there is nothing to document. The description still adds cross-tool semantics by explaining that the returned name/id feeds the `profile` argument of other tools, which is value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('The portfolios on this account') and enumerates the returned fields (id, name, exchange/wallet counts) plus the active flag. This clearly separates it from the singular get_portfolio and from venue/wallet siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit ordering rule ('Call this FIRST when the user names a portfolio'), a trigger example, and a negative case ('An account with one portfolio needs none of this'). It also names the downstream use of the result (pass name or id as the `profile` argument), so an agent knows both when and why to call it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint=true and readOnlyHint=false, but the description goes well beyond them by explaining the exact destruction semantics: the call REPLACES the whole plan, omitted subjects are deleted, and an empty rows array deletes the plan entirely. It also discloses that the call is non-effective until the user approves a returned link — behavior no annotation conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The replacement/destruction warning is front-loaded with emphasis before the mechanics, and the approval-link caveat follows. Despite being multi-sentence, every clause carries information an agent would otherwise get wrong — no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with no output schema, the description covers the destruction model, the axis constraint, the profile default, the prerequisite read call, and the fact that the return value is an approval link rather than an applied change. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds genuine semantics beyond the schema: rows is the COMPLETE plan with delete-on-omit behavior, and dim is constrained to 'asset' (tickers) vs 'sector' (our sector names) with a resolution path when ambiguous. The profile parameter is left entirely to the schema, keeping it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: proposes a change to the user's target allocation, defined in-line as 'the plan they mean to hold'. It is clearly distinguishable from the sibling get_target_allocation, which it explicitly references as the read counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-do-what routing: call get_target_allocation first so you edit the real plan, call it also if unsure which axis the plan uses, and call list_profiles when the user names a portfolio. It also states the follow-up action required after the call (tell the user to open and approve the link).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.