echolon

by DolphinQuant

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.3
Disambiguation5/5
Each tool has a clearly distinct purpose: API introspection, parameter generation, documentation retrieval, catalog listing, scaffolding, and various validation checks. Overlap among validation tools is resolved by specific validation targets (integration, logging, protocol, parameters, etc.).
Naming Consistency4/5
Tools follow a mostly consistent verb_noun pattern (e.g., get_doc, list_indicators, validate_strategy). Minor deviations like 'indicator_info' instead of 'get_indicator_info' and 'suggest_similar' instead of 'get_suggestions' are tolerable.
Tool Count5/5
23 tools cover a comprehensive set of operations for a strategy framework: API description, parameter generation, documentation, catalog browsing, scaffolding, and multiple validation checks. The count is well-scoped for the domain.
Completeness4/5
The tool surface covers key development and validation workflows. Minor gaps exist (e.g., no tool for creating a new strategy directory or running backtests), but the core lifecycle of building and validating components is well-supported.
Average 3.9/5 across 23 of 23 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 188 commits in the last 12 weeks
- Last stable release on May 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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 are present, so the description must carry the burden of behavioral disclosure. It only mentions the return format but does not reveal side effects, authentication needs, or whether the operation is read-only.
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 extremely concise with one sentence and the return format, which is front-loaded. However, it may be too terse, missing important context that a more verbose description would provide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and only one parameter, the description should elaborate on parameter usage and tool behavior. It fails to explain what 'name' expects and lacks context about templates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% and the description adds no meaning to the 'name' parameter beyond its name. It does not clarify what the name refers to (e.g., template name) or provide any format hints.
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 loads a template's files and returns a specific structure. It uses a specific verb and resource, which distinguishes it from other tools that fetch single items like get_doc, but it does not explicitly differentiate from siblings.
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 alternatives like list_templates or get_doc. The description simply states what it does without offering context 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?
Discloses that it returns None if the pattern is unknown, but with no annotations, it lacks other behavioral details like side effects, permissions, or data access patterns.
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, no superfluous words. Every word is essential.
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?
For a simple tool with one parameter and an output schema, the description is minimally adequate but could explain what 'structured content' entails or provide example usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only implies the 'name' parameter identifies the pattern via the tool's purpose. With 0% schema description coverage, the description adds minimal new meaning beyond the parameter name.
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 it returns a pattern's structured content or None, which distinguishes it from sibling tools like get_doc or get_skill. However, it does not explicitly contrast with siblings, so it's not a 5.
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 on when to use this tool versus alternatives like list_patterns or get_doc. No when-not-to-use or contextual advice 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?
Without annotations, the description carries full burden but only mentions it is an AST check and returns findings. It does not disclose error handling, dependencies, or limitations, though the core behavior is adequately described.
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 relatively concise and front-loaded with the main purpose. However, the triple-quoted string formatting may obscure readability slightly.
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?
Considering no output schema, no annotations, and 0% schema coverage, the description is the sole source. It explains checks and return format but lacks parameter clarity, making it somewhat incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter (strategy_dir) with 0% description coverage, and the tool description does not explain its meaning or usage. The agent has no help understanding what value to provide.
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 is an AST-check for component logging, specifying it verifies required method calls with BaseModel and flags self.params.get() antipattern. It distinguishes from sibling tools by its specific focus on logging validation.
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 explicit guidance on when to use this tool versus other similar validation tools (e.g., validate_component_integration). The description does not provide context on prerequisites or 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 must fully disclose behavior. It states the return value but does not mention side effects, authorization needs, or that the operation is read-only (validation). This is insufficient for a tool with no annotation support.
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 concise, using a typical docstring structure. It front-loads the purpose. However, the Args block could be simplified to a single sentence, making it slightly more efficient.
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?
For a simple validation tool with one parameter and no output schema, the description covers purpose and return type adequately. However, it lacks context on what 'echolon contracts' are and what counts as a validation error, which may be needed given the rich set of sibling validation tools.
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 0% description coverage, but the description adds meaning by stating 'Absolute path to the strategy directory'. This compensates well for the schema gap, though it could mention path format (e.g., must exist).
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 verb 'validate' and the resource 'strategy directory against echolon contracts'. It distinguishes the tool from siblings like 'validate_strategy_full' by implication (basic vs full), but does not explicitly name the difference.
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?
There is no explicit guidance on when to use this tool versus alternatives such as 'validate_strategy_full' or other component validators. The context of when not to use it is missing.
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?
Discloses that it returns None for unknown indicators and describes the return structure in detail. Since no annotations are provided, this is important behavioral info. No mention of side effects, but it is an indepotent query.
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 concise with a clear main sentence. It includes a list of keys but the mention of runtime column names is somewhat tangential but not detrimental.
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 simple query tool with one parameter, the description covers the essential behavior and return format. The output schema exists and the description aligns, making it complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'name' is described only implicitly as 'for one indicator'. The schema provides no description, and the tool description adds minimal semantic context beyond being an identifier.
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 returns structured info for a single indicator, or None if unknown, and lists the keys of the returned structure. However, it does not explicitly differentiate from sibling tools like 'list_indicators' or 'indicator_params', though the function is distinct.
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 on when to use this tool versus alternatives. The description does not provide context about prerequisites or appropriate use cases.
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. The description merely states the action without disclosing behavioral traits such as whether the result is paginated, sorted, or if there are any limitations. With zero annotations, the description should provide more 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?
A single, concise sentence that conveys the essential purpose. No unnecessary words, and it is front-loaded with the key information.
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 simplicity (0 parameters, with an output schema), the description is minimally complete but lacks context such as what 'canonical' means or whether the list is ordered. It does not explain the output format, relying on the output schema. Slightly more detail would improve usability.
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. According to guidelines, 0 parameters yields a baseline of 4. The description does not need to add parameter information as there are none, so it adequately fulfills this dimension.
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 all canonical pattern names. It specifies the verb 'return' and the resource 'canonical pattern names', distinguishing it from sibling tools like 'get_pattern' which returns a single pattern's details.
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 on when to use this tool versus alternatives (e.g., get_pattern for details, or other list tools). The description lacks context for an agent to choose correctly among sibling 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?
With no annotations, the description carries the full burden of transparency. It explains the three error conditions, the focus on import success and structural checks, and notes that argument names are ignored. It also states the return format. However, it omits side effects (likely none) and any authentication or performance implications.
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 well-structured with bullet points and clear error code references. It conveys necessary information without extraneous text. However, it could be slightly more concise by combining some lines, but overall it's effective.
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 (1 parameter, no output schema), the description is relatively complete. It explains the validated aspects, error conditions, and return structure. Missing context includes an example or clarification on the format of 'findings' items, but the provided detail is sufficient for basic usage.
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 only one parameter (strategy_dir) with no description. The tool description implies that strategy_dir is a directory for component modules by mentioning 'Import each component module via StrategyLoader', but does not explicitly define it or specify its format. This adds some context but could be clearer for an AI agent.
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: importing component modules via StrategyLoader and checking method arity and DEFAULT_PARAMS shape. It lists specific error codes (STR-002, PRM-002, VAL-005), making the intent precise and actionable. This distinguishes it from sibling validators like validate_component_logging.
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 does not provide any guidance on when to use this tool versus alternatives. It lacks explicit context for when to run integration checks or how it differs from other validation tools. No when-not-to-use or prerequisite information is given.
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 bears full disclosure burden. It explains that missing annotations are not flagged, missing files are skipped, and specifies the return format {"any_errors": bool, "findings": [...]}. It does not mention side effects, but as a read-only validation tool, the description is sufficiently 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 structured with bullet points and a return definition. It front-loads the main purpose and uses compact language. However, it is somewhat verbose for a single-parameter tool, but every sentence adds value. It is generally concise.
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?
For a validator with one parameter and no output schema, the description covers the behavior and return format well. However, the lack of parameter explanation and absence of prerequisites or error conditions (though it implies handling) leave gaps. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, strategy_dir, lacks any explanation in the description or schema description. Since schema description coverage is 0%, the description should compensate but fails to clarify what this parameter represents, its expected format, or constraints. This is a significant gap.
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 identifies the tool's purpose: an AST-check for required component classes having required methods with matching return-type annotations. It specifies concrete rules (STR-003, VAL-006) and differentiates from siblings like validate_component_integration by focusing on method signatures.
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 when to use: to validate method signatures against expected annotations and existence of required methods. It provides context on what is not flagged (missing annotations as stylistic choice, missing files silently skipped), but does not explicitly state when to use an alternative or when not to use. Nonetheless, the guidance is clear for a specialized validator.
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 description reveals that invalid JSON results in a structured error instead of an exception, which is a key behavioral trait. However, it does not confirm read-only status or other side effects, and annotations are absent.
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 relatively concise with a clear structure (Args/Returns), though the docstring format uses some extra lines. Every piece of information is relevant.
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 specifies the return format and error handling. It could mention catalog dependency or constraints, but is sufficient for a simple validation 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 description provides a concrete example and explains the expected JSON format for the single parameter payload_json, compensating for the schema's lack of description.
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 validates a specific payload format (flat-dict strategy_indicator_list.json) against a catalog. It distinguishes from sibling validation tools by specifying the exact resource name.
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 on when to use this tool versus alternatives like validate_component_integration or validate_strategy. No prerequisites or exclusion criteria mentioned.
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, so the description carries the full burden of behavioral disclosure. It states that the tool is an AST check (read-only analysis), returns a dictionary with 'any_errors' and 'findings', and that PRM-003 findings include a severity field ('warning'). It also lists the allowlist, which reduces false positives. The description is transparent about the nature of the tool and its output format, though it does not explicitly confirm no side effects beyond the return value.
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 and well-structured. It opens with a clear statement of purpose, then provides important context about FP risk, interpretation hints, and the allowlist. It is front-loaded and each sentence adds value. Minor redundancy exists (e.g., repeated reference to PRM-003 and PRM-004), but overall it is efficient for its content 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?
Given the single parameter and lack of output schema, the description covers the core logic and return format well. However, it leaves the parameter 'strategy_dir' completely undocumented, and terms like 'B1 validators' and 'component files' are unexplained, relying on domain knowledge. For a complete newcomer, the parameter gap is significant, making the tool less immediately usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'strategy_dir' is not mentioned at all in the description. With 0% schema description coverage, the description must compensate by explaining the parameter's meaning and usage, but it fails to do so. The description mentions '4 component files' but does not clarify that strategy_dir points to a directory containing those files. This leaves the parameter poorly understood.
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 performs an AST check for two specific types of parameter access issues: hardcoded threshold literals (PRM-003) and defensive self.params.get() calls (PRM-004). It specifies the scope (4 component files) and distinguishes itself from sibling validators by naming the exact rules it checks. The verb 'validate' with resource 'parameter access' is precise.
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 clear usage context: it is the highest FP-risk validator among B1 validators, advises that PRM-003 findings should be treated as non-blocking while tuning the allowlist, and states that PRM-004 findings are always bugs. This helps callers interpret results correctly. However, it does not explicitly state when to use this tool versus alternative validators or 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?
With no annotations, the description provides behavioral context: the filter's effect (True/False/Omit) and examples (RSI, ATR, OBV). This is sufficient for a read-only list operation, though it omits details like sorting 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and concise, though the docstring-style Args format adds minor verbosity. Every sentence serves a purpose, and the length is appropriate for the 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?
Given the simple input (one optional parameter) and presence of an output schema, the description covers the essential context. It explains the parameter thoroughly, leaving output details to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains the single parameter 'has_lookback' with concrete semantics for each value (True, False, Omit) and examples. Schema coverage is 0%, so the description compensates completely.
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 returns indicator names from the catalog with optional filtering. The verb 'return' and resource 'indicator names' are specific, but it does not explicitly differentiate from sibling tools like indicator_info or indicator_params.
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 on when to use this tool versus alternatives. With many sibling tools (indicator_info, indicator_params, etc.), the description should indicate what distinguishes listing names from other operations.
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 full burden. It indicates a read-only operation (returning names) but omits details like what 'shipped' means, authentication needs, or rate limits. Adequate but minimal.
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, front-loaded with purpose, no unnecessary words. Every word 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 parameterless tool with an output schema, the description is complete enough. It covers the core purpose, but could mention any constraints or expected response shape (handled by output schema).
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 description coverage is 100%. The description adds no redundancy, and baseline score of 4 is appropriate given zero parameters.
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 all shipped strategy template names. It uses a specific verb (return) and resource (template names), and distinguishes itself from sibling tools like list_indicators and list_patterns.
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 provides no guidance on when to use this tool vs alternatives, nor any when-not-to-use or prerequisite information. It simply states the function without 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?
The description reveals the algorithm (difflib + substring) but lacks behavioral details like case sensitivity, matching threshold, behavior when no matches found, or how the ordering works. With no annotations, it carries the full disclosure burden but only partially meets it.
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?
A single sentence that is front-loaded with the core purpose and method. No redundant words, and it efficiently communicates the tool's function.
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 presence of an output schema (known from context), the description does not need to detail return values. It covers the essential purpose and parameters for a simple suggestion tool, though it could mention edge cases or error handling for 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?
Despite 0% schema description coverage, the description explains both parameters: `name` as the search term and `limit` as the maximum number of results. It adds context by stating 'up to' for limit, which the schema does not convey, effectively compensating for the schema gap.
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 returns similar catalog names based on string similarity, specifying the verb 'return', the resource 'catalog names', and the method 'difflib + substring'. It distinguishes itself from sibling tools like list_indicators or describe_component_api by its unique suggestion functionality.
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 alternatives such as list_catalogs or search functions. There is no mention of prerequisites, when not to use it, or how it fits into a workflow.
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 discloses the dual data sources (in-memory registry and markdown files) and the parser-resilience fallback behavior. However, it does not mention authentication requirements, rate limits, or other potential behavioral traits.
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 yet informative, with clear structure (overview, internal details, fallback). It front-loads the purpose and uses bullet points, making it easy to scan. Every sentence adds value.
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 the simple tool (1 parameter, no output schema, no annotations), the description is remarkably complete. It explains the two-part data source, the fields returned (what, why, fix, etc.), and the fallback mechanism. No major gaps remain.
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 only parameter 'code' has 0% schema description coverage. The description adds meaning by providing examples ('VAL-001', 'IND-003') and explaining it represents an error code. This compensates for the schema's lack of detail, but no full pattern or constraints are given.
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 'Fetch the structured error documentation for a given error code', specifying both the action (fetch) and the resource (error documentation). It implicitly distinguishes from siblings like get_doc or get_pattern by focusing specifically on error codes.
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 alternatives (e.g., get_doc for general documentation). There is no mention of prerequisites, contexts, or 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?
No annotations provided, so description carries full burden. Describes return format, documents both body and body_no_frontmatter, and mentions possible None return. Lacks details on side effects or performance, but acceptable 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?
Three sentences, no fluff. Front-loaded with action and return value. Each sentence adds value.
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?
Output schema exists (not detailed here), but description explains return keys sufficiently. For a simple lookup tool, all needed context is provided.
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 0%, so description must compensate. Only parameter is 'name' (string). Description does not elaborate on it beyond schema, but its role is self-evident. Adequate but not extra 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?
States clearly it returns a skill's body or None. Specifies return dictionary with keys. Distinguishes from sibling tools like get_doc and get_pattern.
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?
Does not explicitly state when to use vs alternatives. Usage is implied by name and description, but no exclusion or context for when not to use.
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 carries the burden. It discloses the None return for unknown indicators, the simplified access pattern, and the structure of each entry (name, default, type). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the purpose and adding a helpful usage note. Every sentence adds value without 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?
For a simple one-parameter tool, the description covers the return format, the None case, and the structured output (name, default, type). An output schema exists, but the description still explains the return structure, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should add meaning to the 'name' parameter. It does not elaborate beyond the schema, failing to clarify that 'name' should be an indicator name. This gap is significant for a single-parameter tool.
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 tunable parameters for an indicator, or None if unknown. It distinguishes from sibling indicator_info by clarifying it is a convenience accessor that skips the wrapper dict.
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 when only parameters are needed by referencing indicator_info and noting it skips the wrapper. However, it does not explicitly state when to use this tool versus alternatives or include exclusions.
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 clearly states the tool never raises exceptions and surfaces failures as findings with error codes, which is transparent about error handling. However, other behavioral aspects (e.g., performance, side effects) are not covered.
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 well-structured with bullet points and code formatting, front-loading the purpose. It is slightly lengthy due to detailed parameter docs, but each sentence adds value. No wasted 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?
Given no output schema, the description explains the return format. With 4 parameters and 2 required, all are documented. The tool is simple (validation-only), and the description covers behavior, parameters, and returns adequately for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains each parameter with examples, defaults, and expected formats (e.g., artifact_path: absolute path; required_json_keys defaults). This adds significant meaning beyond the bare 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 explicitly states the tool validates post-run debug artifacts and lists three deterministic checks with codes (STR-001, VAL-003, BT-010), making the purpose highly specific and distinct from 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 implies use for post-run validation but provides no guidance on when to use this tool versus alternatives (e.g., other validation tools). No exclusions or conditions are mentioned.
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 the burden. It discloses that it runs validators and returns merged findings with output format. No side effects or authorizations mentioned, but for a validation tool, this is adequate.
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 well-structured with Args and Returns, and lists validators in a bullet-like format. It is slightly verbose but every sentence adds value. Efficient for the information conveyed.
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 a single parameter and no output schema, the description provides detailed return format and explains the overall behavior. It is sufficient for an agent to invoke correctly, though it omits potential error conditions or performance notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides an Args section explaining the 'strategy_dir' parameter as an absolute path, adding significant meaning beyond the schema's title. With 0% schema coverage, this fully compensates.
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 that the tool runs every shipped validator and returns merged findings, listing the specific validators composed. This distinguishes it from the individual validators listed as 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?
The description implies use for a complete validation report in one call, but does not explicitly state when to avoid or provide alternatives. Sibling tools are individual validators, so context is clear but not explicit.
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?
Describes deterministic code generation steps, auto-clamping, and error handling (success=False vs raising). No annotations provided, so description compensates well.
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?
Well-structured with clear front-loaded purpose. Each sentence adds value, but could be slightly more concise without losing clarity.
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?
Covers inputs, processing, outputs, error handling, and return format. Despite no output schema or annotations, description provides complete context for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds thorough semantics: absolute paths for params_file_path and output_path, frequency with caps and default. Fully compensates for missing 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?
Clearly states the tool generates strategy_params.py from params_to_optimize.json with specific verb and resource. Differentiates from sibling tools that are mainly descriptive or validation-focused.
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 context for when to use (code generation from JSON) and explains frequency-dependent caps. However, no explicit alternatives or 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?
Despite no annotations, the description thoroughly explains that the result is produced via inspect.signature() on actual classes, ensuring no drift. It details the return shape and the meaning of each section, providing full behavioral 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?
The description is well-structured with a clear purpose, usage instruction, and detailed return shape. It uses code blocks and bullet points, though some sentences are verbose, earning a 4.
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 or output schema, the description provides all necessary context: what the tool does, how it works, the return format, and interpretation tips, making it 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?
The input schema has no parameters, so schema coverage is 100%. The description adds value by explaining the return value; no parameter details are 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 returns the live BaseComponent + IMarketData API surface, using specific verbs and resource names. It distinguishes itself from sibling tools like get_doc and list_skills by focusing on the component API surface.
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 explicitly says 'Use this BEFORE writing any component code,' providing clear usage context. However, it does not mention when not to use it or suggest alternatives among sibling 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?
With no annotations provided, the description fully explains the behavior: it returns a list of skills with name and description extracted from SKILL.md files under a specific path. It describes the source of the description (YAML frontmatter). However, it does not mention potential side effects (none expected), performance characteristics, or error handling (e.g., empty list). Overall, it covers the essential behavioral aspects for a read-only list 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?
The description is compact with three sentences: one declaring the output, one explaining the source, and one giving usage context. It front-loads the key information and every sentence adds value. No wasted words or redundant clarifications.
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 an output schema, the description covers the return format and domain context (the file path). It mentions the tool's role as a directory before get_skill, which completes the picture. However, it omits handling edge cases (e.g., no skills found) and does not explicitly state that no authorization is needed. Still, for a simple listing tool, it is reasonably 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?
The input schema has no parameters, so the description does not need to add parameter information. Schema description coverage is 100% (0 parameters). The baseline for zero parameters is 4, and the description meets that without adding extraneous details.
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 'return', the resource 'all in-package skills', and specifies the output format as a list of name-description pairs. It explicitly distinguishes from the sibling tool 'get_skill' by stating its role as a directory before calling get_skill. The purpose is unambiguous and well-defined.
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 provides explicit usage guidance: 'Use this as a directory of what doctrine is available before calling get_skill(name) for the body.' This tells the agent when to use this tool (before get_skill) and when not to (if the full skill body is needed, use get_skill). It effectively differentiates from the sibling tool, offering clear decision-making context.
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 must disclose behavior. It explains file writing, overwrite control via force, stub nature (no trading logic), and return schema. Does not mention permissions but this is acceptable for a file-writing 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?
Description is well-organized with clear sections for purpose, args, and returns. Uses concise language without redundancy. Every sentence adds value.
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, description provides full return schema. All parameters and behavior (including error cases) are covered. Complete for a file generation tool with the given context signals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description fully explains each parameter: kind with allowed values, strategy_dir as absolute path, force overwrite behavior. Also details return schema. Provides meaning beyond raw 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?
Description clearly states it writes a scaffold stub for strategy components with class name, method signature, and return schema. It is distinct from sibling tools which are validation and listing utilities.
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?
States that coding agents refine the stub into real pathways, indicating its use as a template generator. No explicit when-not-to-use guidance, but context is clear given sibling tools are not generation-focused.
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 discloses behavior: returns path and body on success, error object on failure with specific error types (path_outside_native). It also explains that absolute paths and escape attempts are refused, providing complete transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections (Args, Returns) and front-loaded purpose. Though slightly verbose with the docstring format, every sentence adds value and the structure aids readability.
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 a single parameter and simple read operation, the description fully explains purpose, usage context, input format, error handling, and return values. An output schema exists, and the description complements it effectively with behavioral details, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed semantics for the 'path' parameter: relative path under 'echolon/native/', three concrete examples, and behavior on invalid paths. This adds essential meaning beyond the schema's simple string type.
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 reads any markdown file under 'echolon/native/' and returns its body. It distinguishes itself from sibling tools by naming them as dedicated alternatives (get_pattern, get_skill, get_error_doc, load_template), making purpose 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 identifies as generic fallback for content not covered by dedicated tools, with examples like skill-cross-reference resolution and supplementary files. While it doesn't explicitly say 'do not use when dedicated tools exist', the mention of specific siblings provides clear guidance on when to use 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:

[![echolon MCP server](https://glama.ai/mcp/servers/DolphinQuant/echolon/badges/card.svg)](https://glama.ai/mcp/servers/DolphinQuant/echolon)

Score Badge

Copy to your README.md:

[![echolon MCP server](https://glama.ai/mcp/servers/DolphinQuant/echolon/badges/score.svg)](https://glama.ai/mcp/servers/DolphinQuant/echolon)

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/DolphinQuant/echolon'

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