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.7/5 across 19 of 19 tools scored. Lowest: 2.7/5.
Several tools occupy overlapping anomaly-detection territory (scan, scan_timeseries, price_manipulation, volume_check, token_risk, wallet_profile), which could cause misselection when an agent needs generic vs. specialized analysis. However, descriptions clarify data types and use cases, so the overlap is manageable.
All tools share the consistent 'waveguard_' prefix with descriptive underscore-separated names (e.g., waveguard_cascade_risk, waveguard_volume_check). The occasional verb like 'scan' or 'compare' fits the overall pattern, making the set highly predictable.
With 19 tools, the server is on the heavy side for a typical MCP but not extreme. The breadth reflects a comprehensive risk-analysis platform, though some specialized detectors (e.g., waveguard_price_manipulation vs. waveguard_scan_timeseries) could potentially be consolidated without losing functionality.
The tool surface covers the full analytical workflow: data ingestion (market_data), generic anomaly detection (scan, scan_timeseries), specialized crypto risk (token_risk, volume_check, wallet_profile), structural similarity (fingerprint, compare), and scenario/impact analysis (counterfactual, cascade_risk, mechanism_probe). Minor gaps like direct report generation exist but are not critical for the core purpose.
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 convey readOnly, idempotent, non-destructive behavior. The description adds a high-level function but no extra behavioral details such as input assumptions, output format, or edge cases. Thus it meets the baseline but does not exceed it.
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 sentence with no filler. It front-loads the core purpose effectively. This is ideal 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?
Despite rich annotations and complete schema parameter descriptions, the description does not explain the tool's output structure or provide any usage context for this complex analytical tool. With no output schema, the agent is left without sufficient information to predict the result. The single-sentence description is insufficient for a tool with 6 parameters.
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 descriptions cover 100% of parameters with meaningful explanations, so the description does not need to elaborate. The description itself adds no parameter-specific information, but baseline is appropriate given the complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Score' and 'extract' with objects 'candidate actions' and 'robust action zones', clearly indicating a scoring/analysis tool. However, it does not explicitly differentiate from sibling tools like waveguard_scan or waveguard_cascade_risk, so it merits a 4 rather than a 5.
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 vs alternatives. The description lacks any contextual cues such as prerequisites, use cases, or exclusions. It simply states the function without telling the agent when to select it.
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, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds no behavioral context beyond what annotations provide—no mention of output format, computational complexity, or assumptions. It merely restates a read-only estimation task.
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 that is free of redundant information. Every word adds value, making it highly concise.
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 8 parameters, no output schema, and a complex domain (cascade risk modeling). The description only states the high-level goal and does not explain the expected output, how to interpret results, or how the tool handles edge cases. An agent would likely need additional information to invoke it correctly with confidence.
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%, and each parameter has a clear description (e.g., 'weighted adjacency matrix describing link strengths'). The tool description itself adds no parameter-specific semantics, but the baseline of 3 applies because the schema fully documents parameters.
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 ('estimate') and resource ('shock propagation and resilience') with a clear data source ('adjacency-linked entities'). It distinguishes from sibling tools like waveguard_instability by emphasizing cascade dynamics and graph structure.
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 mention of when to use this tool versus alternatives. The description does not provide usage context, prerequisites, or exclusions. With 18 sibling tools, the lack of guidance leaves the agent to infer applicability solely from the tool name and one-line description.
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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context by specifying return values (cosine similarity and Euclidean distance) and providing interpretation thresholds (>0.95 very similar, <0.80 structurally different). It also reveals the 'physics-based fingerprints' technique, giving insight into how the comparison works beyond the schema.
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 and well-structured: first sentence states purpose and output, second sentence lists use cases, and third sentence provides thresholds. There is no redundant information, and the most important details are 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?
The tool is simple (3 params, no output schema), but the description covers purpose, return format, use cases, and numeric interpretation. It is fully sufficient for an agent to select and invoke the tool, especially with the supportive annotations. No critical behavioral aspects are unexplained.
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%, and each parameter has a basic description: 'First data item to compare', 'Second data item to compare (same type as data_a)', and encoder_type with an enum and 'Omit to auto-detect.' The description itself does not add further parameter detail, but the schema is already adequate. Baseline 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 function: 'Compare two data items for structural similarity using physics-based fingerprints' and lists what it returns (cosine similarity and Euclidean distance). This distinguishes it from sibling tools like waveguard_fingerprint (which likely generates fingerprints) and waveguard_scan (which analyzes a single item).
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 'Use for duplicate detection, behavioral matching, drift analysis, or checking if two tokens/wallets/contracts are structurally similar.' This provides concrete use cases. It does not mention when not to use it or alternative tools, but the use-case list is clear and actionable.
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=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds methodological context (baseline + variants) but does not describe return format, pagination, or any operational quirks. This is acceptable but not rich.
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 filler. Every word contributes to conveying the tool's purpose and method. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns (e.g., sensitivity metrics, verdict comparison). It only vaguely says 'measure verdict/score sensitivity' without specifying output structure. Given the complexity of six parameters and a specialized analysis purpose, more detail is needed for full contextual 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 all six parameters have clear descriptions. The tool description itself adds minimal parameter-level meaning, only hinting at the relationship between base_test and counterfactual_tests. This meets the baseline but does not exceed it.
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 states a specific action ('Run baseline plus counterfactual variants') and an outcome ('measure verdict/score sensitivity'), clearly conveying the tool's core function. However, it does not explicitly differentiate this tool from siblings like waveguard_compare or waveguard_mechanism_probe, though the 'counterfactual' term is fairly distinctive.
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 no explicit guidance on when to use this tool versus alternatives. It implies a use case (sensitivity testing) but does not state prerequisites, exclusions, or refer to sibling tools. There is no 'use when' or 'instead of' context.
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=false. The description goes beyond these by disclosing that the output is deterministic, returns a vector with labeled dimensions (chi statistics, energy distribution, gradient patterns), and that Level 1 adds phase coherence. This adds useful behavioral context without 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?
Three sentences, each with a clear purpose: functionality (what it does), applicability (when to use), and output details (what you get). No redundancy, minimal fluff, and well-structured for quick comprehension.
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 no output schema, the description adequately explains return format (deterministic vector, dimension counts, labeled components) and intended use cases. It does not include a concrete example or deeper interpretation of vector components, but the provided information is sufficient for an agent to understand scope and output. A 4 reflects the good coverage with minor 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?
Input schema covers 100% of parameters with descriptions (data, field_level, encoder_type). The description echoes the 52/62-dim distinction already in the schema and provides output-related labels, but no new parameter-specific semantics. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 ('Get') and resource ('physics embedding of any data item'), specifies dimension counts (52-dim at Level 0, 62-dim at Level 1), and lists concrete use cases (similarity search, clustering, drift detection). This clearly distinguishes it from sibling tools like waveguard_compare or waveguard_scan, which are specialized analysis tools.
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?
It explicitly states when to use the tool (similarity search, clustering, baseline comparison, drift detection) and which data types are acceptable (JSON objects, token metrics, wallet activity, trading data). It lacks explicit 'when not to use' guidance or named alternatives, but the contextual guidance is clear enough for an agent to select it appropriately.
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 declare readOnlyHint, idempotentHint, and destructiveHint, establishing safety. The description adds that no authentication is required and details the return content (status, version, GPU info), which is useful context beyond typical schema.
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, no fluff. The first sentence front-loads the core purpose, and the second adds authentication and return-value details. 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?
For a low-complexity health check tool with one optional parameter and no output schema, the description covers purpose, auth, and return content. It doesn't explain failure behavior, but that's minor for a health endpoint. Overall, the description is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'verbose' is fully described in the schema (100% coverage), so the description doesn't need to repeat it. The description's mention of return values ('Returns status, version, and GPU info') hint at what verbose might control, but doesn't explicitly clarify the parameter's effect. Baseline 3 is warranted.
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 'Check' with a clear resource 'WaveGuard API health', enumerating GPU availability, version, and engine status. This clearly distinguishes it from sibling tools that perform various analyses. The mention of return values reinforces the purpose.
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 specifies 'No authentication required', giving a clear precondition for use. It implies this is a preliminary health check tool, though it doesn't explicitly contrast with siblings. The context is clear enough for an agent to choose this when needing system status before other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_instabilityCEstimate 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 destructiveHint=false, and the description does not contradict them. However, the description adds little behavioral context beyond the method name; it does not explain what happens during trials, what outputs are expected, or any limitations not already covered by 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 short sentence, which is front-loaded but under-specified. While it is not verbose, the brevity sacrifices useful detail that should be present, especially given the tool has 7 parameters and no output schema.
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, a rich set of annotations, and no output schema, the description is too terse to be considered complete. It omits context about required inputs, the nature of 'instability', expected return format, and how it relates to sibling tools, leaving the agent with insufficient information for correct invocation.
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 each parameter already having a description in the schema. The tool description itself provides no parameter-specific semantics, so it adds no extra value beyond the schema, which corresponds to the baseline 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 uses a specific verb ('Estimate') and resource ('instability') and adds the method ('controlled perturb-and-resolve trials'), clearly indicating what the tool does. However, it does not differentiate this from siblings like waveguard_cascade_risk or waveguard_mechanism_probe, so it misses the highest bar for distinction.
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?
There is no guidance on when to use this tool versus alternatives. The description implies it is for instability estimation, but it never states scenarios, exclusions, or comparisons such as 'use this instead of X when Y' which would help an agent select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_interaction_matrixBCompute 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 the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds no extra behavioral context such as output format, computational cost, or limitations, making it minimal but not contradictory.
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 immediately communicates the core operation and target.
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 schema is comprehensive and annotations cover safety, the description is adequate for invoking the tool, but it omits expected output details (e.g., matrix dimensions, cluster labels) and any usage context. This is a moderate gap for a computation tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters, so the schema carries the semantic load. The description does not add additional meaning to parameters beyond what is already in 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 computes a pairwise interaction matrix and cluster decomposition for entities, which is specific and actionable. However, it does not explicitly differentiate from sibling analysis tools like waveguard_phase_coherence or waveguard_mechanism_probe, so it falls short of a 5.
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, nor does it mention prerequisites, intended scenarios, or exclusions. Users are left to infer use cases from the tool name and description alone.
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 mark the tool as readOnly and idempotent, but the description adds behavioral context beyond that: it pulls data from external sources ('WaveGuard pulls it for you') and outlines the return content (price, volume, market cap, etc.). This helps the agent understand side effects and output expectations without 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 compact and front-loaded, with the main purpose in the first sentence and key parameter usage in short bullet-like lines. Every sentence serves a purpose: clarifying data sources, parameter mapping, and downstream integration. No fluff or repetition.
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 a moderate number of actions and parameters, but the schema already explains each action and parameter. The description adds value by clarifying data source selection, integration with other tools, and high-level return fields. Given no output schema, it covers the essential context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are complete (100% coverage), so the baseline is 3. The description repeats examples already in the schema (e.g., 'bitcoin', 'any chain') but does not add new semantic details beyond what the schema provides. It serves as a quick reference but not a meaningful extension.
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 function: 'Fetch live crypto market data from CoinGecko and DexScreener.' The verb 'fetch' plus the named resources (CoinGecko, DexScreener) makes the purpose specific. It also distinguishes from sibling tools by highlighting integration with risk/volume/manipulation tools, setting it apart as the data provider.
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 offers explicit parameter guidance ('Use coin_id for CoinGecko', 'Use contract_address for DexScreener') and mentions the tool's output is 'ready to feed into' other WaveGuard tools, implying when it should be used. However, it does not explicitly state exclusions or alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_mechanism_probeCRun 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?
The annotations (readOnlyHint, idempotentHint, destructiveHint) cover the safety profile, but the description adds no behavioral context beyond its stated purpose. It does not disclose how 'interventions' are executed, what is returned, or any side effects, relying entirely on 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 a single efficient sentence with no wasted words. It front-loads the main action and output, but is so brief that it omits contextual detail, making it concise yet slightly under-specified.
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 many siblings, the description is insufficient for an agent to fully understand what the tool does or what to expect. It lacks information about what 'interventions' mean, how effect sizes are ranked, or what the return value looks like.
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 seven parameters. The description adds no parameter-level meaning, but given full schema coverage, the baseline 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 'Run targeted interventions and rank effect sizes' clearly states the tool's core function with a specific verb and resource. It distinguishes the tool as an intervention/effect-size ranking operation, though it does not explicitly differentiate it from the many sibling tools.
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 usage guidance is provided. The description does not indicate when to choose this tool over siblings like waveguard_counterfactual or waveguard_cascade_risk, nor does it mention prerequisites, typical use cases, 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.
waveguard_multi_horizon_outlookBCompute 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 readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only profile. However, the description adds no additional behavioral context—no details about return format, edge cases, or operational semantics. It simply states the action without exceeding what annotations already provide, so it falls short of the minimum value expected.
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, focused sentence with no filler. It is front-loaded with the verb and concisely encapsulates the tool's main purpose. Every word contributes to understanding, making it appropriately sized for the information it conveys.
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?
This is a relatively complex analytical tool with 6 parameters, no output schema, and many sibling tools. The description is too sparse to provide a complete picture—it omits what the tool returns, how 'outlook' and 'consistency' are quantified, and when an agent should prefer this over other waveguard tools. The lack of an output schema places more burden on the description, which it fails to meet.
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 mentions 'horizon-specific' and 'windows,' which loosely align with the 'horizons' and 'sequence' parameters, but it does not add substantive meaning beyond the schema's own parameter descriptions. It offers no extra clarification of units, formats, or default behaviors.
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 a clear resource: 'horizon-specific anomaly outlook and consistency across windows.' It distinguishes itself from sibling tools by emphasizing the multi-horizon aspect, which is unique among the listed waveguard tools. Even though it is brief, it conveys the tool's primary function without ambiguity.
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. It does not mention any specific context, prerequisites, or exclusions. With 18 sibling tools, some usage direction is essential for an agent to select the correct tool, but none is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_phase_coherenceCMeasure 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?
The annotations already declare the tool as read-only, idempotent, and non-destructive. The description does not add any behavioral traits beyond this, such as return format, processing behavior, or limitations. It only restates the analytical focus, which falls short of disclosing additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose without filler. It is concise and every word contributes to the message, though it may be too terse for complex functionality.
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 (5 parameters, 2 required, no output schema) and the presence of many sibling tools, this one-sentence description is insufficient. It does not explain what 'phase coherence' means, what the output looks like, or how it relates to other waveguard tools, leaving significant gaps for an AI 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?
The input schema already provides detailed descriptions for all five parameters, covering 100% of them. The description adds no additional meaning about how parameters interact or influence results, so the 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 uses the verb 'Measure' with specific objects 'coherence/entropy' and 'collapse-risk indicators' for 'candidate data', clearly indicating the tool's analytic function. However, it does not explicitly differentiate from sibling tools like waveguard_cascade_risk, which also addresses collapse risk, so it's clear but lacks explicit sibling differentiation.
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 like waveguard_instability or waveguard_cascade_risk. There are no prerequisites, exclusions, or context clues about typical use cases beyond the general 'candidate data' phrase.
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?
Beyond the annotations (read-only, non-destructive), the description explains the methodology: early windows define normal trading, recent windows are tested, and names specific attack patterns. It does not detail output format or edge cases, but with annotations covering safety, this is adequate context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two focused sentences plus a practical example, front-loaded with the action. Every sentence earns its place with no redundant wording, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still conveys primary behavior and acceptable input via the example. It could be more explicit about the exact return format or threshold behavior, but it's sufficient for an agent to understand what to send and roughly what to expect.
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?
Although the schema already describes all parameters (100% coverage), the description adds conceptual meaning by explaining how early vs. recent windows relate to window_size/test_windows and by clarifying that data should be a numeric array (e.g., 90 days of closing prices). This goes beyond the structured 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 a specific action ('Detect price manipulation') on a defined resource ('time-series data'), and lists concrete manipulation patterns (pump-and-dump, spoofing, layering), distinguishing it from sibling tools focused on other risk metrics. The example reinforces the exact use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It signals when to use the tool (when given a price/volume history and needing manipulation detection) and specifies input requirements, but it does not explicitly mention alternatives or exclusions relative to sibling tools. Context is clear, but no direct 'use instead of X' guidance.
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 read-only, idempotent, open-world, and non-destructive hints. The description adds valuable behavioral details beyond these: 'Fully stateless,' 'send known-good rows as training and suspect rows as test in ONE call,' and what it returns ('per-row anomaly scores, confidence levels, and the top features explaining WHY'). This goes well beyond the annotation baseline.
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 moderately long but well-structured: a clear opening, a workflow list, and bullet-like examples. It effectively uses whitespace and front-loads the core purpose. Some repetition exists (e.g., mentioning 'one call' twice), but overall it is efficient and readable for the amount of context provided.
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 lacking an output schema, the description tells the agent exactly what to expect (per-row scores, confidence, top features). It covers purpose, usage workflow, integration examples, and key behavioral constraints. No critical gaps are apparent for a tool of this complexity, given the rich schema and annotations.
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?
Input schema coverage is 100% with every parameter described (training, test, field_level, sensitivity, encoder_type). The description adds conceptual context for the key parameters (e.g., what 'training' and 'test' mean and how they fit the workflow), but does not elaborate on all parameters. Since schema already does heavy lifting, the description supplements rather than replaces, earning a 4.
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: 'Find outliers and anomalies in structured data' and positions it as a second step after data retrieval. It uses specific verbs and includes multiple concrete examples (Sheets, financial APIs, CRM) that make the tool's scope obvious and distinct from time-series-focused siblings like waveguard_scan_timeseries.
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 workflow steps ('Typical workflow: (1) Pull data... (2) Pass the first N rows...') and says it is 'ideal as a second step after pulling records' from various sources. However, it does not explicitly state when not to use this tool or mention alternatives for edge cases, so it falls short of a 5.
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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds valuable behavioral context about how the algorithm works: 'Early windows define normal, recent windows are tested for anomalies,' and explains the training/test split, which goes 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 front-loaded with the core purpose and then provides a structured workflow and examples. It is somewhat long, with four similar examples that could be condensed, but each example serves to illustrate a different data source. Overall it is efficient and well-organized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 100% schema coverage, and no output schema, the description is remarkably complete. It explains the algorithm, gives a typical workflow, and states the return value ('which time windows are anomalous'). It also provides multiple example scenarios, making it clear how to apply the tool in practice.
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 every parameter thoroughly. The description adds minimal new meaning beyond mentioning the array and window size; the training/testing semantics are already in the test_windows schema description. Thus, it meets the baseline but does not elevate it.
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 states 'Detect anomalies in time-series data' with a clear verb and resource. It provides concrete examples (revenue, stock, server health) that differentiate it from generic scan tools like waveguard_scan, but it does not explicitly name alternatives or contrast with 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 explicit usage context: 'use after pulling numeric metrics from monitoring APIs, financial data sources, IoT sensors, or spreadsheet columns.' It outlines a typical workflow and multiple use cases, but does not mention when not to use the tool or name alternative tools.
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?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds behavioral context by introducing the training/test paradigm and stating the output ('risk score and which metrics are suspicious'). This goes beyond the annotations without conflicting with them.
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 and well-structured: two short paragraphs with a clear purpose statement, usage explanation, and a concrete example. Every sentence contributes value, and the example aids comprehension without bloat.
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 (training/test model) and absence of an output schema, the description provides sufficient context about inputs, expected behavior, and output. It could be more complete by mentioning the sensitivity parameter, but that is documented in the 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 description coverage is 100%, and the schema already describes each parameter including example fields for training ('price, volume_24h, market_cap, holders, liquidity, age_days, etc.'). The description repeats similar field examples and explains the training/test conceptual split, but adds only marginal detail 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's purpose with a specific verb ('assess') and resource ('crypto token legitimacy risk'), and further specifies detections ('pump-and-dump patterns, fake metrics, and anomalous token profiles'). It distinguishes itself from siblings like waveguard_price_manipulation by focusing on a training/test approach.
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 explains how to use the tool with a concrete example ('Pull CoinGecko data for 20 established tokens → train. Test a new token → get risk score'). It implies when to use it (when you have known-good and suspect tokens) but does not explicitly mention alternatives or exclusions, so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_trajectory_scanCAnalyze 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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. However, the description adds no extra behavioral context beyond its purpose. It does not disclose output format, edge cases, or what happens with invalid inputs. With no output schema, this is a significant gap.
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, grammatically correct sentence with no wasted words. It is appropriately concise for a simple read-only analysis tool, though it is slightly under-specified.
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?
There is no output schema, so the description should explain what the tool returns, but it does not. It also lacks differentiation from similar sibling tools and fails to mention how the analysis works or what the result means. Given the 5 parameters and no output schema, the description is incomplete.
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 descriptions cover 100% of parameters, so the baseline is 3. The description adds no additional parameter semantics; it merely restates 'ordered samples' which is already in the schema for 'sequence.' No extra clarity on field_level, sensitivity, or encoder_type is provided.
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 clear verb 'analyze' and specifies targets 'sequence drift and regime shifts' over 'ordered samples.' It is specific and distinguishes this as a trajectory/sequence analysis tool, but it does not explicitly differentiate from sibling tools like waveguard_scan_timeseries or 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?
The description provides no guidance on when to use this tool versus alternatives. It implies usage for ordered/time-sequence data via 'ordered samples,' but there are no exclusions, prerequisites, or mentions of sibling tools. An agent would not know when to pick this over comparable scans.
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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context by explaining the need for a baseline and suspect set, and enumerates the types of anomalies detected. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence. The example is useful and not repetitive, and every sentence contributes to understanding the tool's use.
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 rich annotations, complete schema coverage, and a clear example, the tool is well-described for selection and invocation. It does not explain what the output looks like (no output schema), but this is not essential for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to add much. It reinforces that 'training' is known-legitimate and 'test' is suspect, but this is already stated in the schema. The sensitivity parameter is not elaborated beyond its default, so the description adds no new semantic value.
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 opens with a specific verb and resource: 'Detect wash trading and fake volume in OHLCV candle data.' It further specifies detection targets (artificial volume spikes, regular patterns, price-volume manipulation), clearly differentiating 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 provides clear usage context: send known-legitimate candles as training and suspect candles as test. The example ('Send 100 candles from a liquid pair as baseline, test candles from a suspicious pair') makes the intended workflow concrete, though it does not explicitly mention alternatives or exclusions.
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=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds behavioral context about the detection capabilities (bot, wash trading, sybil) and the training/test input arrangement, which goes beyond annotations without contradicting them.
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: two sentences plus an illustrative example. It front-loads the core purpose and includes only essential information. No redundant phrases or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, workflow (training/test), and data content (field examples). Given there is no output schema, it could have described what the tool returns (e.g., classification labels, scores), but the current description still gives a solid understanding for a read-only profiling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all three parameters described), but the description adds meaning by listing example fields for the arrays: 'tx_count, avg_value, unique_tokens, gas_spent, active_days, etc.' This clarifies what constitutes a 'wallet activity profile,' adding value beyond the schema's generic 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's function: 'Profile wallet behavior against baselines' and specifies detectable outcomes ('bot activity, wash trading wallets, and sybil patterns'). This specific verb+resource+outcome combination distinguishes it from sibling tools like waveguard_scan or waveguard_compare, which focus on other aspects.
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?
It explains when to use the tool: feed normal transaction patterns as training and suspect wallets as test. The example ('Profile 50 organic wallets → test 10 suspect addresses') provides a concrete scenario. However, it does not explicitly mention alternatives or when not to use it, which is a minor gap.
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!