MCP server that connects to the Bigeye Datawatch API and exposes resources and tools for interacting with data quality monitoring, issues, metrics, lineage, and AI agent tracking.
The Bigeye MCP server has 26 tools with basic structure, but significant quality gaps. Most tools have short descriptions (average ~60 chars), lack comprehensive parameter documentation, and omit output schema definitions. Naming is generally sound (verb_noun pattern), but parameter descriptions are sparse or missing contextual detail. No tool annotations (readOnlyHint/destructiveHint) are present despite clear read vs. write distinctions. Error handling guidance is minimal. While the core API integration appears functional, the tool definitions lack the rigor expected of production-grade agent tools.
Analyze data lineage and dependencies
Check the health of the Bigeye API and server configuration
Create a new data quality metric
Create a tag for Bigeye entities
Delete a metric
Delete a tag from an entity
Generate AI-powered resolution steps for an issue
Missing output schema documentation for all tools. While input schemas are partially specified, return types and response fields are not documented in tool definitions. This forces LLMs to guess what data structure they will receive.
Minimal parameter descriptions. Most complex parameters (e.g., 'parameters' object in create_metric) lack type hints, constraints, or usage guidance. Parameters object types are declared as 'object' without nested schema definition.
No tool annotations for risk classification. Despite Risk field being present (READ_ONLY, WRITE, DESTRUCTIVE), these are not encoded in tool definitions as toolAnnotations (readOnlyHint, destructiveHint). LLMs cannot infer retry-safety or state-modification from raw names alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Get list of columns in a table
Fetch the currently authenticated user from Bigeye
Get detailed information about a specific issue
Get additional resolution information for an issue
Fetch resolution steps for a specific issue
Query and filter data quality metrics
Get list of schemas in a data source
Get detailed information about a specific data source
Get list of data sources
Get list of tables in a schema
Query and filter data quality issues from Bigeye
List all available resources for quick access to frequently needed data
List all tags for a given entity type
Merge multiple issues into a single incident
Read data from a specific resource
Search for entities across Bigeye
Track data lineage and dependencies accessed by AI agents
Update the status and description of an issue resolution step
Update an existing metric
Overly generic or short descriptions. Many tools have descriptions under 60 characters (e.g., 'Get list of data sources', 'Get detailed information about a specific data source'). These lack context on WHEN to use the tool or WHY it differs from similar tools.
No error handling or recovery guidance. Tool descriptions do not explain what errors are possible, how to interpret them, or what the LLM should do when a call fails (retry vs. ask user vs. unrecoverable).
Inconsistent parameter naming across related tools. 'list_issues' accepts 'statuses', 'schema_names', 'table_names' (plural array forms), but 'get_schemas' takes 'source_id' (singular). Inconsistent convention increases LLM confusion when chaining tools.
Generic 'object' parameters without nested schema. 'track_agent_lineage' entities parameter and 'create_metric'/'update_metric' parameters fields are typed as object but lack nested property definitions. LLMs cannot validate or construct these inputs.
Missing pagination guidance for list tools. 'list_issues' accepts page_cursor and page_size, but descriptions don't explain cursor semantics, default limits, or maximum results. This invites LLMs to request unreasonable page sizes.