A
licenseNot graded
qualityD
maintenanceModel Context Protocol server that standardizes tool discovery, execution, and context management for AI applications.
MIT
WaveGuard
by gpartin
WaveGuard is a GPU-accelerated anomaly detection API that uses wave physics simulations instead of machine learning — no training pipelines, model management, or ML expertise required.
Core capabilities:
General anomaly detection (
waveguard_scan): Send 2+ normal examples as training data alongside test samples in a single stateless API call. Works with JSON objects, numeric arrays, text strings, and time series. Returns per-sample anomaly scores, confidence levels, and explanations of which specific features triggered each alert. Supports sensitivity tuning (0.5–5.0) and manual encoder selection.Time-series anomaly detection (
waveguard_scan_timeseries): Send a flat array of numeric values; the tool automatically creates overlapping windows, uses the first portion as a normal baseline, and scores remaining windows. Returns per-window anomaly scores, confidence levels, and p-values. Configurable window size and number of test windows.Health monitoring (
waveguard_health): Check API status, GPU availability, engine version, and service status without authentication.Advanced analytics: Additional intelligence methods including
counterfactual,trajectory_scan,instability, andcascade_riskfor deeper insights.
Key characteristics:
Fully stateless — no stored state between calls
All physics simulation runs server-side on GPU (CUDA-accelerated)
Works across domains: DevOps, fraud detection, security logs, IoT sensors, healthcare, and more
MCP integration available for Claude Desktop and other AI agents
Drop-in replacement for Azure Anomaly Detector (retiring October 2026)
What is WaveGuard?
WaveGuard is a general-purpose anomaly detection API. Send it any data — server metrics, financial transactions, log files, sensor readings, time series — and get back anomaly scores, confidence levels, and explanations of which features triggered the alert.
No training pipelines. No model management. No state. One API call.
Your data → WaveGuard API (GPU) → Anomaly scores + explanationsUnder the hood, it uses GPU-accelerated wave physics instead of machine learning. You don't need to know or care about the physics — it's all server-side.
Modal dashboard vs API endpoints
If you look at Modal, you will see deployed functions (for example fastapi_app, gpu_scan, gpu_fingerprint).
Those are compute/runtime units, not the HTTP route list.
To see all live API endpoints, use:
OpenAPI docs:
https://gpartin--waveguard-api-fastapi-app.modal.run/docsOpenAPI JSON:
https://gpartin--waveguard-api-fastapi-app.modal.run/openapi.json
Your data is encoded onto a 64³ lattice and run through coupled wave equation simulations on GPU. Normal data produces stable wave patterns; anomalies produce divergent ones. A 52-dimensional statistical fingerprint is compared between training and test data. Everything is torn down after each call — nothing is stored.
The key advantage over ML: no training data requirements (2+ samples is enough), no model drift, no retraining, no hyperparameter tuning. Same API call works on structured data, text, numbers, and time series.
Related MCP server: Semantic BI MCP
Benchmarks (v2.2)
WaveGuard v2.2 vs scikit-learn across 6 real-world scenarios (10 training + 10 test samples each).
TL;DR: WaveGuard v2.2 wins 4 of 6 scenarios and averages 0.76 F1 — competitive with sklearn methods while requiring zero ML expertise.
F1 Score (balanced precision-recall)
Scenario | WaveGuard | IsolationForest | LOF | OneClassSVM |
Server Metrics (IT Ops) | 0.87 | 0.71 | 0.87 | 0.62 |
Financial Fraud | 0.83 | 0.74 | 0.77 | 0.77 |
IoT Sensors (Industrial) | 0.87 | 0.69 | 0.69 | 0.65 |
Network Traffic (Security) | 0.82 | 0.61 | 0.77 | 0.61 |
Time-Series (Monitoring) | 0.46 | 0.77 | 0.80 | 0.67 |
Sparse Features (Logs) | 0.72 | 0.90 | 0.82 | 0.78 |
Average | 0.76 | 0.74 | 0.79 | 0.68 |
What's new in v2.2
Multi-resolution scoring tracks each feature's local lattice energy in addition to global fingerprint distance. This catches subtle per-feature anomalies (like 3 of 10 IoT sensors drifting) that v2.1's global averaging missed. IoT F1 improved from 0.30 → 0.87.
When to choose WaveGuard over sklearn
Choose WaveGuard when... | Choose sklearn when... |
False alarms are expensive (alert fatigue, SRE pages) | You need to catch every possible anomaly |
You have no ML expertise on the team | You have data scientists who can tune models |
You need a zero-config API call | You can manage model lifecycle (train/save/load) |
Data schema changes frequently | Feature engineering is stable |
Your AI agent needs anomaly detection (MCP) | Everything runs locally, no API calls |
pip install WaveGuardClient scikit-learn
python benchmarks/benchmark_vs_sklearn.pyResults saved to benchmarks/benchmark_results.json. Benchmarks use deterministic random seeds for reproducibility.
Expanded benchmarks: WaveGuard ranks #1 in F1 score on all 12 public benchmark datasets. See the full comparison on HuggingFace.
Real-World Validation: Crypto Crash Detection
WaveGuard powers CryptoGuard, a crypto risk scanner. Backtested against 7 historical crashes (LUNA, FTX, Celsius, 3AC, UST, SOL/FTX, TITAN):
Method | Recall | Avg Lead Time | False Positive Rate |
WaveGuard | 100% (7/7) | 27.4 days | 6.1% |
Z-score baseline | 100% (7/7) | 28.4 days | 29.9% |
Rolling volatility | 86% (6/7) | 15.5 days | 4.0% |
WaveGuard flagged FTT (FTX token) at CAUTION on October 16, 2022 — 23 days before the 94% crash — while z-score analysis showed nothing unusual.
5× fewer false alarms than statistical baselines with the same recall. Full results: CryptoGuard backtest.
Install
pip install WaveGuardClientThat's it. The only dependency is requests. All physics runs server-side on GPU.
Get your free API key on RapidAPI →
Quickstart
The same scan() call works on any data type. Here are three different industries — same API:
Detect a compromised server
from waveguard import WaveGuard
wg = WaveGuard(api_key="YOUR_KEY")
result = wg.scan(
training=[
{"cpu": 45, "memory": 62, "disk_io": 120, "errors": 0},
{"cpu": 48, "memory": 63, "disk_io": 115, "errors": 0},
{"cpu": 42, "memory": 61, "disk_io": 125, "errors": 1},
],
test=[
{"cpu": 46, "memory": 62, "disk_io": 119, "errors": 0}, # ✅ normal
{"cpu": 99, "memory": 95, "disk_io": 800, "errors": 150}, # 🚨 anomaly
],
)
for r in result.results:
print(f"{'🚨' if r.is_anomaly else '✅'} score={r.score:.1f} confidence={r.confidence:.0%}")Flag a fraudulent transaction
result = wg.scan(
training=[
{"amount": 74.50, "items": 3, "session_sec": 340, "returning": 1},
{"amount": 52.00, "items": 2, "session_sec": 280, "returning": 1},
{"amount": 89.99, "items": 4, "session_sec": 410, "returning": 0},
],
test=[
{"amount": 68.00, "items": 2, "session_sec": 300, "returning": 1}, # ✅ normal
{"amount": 4200.00, "items": 25, "session_sec": 8, "returning": 0}, # 🚨 fraud
],
)Catch a security event in logs
result = wg.scan(
training=[
"2026-02-24 10:15:03 INFO Request processed in 45ms [200 OK]",
"2026-02-24 10:15:04 INFO Request processed in 52ms [200 OK]",
"2026-02-24 10:15:05 INFO Cache hit ratio=0.94 ttl=300s",
],
test=[
"2026-02-24 10:20:03 INFO Request processed in 48ms [200 OK]", # ✅ normal
"2026-02-24 10:20:04 CRIT xmrig consuming 98% CPU, port 45678 open", # 🚨 crypto miner
"2026-02-24 10:20:05 WARN GET /api/users?id=1;DROP TABLE users-- from 185.x.x", # 🚨 SQL injection
],
encoder_type="text",
)Same client. Same scan() call. Any data.
Use Cases
WaveGuard works on any structured, numeric, or text data. If you can describe "normal," it can detect deviations.
Industry | What You Scan | What It Catches |
DevOps | Server metrics (CPU, memory, latency) | Memory leaks, DDoS attacks, runaway processes |
Fintech | Transactions (amount, velocity, location) | Fraud, money laundering, account takeover |
Security | Log files, access events | SQL injection, crypto miners, privilege escalation |
IoT / Manufacturing | Sensor readings (temp, pressure, vibration) | Equipment failure, calibration drift |
E-commerce | User behavior (session time, cart, clicks) | Bot traffic, bulk purchase fraud, scraping |
Healthcare | Lab results, vitals, biomarkers | Abnormal readings, data entry errors |
Time Series | Metric windows (latency, throughput) | Spikes, flatlines, seasonal breaks |
The API doesn't know your domain. It just knows what "normal" looks like (your training data) and flags anything that deviates. This makes it general — you bring the context, it brings the detection.
Supported Data Types
All auto-detected from data shape. No configuration needed:
Type | Example | Use When |
JSON objects |
| Structured records with named fields |
Numeric arrays |
| Feature vectors, embeddings |
Text strings |
| Logs, messages, free text |
Time series |
| Metric windows, sequential readings |
Examples
Every example is a runnable Python script that hits the live API:
# | Example | Industry | What It Shows |
🏭 | Manufacturing | Detect bearing failure, leaks, overloads from sensor data | |
🔒 | Cybersecurity | Catch port scans, C2 beacons, DDoS, data exfiltration | |
🤖 | AI/Agents | Claude calls WaveGuard via MCP — zero ML knowledge | |
01 | General | Minimal scan in 10 lines | |
02 | DevOps | Memory leak + DDoS detection | |
03 | Security | SQL injection, crypto miner detection | |
04 | Monitoring | Latency spikes, flatline detection | |
06 | E-commerce | 20 transactions, fraud flagging | |
07 | Production | Retry logic, exponential backoff |
pip install WaveGuardClient
python examples/iot_predictive_maintenance.pyMCP Server (Claude Desktop)
The first physics-based anomaly detector available as an MCP tool. Give any AI agent the ability to detect anomalies — zero ML knowledge required.
Quick setup
{
"mcpServers": {
"waveguard": {
"command": "uvx",
"args": ["--from", "WaveGuardClient", "waveguard-mcp"]
}
}
}Then ask Claude: "Are any of these sensor readings anomalous?" — it calls waveguard_scan automatically.
Available MCP tools
Tool | Description |
| Detect anomalies in any structured data |
| Auto-window time-series and detect anomalous segments |
| Check API status and GPU availability |
See the MCP Agent Demo for a working example, or the MCP Integration Guide for full setup.
Azure Migration
Azure Anomaly Detector retires October 2026. WaveGuard is a drop-in replacement:
# Before (Azure) — 3+ API calls, stateful, time-series only
client = AnomalyDetectorClient(endpoint, credential)
model = client.train_multivariate_model(request) # minutes
result = client.detect_multivariate_batch_anomaly(model_id, data)
client.delete_multivariate_model(model_id)
# After (WaveGuard) — 1 API call, stateless, any data type
wg = WaveGuard(api_key="YOUR_KEY")
result = wg.scan(training=normal_data, test=new_data) # secondsSee Azure Migration Guide for details.
API Reference
wg.scan(training, test, encoder_type=None, sensitivity=None)
Parameter | Type | Description |
|
| 2+ examples of normal data |
|
| 1+ samples to check |
|
| Force: |
|
| 0.5–3.0, lower = more sensitive (default: 1.0) |
Returns ScanResult with .results (per-sample) and .summary (aggregate).
wg.health() / wg.tier()
Health check (no auth) and subscription tier info.
Advanced intelligence methods (v3.3.0)
wg.counterfactual(...)wg.trajectory_scan(...)wg.instability(...)wg.phase_coherence(...)wg.interaction_matrix(...)wg.cascade_risk(...)wg.mechanism_probe(...)wg.action_surface(...)wg.multi_horizon_outlook(...)
These map directly to /v1/* intelligence endpoints and return the raw JSON payload
for maximal compatibility with rapidly evolving server-side response schemas.
Error Handling
from waveguard import WaveGuard, AuthenticationError, RateLimitError
try:
result = wg.scan(training=data, test=new_data)
except AuthenticationError:
print("Bad API key")
except RateLimitError:
print("Too many requests — back off and retry")Full API reference: docs/api-reference.md
Project Structure
WaveGuardClient/
├── waveguard/ # Python SDK package
│ ├── __init__.py # Public API exports
│ ├── client.py # WaveGuard client class
│ └── exceptions.py # Exception hierarchy
├── mcp_server/ # MCP server for Claude Desktop
│ └── server.py # stdio + HTTP transport
├── benchmarks/ # Reproducible benchmarks vs sklearn
│ ├── benchmark_vs_sklearn.py
│ └── benchmark_results.json
├── examples/ # 9 runnable examples
├── docs/ # Documentation
│ ├── getting-started.md
│ ├── api-reference.md
│ ├── mcp-integration.md
│ └── azure-migration.md
├── tests/ # Test suite
├── pyproject.toml # Package config (pip install -e .)
└── CHANGELOG.mdDevelopment
git clone https://github.com/gpartin/WaveGuardClient.git
cd WaveGuardClient
pip install -e ".[dev]"
pytestLinks
RapidAPI (get your API key): https://rapidapi.com/gpartin/api/waveguard
Live API: https://gpartin--waveguard-api-fastapi-app.modal.run
Interactive Docs (Swagger): https://gpartin--waveguard-api-fastapi-app.modal.run/docs
Smithery: https://smithery.ai/servers/emergentphysicslab/waveguard
Glama: https://glama.ai/mcp/connectors/com.emergentphysicslab/waveguard
License
MIT — see LICENSE.
Available Tools
3 toolswaveguard_healthA
Check WaveGuard API health, GPU availability, version, and engine status. No authentication required. Use this to verify the service is running before scanning.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses no auth needed, checks multiple statuses. No side effects expected. With no annotations, description carries burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states purpose, second gives usage. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a no-param health check. Could optionally mention return format, but not essential for usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, baseline 4. Description appropriately focuses on what the tool does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it checks health, GPU, version, and engine status. Uses specific verb 'check' for resource 'WaveGuard API'. Distinguishes from sibling scan tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'No authentication required' and recommends use before scanning. Could include when not to use (e.g., for scanning), but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_scanA
Detect anomalies in data using GPU-accelerated wave physics simulation. Fully stateless — send training data (normal examples) and test data (samples to check) in ONE call. Returns per-sample anomaly scores, confidence levels, and the top features explaining WHY each anomaly was flagged. Works on any data type: JSON objects, numbers, text, time series, arrays. No separate training step required.
Example: to check if server metrics are anomalous, send 3-5 normal readings as training, and the suspect readings as test.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| training | Yes | 2+ examples of NORMAL/expected data. These define what 'normal' looks like. All samples should be the same type and shape. More samples = better baseline (4-10 is ideal). | |
| test | Yes | 1+ data points to check for anomalies. Same type/shape as training data. Each sample is scored independently. | |
| sensitivity | No | Anomaly threshold multiplier (default: 2.0). Lower = more sensitive (flags more anomalies). Higher = less sensitive. Range: 0.5 to 5.0. | |
| encoder_type | No | Data encoder type. Omit to auto-detect from data shape. Auto-detection works well for most data. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses statelessness, single-call usage, returns per-sample scores, confidence levels, and top features. Does not mention authorization or rate limits, but for a detection tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two concise paragraphs: first states purpose and key features, second provides a clear example. No unnecessary words, 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?
Given 4 parameters and no output schema, the description is complete: explains workflow, return values, and includes an example. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with well-described parameters. The description adds overall context and example but does not significantly enhance parameter meanings beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Detect anomalies in data using GPU-accelerated wave physics simulation', specifying verb and resource. It distinguishes from sibling tools like waveguard_scan_timeseries by emphasizing it works on any data type and is the general-purpose version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes stateless one-call operation and no separate training step, with an example. Does not explicitly state when not to use, but the mention of working on any data type implies the time-series sibling is for specialized cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
waveguard_scan_timeseriesA
Detect anomalies in time-series data using GPU-accelerated wave physics simulation. Send a flat array of numeric values and a window size. The tool automatically creates overlapping windows, uses the first N as training (normal baseline), and scores the remaining windows as test samples. Returns per-window anomaly scores, confidence, and p-values.
Example: send 100 CPU-usage readings with window_size=10. The first 5 windows become training, the rest are tested.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Flat array of numeric time-series values in chronological order. | |
| window_size | No | Number of data points per window (default: 10). Smaller windows = finer resolution. | |
| test_windows | No | Number of trailing windows to test (default: auto, uses last ~40%% of windows). | |
| sensitivity | No | Anomaly threshold multiplier (default: 2.0). Lower = more sensitive. Range: 0.5 to 5.0. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses GPU acceleration, automatic overlapping windows, training on first N windows, and returns per-window anomaly scores, confidence, and p-values. It does not mention potential side effects (none expected) or resource usage, but covers core behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs: first explains purpose and algorithm, second gives an example. It is well-structured and efficient, though the example could be slightly more compact. No extra fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description must explain returns. It lists 'per-window anomaly scores, confidence, and p-values' – sufficient for an agent. It also covers input, algorithm, and example. Given tool complexity, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, so baseline is 3. The description adds significant value: explains window_size gives finer resolution, test_windows defaults to last ~40%, sensitivity range 0.5-5.0, and provides a concrete example linking parameters. This is exemplary.
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 detects anomalies in time-series data using GPU-accelerated wave physics simulation. It specifies the input (flat numeric array, window size) and explains the algorithm. It distinguishes itself from siblings like waveguard_scan by focusing on time-series analysis.
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 explains when to use (detect anomalies in time-series) and provides a concrete example (CPU-usage readings with window_size=10). It does not explicitly mention when not to use or alternatives, but the context is clear enough for agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
v3.3.0- First observed
waveguard_health - First observed
waveguard_scan - First observed
waveguard_scan_timeseries
TDQS
A4.2/5.0
Disambiguation4/5
The three tools have distinct purposes: health check, general anomaly scan for any data, and specialized time-series scan. However, the general scan also works on time-series data, creating ambiguity about which to use for time-series tasks.
Naming Consistency3/5
The naming uses a common prefix 'waveguard_', but mixes verbs: 'health' is a noun, while 'scan' and 'scan_timeseries' are verbs. This inconsistency in verb style could confuse an agent expecting a uniform pattern.
Tool Count4/5
With 3 tools, the server is minimal but covers the essential functions: verification, general scanning, and time-series scanning. It is slightly sparse but acceptable for a focused utility server.
Completeness4/5
The tool set covers the core workflow: health check, anomaly detection for general and time-series data. Minor gaps include lack of configuration or history retrieval, but the stateless design mitigates these.
Maintenance
ActivityInactive
ResponsivenessUnresponsive
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
A Model Context Protocol server for Wix AI tools
MCP server for building and testing AI agents with multi-model experimentation and insights.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceModel Context Protocol (MCP) server that gives AI assistants a safe, correct data-analyst capability over business metrics - without raw SQL improvisation.-
- AlicenseAqualityBmaintenanceDeterministic time-series statistics for AI agents. This MCP server gives any LLM agent unit-tested statistical tools — anomaly detection, changepoint detection, seasonal decomposition, stationarity/trend tests, data-quality audits, baseline forecasts — with schema-validated structured output and no arbitrary code execution.17MIT
@verlon-ai/mcpofficial
AlicenseAqualityBmaintenanceModel Context Protocol server for Verlon AI that exposes gates, logs, recommendations, and experiments as MCP tools, enabling coding agents to inspect and manage AI infrastructure natively.5144MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gpartin/WaveGuardClient'
If you have feedback or need assistance with the MCP directory API, please join our Discord server