Daily exit context, depth, tiers, and sealed records. No commodity futures or execution authority.
Where this caller stands: whether the bearer token verified, the entitlement tier behind it (checked fresh, never trusted from the token), today's tool-call meter, and how to get full access. Call this first when a subscriber tool is missing from tools/list or a call is refused.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark it read-only and idempotent; the description adds that the entitlement tier is checked fresh rather than trusted from the token, conveys that it reports today's meter, and notes how to get full access. It does not detail the exact return shape, but enough behavior is disclosed for a zero-parameter status call.
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?
Every sentence earns its place: the first lists what the status report contains, and the second names the trigger condition. It is front-loaded with the most important information and contains 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 zero-input read-only diagnostic, the description fully supports correct invocation: it names the output categories, states the freshness semantics, and gives the practical situation in which to call it. No output schema is provided, but the response's informational purposes are described sufficiently.
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 no parameters, so there is nothing to document beyond the schema, which already has 100 percent coverage. The baseline of 4 applies because the tool cannot have parameter ambiguity.
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 plainly reports a specific resource: the caller's access status — token verification, entitlement tier, current tool-call meter, and how to get full access. It is distinguishable from the sibling tools because it is an access-status diagnostic rather than a market or trade tool.
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 an explicit trigger condition: call this first when a subscriber tool is missing from tools/list or a call is refused. This tells the agent exactly when to invoke it and what problem it resolves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Realized depth-collapse episodes in BTC ±1% aggregate depth: onset, trough, drawdown fraction and recovery time for each episode that crossed the pre-registered threshold. Detection rules were declared before any episode accrued. Use when asked whether crypto liquidity has actually broken lately, as opposed to how it looks right now. The subscriber exit_desk_full carries the ETH desk beside BTC.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description does not need to re-cover safety. It adds useful context: episodes are realized (not forecasts) and detection rules were pre-registered, which addresses hindsight bias. It stops short of giving units or threshold values for recovery time and drawdown.
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 first three sentences are clear and front-loaded, but the final sentence about 'subscriber exit_desk_full' is vague, unexplained, and does not clearly connect to the tool's purpose or the sibling list. Not 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 0-parameter, read-only tool with no output schema, the description is largely complete: it names the dataset, scope, output fields, and intended use. The missing threshold value, units, and the confusing exit_desk_full note keep it from being fully self-contained.
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 and schema description coverage is 100%, so the schema fully defines the input contract. Baseline of 4 applies because no parameter documentation is required.
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 resource precisely: realized depth-collapse episodes in BTC ±1% aggregate depth, with the returned fields (onset, trough, drawdown fraction, recovery time). The phrase 'as opposed to how it looks right now' differentiates it from current-state liquidity 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?
Explicitly says when to use it: when asked whether crypto liquidity has actually broken lately. It also indicates when not to use it: when the question is about how liquidity looks right now. However, it does not clearly name sibling alternatives; the exit_desk_full sentence is too ambiguous to count as explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What selling a position of a given USD size costs RIGHT NOW, venue by venue, from live public order books (BTC, six venues). Returns the per-venue cost in basis points at the nearest published size rung, the cheapest and dearest venue with approximate dollar cost, and the venue spread. Estimates interpolated from published quote depth — never a book walk, refreshed roughly hourly. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| size_usd | No | position size in USD (published rungs run $1,000 to $1,000,000; nearest rung is used) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and idempotent, but the description adds substantial behavioral context: live public order books, BTC only, six venues, nearest published size rung, interpolation from quote depth, rough hourly refresh, and a disclaimer. 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?
The description is tightly written: purpose first, then outputs, then methodology and limitations. Each sentence earns its place and there is no redundant 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 one-parameter tool with no output schema, the description enumerates the key return elements and constraints well. It could be slightly more explicit about whether size_usd is required despite the schema listing no required parameters, and it leaves venue identities unspecified, but these are minor gaps.
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 schema already documents the single parameter with units, range, and nearest-rung behavior, so the baseline is 3. The description reinforces that the size is in USD and represents a sell position, but it does not add meaningfully new parameter-level details 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?
The description clearly identifies the resource (exit cost for a position), the scope (BTC, six venues), and the outputs (bps cost, cheapest/dearest venue, spread), so an agent can tell what the tool does. It lacks an explicit imperative verb like 'calculate' and does not name a sibling, but 'venue by venue' and 'never a book walk' help distinguish it from related 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?
The description implies usage: use this for quick, current, per-venue exit cost estimates from public order books, and treat it as an estimate rather than an exact book walk. However, it does not explicitly compare itself to sibling tools such as trade_safety_exit_context or venue_price_reconciliation, nor does it 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.
The exact full-text Undertow editorial published today, with its evidence clock, generation mode and passing quality receipt. This returns the canonical revision verbatim and never rewrites facts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint. The description adds behavioral guarantees: it returns the canonical revision verbatim and never rewrites facts, and it discloses the accompanying metadata (evidence clock, generation mode, quality receipt). It does not describe failure/empty cases, but that is a minor gap given 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?
The description is two sentences with the core noun phrase front-loaded. It is compact but contains unexplained jargon ('evidence clock', 'passing quality receipt') and some redundancy between 'exact full-text' and 'canonical revision verbatim', so it is not perfectly lean.
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 retrieval, the description covers the main return components and fidelity guarantees, which is sufficient in the absence of an output schema. It omits edge behavior (e.g., no article published today) and leaves specialized metadata terms undefined, preventing a 5.
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 and an empty schema, so the description carries no parameter burden. With 0 params, the baseline is 4; the description appropriately focuses on return content instead of parameter syntax.
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 ('returns') and names the resource ('full-text Undertow editorial published today'), and further specifies the returned content as the canonical revision with metadata fields. The sibling tools are all trading/risk related, so this tool's editorial-retrieval purpose is unambiguously distinct.
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 clear context: it is the tool for today's Undertow editorial. It does not explicitly list alternatives or when-not conditions, but because no sibling tool overlaps in domain, the routing risk is minimal. It stops short of explicit guidance that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Undertow board's TIER ROW: one liquidity tier per market segment (UST, IG, HY, EQUITY, ETF, FX, CN, CRYPTO, BSTOCK) plus the funding-stress overlay regime. PARTIAL means insufficient scoring history, reported honestly instead of guessed. Use for 'how liquid are markets today' at one glance, then drill into crypto with the other tools; the FULL board (every measure with its stress percentile and analyst note) is the subscriber board_full tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnly and idempotent behavior. The description adds non-obvious behavioral context: PARTIAL means insufficient scoring history and is reported honestly rather than guessed. This goes beyond the structured annotations and clarifies a key output semantics.
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 compact and front-loaded with the core output, then explains the PARTIAL behavior and use cases. It contains no filler, though the parenthetical segment list makes it slightly dense.
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 board-view tool, the description fully covers what the output contains, what PARTIAL means, and how this tool relates to alternatives. There is no missing information that would prevent an agent from invoking or interpreting 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?
The tool takes zero parameters, so there is no parameter burden for the description to carry. The description focuses entirely on output semantics, which is appropriate 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 clearly identifies the resource ('Undertow board's TIER ROW') and the exact content: one liquidity tier per named market segment plus a funding-stress overlay regime. It also distinguishes itself from the subscriber board_full tool, making its scope 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?
It explicitly frames the tool for a quick 'how liquid are markets today' glance and directs deeper crypto investigation to 'the other tools' and full detail to board_full. This provides clear when-to-use and an explicit alternative, even if the sibling names are not all enumerated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Undertow's own sealed forward-calls record: every call hash-chained and signed BEFORE its outcome, scored against the immutable point-in-time board for its horizon date, with misses kept published. Returns the full record with outcomes and the ledger root. Use when asked whether Undertow's judgements can be trusted, and quote the misses as prominently as the hits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only, idempotent annotations, the description explains the hash-chaining and signing before outcomes, scoring against the immutable point-in-time board, and that misses are kept published. It also discloses the return contents, which is valuable because no output schema is provided.
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 compact yet information-dense: it defines the record, explains its integrity guarantees, states what is returned, and gives usage guidance. No sentence is wasted.
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 tool with no output schema, the description fully covers what the tool returns, why it can be trusted, and when to use it. There are no significant gaps for an agent deciding whether and how to call it.
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 there is no parameter detail for the description to add. Baseline 4 applies here, and the description sensibly focuses on behavior and output rather than parameters.
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 indicates the tool returns a sealed forward-calls record with outcomes and the ledger root, and the title reinforces that misses are kept. It does not explicitly contrast itself with sibling tools, but the unique resource and trust-related purpose are unmistakable.
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 states exactly when to use this tool: when asked whether Undertow's judgements can be trusted, and it instructs the agent to quote misses as prominently as hits. It does not mention alternatives or exclusions, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact-rung BTC/USD sell evidence for observe/paper Trade Safety. Binds the opaque request, source pack and reviewed rights to PIT; rechecks USD/USDT conversion, required bid bands, six venue clocks and startup SHA. Context only: no nearest rung, live mode, execution or clearance authority.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| side | Yes | ||
| venue | Yes | ||
| instrument | Yes | ||
| request_hash | Yes | Opaque complete-request hash | |
| requested_size_usd | Yes | Exact published USD rung |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
ReadOnlyHint and idempotentHint already cover the non-mutating profile, and the description adds meaningful context by stating this is context-only with no execution or clearance authority and by listing specific internal rechecks. It does not contradict the annotations, though output shape and failure behavior are left unspecified.
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 dense sentences front-load the purpose, list the checks, and then state exclusions without filler. The telegraphic jargon makes it less parseable than it could be, but the structure is appropriately compact.
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 six-parameter tool with no output schema, the description conveys purpose and boundaries but leaves the return value, failure behavior, and relationship to sibling tools unexplained. It is usable for selection but not fully complete for confident 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?
The description restates several schema constraints (BTC/USD, sell, observe/paper, exact rung) and refers to the opaque request hash, but schema coverage is only 33% and the description adds little about the venue parameter or how each parameter influences the result. It partially compensates for the low coverage but does not fully do so.
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 first sentence identifies a specific resource (BTC/USD sell evidence) and scope (observe/paper Trade Safety), and the second describes concrete verification work: binding the request to PIT and rechecking conversions, bid bands, venue clocks, and startup SHA. The heavy jargon and lack of explicit sibling differentiation keep it from 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?
It clearly scopes use to observe/paper Trade Safety and gives explicit negative guidance: no nearest rung, live mode, execution, or clearance authority. It does not name any sibling tool as the alternative to use, so it does not fully meet the top criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Can a watched fund's book actually leave the building? Unwind stress for the watched 13F filers (incl. the Situational Awareness LP replay): effective position count, whole-book days-to-exit at 10% of a median day's volume (bracketed as-if median large / median small-mid name, and each count published as a band that contains it rather than as a point, because the exact count returns the basket's median dollar volume by one division), and the leverage x shock x maintenance margin grid with its three honest states (NO_CALL / CALL / EQUITY_EXHAUSTED). Default is the per-filer headline; pass cik for one filer's full free row. Display-only measure on frozen grids; 13F sees no shorts or options, so every number is a floor. Use when asked whether a fund's book could exit, or what the Aschenbrenner failure mode looks like in a current filing. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | optional: SEC CIK of a watched filer (returns that filer's full FREE row instead of the all-filer headline) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses important behavioral traits: it is a 'display-only measure on frozen grids', 13F data 'sees no shorts or options', and therefore 'every number is a floor'. It also names the three margin grid states (NO_CALL / CALL / EQUITY_EXHAUSTED), which materially helps an agent interpret results.
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 dense and information-rich, but it is overloaded with parenthetical asides and rhetorical framing such as 'incl. the Situational Awareness LP replay' and 'bracketed as-if median large / median small-mid name'. This makes it harder for an agent to parse quickly, even though most clauses carry useful 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?
Because there is no output schema, the description carries the full burden of explaining return semantics, and it does so thoroughly: it enumerates the metrics, explains the banding/floor nature of the numbers, describes the grid states, and clarifies default vs. per-filer modes. Nothing essential for correct invocation 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 the baseline is 3, but the description adds meaningful context for the optional cik parameter: 'Default is the per-filer headline; pass cik for one filer's full free row.' This clarifies behavior that the schema description alone does not fully convey.
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 identifies the resource (watched 13F filers) and the specific computation: effective position count, whole-book days-to-exit, and the leverage/shock/maintenance margin grid. It clearly conveys what the tool measures, though it does not explicitly distinguish itself from closely related siblings like exit_cost or trade_safety_exit_context.
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 use triggers: 'Use when asked whether a fund's book could exit, or what the Aschenbrenner failure mode looks like in a current filing.' It also explains the default vs. cik calling pattern. It does not name when not to use the tool or point to alternatives, but the provided context is sufficient for most selection decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How concentrated the BTC depth backbone is today: which venue holds the largest share of ±1% aggregate depth, the HHI, the effective venue count (1/HHI), and per-venue depth in USD. Low effective venue count means an exit depends on one venue staying open. The subscriber exit_desk_full adds ETH and the venue-failure withdrawal scenario (what your exit costs if the top venue goes dark).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral detail: the exact concentration metrics computed, the ±1% depth band, USD denomination, and the practical implication of low effective venue count. This goes beyond the structured hints.
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 compact and front-loads the core output in the first sentence. The second sentence adds a useful interpretation. The third sentence introduces the exit_desk_full subscriber variant, which is somewhat tangential for invoking this tool but still relevant context; it does not seriously detract.
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 burden of explaining what is returned, and it does so concretely: venue share, HHI, effective venue count, and per-venue USD depth. It also frames the business significance. Minor ambiguity remains about data freshness and how the subscriber variant relates to this tool, but the core usage is adequately complete.
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 input schema has zero parameters and schema description coverage is 100%, so there is no parameter documentation burden. The description appropriately focuses on what the tool reports rather than inputs, matching the no-parameter 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?
The description clearly identifies the tool's focus: measuring concentration of BTC depth across venues, and enumerates the exact metrics returned (largest venue share, HHI, effective venue count, per-venue USD depth). It does not explicitly contrast with sibling tools like depth_episodes or liquidity_tiers, so sibling differentiation is only implicit.
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 provides useful interpretive context—low effective venue count implies exit risk tied to a single venue—and mentions an extended subscriber variant. However, it does not explicitly state when to choose this tool over siblings such as exit_cost, trade_safety_exit_context, or liquidity_tiers, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the price IS when venues disagree: the cross-venue consensus mark for BTC and ETH, weighted by resting depth over squared half-spread (NOT a median of last prices), with the BLINDNESS GAP — how far the deepest venue sits from consensus, i.e. how wrong you would be pricing off the venue you would naturally trust — plus depth concentration (CR1/HHI) and the names of any dislocated venues. Use for 'what is BTC/ETH actually worth right now', 'is an exchange dislocated', or before trusting any single venue's price. Experimental until its accrual gates pass; the payload says so. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint annotation by explaining the unusual weighting formula, explicitly warning that it is NOT a median of last prices, describing the blindness gap and depth concentration metrics, and disclosing that the tool is experimental until accrual gates pass. This prevents important misinterpretations.
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 fairly long but every clause adds substantive information: definition, formula, caveats, use cases, and experimental status. It front-loads the core meaning and ends with practical warnings, though a more structured format could improve scannability.
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 tool with no output schema, the description is comprehensive: it names the assets covered, the weighting methodology, the key output fields (blindness gap, CR1/HHI, dislocated venues), and the experimental caveat. An agent has enough to invoke and interpret the result 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?
The tool has zero parameters and the schema is fully described by its empty properties object, so there is no parameter documentation burden on the description. It appropriately focuses on output semantics instead, which is the only meaningful additional context an agent needs.
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 exactly what the tool computes: a cross-venue consensus mark for BTC and ETH, weighted by resting depth over squared half-spread. It is not just a vague label — it explains the resource (BTC/ETH prices), the nature of the output (consensus with associated metrics), and explicitly contrasts itself with a median of last prices.
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 use cases: 'what is BTC/ETH actually worth right now', 'is an exchange dislocated', and 'before trusting any single venue's price'. It does not name sibling alternatives or state when not to use this tool, but the context is clear enough for an agent to select it appropriately.
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. Dates show when Glama detected each change.
agent_access_statusdepth_episodesexit_costlatest_articleliquidity_tierssealed_recordtrade_safety_exit_contextunwind_watchvenue_concentrationvenue_price_reconciliationClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Read-only paper risk evidence and policy-gated committed event research. No real orders.
Read-only discovery and bounded access to a finite market briefing with evidence boundaries.
One-call market verdict, plus funding, open interest, execution cost, volatility and macro
Keyless prediction-market data across 12 venues plus paper-trading of crypto spot, futures, and PM.
Add one secure layer between your agents and this server.
Most tools target clearly distinct outputs—current exit cost, historical depth episodes, venue concentration, price reconciliation, fund unwind stress, and access status—even within the shared BTC liquidity theme. The main confusion risk is mild overlap between exit_cost and trade_safety_exit_context, and between liquidity_tiers and the BTC-depth tools.
All tool names use the same lower_snake_case descriptive-noun-phrase style, such as depth_episodes, venue_concentration, and exit_cost. There are no mixed casing conventions, verb styles, or unpredictable patterns.
Ten tools is well within the ideal range, and each tool covers a distinct piece of the liquidity/exit-cost domain, including access and trust features. None feel redundant or filler.
The set covers current BTC exit costs, venue depth concentration, price reconciliation, historical depth episodes, overall liquidity tiers, and fund unwind stress, so core workflows are covered. Gaps are mostly ETH-specific exit/depth tools and the full board being subscriber-only, which agents can generally work around with the public tools.