Market-phase classifications over a metered API — phase events per currency and timeframe.
Scored across 9 tools
Each tool targets a distinct resource and action; the two phase-fetching tools are clearly separated as single vs batch. System tools for balance, usage, notifications, and deposit polling have no functional overlap.
Naming is consistently snake_case with clear domain prefixes (bfxpremium_, system_, trendvane_) and mostly follows a verb_noun pattern. A few names like trendvane_phase_resolution_stats and system_deposit_poll deviate slightly but remain predictable.
With 9 tools, the set is well-scoped for a crypto analytics and account-management server. Each tool has a distinct purpose, and there is no bloat or duplicative functionality.
The tool surface covers the core workflows: metadata, current phase readings (single and batch), premium data, stats, and account/billing management. Minor gaps like no historical phase queries or in-app deposit management are workaround via the dashboard.
Call this right after you send a stablecoin deposit to have it picked up sooner: it tells the system to check your deposit addresses now. It moves no money and is free. If it comes back with nothing, you don't have a deposit address yet, so add one from the web dashboard.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotation, the description discloses that the tool 'moves no money and is free,' that it triggers an immediate check of deposit addresses, and what an empty result means. This gives an agent a clear safety and side-effect profile without relying solely on readOnlyHint.
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 three tight sentences, front-loading the exact moment to call the tool and its purpose. Every sentence adds useful information: when to call, what it does and doesn't do, and how to interpret an empty response.
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?
The description adequately covers when to call, what the call triggers, and the meaning of an empty result. It does not describe the exact shape of a successful response, but with zero parameters, no output schema, and a simple poll behavior, this is 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?
With zero parameters, there is no schema semantics for the description to enhance. The description still adds useful context by explaining what the no-parameter call accomplishes, which meets the baseline for a parameterless 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 states a specific verb and resource: it 'tells the system to check your deposit addresses now' and is to be called 'right after you send a stablecoin deposit.' This clearly distinguishes it from the sibling tools, which focus on balances, notifications, usage, and phases.
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 description gives explicit timing ('right after you send a stablecoin deposit'), the reason ('to have it picked up sooner'), and a conditional follow-up if the poll comes back empty (no deposit address yet; add one from the web dashboard). This is strong operational guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your prepaid balance before a paid call. Shows the credit you have left to spend, anything on hold, any bonus credit and when it expires, whether the account is paused, the current pricing, and the deposit addresses on your account. It's free. If you run out, paid calls are turned away until you top up. To add a deposit address, sign in to the web dashboard.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already declares the read-only nature. The description adds value by noting 'It's free,' explaining the consequence of running out ('paid calls are turned away until you top up'), and clarifying that deposit addresses cannot be added via this tool (use the dashboard). These details go beyond the annotation and set correct expectations about side effects and costs.
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 informative but not overly verbose. It front-loads the primary purpose and then lists specific data elements, followed by essential usage notes. Each sentence contributes: the 'free' note, the consequence of zero balance, and the dashboard redirect for deposits. It's slightly long but efficiently organized, with no 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 zero-parameter, read-only balance check with no output schema, the description is fully sufficient. It enumerates what information will be returned (credit, hold, bonus, expiry, pause status, pricing, deposit addresses), clarifies the cost, and explains the behavioral outcome of insufficient funds. An agent has everything needed to decide when to call and what to expect, without needing additional schema or annotations.
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 has zero parameters, so schema coverage is trivially 100%. The description does not need to explain any parameters, and it doesn't. Per the rubric, a baseline of 4 is appropriate for 0-parameter tools; the description adds no parameter-specific information because none is needed.
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 opens with a specific verb and resource: 'Check your prepaid balance before a paid call.' It clearly enumerates the exact data points returned (credit, hold, bonus credit, expiry, pause status, pricing, deposit addresses), which distinguishes it from siblings like system_get_usage (usage) and system_get_notifications (notifications). An agent can immediately understand the tool's scope.
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 states when to use it: 'before a paid call.' It also explains the consequence of insufficient balance and instructs that adding a deposit address requires the web dashboard, implying this tool is read-only. While it doesn't name alternative tools explicitly, the usage context is clear and provides practical guidance on when to invoke this tool versus external actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read your account messages: support, billing, and account notices. With no arguments you get the ten most recent in each group, each with a cursor; pass a category and cursor to page further back. It's read-only and free, and it never marks anything as read. Security alerts aren't available here, and any group you've switched off for API access won't show up.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Opaque pagination cursor from a previous nextCursor (requires category). | |
| category | No | Drill into one category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, and the description effectively discloses it's read-only, free, and never marks messages as read, adding value beyond the annotation. It also mentions that disabled groups are omitted, which is behavioral context not captured in annotations. Slight deduction for not describing the output structure in detail, but not critical.
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 concise, front-loading the core purpose and usage, and every sentence adds value—covering default behavior, parameters, read-only nature, and exclusions. No waste 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 two-parameter tool with no required parameters and an existing schema, the description provides all necessary information: default behavior, pagination usage, read-only guarantee, and exclusions. Nothing critical is missing for 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents both cursor and category parameters. The description adds context by explaining how cursor and category work together for pagination, which is marginally helpful. Given the high coverage, a 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 clearly states the tool reads account messages across support, billing, and account notices, using a specific verb and resource. It distinguishes itself from siblings by specifying its unique functionality of retrieving notifications, which is not indicated by any sibling tool name.
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 explains when to use it: with no arguments for recent items, and with category and cursor for pagination. It also states exclusions: security alerts are not available and disabled groups won't show, providing clear context and alternatives for such cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your history of paid calls, newest first. For each one it shows which tool you used, the coins and timeframes, how much data came back, and what it cost. Free. Page back through older calls with before, using the cursor the previous page returned.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows per page (1–200, default 50). | |
| before | No | id cursor from a previous page's nextBefore (older rows). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds meaningful behavior: the call is free, results are ordered newest first, each entry includes specific fields, and pagination uses a cursor from the previous page. This is strong disclosure for a read-only history tool.
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 short sentences, each earning its place: the first states the purpose and ordering, the second describes the output contents, and the third explains pagination. It is front-loaded and free of 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 read-only tool with no output schema, the description covers what the response contains, ordering, pagination, and cost. Together with the input schema and annotations, an agent has everything needed 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 description coverage is 100%; both `limit` and `before` already have clear descriptions. The tool description only re-states the cursor behavior without adding new parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool returns the history of paid calls, newest first, and enumerates the displayed fields (tool used, coins/timeframes, data returned, cost). This distinguishes it from sibling tools like system_get_balance or system_get_notifications.
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 description implies usage: it is for reviewing past paid calls and navigating older pages with the `before` cursor. However, it does not explicitly state when to choose this tool over sibling alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get phases for several coins and timeframes in one paid call. Set kind to 'boundary' for the settled last-closed-bar reading or 'updates' for the still-forming one. The cost scales with how many readings come back, which is your coins times your timeframes.
| Name | Required | Description | Default |
|---|---|---|---|
| tfs | Yes | ||
| kind | Yes | 'boundary' = the settled reading from the last closed bar; 'updates' = the live reading still forming in the current bar. | |
| currencies | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds valuable behavior beyond that: this is a paid call and cost scales with coins × timeframes. It also clarifies the semantic difference between settled last-closed-bar readings and still-forming updates. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no filler. The main operation is front-loaded, the 'kind' distinction is explained immediately, and the cost warning is placed last as supporting context. Every sentence 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 paid bulk-read tool with no output schema, the description covers the main things an agent needs: required parameters, the choice between settled and forming readings, and cost behavior. It does not describe the response shape or valid currency identifiers, but given the read-only annotation and simple parameter structure, the description is largely sufficient.
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 only 33%, so the description must compensate. It does explain 'kind' and generally maps 'currencies' and 'tfs' to coins and timeframes, but it does not specify the expected currency string format or any limits on array sizes. It adds some value but leaves part of the parameter semantics to inference.
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 states a specific verb ('Get'), a clear resource ('phases'), and the distinguishing scope ('several coins and timeframes'), which separates it from the singular sibling trendvane_get_phase. It also names the two 'kind' variants, making the operation 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 description conveys clear when-to-use context: use this for multiple coins and timeframes in a single paid call, and choose 'boundary' vs 'updates' depending on whether the bar is closed. It does not explicitly list when-not-to-use or point to a single-coin alternative, but the bulk-vs-single distinction is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current market phase for one coin, across a timeframe. This is a paid call. Set kind to 'boundary' for the reading from the last closed bar, which is settled and won't change, or 'updates' for the live reading still forming inside the current bar. Leave tf off, or set it to 'all', for every timeframe.
| Name | Required | Description | Default |
|---|---|---|---|
| tf | No | Timeframe; omit or 'all' for every enabled timeframe. | |
| kind | Yes | 'boundary' = the settled reading from the last closed bar; 'updates' = the live reading still forming in the current bar. | |
| currency | Yes | The currency to classify. Call trendvane_list_phase_meta for the enabled set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this as read-only. The description adds valuable context beyond annotations: it is a paid call, and it clarifies that 'boundary' is settled and won't change while 'updates' is still forming. No contradiction with readOnlyHint.
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, each earning its place: the operation, the paid-call warning, and the two parameter decisions. No filler, and the core purpose is front-loaded.
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 call with full schema coverage, the description covers the core operation, the paid nature, and the meaningful distinction between the two kinds of readings. It does not describe the response shape, but with no output schema and an understandable 'get phase' return, this is 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 coverage is 100% and the schema already documents all three parameters. The description still adds practical guidance, especially around the default behavior for 'tf' (omitting it or setting it to 'all') and the settled-versus-live distinction for 'kind'.
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: 'Get the current market phase for one coin'. The phrase 'for one coin' clearly separates this from sibling tools like trendvane_list_phase_meta or trendvane_compose_phases.
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 clear operational context: the call is paid, and it explains when to use 'boundary' versus 'updates' and how to request all timeframes. It does not explicitly name sibling alternatives or say when not to use the tool, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tool to call first, and it's free with no account. Lists the phases the model can report, the timeframes and currencies covered, and a short card for each phase explaining what it means and what tends to come next. Also returns the current pricing, so you can work out what a paid call costs before you make one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful non-obvious behavioral facts: the tool is free, requires no account, and returns current pricing so users can evaluate costs before a paid call. This goes beyond the structured annotation without contradicting it.
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 most actionable information ('The tool to call first'), and every clause contributes value. No filler or repetition.
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-parameter list tool with no output schema, the description fully covers what the tool returns, why it should be called first, and its cost/free status. An agent has everything needed 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?
There are zero parameters, so the schema leaves nothing to document. The description explains what the tool returns instead, which is appropriate and sufficient for a parameterless metadata endpoint.
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 the specific verb 'Lists' and clearly identifies the resource: phases, timeframes, currencies, and per-phase cards. It also distinguishes this tool from siblings like get_phase by emphasizing that it returns overview metadata and pricing, not a single phase.
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 description explicitly says 'The tool to call first' and notes it is free with no account, giving clear guidance on when to use it. It does not explicitly name alternatives or exclusions, but the 'call first' directive and pricing purpose provide strong contextual usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, and how you read meaning into a phase. For each one it shows what usually happens next, how often a trend keeps running, and how the typical move rewarded you against how far it drew down first. Every figure comes with the number of past cases behind it. It's a behavior model built from years of Bitcoin history, not live per-coin data, so pair it with trendvane_get_phase.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safety profile is already known. The description adds context that the data is historical and that every figure includes a sample size, which are useful behavioral details. It does not contradict the annotations and adds some value beyond them, though it could be more explicit about output structure.
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 only a few sentences but includes a confusing opening ('Free, and how you read meaning into a phase') that adds no value and detracts from clarity. The key information is present, but the structure is not tight and the phrasing is awkward. It could be significantly more concise and front-loaded.
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 stats tool with no parameters and no output schema, the description gives a good sense of what is returned: next-step tendencies, continuation rates, reward vs. drawdown, and sample sizes. It also mentions the historical nature and pairing advice. Minor gaps include not explaining what 'Free' means or how the stats are formatted, but overall it is sufficiently complete for an agent to understand the tool's value.
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 has zero parameters, so the baseline is 4. The description does not need to explain any parameters, and the schema confirms no inputs are required. No additional parameter semantics are necessary.
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 conveys that the tool provides statistical insights about phases (what happens next, continuation rates, reward vs. drawdown, sample sizes), built from historical Bitcoin data. However, the opening phrase 'Free, and how you read meaning into a phase' is confusing and undermines clarity. It does name a specific resource (phase resolution stats) and distinguishes itself from live per-coin data, but the purpose is not stated as a crisp verb+resource.
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 description advises pairing with trendvane_get_phase and clarifies that it is a historical behavior model rather than live data, which helps an agent know when to use it (for historical context) and when not (for live data). It does not explicitly list alternatives or exclusion conditions beyond the live-data caveat, so guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
bfxpremium_get_premiumcompose_phasesget_phasetrendvane_compose_phasestrendvane_get_phasedeposit_pollget_balanceget_notificationsget_phase1 field changedInput schema / properties / currency / descriptionPrevious value: -"The currency to classify. Call list_phase_meta for the enabled set."New value: +"The currency to classify. Call trendvane_list_phase_meta for the enabled set."get_usagelist_phase_metaphase_resolution_statssystem_deposit_pollsystem_get_balancesystem_get_notificationssystem_get_usagetrendvane_list_phase_metatrendvane_phase_resolution_statscompose_phasesdeposit_pollget_balanceget_notificationsget_phaseget_usagelist_phase_metaphase_resolution_statsHourly crypto news sentiment and typed market events, with sources on every signal.
Crypto regime classifier for trading agents. 100% bounded regime accuracy. 50 free calls/day.
Crypto backtesting & Bitcoin cycle analytics. Point-in-time, DSR-corrected, look-ahead-aware.
Live crypto trend signals, ranking, and backtesting for BTC/ETH/SOL/XRP/ADA. x402 pay-per-call.
Add one secure layer between your agents and this server.
