fahali-mcp

Server Quality Checklist

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

Latest release: v1.5.3
Disambiguation4/5
Most tools have distinct purposes due to very detailed descriptions, but there is some overlap among portfolio risk tools (metrics, risk, analyze) and market data tools (sentiment, verdict, snapshot, regime). An agent could confuse them without careful reading, but the descriptions generally clarify.
Naming Consistency4/5
The vast majority follow the 'fahali_get_<descriptive_name>' pattern, but 'search_memories' lacks the prefix and uses 'search' instead of 'get', and 'fahali_analyze_custom_portfolio' uses 'analyze'. These minor deviations prevent a perfect score.
Tool Count4/5
22 tools is slightly above the typical well-scoped range, but each tool serves a specific analytical function (e.g., engine status, case studies, correlation matrices). The count is justified by the broad domain of financial analytics, though a few could potentially be merged.
Completeness4/5
The tool set covers the core functionalities of the Fahali platform: market data, detection engines, portfolio risk, and track records. However, it lacks any mutation or write operations (e.g., setting alerts, managing portfolios) and is missing some common financial data queries like historical prices or news feeds, which are minor gaps.
Average 4.2/5 across 22 of 22 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on July 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
This repository includes a glama.json configuration file.
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

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 discloses default limit, compact mode behavior, and public data status. However, it omits details like error handling, data freshness (real-time vs delayed), or sorting direction, leaving gaps for the agent.
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?
The description is three sentences, 35 words, with the key purpose in the first sentence. No filler or repetition. Every sentence adds distinct information, making it efficient for an agent to parse.
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 an output schema, the description covers the main return fields (prices, changes, etc.), default limit, and compact mode. It does not explain sorting/filtering behavior or response format, but for a simple list tool this is largely sufficient.
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 description coverage is 100%, baseline is 3. The description adds minimal extra value: it restates the default limit and simplifies compact mode output, but does not address sort_by or asset_class beyond what the schema already provides. Minor redundancy detected.
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 a live market snapshot with detailed fields (prices, changes, asset class, venue, underlying). However, it does not explicitly differentiate from sibling tools like fahali_get_market_sentiment, leaving the agent to infer use cases from context.
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 is provided on when to use this tool versus other market-data siblings. The mention of 'public data — no tier required' is a constraint, not a usage condition. Alternatives are not named, and there is no when-not-to-use advice.
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 are provided, so the description must fully disclose behavior. It states the tool synthesizes data from three engines and returns four specific metrics. It implies a read-only operation without side effects, but does not explicitly confirm non-destructiveness or state any rate limits or other behavioral details.
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, each serving a distinct purpose: first states the tool's action and summary of metrics; second adds data sources and access requirements. No unnecessary words, well 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?
For a tool with no parameters and no output schema, the description covers the returned metrics, their derivation, and data sources. It could mention whether the metrics are real-time or snapshot, but overall is sufficiently complete for an agent to understand usage.
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 has no parameters (schema coverage 100% by emptiness). The description adds value by explaining the returned metrics and their derivation, which is the only needed context since there are no parameters to describe.
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 aggregates portfolio risk metrics and lists the specific metrics (sentiment momentum, cascade risk, liquidity stress, signal stress). This differentiates it from siblings like fahali_get_portfolio_risk which may focus on individual risk factors, though the distinction is not explicit.
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 notes the data is public and no tier required, which helps with access decisions. However, it does not specify when to use this tool versus alternatives such as fahali_get_portfolio_risk or other risk-related tools, nor 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses return values (risk score, VaR95, etc.) and access requirements, but does not mention side effects, rate limits, or whether the operation is read-only. The description is adequate but not exhaustive.
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?
The description is extremely concise, using three sentences to convey purpose, outputs, and requirements without extraneous words. It is front-loaded with the main action.
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, no annotations, and no output schema, the description provides sufficient detail about returned data (risk score, VaR95, drawdown, recommendations) and prerequisites. Minor omission: could mention update frequency or data freshness, but overall complete for this 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?
With zero parameters and 100% schema description coverage, the description adds no parameter information, which is unnecessary. Baseline is 4 for no parameters, and the description appropriately avoids redundant detail.
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 'portfolio risk assessment' with specific outputs like risk score (0-100), VaR95, drawdown, and per-position recommendations. It distinguishes from siblings like fahali_get_portfolio_metrics by focusing on risk, but lacks explicit differentiation from other risk tools.
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 mentions prerequisites ('Requires connected exchange accounts' and 'Elite tier or higher'), which provides usage context. However, it does not specify when to use this tool over alternatives or indicate when not to use it, leaving the guidance incomplete.
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, the description carries full burden. It explicitly discloses that the data is a proxy from public microstructure, not actual off-exchange measurements. It also states the engine coverage and tier requirement. This is transparent for a non-destructive read 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?
Three short sentences with no wasted words. The first sentence front-loads the core purpose, the second adds a critical caveat, and the third provides scope and access info. Every sentence adds value.
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?
The description covers what the tool returns (symbols, score, patterns, sentiment, ML breakdown) and the data limitation. There is no output schema to supplement. Minor gaps include lack of score interpretation or data frequency, but it is fairly complete for a parameterless 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?
There are zero parameters in the input schema, so the description need not add parameter details. The baseline for no params is 4. The description does not add anything beyond what the schema provides, but it correctly implies no input is needed.
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 it retrieves dark pool proxy estimates and lists output components (score, patterns, sentiment, ML breakdown). It specifies it is a proxy and covers the 'dark_pool engine'. While it does not explicitly differentiate from sibling tools, the verb and resource are specific enough.
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 notes 'Public data — no tier required', implying broad accessibility. However, it does not specify when to use this tool over alternatives, nor does it mention any exclusions or prerequisites. Usage context is only implied.
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?
The description fully discloses that the tool returns 40 time-diverse cases with detailed fields, and states it is public. However, without annotations, it could have added more about potential limitations or side effects (e.g., rate limits, data freshness). It does not contradict any implicit behavioral expectations.
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?
The description is two sentences long, front-loaded with the essential action and result details. Every sentence adds value: the first explains what is returned, the second adds the engine context and access level.
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, the description provides a thorough list of return fields and notes public access. It explains the source and coverage of the cases. Missing is an explicit use case or when to prefer this tool, but it is largely complete for the tool's simplicity.
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 tool has zero parameters, so schema coverage is effectively 100%. The description adds no parameter details but explains the return data, which compensates for the lack of output schema. Baseline for zero parameters is 4.
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 clearly states the tool retrieves verified case studies with a specific list of fields, including symbol, alert type, confidence, direction, entry/outcome prices, profit/loss, correctness, outcome kind, and returns. It specifies the source as 'signal-outcome moat' and 'walk_forward engine,' making the purpose distinct and actionable.
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 notes 'Public data — no tier required,' which implies accessibility, but it does not specify when to use this tool versus alternatives like fahali_get_track_record_scorecard or search_memories. No explicit when-to-use or when-not-to-use guidance is provided.
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 discloses the output structure (nodes, edges, clusters) and the engine coverage (tail_dependence and correlation). However, it does not state whether the tool is read-only, safe, or has any rate limits or side effects. The tier requirement is mentioned but not what happens if unmet. Basic but not comprehensive.
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?
The description is three sentences, front-loaded with the main purpose, and every sentence adds value. No redundant or filler content. Well-structured and efficient.
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 complexity (returning nodes, edges, clusters with multiple attributes) and the absence of an output schema, the description explains the return values at a high level. It covers the main components and mentions the required tier. Minor specifics like definitions of 'risk scores' or 'confidence' are omitted, but overall it gives sufficient context for an agent to understand what the tool provides.
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 has zero parameters, so schema description coverage is 100% (empty). Baseline for 0 parameters is 4. The description does not need to add parameter information since there are none, and it correctly focuses on the output instead.
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 clearly states the tool gets a 'cross-asset contagion and tail dependence map' and enumerates what it returns: nodes with risk scores, edges with correlation strength/confidence/time, and clusters with lead symbols. This specific verb+resource distinguishes it from sibling tools like fahali_get_correlation_matrix, which focuses on general correlation.
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 mentions a prerequisite ('Requires Elite tier or higher') but does not provide explicit guidance on when to use this tool versus alternatives. For example, it doesn't contrast with the similar correlation matrix tool or indicate scenarios where contagion analysis is more appropriate. Usage context is implied by the tool's purpose but not explicitly stated.
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 must cover behavioral traits. It states the tool is a 'Get' operation (read), returns specific data, and is public. However, it does not mention side effects, latency, or rate limits. While sufficient for a simple read, more explicit safety info would improve clarity.
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 concise sentences: first specifies action and source, second enumerates return fields, third notes engine coverage and access. No redundancy, well-structured, and front-loaded with key purpose.
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 adequately details the return fields (correlation, dependence, affected symbols, etc.). It also clarifies engine coverage and access level. Lacks explicit structure format, but the list of fields suffices for a simple retrieval 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?
No parameters exist, so the description carries no parameter burden. It effectively describes the output and engine coverage, adding value beyond the empty schema. Baseline for 0 params is 4, and it meets that.
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 clearly states the tool retrieves a cross-asset correlation matrix from the tail_dependence engine. It lists specific return fields (per-symbol correlation, dependence strength, etc.) and mentions it covers both correlation and tail_dependence engines, distinguishing it from siblings like contagion maps or portfolio 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?
The description notes that data is public and no tier is required, but does not explicitly specify when to use this tool versus alternatives like fahali_get_contagion_map or fahali_get_portfolio_risk. It implies usage for correlation analysis but lacks direct 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 bears full burden. It states the tool is public and returns specific fields, but does not mention mutation, authorization details, rate limits, or side effects. Adequate for a read-only tool but lacks depth.
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 concise sentences, front-loaded with the primary action, followed by specific output details. Every sentence adds value; no fluff.
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?
No output schema exists, so description must cover return values. It does so thoroughly (status, time windows, interpretation, context, inventory). For a no-parameter tool, this is nearly complete. Minor gap: no mention of pagination or result size limits.
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; schema coverage is 100%. Description adds value by detailing the return structure (per-engine fields, market context, unmapped alerts), which goes beyond the empty schema. Baseline 4 for 0 params is appropriate with additional 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?
Description clearly states it gets liveness report for all detection engines, enumerating returned fields (last fired timestamp, event counts, status, interpretation, market context, unmapped alert types). Verb 'get' + resource 'engine status' is specific and distinguishes from sibling tools like fahali_get_contagion_map or search_memories.
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 or when-not-to-use guidance. The note 'Public data — no tier required' implies ease of access but no comparison to alternatives or exclusions. Usage is implied from purpose but could be stronger.
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, the description fully discloses behavioral traits: it returns aggregated consensus signals, details the entry fields (engine list, severity, direction, timestamp, provenance), validates engine names against a canonical registry, and states it is public. No destructive side effects are implied. This is thorough.
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?
The description consists of two concise sentences: the first states the purpose and output, the second details the entry fields and validation. No unnecessary words, and key information is 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 no parameters and no output schema, the description adequately explains what the tool does and returns. It covers the consensus logic, field details, and access. It does not mention limits or pagination, but for a simple retrieval tool, this is sufficient.
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?
There are no parameters, and schema coverage is 100%, so the description does not need to add parameter information. Baseline 4 is appropriate, and the description adds context about the returned data structure, which is helpful.
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 clearly states the tool's purpose: 'Get highest-conviction multi-engine consensus signals.' It describes what is returned: symbols with 2+ engines agreeing, ranked by engine count and directional decisiveness. This distinguishes it from siblings like fahali_get_contagion_map which focus on different aspects.
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 mentions 'Public data — no tier required,' indicating accessibility, but does not provide guidance on when to use this tool versus alternatives like fahali_get_market_sentiment or fahali_get_engine_status. There is no 'when-not-to-use' or explicit recommendation.
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 are provided, but the description discloses the search mechanism (vector similarity or ILIKE fallback) and implies read-only behavior, providing good transparency.
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 no extraneous words; the first sentence captures the core purpose, making it efficient and 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?
The description explains functionality and parameters adequately but omits details about the return format, which would be helpful given no output schema.
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%, so the description adds minimal value beyond the schema—only clarifying that the search is semantic and matches keys and values.
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 explicitly states the tool performs semantic search across agent memories, using vector similarity or ILIKE fallback, which clearly differentiates it from the unrelated financial siblings.
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 mentions the Professional tier requirement, giving a prerequisite but no explicit guidance on when to use versus alternatives, which are absent.
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, the description carries the full burden. It explains the internal process (canonical verdict arbiter) and what the response includes (confidence, reasoning chain, etc.). It does not imply destructive behavior, and the read-only nature is evident.
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 front-loaded with the purpose, followed by relevant details. It is slightly verbose but well-structured, with each sentence adding value. Could be slightly more concise but effectively conveys needed 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 no output schema, the description explains the verdict fields (canonical, confidence, reasoning, horizon) and the enrichment option. It covers tier requirements and behavior for omitted symbols. It is fairly complete for a read 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%. The description adds value by clarifying that omitting symbols returns top signals and that includeContagion enriches with contagion risk, requiring a higher tier. This goes beyond the schema descriptions.
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 clearly states the tool gets a structured market verdict for symbols, specifying the resource and action. It distinguishes from siblings by detailing the canonical arbiter and included fields like confidence, reasoning chain, and forecast horizon.
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 mentions the tier requirement and that omitting symbols returns top signals, but it does not explicitly guide when to use this tool versus siblings like fahali_get_market_sentiment or fahali_get_highest_conviction_signals. No 'when-not' or alternative recommendations.
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, the description carries the full burden. It clearly states return fields (sentiment score, confidence, direction, source, news count) and that data is public. Does not mention rate limits, caching, or freshness, but covers essential behavioral aspects for a read-only 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 sentences, no redundancy, front-loads the main action and then enumerates return fields and extra context. Every word is informative.
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 adequately describes return values and key context (engines, public access). Slight omission: no mention of default limit value, but overall complete for a simple list 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 already covers 100% of parameters with descriptions. The description adds context by explaining the symbol filter's effect (aggregate vs specific) and the engines involved. However, it doesn't state the default limit value (20) which is in 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?
Clearly states 'Get market sentiment history from news and detection signals' with specific verb and resource. Mentions optional symbol filter and two engines (momentum, volume_anomaly), distinguishing it from sibling tools like fahali_get_market_snapshot or fahali_get_market_regime.
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?
Indicates optional symbol filter and public access, and identifies the specific engines covered, implying when to use for sentiment from these sources. However, no explicit guidance on when to choose this tool over other sentiment-related tools or what alternatives exist.
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 the description carries full burden. It explains expected behavior: accepts inline positions or symbols, returns risk breakdown (VaR95, drawdown, per-position scores, recommendations, contagion). No side effects mentioned but likely none.
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 concise sentences, front-loaded with purpose, then details. No redundant information. Perfectly structured.
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?
With no output schema, the description compensates by listing return fields. It covers inputs, outputs, use cases. For a tool with 2 parameters and no nested objects, it is complete.
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 descriptions for both parameters. The description repeats what's in the schema but adds no new meaning beyond that. Baseline of 3 is appropriate.
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 clearly states the verb 'Analyze risk' and the resource 'custom portfolio that you provide inline'. It distinguishes itself from get_portfolio_risk by noting no connected accounts needed. The purpose is unambiguous.
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 tool is 'Useful for what-if analysis or evaluating a portfolio before you connect accounts.' It contrasts with get_portfolio_risk which requires accounts, but does not list other alternative tools or give 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the composition from multiple signals, horizon specificity (6-72h), the meaning of roles and tiers, and the separation of detection confidence from outcome probability. No behavioral traits are hidden or contradicted.
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 lengthy but front-loaded with key output components. It could be slightly more concise, but the complexity of the tool justifies the detail. Every sentence adds value, explaining nuances.
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 lacking an output schema, the description thoroughly explains the return structure, including the distinction between detector and forecaster roles, stance interpretation, and access requirements (Professional tier). It is complete for a tool of this complexity.
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%, so both parameters are described in the schema. The description adds minimal extra meaning beyond what the schema provides (e.g., confirms symbol is required and include for extras). Baseline of 3 is appropriate.
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 clearly states the tool returns a probabilistic forecast for a symbol, listing components like crash/pump/neutral probabilities, expected return, uncertainty cone, driver contributions, and historical accuracy. This specific verb+resource distinguishes it from sibling tools like fahali_get_market_sentiment or fahali_get_highest_conviction_signals.
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?
The description provides important context on how to interpret outputs (e.g., detectionConfidence vs outcomeProbability, stance field) and warns that most Fahali agents are detectors, not trade-signal generators. While it doesn't explicitly list when to use alternatives, the guidance on reading results is clear and helpful.
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?
Given no annotations, the description fully covers behavioral traits: output ranges, risk levels, crash component capping at 50, and the nature (observation, not advice). This provides strong transparency for the agent.
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?
The description is concise (5 sentences) and efficiently front-loaded: first sentence states the core purpose, then details output, special behavior, and context. Every sentence adds unique value.
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?
With no output schema, the description covers return structure well but lacks specifics on component breakdown format. Still sufficient for a 0-param tool; could mention if data is real-time or historical.
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?
No parameters exist, so baseline is 4. The description correctly omits parameter details as they are not needed. No value added or missing.
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 clearly states the tool computes an institutional risk score from weighted detection engine signals. It lists specific output components (score 0-100, risk level, narrative, breakdown, detection count), making the purpose highly specific and distinguishable from sibling tools.
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 guidance on when to use vs alternatives like fahali_get_portfolio_risk or fahali_get_market_verdict. The note about 'public data — no tier required' implies broad access, but no when-not or alternative suggestions.
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 burden. It discloses the metrics returned, emphasizes the base-rate lift nuance, and states 'Public data — no tier required,' providing access transparency. Does not describe side effects (none expected for a read 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?
Three sentences, front-loaded with purpose, and every sentence adds value: tool function, return contents, usage warning, access note. No redundant or vague 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?
Despite no output schema or annotations, the description covers what the tool returns and how to use the results. Lacks details on output format (e.g., JSON structure), but for a simple data retrieval tool, this is adequate.
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?
Tool has zero parameters; schema coverage is 100% (trivially). Per guidelines, baseline score of 4 applies since description adds no parameter info but none is needed.
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 clearly states the tool retrieves a '4-axis track record scorecard' listing specific metrics (direction accuracy, magnitude precision, etc.), distinguishing it from sibling tools that cover different financial analyses.
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?
Includes explicit guidance: 'Do NOT cite raw percentages without the base rate lift,' instructing the agent on correct output usage. Lacks explicit when-to-use vs alternatives, but sibling context suggests it's for track record evaluation.
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, the description carries full burden. It details the output structure comprehensively, including nodes, flows, vortex metadata, etc. The 'Public data — no tier required' statement clarifies access. However, it does not explicitly confirm read-only behavior or mention potential rate limits or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose. The first sentence clearly states the tool function and output. The second lists details, which is informative but slightly verbose. Could be trimmed but overall efficient.
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?
Given zero parameters and no output schema, the description provides a complete picture. It enumerates all return components (nodes, flows, vortex metadata) and notes coverage scope and access tier. No missing critical info for a get-snapshot 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?
There are no parameters, so schema coverage is 100%. The description adds value by explaining that the tool returns a full snapshot of all 18 engines without filters, which goes beyond the empty schema. Baseline 4 is appropriate.
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 clearly states the tool retrieves a unified snapshot of all 18 detection engines, specifying concrete output elements (nodes, flows, vortex metadata). It distinguishes from siblings like fahali_get_market_sentiment by emphasizing comprehensive coverage and public access no tier required.
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?
The description implies use cases as a holistic overview, mentioning 'unified snapshot' and 'all 18 engines'. It provides a clear context but does not explicitly exclude scenarios or name alternatives. The 'no tier required' note adds practical guidance. Slight gap in explicit when-not.
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 fully covers behavioral context: it is a read-only observation ('Observation, not advice'), requires authentication, and discloses that results depend on detection-layer writes. It also describes the return behavior when 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, covering purpose, return values, conditions, and disclaimers in a few sentences. It is front-loaded with the main action and provides all necessary details without fluff.
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 the lack of an output schema, the description explains the return structure (regime type, volatility, trend, expected return) and when null responses occur. This compensates for the missing schema and provides sufficient context for a zero-parameter 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?
The tool has zero parameters and the input schema is empty, so no parameter documentation is needed. The baseline for 0 parameters is 4, and the description adds no parameter information because none exists.
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 clearly states the action ('Get detected market regime') and the resource ('HMM 4-regime engine'). It specifies the returned fields (regime type, volatility, trend, expected return) and distinguishes itself from sibling tools by noting it 'Covers the market_regime engine'.
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 explains data availability and returns empty/null when data is not persisted, but it does not explicitly compare this tool to sibling tools (e.g., fahali_get_market_sentiment) or state when to use it over alternatives. The guidance is implicit rather than explicit.
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?
No annotations are provided, so the description carries full burden. It proactively discloses that Fahali ingests no on-chain/venue order-flow feed, clarifies that field names like 'symbolsWithRecentDetections' and 'alertLean' are literal and refer to alert-based data, not institutional activity. It also states 'Public data — no tier required,' which is transparent about access requirements.
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 somewhat long but each sentence adds unique value: core purpose, negative clarification, list of outputs, field name explanation, and access note. It is front-loaded with the main purpose. Could be slightly more concise by removing the repetitive negation, but overall well-structured.
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?
With no parameters and no output schema, the description must fully explain the tool's behavior and return structure. It does so comprehensively, detailing all output fields and their meanings, correcting potential misinterpretations, and providing context about data source and accessibility. This leaves little ambiguity for an agent.
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?
There are zero parameters, and the schema coverage is 100% (empty schema). Baseline for 0 params is 4. The description does not need to add parameter information, and it appropriately focuses on the output and caveats. It adds value beyond the schema by clarifying what is returned.
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 clearly states the tool returns 'Recent DETECTION-ALERT activity' and explicitly distinguishes it from institutional or on-chain smart money flow. It lists specific outputs: symbols with recent alerts, detection count, bullish/bearish lean, most-alerted symbol, and sentiment. This specificity sets it apart from siblings like fahali_get_institutional_risk_score.
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?
The description tells users what the tool is NOT (institutional/on-chain), advises to read dataOrigin and disclaimer, and notes public access. However, it does not explicitly mention when to use this tool versus alternatives like fahali_get_whale_activity or fahali_get_dark_pool_activity, which might be relevant for institutional flow. The guidance on misconceptions is strong but could be more directive.
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, the description carries full burden. It fully discloses the detection strength formula (risk_weight × alert_confidence), calibration status (false), what the tool does NOT return (P(crash), time-to-crash, magnitude), and the engine's weak performance (realized lift ~0). This is highly transparent.
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 moderately concise; every sentence adds value. It front-loads the key caveat ('NOT a calibrated crash probability'). A slight reduction in length could improve conciseness, but it is well-structured.
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?
Given no parameters, no output schema, and the tool's complexity, the description is remarkably complete. It explains the signal's nature, what it ranks, what it does not provide, and its empirical performance. An agent can fully understand the tool's capabilities and limitations.
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?
There are zero parameters, so the baseline is 4. The description adds value by explaining what the output represents, despite no input schema. No additional parameter information is needed.
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 clearly states it provides per-symbol flash-crash 'precursor detection strength' and explicitly distinguishes it from a calibrated crash probability. The verb 'get' combined with 'detection strength' makes the purpose unambiguous. It also differentiates from sibling tools by focusing on precursor signals.
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?
The description explicitly tells when to use (to rank symbols with flashing precursor signals) and when not to use (not for calibrated probability, time-to-crash, or move magnitude). It even mentions that realized lift is ~0 and actionability is withheld, guiding the agent to avoid over-reliance. Also states 'Public data — no tier required', clarifying access.
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?
Discloses important behavioral details: detectionConfidence is RAW (not calibrated), can be null, and is never fabricated. No annotations are provided, so the description carries full burden and addresses it thoroughly.
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 detailed and well-structured, beginning with purpose and benefit, then clarifying key fields and alternatives. Every sentence adds value, though slightly verbose.
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?
Given zero parameters, no annotations, and no output schema, the description fully explains the tool's behavior, output structure, and related tools, making it complete for agent invocation.
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?
No parameters exist in the schema (0 params), so baseline is 4. The description does not need to add parameter info but explains the output structure, which adds value.
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 clearly states 'Get realtime detection feed clustered by (symbol, thesis)', which is a specific verb and resource. It distinguishes from sibling tools by explaining the clustering benefit and pointing to alternatives for reliability and arbitrated reads.
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?
Explicitly provides when-to-use and when-not-to-use: 'For judged reliability use fahali_get_track_record_scorecard; for the arbitrated read use fahali_get_market_verdict.' Also notes 'Public data — no tier required', giving clear 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, the description fully discloses the behavioral trait: the tool returns ABSTAIN status and does not fabricate data. It explains the abstention reason and return structure clearly.
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 a single, information-packed sentence. While it contains all necessary details, it could be slightly more concise. However, it is well-structured and front-loads the abstain policy.
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?
Given zero parameters, no output schema, and no annotations, the description fully explains the tool's behavior, return values, and abstention rationale. It is complete for a tool that does nothing.
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?
No parameters exist, so baseline is 4. The description adds value by explaining the abstain behavior and return structure, which is not apparent from 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?
The description clearly states the tool's purpose: to abstain from whale tracking due to lack of data, returning a specific status and empty activities. It also distinguishes itself from sibling tools by naming alternatives like fahali_get_market_verdict.
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?
Explicitly tells when the tool abstains and provides direct alternatives (fahali_get_market_verdict and fahali_get_realtime_alerts) for actual detections, offering clear usage guidance.
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:

[![fahali-mcp MCP server](https://glama.ai/mcp/servers/Future-Legends-Inc/fahali-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Future-Legends-Inc/fahali-mcp)

Score Badge

Copy to your README.md:

[![fahali-mcp MCP server](https://glama.ai/mcp/servers/Future-Legends-Inc/fahali-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Future-Legends-Inc/fahali-mcp)

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/Future-Legends-Inc/fahali-mcp'

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