Anomaly detection API powered by physics simulation. Scan any data for outliers.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 19 of 19 tools scored. Lowest: 3.1/5.
Each tool has a clear, distinct purpose. While tools like waveguard_scan and waveguard_scan_timeseries both detect anomalies, their descriptions clearly differentiate structured data from time-series data. Similarly, token risk, volume check, and price manipulation tools address separate aspects of token analysis, avoiding overlap.
All tools follow the consistent pattern 'waveguard_<descriptive_name>' in snake_case. The names are descriptive and predictable, making it easy to infer functionality from the name alone. No mixed conventions or vague names are present.
19 tools is on the higher side but still appropriate given the broad domain of crypto analytics, anomaly detection, and market data. Each tool serves a specific purpose, and the count is justified by the comprehensive feature set. However, a few tools could potentially be merged without loss of clarity.
The tool set covers a wide range of functionalities: health check, market data fetching, fingerprinting, similarity comparison, anomaly detection (structured and time-series), risk assessment (token, price manipulation, volume, wallet), counterfactuals, and interaction matrices. Some minor gaps exist, such as missing data export or visualization tools, but core workflows are well-supported.
waveguard_action_surfaceBScore candidate actions and extract robust action zones.
| Name | Required | Description | Default |
|---|---|---|---|
| training | Yes | 2+ baseline normal samples used to define the reference profile. | |
| field_level | No | 0 = real scalar field, 1 = complex field. | |
| sensitivity | No | Anomaly sensitivity multiplier (default: 1.0). | |
| action_tests | Yes | 1+ candidate actions/scenarios to score against baseline. | |
| encoder_type | No | Optional encoder override. Omit to auto-detect. | |
| action_labels | No | Optional labels for each action variant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description 'score... and extract' does not contradict these and adds no additional behavioral traits such as dependencies, side effects, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple tool, though it could include a bit more structure without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description is too sparse. It does not explain what 'robust action zones' are, what the output format looks like, or how the parameters interact. The annotations help with safety but not with functional completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 6 parameters described adequately. The tool description adds no extra meaning about parameters beyond what the schema provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Score candidate actions and extract robust action zones.' It uses a specific verb and resource, but 'robust action zones' is jargon not explained, slightly reducing clarity. It does not explicitly distinguish from sibling tools, but the purpose is focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools (e.g., waveguard_compare, waveguard_counterfactual). There are no context cues, exclusions, or alternatives mentioned, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_cascade_riskBEstimate shock propagation and resilience from adjacency-linked entities.
| Name | Required | Description | Default |
|---|---|---|---|
| entities | Yes | 2+ entities/nodes participating in the cascade graph. | |
| field_level | No | Field representation level. Default 1 for graph interaction dynamics. | |
| sensitivity | No | Anomaly sensitivity multiplier (default: 1.0). | |
| encoder_type | No | Optional encoder override. Omit to auto-detect. | |
| shock_indices | Yes | Indices of initially shocked entities within the entities array. | |
| shock_strength | No | Initial perturbation magnitude injected at shock indices. | |
| adjacency_matrix | Yes | N×N weighted adjacency matrix describing link strengths between entities. | |
| training_context | Yes | 2+ baseline context samples used for normalization. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds minimal behavioral context beyond the stated purpose, not contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, delivering the core purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description does not explain what the tool returns, such as resilience metrics or shock propagation outputs. For a tool with 8 parameters and no output documentation, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The tool description does not add additional semantic meaning or context for parameter usage beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Estimate' and the specific resource 'shock propagation and resilience from adjacency-linked entities', making the tool's purpose distinct from siblings like waveguard_instability or waveguard_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as conditions that favor cascade risk estimation over other analytical tools in the family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_compareACompare two data items for structural similarity using physics-based fingerprints. Returns cosine similarity (0–1) and Euclidean distance. Use for duplicate detection, behavioral matching, drift analysis, or checking if two tokens/wallets/contracts are structurally similar.
Cosine similarity > 0.95 = very similar. < 0.80 = structurally different.
| Name | Required | Description | Default |
|---|---|---|---|
| data_a | Yes | First data item to compare. | |
| data_b | Yes | Second data item to compare (same type as data_a). | |
| encoder_type | No | Data encoder. Omit to auto-detect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds value by explaining the output (cosine similarity and Euclidean distance) and providing interpretation thresholds, which are not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three well-organized sentences: function overview, use cases, and output interpretation. No unnecessary information, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a comparison tool with good annotations and full schema coverage, the description adequately covers purpose, usage, and output interpretation. It is complete for an AI agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description does not add significant new meaning beyond the schema; it mentions comparing 'two data items' but does not elaborate on parameter details or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares two data items for structural similarity using physics-based fingerprints, listing specific use cases. The verb 'compare' and resource 'data items' are specific, and the tool is well-differentiated from siblings through its unique functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example use cases (duplicate detection, behavioral matching, drift analysis) but does not explicitly state when not to use the tool or mention alternative tools like waveguard_fingerprint. Guidance is implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_counterfactualBRun baseline plus counterfactual variants and measure verdict/score sensitivity.
| Name | Required | Description | Default |
|---|---|---|---|
| training | Yes | 2+ baseline normal samples used to build the reference profile. | |
| base_test | Yes | Baseline candidate sample to evaluate before counterfactual perturbations. | |
| field_level | No | 0 = real scalar field (faster), 1 = complex field (richer phase dynamics). | |
| sensitivity | No | Anomaly sensitivity multiplier (default: 1.0). Higher values flag more aggressively. | |
| encoder_type | No | Optional encoder override. Omit to auto-detect from input structure. | |
| counterfactual_tests | Yes | 1+ perturbed variants of base_test for sensitivity analysis. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds that it measures sensitivity but doesn't disclose further behavioral traits like auth needs or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extraneous content, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no explanation of return values or interpretation, the description is incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description doesn't need to add much. It doesn't provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs baseline plus counterfactual variants and measures sensitivity, which distinguishes it from sibling tools like waveguard_scan or waveguard_compare.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, when not to use it, or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_fingerprintAGet a physics embedding of any data item (52-dim at Level 0, 62-dim at Level 1 with phase statistics). The fingerprint captures structural properties via wave-equation dynamics — useful for similarity search, clustering, baseline comparison, and drift detection. Works on JSON objects, token metrics, wallet activity, trading data, or any structured data.
Returns a deterministic vector with labeled dimensions (chi statistics, energy distribution, gradient patterns, and phase coherence at Level 1).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Any data item to fingerprint: JSON object, numeric array, string, or structured record. | |
| field_level | No | 0 = real scalar 52-dim (default), 1 = complex field 62-dim. | |
| encoder_type | No | Data encoder. Omit to auto-detect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context about the deterministic nature and internal components (chi statistics, energy distribution, gradient patterns, phase coherence), going beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs front-load the core purpose and key details. Every sentence contributes value, but some redundancy exists (e.g., listing data types twice). Could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool without an output schema, the description adequately explains the return format (labeled vector with dimension details) and works across diverse inputs. Use cases and data variety are covered, making it complete for most agent scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). The description adds meaning by explaining the difference between field_level values (0 vs 1) and encoder_type options (auto-detect), though the schema already includes these details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it produces a physics embedding (fingerprint) of any data item, with specific dimensionality at different levels. Use cases (similarity search, clustering, drift detection) are explicitly mentioned, distinguishing it from sibling tools that focus on action surfaces, risk, comparisons, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes broad applicability to structured data but lacks explicit guidance on when to use versus alternatives like waveguard_compare or waveguard_scan. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_healthACheck WaveGuard API health, GPU availability, version, and engine status. No authentication required. Returns status, version, and GPU info.
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | Return detailed health info including memory and uptime (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds context beyond annotations: no auth needed, return values (status, version, GPU info). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with the core purpose and key usage detail. Every word adds value; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check tool with one optional parameter and no output schema, the description fully covers purpose, key details, and return information. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single boolean parameter 'verbose.' The description does not add meaning beyond the schema's default and description, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact resource and actions: 'Check WaveGuard API health, GPU availability, version, and engine status.' It clearly distinguishes from sibling tools, which are domain-specific analyses (e.g., cascade risk, fingerprint).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'No authentication required,' providing a clear usage condition. It implies this is a lightweight health check, but could more explicitly state when to use it versus alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_instabilityBEstimate instability under controlled perturb-and-resolve trials.
| Name | Required | Description | Default |
|---|---|---|---|
| test | Yes | 1+ candidate samples to stress-test with perturbation trials. | |
| trials | No | Number of perturbation trials per sample. | |
| training | Yes | 2+ baseline normal samples for reference dynamics. | |
| field_level | No | 0 = real scalar field, 1 = complex field. | |
| sensitivity | No | Anomaly sensitivity multiplier (default: 1.0). | |
| encoder_type | No | Optional encoder override. Omit to auto-detect. | |
| perturbation_strength | No | Relative perturbation amplitude applied during instability assay. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, non-destructive behavior. The description adds 'controlled perturb-and-resolve trials,' which hints at the process but does not expand on side effects, output nature, or state implications. With annotations covering safety, the description provides marginal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (8 words) that front-loads the core purpose. It is efficient with no redundant language, but could benefit from a brief structual note (e.g., returning scores) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the presence of 7 parameters (with only 2 required), the description does not explain return values, expected output format, or how the results integrate with other waveguard tools. It is too short to be fully informative for a moderately complex tool with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a clear description (e.g., test: '1+ candidate samples to stress-test with perturbation trials'). The tool description adds no additional meaning beyond the schema; thus, it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates instability under controlled perturb-and-resolve trials, using a specific verb and resource. This distinguishes it from sibling tools like waveguard_health or waveguard_scan. However, it could be more explicit about what 'instability' means in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like waveguard_cascade_risk or waveguard_phase_coherence. The description lacks when-to-use, when-not-to-use, or prerequisite information, leaving the agent to infer context from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_interaction_matrixACompute pairwise interaction matrix and cluster decomposition for entities.
| Name | Required | Description | Default |
|---|---|---|---|
| entities | Yes | 2+ entities to evaluate for pairwise interaction effects. | |
| field_level | No | Field representation level. Default 1 for interaction/phase features. | |
| sensitivity | No | Anomaly sensitivity multiplier (default: 1.0). | |
| encoder_type | No | Optional encoder override. Omit to auto-detect. | |
| training_context | Yes | 2+ baseline context samples used for normalization. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description ('Compute') is consistent with these, but it adds no additional behavioral context beyond what annotations provide, such as output details or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no extraneous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only the description, the tool is adequately defined for its purpose. However, more detail on the output (e.g., matrix structure, clustering method) would improve completeness. The annotations provide safety context, so the description carries a moderate burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters. The description adds only the high-level context of computing an interaction matrix, but does not elaborate on parameter usage or semantics beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compute pairwise interaction matrix and cluster decomposition for entities.' This is specific about the action (compute) and the resource (interaction matrix, cluster decomposition), and it distinguishes from sibling tools like waveguard_compare or waveguard_cascade_risk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The usage is only implied by the tool name and description, but explicit guidelines are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_market_dataAFetch live crypto market data from CoinGecko and DexScreener. No external data needed — WaveGuard pulls it for you.
Use 'coin_id' for CoinGecko (e.g. 'bitcoin', 'ethereum', 'solana'). Use 'contract_address' for DexScreener (any chain). Use 'search' to find token IDs by name/symbol.
Returns: price, volume, market cap, liquidity, price history, OHLC candles — ready to feed into waveguard_token_risk, waveguard_volume_check, or waveguard_price_manipulation.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days of history (default: 90 for price_history, 30 for ohlc). | |
| count | No | Number of results for top_coins (default: 25). | |
| query | No | Search query. Required for search, dex_search. | |
| action | Yes | What data to fetch: - token_data: full metrics for a CoinGecko coin - price_history: daily prices (for price_manipulation) - ohlc: OHLC candles (for volume_check) - top_coins: top N by market cap (training baseline) - search: find CoinGecko coin IDs - dex_token: DEX data by contract address - dex_search: search DEX pairs | |
| coin_id | No | CoinGecko coin ID (e.g. 'bitcoin', 'ethereum'). Required for token_data, price_history, ohlc. | |
| contract_address | No | Token contract address (any chain). Required for dex_token. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds that no external data is needed and identifies data sources. It provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (under 100 words), front-loaded with purpose, then parameter guidance, then return values. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, 1 required, no output schema), the description covers purpose, parameter usage, return fields, and even suggests downstream tools, making it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by mapping actions to parameters (e.g., 'coin_id' for CoinGecko) and providing examples, going beyond the schema's bare descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches live crypto market data from CoinGecko and DexScreener, with a specific verb and resource. It distinguishes from sibling tools which are analysis-focused, not data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given for when to use coin_id, contract_address, and search parameters. While it doesn't state when not to use this tool, the context is clear as siblings are for analysis, not data fetching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_mechanism_probeBRun targeted interventions and rank effect sizes.
| Name | Required | Description | Default |
|---|---|---|---|
| training | Yes | 2+ baseline normal samples used to construct the reference profile. | |
| base_test | Yes | Baseline candidate sample before interventions. | |
| field_level | No | 0 = real scalar field, 1 = complex field. | |
| sensitivity | No | Anomaly sensitivity multiplier (default: 1.0). | |
| encoder_type | No | Optional encoder override. Omit to auto-detect. | |
| intervention_tests | Yes | 1+ intervention variants used to estimate effect sizes. | |
| intervention_labels | No | Optional labels for intervention variants (same order as intervention_tests). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, non-destructive operation. The description 'Run targeted interventions' does not contradict these, but adds no new behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, achieving conciseness. However, it could benefit from brevity without sacrificing clarity; front-loading the core action is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and a complex domain (mechanism probing, effect sizes), the description is too brief. It fails to explain what 'rank effect sizes' means, the return format, or how to interpret results, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions (e.g., '2+ baseline normal samples used to construct the reference profile'). The tool description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run targeted interventions and rank effect sizes' clearly indicates the tool performs interventions and ranks effects, distinguishing it from sibling tools like 'waveguard_scan' or 'waveguard_health' which lack this focus. However, it could be more specific about what 'targeted interventions' entail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like 'waveguard_counterfactual' or 'waveguard_interaction_matrix'. The description lacks when-to-use, when-not-to-use, or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_multi_horizon_outlookACompute horizon-specific anomaly outlook and consistency across windows.
| Name | Required | Description | Default |
|---|---|---|---|
| horizons | Yes | List of horizon lengths (in sequence steps) to evaluate. | |
| sequence | Yes | Ordered sample sequence used for multi-horizon outlook analysis. | |
| training | Yes | 2+ baseline normal samples used to establish reference behavior. | |
| field_level | No | 0 = real scalar field, 1 = complex field. | |
| sensitivity | No | Anomaly sensitivity multiplier (default: 1.0). | |
| encoder_type | No | Optional encoder override. Omit to auto-detect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds that it computes outlook and consistency, providing meaningful behavioral context beyond the annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with front-loaded verb, no redundant words. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a compute tool with no output schema, the description lacks information about return format or how to interpret results. However, schema coverage and annotations are strong. Adequate but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning to parameters beyond the schema; it only summarizes the overall purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Compute' and identifies the resource as 'horizon-specific anomaly outlook and consistency across windows', clearly distinguishing this tool from siblings like waveguard_scan or waveguard_health that handle different analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., waveguard_scan for single-window analysis) or when not to use it. The description implies multi-horizon analysis but lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_phase_coherenceAMeasure coherence/entropy and collapse-risk indicators for candidate data.
| Name | Required | Description | Default |
|---|---|---|---|
| test | Yes | 1+ candidate samples to evaluate for phase coherence and entropy. | |
| training | Yes | 2+ baseline normal samples for reference coherence metrics. | |
| field_level | No | Field representation level. Default 1 for phase-aware analysis. | |
| sensitivity | No | Anomaly sensitivity multiplier (default: 1.0). | |
| encoder_type | No | Optional encoder override. Omit to auto-detect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context by specifying what is measured (coherence, entropy, collapse-risk indicators), which aligns with the annotations and provides useful behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It effectively communicates the tool's purpose succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does not explain what the tool returns, such as a risk score or coherence value. It is adequate for a read-only tool with rich annotations but lacks completeness for an agent to fully understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no new meaning beyond the field descriptions. The description's mention of 'candidate data' and 'baseline normal samples' is implicit and not detailed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool measures coherence/entropy and collapse-risk indicators for candidate data. It uses a specific verb and resource, but could better distinguish from similar sibling tools like waveguard_instability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as waveguard_health or waveguard_instability. There is no mention of when to use or 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.
waveguard_price_manipulationADetect price manipulation in time-series data. Send a price or price+volume history as a numeric array. Early windows define 'normal' trading, recent windows are tested for manipulation patterns (pump-and-dump, spoofing, layering).
Example: Send 90 days of closing prices → detect manipulated windows.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Price time-series array (chronological). At least 20 data points. | |
| sensitivity | No | Detection sensitivity (default: 1.5). | |
| window_size | No | Window size (default: 10). Smaller = finer detection. | |
| test_windows | No | Number of recent windows to test (default: half). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context beyond annotations by explaining the baseline window logic (early windows define normal) and the types of manipulations detected (pump-and-dump, spoofing, layering). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an example. Every sentence adds value—first sentence states purpose and input, second explains detection approach, example clarifies usage. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, 100% schema coverage, and no output schema. The description explains the detection concept but does not describe the output format or return values. For a tool with moderate complexity and no output schema, more detail on what the agent can expect as output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning beyond the schema, such as implying that window_size affects detection granularity ('Smaller = finer detection' is already in schema). It does not compensate for schema gaps because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects price manipulation in time-series data. It specifies the input (price or price+volume history) and the detection approach (early windows define normal, recent windows tested for patterns like pump-and-dump, spoofing, layering). This is a specific verb-resource combination that distinguishes it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an example usage (send 90 days of closing prices) but does not explicitly state when to use this tool versus sibling tools like waveguard_scan_timeseries. It lacks guidance on prerequisites or exclusions a user should consider.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_scanAFind outliers and anomalies in structured data — ideal as a second step after pulling records from Google Sheets, Airtable, Supabase, Notion databases, HubSpot, Financial APIs, GitHub, NPM, or any source that returns rows of JSON. Fully stateless: send known-good rows as training and suspect rows as test in ONE call. Returns per-row anomaly scores, confidence levels, and the top features explaining WHY each row was flagged.
Typical workflow: (1) Pull data from another tool (e.g. Google Sheets, Supabase query, HubSpot deals). (2) Pass the first N rows as training (normal baseline). (3) Pass remaining or new rows as test. (4) Report which rows are anomalous and why.
Works on JSON objects, numbers, text, arrays. No separate training step required.
Examples:
Spreadsheet QA: Pull 500 sales rows from Sheets → train on first 400 → test last 100 → flag outlier entries
Financial screening: Get ratios for 50 stocks from a financial API → find anomalous ones
CRM hygiene: Pull HubSpot deals → flag deals with unusual discount/value patterns
Dependency audit: Get NPM package metrics → flag packages with anomalous quality scores
Commit review: Pull GitHub commit metadata → flag unusual commit patterns
| Name | Required | Description | Default |
|---|---|---|---|
| test | Yes | 1+ data points to check for anomalies — new entries, recent rows, or the subset you want validated. Same type/shape as training. Each sample is scored independently. | |
| training | Yes | 2+ examples of NORMAL/expected data — the known-good baseline. Typically the bulk of rows from a spreadsheet, database query, or API response. All samples should be the same type/shape. More samples = better baseline (10-100 is ideal for tabular data). | |
| field_level | No | Physics field complexity. 0 = real scalar (default). 1 = complex field (phase-aware, 62-dim fingerprint). | |
| sensitivity | No | Anomaly threshold multiplier (default: 2.0). Lower = more sensitive. Higher = less sensitive. Range: 0.5 to 5.0. | |
| encoder_type | No | Data encoder type. Omit to auto-detect from data shape. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc., and the description adds value by explaining the stateless nature, single-call training and testing, and return values (scores, confidence, top features). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, workflow steps, and bulleted examples. It is slightly long but highly informative and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains return values. The workflow, parameter options, and data types are thoroughly covered, making the tool self-contained for an agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds workflow context and examples that illustrate parameter usage, but does not significantly extend the schema descriptions themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds outliers and anomalies in structured data using specific verbs ('Find outliers and anomalies') and distinguishes it from sibling tools by detailing its stateless, single-call workflow and typical use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (as a second step after pulling data) and outlines a typical workflow with examples. It does not explicitly state when not to use it or compare to siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_scan_timeseriesADetect anomalies in time-series data — use after pulling numeric metrics from monitoring APIs, financial data sources, IoT sensors, or spreadsheet columns. Send a single numeric array and specify a window size. Early windows define 'normal', recent windows are tested for anomalies.
Typical workflow: (1) Pull a column of numbers from Sheets, a Supabase time-series table, or a metrics API. (2) Pass the array here. (3) Get back which time windows are anomalous.
Examples:
Revenue monitoring: Pull monthly revenue from Sheets → detect anomalous months
Stock screening: Pull 90 days of closing prices → find unusual price windows
Server health: Pull response-time metrics → identify degradation windows
Sensor QA: Pull temperature readings from IoT API → flag sensor drift
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Numeric time-series array, ordered chronologically. Should have at least 3x window_size data points. | |
| sensitivity | No | Anomaly sensitivity (default: 1.0). Higher = more sensitive. | |
| window_size | No | Number of data points per window (default: 10). Smaller windows detect finer-grained anomalies. | |
| test_windows | No | Number of most recent windows to test (default: half of total windows). The rest are used as training (normal baseline). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds algorithm detail: 'Early windows define normal, recent windows are tested for anomalies', which is helpful beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: purpose first, then parameter hints, then workflow, then examples. Concise enough but includes a useful typical workflow and examples. Could be slightly tighter but effectively communicates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 100% schema coverage, and no output schema, the description provides a complete picture of input requirements and algorithm behavior. It explains what the tool does and how to use it. Return format is not specified, but the examples imply a list of anomalous windows, which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters are described in schema (100% coverage). The description adds workflow context (e.g., 'Should have at least 3x window_size data points' for data, 'Higher = more sensitive' for sensitivity, 'Smaller windows detect finer-grained anomalies' for window_size). It explains the role of test_windows in dividing training vs. testing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Detect anomalies in time-series data'. It provides specific verb-resource pairing and distinguishes from sibling tools like waveguard_scan (general) and waveguard_trajectory_scan (trajectories). Examples (revenue, stock, server, sensor) reinforce the specific domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'use after pulling numeric metrics from monitoring APIs, financial data, IoT sensors, or spreadsheet columns' and provides a typical workflow (pull → pass → get results). Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_token_riskAAssess crypto token legitimacy risk. Send metrics from known-good tokens as training (price, volume, holders, liquidity, market_cap, age_days, etc.) and suspect tokens as test. Detects pump-and-dump patterns, fake metrics, and anomalous token profiles.
Example: Pull CoinGecko data for 20 established tokens → train. Test a new token → get risk score and which metrics are suspicious.
| Name | Required | Description | Default |
|---|---|---|---|
| test | Yes | 1+ suspect token metric objects to evaluate. | |
| training | Yes | 3+ known-good token metric objects. Each should include fields like price, volume_24h, market_cap, holders, liquidity, age_days, etc. | |
| sensitivity | No | Risk sensitivity (default: 1.5). Higher = more flags. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: describes the training/test methodology, detection of pump-and-dump patterns, fake metrics, and anomalous profiles. Annotations provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, all consistent with the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct paragraphs: first explains purpose and methodology, second provides a practical example. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, input structure, and example usage. No output schema, but the example mentions 'get risk score and which metrics are suspicious'. Could be slightly more explicit about the output format, but sufficient given the clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining the fields (price, volume, holders, etc.) and the purpose of training and test arrays. Sensitivity parameter is mentioned in schema but not in description; however, the example implicitly covers usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Assess crypto token legitimacy risk' and specifies detection of pump-and-dump patterns, fake metrics, and anomalous token profiles. It distinguishes from siblings like waveguard_scan and waveguard_health by focusing on risk assessment via training/test split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: use known-good tokens as training, suspect tokens as test. Includes a concrete example with CoinGecko data. Lacks explicit alternatives or when-not-to-use conditions, but the context is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_trajectory_scanAAnalyze sequence drift and regime shifts over ordered samples.
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | Ordered samples (time sequence) to scan for drift and regime shifts. | |
| training | Yes | 2+ baseline normal samples used to establish the reference regime. | |
| field_level | No | 0 = real scalar field, 1 = complex field. | |
| sensitivity | No | Anomaly sensitivity multiplier (default: 1.0). | |
| encoder_type | No | Optional encoder override. Omit to auto-detect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, which cover safety. The description adds context about analyzing drift/shifts but does not disclose behavioral details like what happens with parameter variations or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no extraneous words. It achieves maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no nested objects. The description focuses only on purpose and lacks details on return values or how to interpret results, but annotations compensate for some context. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add meaning. It does not elaborate on parameters beyond the schema, which is acceptable given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes sequence drift and regime shifts over ordered samples. It distinguishes itself from siblings like waveguard_scan_timeseries by explicitly mentioning 'regime shifts' and 'drift'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used for detecting drift and regime shifts in ordered samples, but no guidance is given on when to use it versus alternatives like waveguard_scan or waveguard_phase_coherence. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_volume_checkADetect wash trading and fake volume in OHLCV candle data. Send known-legitimate candles as training and suspect candles as test. Detects artificial volume spikes, suspiciously regular patterns, and manipulated price-volume relationships.
Example: Send 100 candles from a liquid pair as baseline, test candles from a suspicious pair.
| Name | Required | Description | Default |
|---|---|---|---|
| test | Yes | 1+ suspect candle objects to evaluate. | |
| training | Yes | 3+ OHLCV candle objects from known-legitimate trading. Fields: open, high, low, close, volume. | |
| sensitivity | No | Detection sensitivity (default: 1.5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds behavioral detail on detection criteria (artificial volume spikes, regular patterns, manipulated price-volume relationships) but does not disclose output format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two impactful sentences and a clear example. It front-loads the primary purpose and provides necessary guidance without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers how to use the tool and what it detects, but lacks information on return values (e.g., output format or detection results). Given no output schema, this is a minor gap for a fully complete specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description enriches parameter meaning by explaining the role of training (known-legitimate) and test (suspect) arrays in the detection context, though the sensitivity parameter is only briefly mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects wash trading and fake volume in OHLCV data, using a specific verb 'detect' and resource. It distinguishes from sibling tools like waveguard_price_manipulation by focusing on volume authenticity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to send known-legitimate candles as training and suspect candles as test, with a concrete example using liquid pair baseline and suspicious pair test. This provides clear when-to-use guidance without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_wallet_profileAProfile wallet behavior against baselines. Send normal wallet transaction patterns as training (tx_count, avg_value, unique_tokens, gas_spent, active_days, etc.) and suspect wallets as test. Detects bot activity, wash trading wallets, and sybil patterns.
Example: Profile 50 organic wallets → test 10 suspect addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| test | Yes | 1+ suspect wallet profiles to evaluate. | |
| training | Yes | 3+ known-organic wallet activity profiles. | |
| sensitivity | No | Detection sensitivity (default: 1.5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds detection capabilities (bot, wash trading, sybil patterns) but does not detail computational cost, data persistence, or scale limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, all front-loaded. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers training/test paradigm, example fields, and detection types. Missing output format description, 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds meaning by explaining that training/test arrays contain wallet profiles with fields like tx_count, avg_value, etc. Also provides example usage. Sensitivity parameter not detailed but default mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Profile', resource 'wallet behavior', and method 'against baselines using training/test'. Example and sibling list differentiate it from other waveguard tools by focusing on wallet profiling with training and test sets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for use: send normal wallet patterns as training and suspect wallets as test. Example illustrates typical use. However, no explicit when-not-to-use or comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!