EdgeDepth Research
Server Details
Search recorded crypto and TradFi microstructure through deterministic, reproducible agent tools.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.7/5 across 9 of 9 tools scored.
Each tool has a clearly distinct purpose: base_rate measures condition frequency, commonality analyzes feature agreement across moments, run_scan and run_cohort perform queries and comparisons, while interpret_prose, list_features, get_report, next_page, and snapshot_at handle interpretation, registry, reports, pagination, and state reading. No two tools overlap in function.
Tool names mostly follow a verb_noun or descriptive noun pattern (run_scan, get_report, list_features, interpret_prose), with minor deviations like base_rate and commonality (nouns) and snapshot_at (verb_preposition). Overall consistent and readable.
The 9 tools are well-scoped for a research platform: covering query execution (run_scan, run_cohort, base_rate, commonality), data discovery (list_features, snapshot_at), interpretation (interpret_prose), result retrieval (get_report), and pagination (next_page). Not bloated nor sparse.
Essential operations are covered: scanning, comparison, frequency analysis, feature listing, state inspection, report fetching, and prose interpretation. Minor gaps such as explicit report publishing or feature creation are absent, but these align with the platform's deterministic and registry-based design.
Available Tools
9 toolsbase_rateBase rate of a single conditionARead-onlyInspect
Count how often a SINGLE stated condition holds over a window: matches / eligible, with denominators. The honesty primitive behind commonality - a condition that holds almost everywhere prints a high base rate and is visibly uninformative. The result's outcomes_summary also reports what followed every match over 30m/1h/4h/24h horizons (returns + MFE/MAE, thresholds to +/-20 pct); matches too close to the end of recorded data for a horizon are counted absent for it, never truncated - use present as the denominator for horizon rates. Deterministic and free to rerun. field, operator and value must be grammar-valid (see list_features); expect the 422 contract code verbatim if not. The assembled one-clause document is echoed back so you can show the user exactly what ran.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Window end, RFC3339. | |
| from | Yes | Window start, RFC3339. | |
| field | Yes | A feature.* or window.* id from list_features (e.g. feature.vpin). | |
| value | No | A number, string or array matching the operator (between and in take arrays). | |
| symbol | No | Optional scope: one lowercase perp or a list. Omit for the whole universe. | |
| operator | Yes | gte, lte, between, eq or in - matching the field dtype. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds determinism, horizon handling (counts absent, not truncated), error behavior (422 contract code), and that the result reports outcomes_summary. 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?
Description is moderately long but every sentence adds value. It is front-loaded with the main purpose. Could be slightly shorter, but overall efficient.
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 6 parameters, no output schema, the description covers purpose, input validation, horizon behavior, determinism, and return value. Lacks explicit output schema details, but the description gives a sufficient high-level picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented. Description adds context that field/operator/value must be grammar-valid (see list_features) and explains value types for operators like between and in. This goes 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?
Description states 'Count how often a SINGLE stated condition holds over a window: matches / eligible, with denominators.' This is a specific verb and resource, and it distinguishes from siblings like commonality by calling it the 'honesty primitive behind commonality.'
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?
Describes when to use (for a single condition's base rate), mentions determinism and free reruns, and notes that the assembled document is echoed back. Does not explicitly state when not to use or provide alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
commonalityCommonality across N momentsARead-onlyInspect
Given N (symbol, time) moments, return the DETERMINISTIC intersection: per registry field a verdict of agree, partial, disagree, quiet or absent, plus the survivorship and multiple-comparisons honesty framing IN the output. Never similarity search. A shared feature is a description of the chosen moments, not a prediction: to test any AGREE chip, follow up with base_rate over the same window.
| Name | Required | Description | Default |
|---|---|---|---|
| moments | Yes | At least 2 moments: { symbol: lowercase perp, at: RFC3339 }. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds key behavioral traits: determinism, return of verdicts per field, inclusion of survivorship and multiple-comparisons framing, and that it describes moments rather than making predictions. This significantly aids agent understanding.
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 (3 sentences) and front-loaded with the main action. However, the third sentence is dense and could be slightly reorganized for better readability, though it remains effective.
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 single parameter fully documented in the schema and no output schema, the description provides sufficient context about the output (verdicts, framing) and behavior (deterministic, not prediction). It is complete for the tool's complexity.
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 has 100% coverage for the single 'moments' parameter, but the description adds real-world usage constraints: moments are 'symbol, time', at least 2, with symbol being 'lowercase perp' and at as RFC3339. This adds meaning 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 explicitly states the tool's purpose: given N moments, return the deterministic intersection with verdicts per registry field. It clearly distinguishes itself from similarity search and explains what the output contains (agree, partial, disagree, quiet, absent, plus survivorship and honesty framing).
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 guidance: use for deterministic intersection, not for similarity search. It also tells users to follow up with base_rate to test any AGREE chip, indicating when this tool is appropriate and when to use an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reportFetch a published report by hashARead-onlyInspect
Fetch a published EdgeDepth research report by its 8-hex canonical hash: title, author, the definition that ran (re-submittable to run_scan) and the result pinned at publish time (it never mutates). A citable public artifact.
| Name | Required | Description | Default |
|---|---|---|---|
| hash8 | Yes | 8 lowercase hex characters, the report canonical id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description adds details beyond these: 'it never mutates', 'pinned at publish time', and 'citable public artifact', providing clear behavioral expectations without contradictions.
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, no wasted words, and front-loaded with the primary action. Every sentence serves a purpose.
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 simple parameter set, no output schema, and rich annotations, the description is complete. It explains what the tool returns and the nature of the artifact, which compensates for the lack of an output schema.
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 defines hash8 with description '8 lowercase hex characters, the report canonical id.' The description repeats this information almost verbatim. With 100% schema coverage, the description adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a published EdgeDepth research report by hash, specifying the verb 'Fetch' and the resource 'published report'. It lists the returned fields (title, author, definition, result) and distinguishes itself from siblings like run_scan by indicating this is a static artifact.
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 use when you have a canonical hash and want the static report. It does not explicitly mention when not to use it or alternatives, but the context of siblings suggests run_scan might be the alternative for generating new reports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
interpret_proseInterpret prose into a proposed research documentARead-onlyInspect
Turn a plain-language market question into a PROPOSED research_query.v2 document. The result is a proposal, not a result: it is labeled proposal:true and is never executed here. Show the document (plus any unsupported[] stand-ins and clarify notices) to the user, then call run_scan with the document to execute. That second call is the confirm gate. Requires the research:interpret scope and is metered separately (each call spends provider money).
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | The market question in plain language, e.g. "vpin above 0.7 then a liquidation surge within 30m on majors last week". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond annotations, including that the document is labeled proposal:true, never executed here, and includes unsupported stand-ins and clarify notices. It also states the scope requirement and metering cost, adding context the annotations 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 concise at four sentences, front-loaded with the primary purpose. Each sentence adds essential information: output type, proposal nature, usage workflow, and access constraints. No redundant or irrelevant content.
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 explains the return value (proposed document with proposal:true, unsupported stand-ins, clarity notices) and the required follow-up action (call run_scan). It covers all necessary context for an agent to use the tool 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 input schema covers the single parameter 'language' with a description and example. The tool description does not add new information beyond what is already in the schema, so it meets the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts plain-language market questions into proposed research_query.v2 documents, distinguishing it as a proposal generator rather than an execution tool. It explicitly differentiates from sibling tools like run_scan, which executes the returned document.
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 step-by-step guidance: show the proposal to the user, then call run_scan to execute. It also clarifies the result is a proposal (never executed) and lists the required scope and metering costs, giving complete usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_featuresList research features (the grammar registry)ARead-onlyInspect
Return the closed registry for the pinned feature_version: every feature id with its dtype and range, the operators, window aggregates and durations, sequence rules, limits, sort fields, and the machine-readable validation and transport error-code lists. Call this FIRST: a document that only uses ids from here cannot invent field names. The registry is ETag-revalidated on every read, so additive feature ids become visible to long-running agents without inventing or hard-coding fields.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses that the registry is ETag-revalidated on every read, making additive feature ids visible to long-running agents. This provides valuable behavioral context.
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 consists of two sentences: the first delivers the core purpose and content, the second adds usage guidance and behavioral insight. Every sentence is necessary and well-structured.
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 complexity of the return value and lack of output schema, the description lists the major registry components. It also covers key behavioral aspects like revalidation. However, it does not explain how to interpret or use the registry after retrieval, which could be considered 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?
The input schema has zero parameters, so no parameter documentation is needed. Schema description coverage is 100%, and the description adds no parameter-specific information, which is acceptable for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the closed registry for the pinned feature_version, listing specific components like feature ids, dtypes, operators, etc. It distinguishes itself from sibling tools by being the foundational registry that defines valid field names.
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 'Call this FIRST' and explains that documents using ids from here cannot invent field names, providing clear context for when to use. However, it does not mention when not to use or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
next_pageFetch the next page of a prior scanARead-onlyInspect
Continue a prior run_scan by re-sending the SAME document with the opaque cursor from the previous response. Never construct cursors. If X-Dataset-Revision changed since page 1, the nightly append landed and the result set changed: restart from page 1. counts and outcomes_summary arrive on page 1 only; later pages are more example rows.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | Yes | The opaque page.cursor from the previous response. Never construct or edit it. | |
| document | Yes | The EXACT document from the prior run_scan. | |
| if_none_match | No | Optional ETag to revalidate this page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint:true and openWorldHint:true. Description adds vital behavioral details: the cursor is opaque, the document must be identical, revision changes invalidate continuation, and page-specific result structure. 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?
Two sentences, front-loaded with the core action in the first sentence. Every sentence provides essential guidance 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?
For a tool with no output schema, description explains what to expect per page (counts/outcomes on page 1, more rows on later pages) and handles edge cases (revision change). Covers all necessary context for an agent to use 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% for all three parameters. Description reinforces the semantics: 'opaque cursor from previous response', 'EXACT document from prior run_scan', and hints at optional ETag usage. Adds value beyond schema descriptions by explaining usage constraints.
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 'Continue a prior run_scan by re-sending the SAME document with the opaque cursor from the previous response.' It specifies the action (fetch next page) and resource (prior scan results). Distinguishes from sibling tools like run_scan, which initiates the scan, by being the continuation step.
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 ('after a prior run_scan'), provides critical constraints ('never construct cursors', 'send exact same document'), and warns about data changes ('if X-Dataset-Revision changed, restart from page 1'). Also describes what is absent on later pages ('counts and outcomes_summary arrive on page 1 only').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_cohortRun a cohort comparison study (record_occurrences)ARead-onlyInspect
Execute a research_query.v2 document as a §4.5.3 COHORT COMPARISON and return canonical cohort_result.v1 bytes: what followed the condition (the matched side, byte-identical to the run_scan outcomes_summary for the same document) vs what followed every OTHER eligible bucket where the condition was ABSENT (the baseline), each as the same 30m/1h/4h/24h return + MFE/MAE summary over ALL occurrences. WHERE-ONLY: a sequence document is refused with 422 COHORT_SEQUENCE_UNSUPPORTED (run it as an ordinary run_scan instead). The bytes carry NO ratios, lift, averages or significance - you compare the two distributions yourself, and three mandatory caveats ship in the result. Both sides honour the completeness rule: an occurrence closer to the end of recorded data than a horizon has that horizon ABSENT - quote present, not total, as the denominator. CONTRACT (relay to the user): Echo the exact document and the reproducibility key to the user with the result. Rates come from outcomes_summary over all occurrences; page rows are examples, never the denominator. Outcome fields cannot be filtered; expect OUTCOME_IN_PREDICATE if tried. A rerun of the same document is served from cache (X-Research-Cache: hit) in its own cohort namespace; reruns and 304 revalidations are free.
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes | A complete research_query.v2 document (target record_occurrences, WHERE-ONLY - no sequence). Call list_features for the grammar; do not invent field names. | |
| if_none_match | No | An ETag from a previous cohort run to revalidate: identical data answers 304 and spends nothing. Pass it back verbatim (it may be weak, W/"..."). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds extensive behavioral context: caching behavior (X-Research-Cache), output structure (no ratios/lift/averages, three mandatory caveats), completeness rule for absent horizons, and error conditions. This goes well beyond annotations and fully informs the agent of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and dense, but every sentence provides essential information. It is front-loaded with the core purpose and structured with specifics following. While slightly lengthy, it is necessary given the tool's complexity. A 4 is appropriate as it could be slightly more concise but remains effective.
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 complexity, the description covers all relevant aspects: purpose, output structure, error handling, caching, contractual obligations for relaying to user, and completeness rules. There is no output schema, but the description compensates with detailed output explanation. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds extra semantics for the 'document' parameter, specifying it must be a research_query.v2 targeting record_occurrences, WHERE-ONLY, and to call list_features for grammar. This supplements the schema description meaningfully.
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 executes a research_query.v2 document as a cohort comparison, returning canonical cohort_result.v1 bytes. It specifies the verb 'execute', the resource, and the output format. It also distinguishes from sibling tool run_scan by advising a sequence document should be run as run_scan instead.
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 usage guidance: it states that sequence documents are refused with a specific error and should be run as run_scan instead. It also warns that outcome fields cannot be filtered, and instructs to call list_features for the grammar. This helps the agent choose correctly when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_scanRun a research scan (record_occurrences)ARead-onlyInspect
Execute a research_query.v2 document over the deterministic engine and return counts, denominators, outcomes_summary, the reproducibility key and page-1 rows as the engine's canonical bytes. outcomes_summary carries forward outcomes over FOUR horizons per occurrence: 30m return, 1h MFE/MAE, and 4h and 24h return + MFE/MAE (record_result.v3), with a closed threshold ladder to +/-20 pct - "how often did this setup reach +5% within 24h, with how much drawdown" is answered by the summary over ALL occurrences. Completeness caveat: an occurrence closer to the end of recorded data than a horizon has that horizon ABSENT (counted in the absent tally, never a truncated or implied-zero outcome) - quote present, not total_matching, as the denominator for any horizon rate. Document-only input: stated chips are the only input the scan path accepts (use interpret_prose first if you have prose, then re-submit its document). CONTRACT (relay to the user): Echo the exact document and the reproducibility key to the user with the result. Rates come from outcomes_summary over all occurrences; page rows are examples, never the denominator. Outcome fields cannot be filtered; expect OUTCOME_IN_PREDICATE if tried. You may rerun freely: a rerun of the same document is served from cache (X-Research-Cache: hit), and reruns and 304 revalidations are free.
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes | A complete research_query.v2 document (target record_occurrences, stated chips only). Call list_features for the grammar; do not invent field names. | |
| if_none_match | No | An ETag from a previous run to revalidate: identical data answers 304 and spends nothing. Pass it back verbatim (it may be weak, W/"..."). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description details outcome horizons, absent horizon handling, caching behavior, and the fact that rates come from the summary, not rows. 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 dense but front-loaded with the core purpose. All sentences add value for the tool's complexity, though it could be slightly more concise without losing critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully explains return values (counts, denominators, outcomes_summary, etc.), outcome horizons, cached reruns, and usage caveats. It is complete for the tool's complexity.
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% with descriptions, but the description adds significant context: document is a complete research_query.v2 with stated chips only, and if_none_match is an ETag for revalidation. It also directs to list_features for grammar.
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 executes a research_query.v2 document and returns specific outputs like counts, denominators, outcomes_summary, and reproducibility key. It also distinguishes from siblings by directing prose inputs to interpret_prose first.
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 guidance: document-only input, use interpret_prose for prose, rerun freely with caching, and warns that outcome fields cannot be filtered. It could be more explicit about when not to use this tool, but it names alternatives like list_features for grammar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapshot_atRead the registry as-of a momentARead-onlyInspect
Read the engine registry AS-OF the grid bucket containing a moment: every feature value, the closed-list window aggregates, and the fired rulebook ids, as the engine's canonical bytes. A read, never a scan (not credit-metered). Use it to turn one observed moment into candidate clauses, then run_scan to find every other time it looked like that. Selection discipline: if you picked the moment because it moved, expect the follow-up scan to deflate over all occurrences. That is the product working.
| Name | Required | Description | Default |
|---|---|---|---|
| at | Yes | An RFC3339 datetime; the engine floors it to the grid bucket that contains it. | |
| symbol | Yes | Lowercase perp, e.g. btcusdt. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds context that it's not a scan and not credit-metered, and explains the engine floors datetime to a grid bucket. No contradictions.
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 clear and front-loaded with purpose, but includes some advisory text that could be slightly trimmed. Still concise overall.
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 annotations and complete schema, the description covers what the tool returns and its typical use case. Though no output schema, the description mentions the content. Adequate for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant new parameter meaning beyond what is already in the schema, e.g., 'at' description matches 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 explicitly states the tool reads the engine registry as-of a specific time, listing feature values, window aggregates, and rulebook ids. It distinguishes from sibling tools like run_scan by specifying a different use case.
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 guidance: use snapshot_at to turn a moment into candidate clauses, then use run_scan for further analysis. It also notes that it is a read operation not credit-metered, and offers a selection discipline.
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.
Discussions
No comments yet. Be the first to start the discussion!