Daily editorials, exit costs, depth concentration, tiers, and sealed records. No commodity futures.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 8 of 8 tools scored.
Each tool targets a distinct aspect of market liquidity: access status, historical depth episodes, current exit costs, liquidity overview, trust record, fund unwind, venue concentration, and price reconciliation. No two tools overlap in purpose.
All tool names use a consistent lowercase_snake_case noun phrase pattern (e.g., depth_episodes, exit_cost, venue_concentration). This is predictable and coherent, even though the convention is not verb_noun.
Eight tools is well within the ideal 3-15 range for a specialized analytics server. Each tool provides a unique function without redundancy or bloat.
The tool set covers the domain thoroughly: current liquidity state (exit_cost, venue_concentration, venue_price_reconciliation, liquidity_tiers), historical events (depth_episodes), risk assessment (unwind_watch), and platform meta (agent_access_status, sealed_record). No obvious gaps for the described purpose.
agent_access_statusYour access + meterAWhere 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, reducing the need for behavioral disclosure. The description adds valuable context (e.g., checking fresh entitlement, not trusting token) but does not elaborate on potential side effects or error conditions, which is acceptable 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?
Two succinct sentences front-load the key purpose and usage. Every sentence adds value without redundancy, making it highly efficient for an agent to parse.
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 the tool's simplicity (no parameters, no output schema, but with annotations), the description covers purpose, usage, and behavioral details comprehensively. An agent can correctly understand when and how to invoke this 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?
With zero parameters and 100% schema coverage, the description adds no parameter-specific information, which is appropriate. The baseline score of 4 applies as the description compensates by clarifying the tool's overall function.
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 what the tool does: provides caller's access status, bearer token verification, entitlement tier, tool-call meter, and instructions for full access. It distinctly serves as an access and meter check, differentiating it from sibling tools like depth_episodes or sealed_record.
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 states when to call: 'Call this first when a subscriber tool is missing from tools/list or a call is refused.' This provides clear, actionable guidance, leaving no ambiguity about its primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depth_episodesRealized depth collapsesARealized 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?
With annotations already declaring readOnlyHint and idempotentHint, the description adds context about the pre-registered threshold and the fact that detection rules were declared before episodes accrued. This methodological transparency goes beyond the annotations, though it doesn't detail edge cases or output 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?
The description is four sentences, each earning its place: it defines the content, notes the methodological assurance, gives usage guidance, and adds a scope caveat. It's front-loaded and free of fluff.
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 tool with no output schema, the description sufficiently explains what the tool returns and when to use it. However, it omits details like the time range covered or number of episodes, leaving some ambiguity about the dataset's extent.
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 description needn't add parameter details. The schema is empty, and the description focuses on the output and use case, which is entirely appropriate for a parameterless tool. Baseline 4 is justified.
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's function: reporting realized depth-collapse episodes in BTC ±1% aggregate depth with specific metrics (onset, trough, drawdown fraction, recovery time). It distinguishes itself from current-state tools like liquidity_tiers by focusing on historical, threshold-crossing episodes, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a usage criterion: 'Use when asked whether crypto liquidity has actually broken lately, as opposed to how it looks right now.' It also contrasts with current-liquidity tools and notes that `exit_desk_full` covers ETH, guiding users away from this tool when ETH is the focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
exit_costExit cost at your size, per venueAWhat 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 as read-only and idempotent. The description adds valuable behavioral context: data source (live public order books, BTC, six venues), refresh rate (hourly), interpolation method (from published quote depth, never a book walk), and output format. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, yet captures purpose, data source, limitations, and output types. Every word adds value, with no redundancy. It is front-loaded with the core action and immediately provides critical caveats.
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 the tool's simplicity (one parameter, no output schema), the description provides complete context: what it does, how it works, limitations, and output summary. It explains the estimation methodology and refresh cycle, leaving no significant gaps for an AI agent to interpret.
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 parameter 'size_usd' has a complete schema description. The tool description adds crucial context about the range of published rungs ($1,000 to $1,000,000) and that the nearest rung is used, which goes beyond the schema. With 100% schema coverage, this extra detail earns a top score.
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 computes exit cost for a given USD size per venue, using live order books. It names the specific outputs (per-venue cost in bps, cheapest/dearest venue, venue spread) and distinguishes it from sibling tools by focusing on exit cost estimation.
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 clear context for when to use the tool (checking selling costs right now) but does not explicitly mention when not to use it or name alternative tools. It includes important caveats like 'never a book walk' and 'not investment advice'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
latest_articlelatest_articleAThe 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?
The annotations already establish read-only, idempotent, and closed-world behavior. The description adds valuable transparency by guaranteeing the 'canonical revision verbatim' and 'never rewrites facts', assuring the agent of data integrity. It also previews the output structure (evidence clock, generation mode, quality receipt), compensating for the lack of an output schema.
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, packed with relevant information, no filler. Every phrase contributes to understanding the tool's purpose and behavior.
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 parameter-less tool with no output schema, the description fully covers what the tool does, what it returns, and any behavioral guarantees. It is self-sufficient and leaves no critical 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?
There are zero parameters, so the schema provides no ambiguity. The baseline for 0 params is 4, and the description appropriately focuses on the output rather than parameters, adding no irrelevant detail.
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 explicitly states it returns the 'exact full-text Undertow editorial published today' with specific components (evidence clock, generation mode, quality receipt). The verb 'returns' is implied, and the resource is clearly defined. It distinguishes itself from sibling tools by being the only article-related 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?
The context is clear: use this when you need today's Undertow editorial in full. It does not explicitly mention alternatives or exclusions, but the sibling tools are clearly unrelated (financial metrics), so the intended usage is obvious without needing explicit contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
liquidity_tiersFull board: tiers + fundingAThe 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?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds transparency by explaining the PARTIAL status as 'insufficient scoring history, reported honestly instead of guessed.' It also mentions the funding-stress overlay regime, providing behavioral context not captured in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all value-dense: first defines the tool's content, second clarifies PARTIAL semantics, third gives usage guidance and alternative. No fluff 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?
Despite no output schema, the description explains what the tool shows, the meaning of a key value, and how to get more detail via board_full. This is complete for a simple, read-only board view 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?
With zero parameters, the description correctly focuses on the content rather than parameter syntax. The baseline for 0 params is 4, and the description adds value by enumerating the market segments covered, even though this isn't parameter-related.
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 as providing the Undertow board's tier row, listing the exact market segments (UST, IG, HY, EQUITY, ETF, FX, CN, CRYPTO, BSTOCK) and the funding-stress overlay. It distinguishes itself from the sibling 'board_full' tool by noting the difference between a quick glance and full measures.
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 states when to use this tool ('how liquid are markets today' at one glance) and provides alternatives: drill into crypto with other tools, or use the subscriber 'board_full' tool for every measure with stress percentile and analyst note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sealed_recordSealed calls record (misses kept)AUndertow'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?
Annotations indicate readOnly, idempotent, not open-world. The description adds that the record is hash-chained and signed before outcome, scored against an immutable board, and includes misses. It also states the return format (full record with outcomes and ledger root), providing transparent 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 sentences: first explains what the tool is and its process, second gives return and usage. Every word earns its place; 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?
Given zero parameters, no output schema, and annotations covering safety, the description completely explains the tool's purpose and output. Siblings are unrelated, so no additional context needed.
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?
No parameters exist, so baseline 4 is appropriate. The description does not need to add parameter semantics as there are none.
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 it provides Undertow's sealed forward-calls record, including the process of hash-chaining, signing, scoring, and keeping misses. It returns the full record with outcomes and the ledger root. This distinguishes it from siblings like depth_episodes or exit_cost.
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 'Use when asked whether Undertow's judgements can be trusted, and quote the misses as prominently as the hits.' This gives clear context for when to invoke and how to use the output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unwind_watchCan the watched books exit? (free)ACan 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 key behavioral details: it is 'display-only' on frozen grids, uses bands instead of point estimates for counts, and notes that 13F data excludes shorts/options so every number is a floor. It also explains the three 'honest states' of the leverage grid, adding context that annotations alone do not provide.
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 but every sentence contributes value: what the tool does, how metrics are computed, default vs optional parameter, limitations, and when to use it. It is front-loaded with the core question and remains information-dense without fluff, earning a 5.
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?
Despite having no output schema, the description thoroughly explains the main outputs (effective position count, days-to-exit, leverage grid with states) and clarifies the default vs cik behavior. It also addresses limitations (frozen grids, no shorts/options) which is critical for interpreting results. The context is complete for an agent to invoke and understand the 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?
The schema already provides a clear description for the single optional parameter cik (returns that filer's full FREE row). The tool description reinforces this ('pass cik for one filer's full free row') and mentions the default, but it does not add additional meaning beyond the schema. With 100% schema coverage, 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 opens with a clear question ('Can a watched fund's book actually leave the building?') and then specifies the resource (watched 13F filers) and the primary output (days-to-exit, leverage grid, etc.). It clearly distinguishes itself from sibling tools by focusing on exit feasibility, not just cost or liquidity.
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 states when to use the tool: '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 behavior and how to get a single filer's row via cik. However, it doesn't mention when not to use it or alternatives among siblings, so it earns 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.
venue_concentrationDepth concentration todayAHow 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 convey read-only and idempotent behavior. The description adds interpretive context ('Low effective venue count means...'), explicitly identifies the BTC-only scope, and mentions the subscriber add-on for ETH and venue-failure scenarios, disclosing limitations and upgrade paths 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?
The description is a lean three sentences: what is measured, why it matters, and what is excluded. Every sentence earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description enumerates all returned metrics and their interpretation, and notes the related extended tool. For a no-input analytics tool, this provides complete context for an AI agent to invoke it appropriately.
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, making the schema trivially complete. The description adds that it reflects 'today' (current state) and requires no input, satisfying the baseline for zero-parameter tools without needing additional parameter explanations.
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 as measuring BTC depth concentration, naming specific outputs (largest share, HHI, effective venue count, per-venue depth in USD). This is a distinct resource and metric set, differentiating it from sibling tools like exit_cost or liquidity_tiers.
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 for when this tool is relevant: assessing 'exit depends on one venue staying open'. It implies the tool is BTC-focused and that an add-on (exit_desk_full) is needed for ETH, which helps scoping, though it doesn't explicitly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
venue_price_reconciliationConsensus price when venues disagreeAWhat 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?
Beyond annotations (readOnlyHint, idempotentHint), the description adds critical context: the tool is experimental, the payload says so, and it is not investment advice. It explains the calculation method in detail, which annotations do not cover.
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 a single paragraph that is information-dense and front-loaded. It could benefit from structured formatting (e.g., bullet points) for clarity, but it is not overly 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?
Given no parameters and no output schema, the description fully describes what the tool returns: the consensus mark, blindness gap, depth concentration, and dislocated venues. It also explains the weighting and experimental nature. No 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 tool has zero parameters, so baseline is 4. The description does not need to explain parameters. The schema coverage is 100% vacuously.
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 defines the tool's purpose: computing a cross-venue consensus mark for BTC and ETH using a specific weighting method. It lists outputs and contrasts with sibling tools implicitly by specifying use cases. However, it does not explicitly differentiate each 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?
The description provides explicit use cases: 'what is BTC/ETH actually worth right now', 'is an exchange dislocated', or 'before trusting any single venue's price'. It also notes experimental status. It lacks explicit when-not-to-use guidance but the use cases are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!