fathom-fyi

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v4.5.1
Disambiguation3/5
The tools have overlapping purposes that could cause confusion, such as multiple 'get_' tools for market analysis (e.g., get_market_regime, get_reality_check, get_sentiment_state) which may seem redundant. However, descriptions provide some differentiation, like get_reality_check synthesizing all data sources, but an agent might struggle to choose the right one for specific needs without careful reading.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with 'get_', 'set_', 'evaluate_', and 'manage_' prefixes clearly indicating actions. This predictability makes it easy for agents to understand the tool's function at a glance, with no deviations in style.
Tool Count2/5
With 31 tools, the count is excessive for a single server, likely overwhelming agents and causing decision paralysis. While the domain (crypto market analysis) is broad, many tools could be consolidated or grouped to reduce complexity, making it feel bloated and inefficient.
Completeness5/5
The tool set provides comprehensive coverage for crypto market analysis, including data retrieval (e.g., get_asset_context, get_macro_context), strategy evaluation, portfolio management, alerts, and webhooks. There are no obvious gaps; it supports full lifecycle operations from setup to monitoring and adjustment.
Average 3.9/5 across 31 of 31 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so full burden falls on description. While 'Get' implies read-only behavior, the description fails to disclose whether this requires authentication, if data is real-time versus cached, potential rate limits, or failure modes when macro data is unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently front-loaded with the action and domain. The colon-separated list of specific metrics is information-dense without being verbose, though slight restructuring could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description partially compensates by enumerating the specific data points returned (Fed Funds Rate, DXY, etc.), but lacks structural details about the response format, data types, or whether all fields are always present versus optionally null.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present, meeting the baseline of 4. With no input parameters, there are no semantics to clarify beyond the schema, and the description appropriately indicates this is a parameterless retrieval operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' and resource 'macro economic context for crypto' with specific output fields listed (Fed Funds Rate, DXY, yield curve, recession probability, net macro impact). Distinguishes from siblings like get_asset_context and get_chain_context by specifying macroeconomic rather than asset-specific or on-chain data, though explicit comparative guidance is absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus sibling tools like get_asset_context, get_chain_context, or get_temporal_context. No mention of prerequisites, sequencing, or conditions where this tool is most valuable versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. While it describes output content, it fails to disclose behavioral traits: read-only safety, data freshness (real-time vs cached), rate limits, authentication requirements, or error conditions. The word 'Get' implies reading, but explicit safety confirmation is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that front-loads the action and resource, followed by specific enumerated components. Every clause earns its place by disambiguating the return payload with concrete examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately compensates by enumerating the four key data components returned (Fear & Greed Index, trend, signals, opportunities). For a simple read-only data retrieval tool, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters. Per evaluation rules, zero parameters establishes a baseline score of 4 since there are no parameter semantics to describe beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('crypto sentiment state'), and enumerates exact data components returned (Fear & Greed Index, 7-day trend, contrarian signals, extreme opportunities). It effectively distinguishes this from generic market data tools by specifying these unique sentiment metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists what data is returned but provides no guidance on when to select this tool over siblings like get_crowd_intelligence, get_narrative_pulse, or get_alternative_signals. No prerequisites, filtering conditions, or decision criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adequately describes the content categories returned (weather data, political positioning, seasonality, macro events) but omits operational details such as data freshness, caching behavior, authorization requirements, or response structure/format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description suffers from marketing fluff ('99% of agents ignore,' 'most tools overlook') that states the same comparative positioning twice. However, the middle sentence efficiently packs four distinct signal categories with specific examples (sunshine effect, Santa Claus rally, FOMC), preventing a lower score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description partially compensates by enumerating the types of alternative signals returned. However, for a tool returning complex multi-domain data, it lacks details on response structure, nesting, or how these signals are formatted (e.g., boolean flags, numerical scores, calendar events).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters. Per calibration guidelines, 0 parameters establishes a baseline score of 4. The description appropriately requires no parameter clarification beyond what the empty schema indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (unconventional market signals) and distinguishes from siblings by emphasizing 'academically documented patterns most tools overlook.' It lists specific signal categories (weather effects, political cycles, seasonality patterns, macro calendar) that differentiate it from standard tools like get_macro_context. However, it lacks an explicit action verb (e.g., 'Retrieves'), relying on the tool name 'get_' to imply the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by characterizing these as signals '99% of agents ignore' and patterns 'most tools overlook,' suggesting when to use this over conventional market data tools. However, it lacks explicit when-to-use/when-not-to-use guidance or named alternative tools to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully communicates Beta status and data quality caveats ('Accuracy scoring is under development'), but omits operational details like pagination behavior, data retention periods, or computational costs that would be needed for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four efficient sentences with minimal waste. The Beta tag is front-loaded, followed by purpose, specific data fields, use case, and data quality disclaimer. Each sentence adds distinct value, though 'Shows recent signals' slightly overlaps with 'View...signal log' but adds field specificity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple single-parameter tool with complete schema coverage. The description identifies key return fields (regimes, postures, risk scores) compensating somewhat for the missing output schema, but could strengthen completeness by clarifying the time window behavior (only 'recent' signals) and Beta limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage for the single 'limit' parameter which is well-documented in the schema itself. The description mentions no parameters, which warrants the baseline score of 3 when schema coverage is high (>80%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool 'View Fathom's signal log' with specific content details (regimes, postures, risk scores) that help distinguish it from siblings like get_alerts or get_market_regime. However, it lacks explicit scope limitations or direct comparison to sibling tools that would make differentiation immediate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an implied use case ('Useful for tracking how conditions evolved over time') but lacks explicit guidance on when to select this over siblings like get_historical_context or get_alternative_signals, and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adequately describes the conceptual output (TVL trends, health scores) substituting for the missing output schema, but lacks operational details like data sources, caching behavior, or freshness of data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with efficient colon structure. Front-loaded purpose ('Assess DeFi ecosystem health') followed by specific metric enumeration. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately compensates for missing output schema by enumerating expected return data (TVL, revenue trends, concentration risk). For a zero-parameter read-only tool, this provides sufficient context, though data source or latency notes would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema contains zero parameters. Per scoring guidelines, zero parameters warrants a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Assess') and resource ('DeFi ecosystem health') with specific output metrics listed (TVL, health score, concentration risk). Implicitly distinguishes from siblings like get_asset_context or get_chain_context by focusing on ecosystem-wide DeFi metrics, though lacks explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists what data is returned but provides no guidance on when to use this versus alternatives like get_chain_context or get_macro_context. No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full disclosure burden. It compensates partially by listing the specific fields returned (regime, fear/greed, risk score, BTC price, TVL) which helps since there is no output schema. However, it omits operational details such as how far back historical data extends, whether the lookup is idempotent, or if there are rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief with three information-dense statements covering purpose, return values, and utility. The structure front-loads the core action and avoids redundancy, though the fragment 'Returns regime...' slightly breaks grammatical flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one primitive parameter) and lack of output schema, the description adequately compensates by enumerating the returned data fields. However, it could be strengthened by noting date range limitations or data availability constraints that are common considerations for historical lookups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter, documenting the ISO format with examples. The description adds no additional semantic context beyond implying a historical date is required, meeting the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves historical market conditions using the specific verb 'Look up' combined with the resource 'market conditions'. It effectively distinguishes this from sibling tools by emphasizing the temporal aspect ('on a specific date', 'past conditions') and listing specific historical data points (regime, fear/greed) that suggest a historical snapshot rather than current state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the use case 'comparing past conditions to current ones' which implies when the tool is valuable. However, it lacks explicit guidance on when not to use this tool (e.g., for real-time data) and fails to name specific alternatives from the sibling list like get_market_regime or get_temporal_context that might serve similar but distinct purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description carries full burden. States 'Save' implying persistence, but does not clarify if calls overwrite or append, validation rules for asset names, or session vs permanent storage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with front-loaded purpose. The inline example is dense but high-value. No redundancy, though could benefit from line breaks for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a setter with complete schema coverage and helpful example. Missing clarification on update semantics (overwrite vs modify) and whether this is required before calling get_portfolio_analysis.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the concrete JSON example adds significant value by showing exact format, asset naming conventions (fullname vs ticker), and implied data types in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Save' and resource 'portfolio holdings' with explicit outcome 'personalized guidance'. Distinguishes from getter siblings but does not clarify relationship vs other 'set_' tools like set_custom_strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the outcome benefit (personalized guidance) implying when to use it, but lacks explicit when-not guidance or comparison to alternatives like manual state management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It transparently lists what data aspects are returned (behavioral output characteristics), but lacks operational details such as data freshness, caching behavior, rate limits, or whether this requires specific permissions/tiers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first establishes value proposition and return data scope, second provides input instruction with concrete examples. Appropriately front-loaded and sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description adequately compensates by enumerating the six analytical dimensions returned. Given the single simple input parameter and the richness of the described output, this is complete enough, though mentioning return format (object vs text) would elevate it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'asset' parameter fully documented. Description echoes the schema's example values ('bitcoin', 'btc') without adding syntactic constraints, validation rules, or semantic distinctions between name vs symbol resolution. Meets baseline expectations when schema is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb+resource ('Get deep context' on 'crypto asset') and lists six distinct analytical aspects returned (cycle position, price trend, volume health, holder behavior, risk level, positioning guidance). However, it does not explicitly differentiate from siblings like get_asset_momentum or get_onchain_pulse, leaving ambiguity about why to choose this comprehensive tool over specialized alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit when-to-use or when-not-to-use relative to siblings, nor mentions prerequisites. However, the exhaustive list of analytical aspects implicitly signals this is the comprehensive asset analysis tool vs. single-metric alternatives, meeting the threshold for implied usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Adds valuable behavioral context by specifying list returns 'conditions, trigger counts, and last triggered time'. Mentions 'delete' for remove action, but omits safety details (permanent deletion, error handling, auth requirements) that annotations would typically cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with logical structure: overview, list details, remove details. No filler content. Slightly verbose with quoted action names and redundant 'webhook' references, but generally efficient for the dual-purpose explanation required.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description must cover return values. Adequately describes list output (conditions, trigger counts, timestamps) but omits what remove returns (success confirmation, error states). Given 2-parameter simplicity, coverage is acceptable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage establishing baseline 3. Description reinforces parameter purposes ('list to see all', 'remove with webhook_id to delete') and adds context about list output fields, which helps understand the action's utility without repeating schema definitions verbatim.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states dual functions (list/remove) and uses specific verbs with the resource 'webhooks'. The term 'registered webhooks' implicitly distinguishes this from sibling 'set_webhook' (creation), but lacks explicit cross-reference naming the alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on parameter values: 'Use action list to...' and 'Use action remove with...'. Clearly maps actions to outcomes. Lacks explicit 'when not to use' guidance (e.g., not for creating webhooks) though this is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It successfully details the analytical constructs returned (sector rotation, momentum scores, cycle phase, narrative classification), but omits operational context like data latency, source aggregation, or permission requirements expected for a financial data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with zero waste. Front-loaded with specific action verbs (Identify/Shows) and immediately qualifies the scope (accelerating/decelerating/emerging). Every phrase earns its place by conveying distinct analytical dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero input complexity and absence of output schema or annotations, the description adequately compensates by enumerating the key conceptual data points returned (sector rotation, momentum scores, cycle phase). Sufficient for agent selection despite lacking format specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema contains zero parameters. By baseline rules for zero-parameter tools, no additional semantic explanation is required in the description, warranting the default score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verbs ('Identify', 'Shows') and clearly defines the resource as 'crypto narratives' with distinct scope (accelerating/decelerating/emerging). Differentiates from sibling tools like get_asset_momentum and get_sentiment_state by focusing on narrative/themes rather than individual assets or raw sentiment, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage context with 'for positioning,' suggesting use during portfolio or trade positioning decisions. However, lacks explicit when-to-use guidance or comparison to related analysis tools like get_market_regime or get_asset_momentum.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It adequately discloses what data is returned (days since halving, cycle phase, analogs, guidance) but omits operational characteristics like whether this is a read-only operation, rate limits, or data freshness/staleness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense sentence with zero waste. Front-loaded with action verb ('Get'), followed by resource specification, then colon-delimited list of specific return components.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool without output schema, the description sufficiently enumerates return value components (days, phase, analogs, guidance). Minor gap: does not indicate if tool covers only Bitcoin or if it retrieves data for other assets with halving mechanics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present; baseline 4 applies per rubric. No parameter explanation required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'Get Bitcoin halving cycle positioning' uses concrete verb and resource, clearly distinguishing this from sibling tools like get_historical_context or get_macro_context by focusing specifically on halving cycle data rather than general price history or macro indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to invoke this tool versus alternatives like get_historical_context or get_asset_context, nor does it specify prerequisites (e.g., Bitcoin-only analysis scope).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: comparative analysis ('state changes since last check'), return dimensions (cycle position, risk, volume), and hard limit (max 10). Without annotations, missing operational details like rate limits, caching/TTL for 'last check', or error behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, zero waste. Front-loaded with core action ('Analyze multiple assets'), followed by outputs, behavior, and constraints. Each sentence earns its place with distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description appropriately explains return values (cycle position, risk level, volume health). Covers the tool's comparative nature and batch constraints. Could mention error handling or invalid asset behavior, but sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage (assets array documented with examples), baseline is 3. Description reinforces the maxItems constraint ('Max 10 assets') but doesn't add parameter syntax, format details, or validation rules beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Analyze multiple assets') and distinguishes from single-asset siblings like get_asset_context/get_asset_momentum. Specifies exact analysis dimensions (cycle position, risk level, volume health) that clarify the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies monitoring use case via 'Detects state changes since last check' and states the 'Max 10 assets' constraint. However, lacks explicit guidance on when to prefer this over single-asset alternatives or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses key behavioral traits: preferences persist between sessions (statefulness), regime/sentiment cannot be disabled (immutable constraints), and signals can be individually toggled (mutation scope). It does not mention rate limits or return values, but covers the essential behavioral contract for a preferences tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four efficient sentences front-load the purpose (reality check customization), explain mechanism (on/off), state constraints (regime/sentiment), and provide persistence info with a concrete example. Every sentence earns its place, though the example sentence combines persistence declaration with example data which slightly impacts scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nine well-documented boolean parameters (100% schema coverage) and no output schema, the description appropriately focuses on domain context (reality check integration) and behavioral constraints rather than repeating parameter documentation. It adequately explains what the tool affects and how settings behave over time, which is sufficient completeness for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds valuable context by explaining that regime and sentiment are omitted from parameters because they are always included—justifying the schema structure. It also maps parameters to the 'reality check' domain and provides a concrete JSON example that clarifies the boolean toggle semantics beyond the schema's 'Include...' descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool customizes signal sources feeding into the user's 'reality check' (specific verb+resource combination). It scopes the tool to the reality-check feature, implicitly distinguishing it from siblings like set_alert or set_custom_strategy. However, it assumes familiarity with what 'reality check' means without referencing the sibling get_reality_check tool explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete constraints ('Regime and sentiment are always included') and an example usage pattern, which implies when certain parameters should be toggled. However, it lacks explicit guidance on when to use this versus set_alert or set_custom_strategy, and does not state prerequisites or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'evaluate' but fails to clarify if this is read-only simulation, modifies state, or incurs costs/rate limits. Critical behavioral gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with zero waste. Front-loaded with action and scope, followed by valid inputs and their source. Excellent information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a single-parameter tool with complete schema coverage, but gaps remain: no output schema exists yet description omits what evaluation returns, and behavioral safety is undisclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value by enumerating all five valid built-in strategy names (completing the partial list in schema) and clarifying custom strategy provenance from 'set_custom_strategy'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Provides specific verb (Evaluate), resource (trading strategy), and scope (against current market conditions). Lists all five built-in strategies, clearly positioning it relative to the data-retrieval 'get_' siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly references sibling tool 'set_custom_strategy' as the prerequisite for evaluating custom strategies, clarifying the workflow. However, lacks explicit 'when not to use' guidance relative to analysis tools like 'get_portfolio_analysis'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds valuable behavioral context that 'alert conditions' are evaluated against 'live market data' (real-time evaluation). However, with zero annotations, the description fails to disclose safety profile (read-only vs mutation), error conditions (what if no alerts configured?), or idempotency concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly constructed sentences with zero redundancy. First sentence establishes purpose, second adds critical behavioral context (live evaluation). Appropriately terse for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality adequately for a low-complexity tool, but lacks output specification (what format do triggered alerts return in?) and error scenarios. No output schema exists to compensate, leaving operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present per schema. Per scoring rules, 0 params equals baseline score of 4. No parameters require semantic elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'Check' and 'Evaluates' are clear action verbs, 'configured alerts' identifies the resource precisely. Implicitly distinguishes from sibling 'set_alert' by focusing on checking existing configured alerts rather than creating them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage context ('Check which...are currently triggered'), but fails to explicitly contrast with sibling 'set_alert' or indicate when to prefer this over other monitoring tools like 'get_watchlist_report'. No explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully identifies the data source (Deribit) and enumerates specific data categories returned, but omits critical behavioral details such as data freshness (real-time vs cached), rate limits, or whether historical data is available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description efficiently packs specific data types, use case justification, and source attribution into two sentences. While 'Derivatives intelligence' is slightly abstract, the colon-delimited list immediately clarifies the concrete data points, minimizing cognitive load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameters and output schema, the description adequately compensates by enumerating the specific metrics returned (funding rates, Greeks, open interest). For a simple data-retrieval tool, this provides sufficient context for invocation, though mentioning return structure format would further improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Per the evaluation rules, tools with zero parameters receive a baseline score of 4. The input schema contains no properties requiring semantic elaboration, so no additional descriptive compensation is needed beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely identifies the resource (derivatives data) and specific sub-types (perpetual funding rates for BTC/ETH/SOL, options data including put/call ratios and max pain price, and leverage positioning). It clearly distinguishes from siblings like get_asset_context or get_macro_context by focusing exclusively on derivatives market data from Deribit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context by stating it is 'Critical for understanding market positioning and liquidation risk,' which hints at when to invoke the tool. However, it lacks explicit guidance on when to choose this over similar context-gathering siblings (e.g., get_asset_context vs get_derivatives_context) and does not mention prerequisites or filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It adequately reveals the stateful dependency on set_portfolio_context but fails to disclose other behavioral traits like idempotency, error responses when context is missing, caching behavior, or rate limits. The mention of what it 'Shows' implies read-only behavior but does not explicitly confirm no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: sentence 1 defines purpose, sentence 2 enumerates outputs, and sentence 3 states prerequisites. Information is front-loaded and each sentence earns its place without redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description compensates by listing expected return components (position values, allocation percentages, PnL, etc.). It appropriately covers the stateful prerequisite for a zero-parameter tool, though annotations for read-only safety or performance hints would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, establishing a baseline score of 4 per evaluation rules. The description implicitly explains the absence of personalization parameters by noting the requirement for set_portfolio_context, suggesting configuration happens externally rather than per-call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get personalized portfolio analysis') and enumerates specific outputs including 'position values, allocation percentages, PnL, concentration risk, regime alignment, and specific rebalancing suggestions,' which distinguishes it from sibling tools like get_market_regime or get_account_status that return narrower datasets. However, 'personalized' remains vague regarding which entity's portfolio is analyzed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the temporal prerequisite 'Requires set_portfolio_context to be called first,' establishing clear sequencing for when to use the tool. This prevents invocation errors by indicating the required setup state, though it does not explicitly list alternative tools for users without portfolio context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It explains the trigger mechanism conceptually and the workflow (set then get), but omits critical behavioral details: whether alerts persist across sessions, overwrite previous calls or append, volume limits, and what 'triggered' means (notification vs state change).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient components: purpose statement, concrete example, and usage workflow. Every sentence earns its place; front-loaded with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage and no output schema, the description covers the essential input structure via example. However, for a configuration tool with no annotations, it should clarify mutation semantics (append vs replace) and persistence to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage (baseline 3). The concrete JSON example adds significant semantic value by showing valid operator syntax ('<'), field name format ('fear_greed'), and array structure, complementing the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ('Set custom alerts'), specific domain context ('market conditions'), and distinguishes from sibling get_alerts by stating alerts 'trigger' and require calling get_alerts to check status. The example clarifies the threshold concept effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides workflow guidance ('Call get_alerts to check which are triggered') but lacks explicit comparison with similar configuration tools like set_signal_preferences or manage_webhooks, and doesn't specify when to use alerts vs webhooks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adequately describes the conceptual data returned (compensating for the missing output schema), but omits operational details like rate limits, data freshness, error behaviors for unsupported chains, or whether results are cached vs real-time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: the first clause defines the action and resource, the colon-delimited list specifies return values, and the final fragment enumerates valid inputs. Zero waste, appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter input and lack of output schema, the description compensates well by detailing the expected return content (TVL, dominance, etc.) and listing all valid chain values. It is complete for a read-only data retrieval tool, though error scenarios could be mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema already documents the parameter well. However, the description adds significant value by providing the complete enumeration of supported chains ('ethereum, solana, base...'), effectively serving as an enum constraint that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clear resource ('DeFi context for a specific blockchain'), then enumerates exactly what metrics are returned (TVL, dominance, trend, top protocols, market share direction). This clearly distinguishes it from sibling tools like get_asset_context (asset-level) and get_defi_health (health-focused).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage through specificity of returned metrics, it lacks explicit guidance on when to prefer this over siblings like get_onchain_pulse or get_defi_health. No alternatives or exclusion criteria are mentioned, leaving selection logic implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The [BETA] tag and network scaling disclosure add value beyond the empty schema, but with no annotations provided, the description carries the full burden and omits rate limits, data freshness, or caching behavior typical for intelligence feeds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficiently structured sentences: beta status and primary purpose front-loaded, return values specified second, and quality caveat third. Every sentence conveys distinct information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description adequately enumerates the four aggregate metrics returned. It covers the beta lifecycle status and network dependency, though data update frequency or TTL would strengthen completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage trivially satisfied, the description appropriately makes no parameter claims, meeting the baseline expectation for zero-argument tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'see' and resource 'what other Fathom-connected agents are doing' clearly identifies the crowd intelligence scope. Lists specific return metrics (posture distribution, consensus strength, fear levels) that distinguish it from individual asset analysis tools like get_asset_context or get_sentiment_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides the caveat that 'Signal quality scales with network size,' implying usage constraints, but lacks explicit guidance on when to prefer this over similar aggregate tools like get_sentiment_state or get_narrative_pulse in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It effectively discloses response structure (impact ratings, expected direction, historical volatility, trading notes) and time buckets (24h/7d/30d), but omits operational details like data freshness, rate limits, caching behavior, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly efficient single sentence with zero waste. Front-loaded with the core concept ('Upcoming market-moving events'), followed by concrete examples, then detailed return structure specifications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Compensates well for missing output schema by detailing return fields (impact ratings, volatility, trading notes) and timeframes. With zero inputs and no annotations, the description adequately covers what the agent needs to know to invoke and handle the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present per context signals, which establishes a baseline of 4. No parameter semantics needed in description, and none provided, which is appropriate given the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent clarity: uses specific verb 'Returns' plus concrete resource examples (FOMC, CPI, options expiry, BTC halving) that distinguish this as a scheduled events/calendar tool distinct from general market data or sentiment siblings like get_macro_context or get_sentiment_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists specific event types (quad witching, political events) that imply appropriate use cases, but lacks explicit guidance on when to prefer this over get_macro_context or get_temporal_context, and includes no 'when-not-to-use' exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return value categories (mempool congestion, fees, etc.) but omits operational details: safety profile (read-only vs destructive), rate limits, data freshness, or authentication requirements. The 'Get' prefix suggests read-only but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence with action front-loaded. The colon-delimited list of six specific metrics adds precise value without verbosity. No filler words or redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description adequately compensates by enumerating six specific return categories that would typically appear in an output schema. Lacks only operational metadata (rate limits, caching) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present. According to scoring rules, 0 params = baseline 4. The description appropriately requires no parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: verb 'Get' + resource 'Bitcoin on-chain health' with six explicit metric categories (mempool congestion, fees, miner distribution, etc.). Clearly distinguishes from sibling get_chain_context (general blockchain data) and get_asset_context (market data) by focusing specifically on Bitcoin network health metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or comparison to siblings like get_chain_context or get_defi_health. However, the highly specific scope ('Bitcoin on-chain health') makes the intended use case implied—users should call this when they need Bitcoin network metrics specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and effectively discloses what data is returned (current tier, hourly request usage, locked/unlocked tools, cache state, upgrade options). It implies read-only behavior via 'Check' but does not explicitly state safety characteristics or cache behavior beyond freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences. First sentence is front-loaded with the action verb and enumerates specific data points returned. Second sentence provides necessary tier constraint. No redundancy with structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status endpoint with no output schema, the description adequately compensates by listing specific response fields and access constraints. Sufficient for agent to understand this retrieves quota/account metadata rather than market data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters (coverage 100%), establishing baseline 4. Description confirms there are no configuration options required (implicitly, by focusing entirely on return value description and not mentioning required inputs).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Check' with resource 'Fathom account' and enumerates specific return fields (tier, requests used, tools, cache freshness). It clearly distinguishes from data-focused siblings (get_asset_context, get_correlation_matrix, etc.) by focusing on account metadata and rate limit status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides tier availability context ('Available on all tiers including free') indicating when the tool is accessible, but lacks explicit guidance contrasting with action-oriented siblings like rotate_api_key or set_alert. Usage is implied by the nature of the return fields listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It comprehensively enumerates output components (executive summary, scores, regime, etc.) but omits operational characteristics critical for a heavy aggregation tool: latency expectations, computational cost, caching behavior, or read-only safety assurances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with value proposition ('The master tool'). The enumerated list of briefing components is long but necessary to communicate scope breadth efficiently. Final sentence delivers clear usage directive. Minimal waste despite density of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking output schema and annotations, description compensates by detailing the 10+ output sections (executive summary, risk scores, etc.). Adequate for a zero-parameter aggregation tool, though could enhance with performance warnings given 'ALL data sources' complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema contains zero parameters. Per scoring rules, zero-parameter tools receive baseline 4. The description appropriately acknowledges no configuration is needed by not mentioning parameters, consistent with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (synthesizes ALL data sources) and output type (unified financial reality briefing). Explicitly positions itself as the 'master tool' against 20+ specialized siblings (get_macro_context, get_asset_context, etc.), clearly distinguishing its comprehensive scope from domain-specific alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Call this before any financially consequential decision'). While it doesn't explicitly name sibling alternatives or exclusion criteria, the 'master tool' framing effectively implies this is the entry point before drilling down with specialized tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Create' implying mutation/persistence, and mentions workflow with evaluate_strategy. However, lacks details on idempotency (duplicate names?), return values, or side effects (does it activate immediately?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Front-loaded with purpose, second sentence earns its place by providing critical workflow context. No redundancy with structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Creation tool with no annotations and no output schema. Description provides adequate workflow context (use evaluate_strategy next) but omits what this returns (strategy ID?), persistence behavior, or error conditions. Adequate but gaps remain for a state-mutating operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, establishing baseline 3. Description references 'conditions' generally but adds no syntax details, examples, or format guidance beyond what the schema already provides for the nested field/operator/threshold structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb (Create) + resource (custom trading strategy) + scope (with conditions). Explicitly distinguishes from sibling evaluate_strategy by stating this tool creates while that one tests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Excellent workflow guidance: explicitly directs user to 'use evaluate_strategy to test it against current market conditions' after creation. Clear sequencing between create and evaluation phases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries the full burden. It effectively discloses return data structure (total supply, 24h/7d/30d minting/redemptions, depeg warnings, liquidity assessment) and semantic meaning (net capital flow signal). Missing operational details like data freshness, rate limits, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: (1) core purpose and scope, (2) specific data points returned, (3) interpretive value/usage context. Logical progression from what to why. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, description adequately compensates by detailing return value structure (timeframes, warning types, assessments). Sufficient for a simple retrieval tool, though mentioning data latency or granularity would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters. Per evaluation rules, baseline score is 4 for parameter-less tools. No parameters exist requiring semantic clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Track' + specific resource 'stablecoin supply changes' with clear scope (USDT, USDC, all major). Explicitly distinguishes from generic siblings like get_asset_context or get_onchain_pulse by focusing specifically on stablecoin mechanics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong contextual guidance by stating these flows are a 'leading indicator of capital entering or leaving crypto,' signaling when to invoke (capital flow analysis). Lacks explicit naming of alternative tools (e.g., get_onchain_pulse), so stops short of score 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Successfully reveals polling frequency (60s), conjunction logic (ALL conditions), and payload format (JSON). Missing webhook lifecycle details (expiration, persistence) and error handling behavior (retries, timeout).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four logical segments: purpose declaration, behavioral details, concrete example, field reference. Every sentence earns its place. Front-loaded with essential mechanism details before moving to reference data. No redundant or tautological language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage and no output schema, description appropriately compensates by explaining the trigger evaluation logic and field semantics. Minor gap: does not indicate what successful registration returns (webhook ID?) or management lifecycle, which would help for a stateful configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description adds significant value by enumerating complete available field list (expanding on schema's 'etc.'), and providing concrete syntax example showing operators and thresholds in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent clarity: 'Register a webhook' provides specific verb and resource. Expands to explain trigger mechanism (market conditions), execution frequency (60 seconds), and payload format (JSON POST). Clearly distinguishes from passive data retrieval tools in sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete usage example ('alert me at my bot URL when fear_greed < 20...') illustrating the condition syntax. However, lacks explicit guidance on when to use this versus set_alert or manage_webhooks siblings, or prerequisites like URL accessibility requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and performs well: it documents the complete output structure including ranges (confidence_score -100 to +100), enum states (volatility states), and constituent metrics, effectively compensating for the missing 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient two-sentence structure: defines the tool, enumerates return values with ranges/states, lists valid timeframes, and states the use case. Every clause delivers value with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a 2-parameter tool. Given the lack of an output schema, the description meticulously documents all return fields, value ranges, and categorical states, leaving no critical gaps for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both 'asset' and 'timeframe' are well-documented in the schema), establishing a baseline of 3. The description repeats the timeframe options and implies broader asset support ('any asset') but adds minimal semantic depth beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific operation ('Short-term momentum signal') on a specific resource ('any asset') and distinguishes itself from sentiment-focused siblings like get_sentiment_state or get_narrative_pulse by listing technical indicators (RSI, Bollinger bandwidth, ATR).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context ('Essential for timing entries and exits'), indicating when to invoke the tool. However, it does not explicitly contrast with similar analysis siblings (e.g., get_alternative_signals) or state when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries full disclosure burden and succeeds by detailing the analytical methodology (classification with confidence scoring) and specific output components (evidence, historical analog, actionable guidance). Lacks operational details like rate limits or latency, but clearly establishes this as an analytical inference tool rather than simple data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense sentence of ~25 words with zero waste. Front-loaded with specific regime taxonomy followed by comma-separated output descriptors. Every clause conveys essential information about capability and return structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Excellent coverage for a parameter-less tool with no output schema. Compensates for missing output schema by explicitly enumerating return components (confidence score, evidence, historical analog, guidance), fully preparing the agent for the structured analytical response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present, warranting baseline score of 4 per rubric. Schema is empty object with no fields requiring semantic elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Classify' paired with clear resource 'crypto market regime' and detailed scope including five distinct regime types (risk-on, risk-off, transitional, euphoric, capitulation). Distinguishes from siblings like get_macro_context or get_sentiment_state by focusing specifically on regime classification with multi-factor evidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context through specificity of regime classification framework, but lacks explicit when-to-use guidance versus alternatives like get_macro_context or get_alternative_signals. No mention of prerequisites or conditions that would trigger selecting this over sibling analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations exist, description carries full burden and discloses: calculation method (Pearson correlation), timeframe (30-day), included assets (S&P 500, Gold), additional returned data (current TradFi prices), and interpretation semantics (risk asset classification). Only missing operational details like data freshness or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: technical specs first, interpretation guide second, use case third. Front-loaded with specific methodology and assets. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool without output schema, description adequately explains return values (correlation coefficients, TradFi prices) and their semantic meaning (spillover risk assessment). Sufficient for an agent to understand what data will be returned and how to interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters, establishing baseline of 4. Description adds value by specifying the implicit timeframe (30-day) and fixed methodology (Pearson) that would otherwise be unknown parameters of the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (correlation) + specific resources (BTC vs S&P 500/Gold) + methodology (30-day Pearson). Distinguishes from siblings like get_macro_context or get_asset_context by focusing specifically on cross-asset correlation analysis rather than general market data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use it ('Critical for understanding macro spillover risk') and what insight it provides ('Shows whether BTC is trading as a risk asset, safe haven, or independently'). While it doesn't explicitly name sibling alternatives, the functional scope is distinct enough to imply appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It excellently discloses destructive behavior ('deactivates the old one'), side effects (invalidates previous key), output ('returns the new key'), rate limits, and tier requirements. Comprehensive for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, zero waste. Front-loaded with the core action, followed by mechanics, user obligations, limits, and requirements. Every sentence provides essential information not available in structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explicitly states what gets returned ('returns the new key'). Covers prerequisites, side effects, and operational constraints, making it complete for a credential rotation tool with no parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters. Per rubric, 0 params = baseline 4. The description correctly focuses on operation mechanics rather than inventing unnecessary parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Rotate' with the resource 'Fathom API key' and clearly distinguishes from siblings (all data retrieval/analysis tools). It further clarifies the mechanics: 'Generates a new key, deactivates the old one, and returns the new key'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear prerequisites ('Requires Starter tier or above'), rate limits ('Max 3 rotations per day'), and critical post-action requirements ('The user must update their MCP config with the new key'). Lacks explicit 'when-not-to-use' or named sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fathom-fyi MCP server](https://glama.ai/mcp/servers/0xHashy/fathom-fyi/badges/card.svg)](https://glama.ai/mcp/servers/0xHashy/fathom-fyi)

Score Badge

Copy to your README.md:

[![fathom-fyi MCP server](https://glama.ai/mcp/servers/0xHashy/fathom-fyi/badges/score.svg)](https://glama.ai/mcp/servers/0xHashy/fathom-fyi)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/0xHashy/fathom-fyi'

If you have feedback or need assistance with the MCP directory API, please join our Discord server