WaveGuard

waveguard_scan

Read-onlyIdempotent

Find 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

Input Schema

TableJSON Schema

Name	Required	Description
`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.

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description 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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All WaveGuard tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation5/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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Resources

Need Help?