Skip to main content
Glama

report_data_issue

Report a data-quality problem you found in an autario dataset or chart (World Bank, FRED, Eurostat, OECD, WHO, IMF, ECB, US Census, SEC or any other publisher in the catalog), so the engine can fix it. Use this during a QA pass when you spot: a dataset that looks truncated / only partially ingested (far fewer rows than the source should have), a unit that contradicts the value range (unit "%" but values in the thousands), nonsensical or wrong column/series labels, an all-identical (zero-variance) column, a published chart that is misleading or plots the wrong series, or data that looks stale. ALWAYS attach the concrete numbers you observed in evidence (e.g. the row count you saw vs. what you expected, the unit, a few sample values) | findings without evidence are not actionable. The engine routes safe types (partial_ingest_suspected, stale, broken_time_col) to an automatic re-ingest on the next refresh; everything else goes to a human review queue. Reporting the same unresolved issue again never creates a duplicate row: it is COUNTED on the existing finding (occurrences in the response), and once the same issue has been reported three times it is escalated into the human review queue. So a repeat is safe, but it is not silent | only report again if you observed the problem again. Requires authentication.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailNoOne-sentence human-readable summary of the issue.
evidenceNoThe concrete numbers backing the finding, as a JSON object. Examples: {"rows_seen": 500, "rows_expected": 15000, "source": "World Bank API has ~15k country-year rows"} or {"unit": "%", "value_range": [120, 9800]}. Required for an actionable finding.
severityNoHow bad it is for end users. high = wrong/misleading numbers shown publicly. Default medium.medium
dataset_idNoThe UUID of the dataset the issue is about (from search_datasets / get_dataset_info). Omit only for a chart-level issue with no single owning dataset.
finding_typeYesWhat kind of problem. partial_ingest_suspected = fewer rows than the source has (truncated). stale = data older than it should be. broken_time_col = every row shares one date / a vintage column is used as time. unit_mismatch = declared unit contradicts the numbers. label = wrong/nonsensical column or series names. wrong_series = the wrong or a duplicate series is shown. confusing_chart = a published chart is misleading to end users. zero_variance = all values identical. engine_gap = a systematic parser/engine bug. moved/dead_source = source URL changed or returns 404.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (readOnly=false, idempotent=false) by disclosing deduplication semantics (no duplicate rows, occurrences counter, escalation after three reports), routing of safe types to automatic re-ingest, and the authentication requirement. This is exactly the kind of behavioral nuance an agent needs.

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?

Dense and front-loaded; every sentence carries information. The logical flow is strong: purpose → trigger conditions → evidence requirement → routing → repeat behavior. Slightly wordy and leans on ALL CAPS emphasis in three places, but nothing is wasted.

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?

For a complex reporting tool with routing, deduplication, and escalation, every behavioral aspect an agent needs is covered: evidence requirement, safe-type routing, duplicate handling, escalation threshold, and auth. No output schema exists, so the mention of `occurrences` in the response is sufficient return-value guidance.

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?

Schema already documents all 5 params at 100% coverage, so baseline is 3. The description adds operational value by mandating concrete numbers in `evidence` with examples, and by mapping real-world symptoms to finding_type categories (partial_ingest, unit_mismatch, zero_variance, etc.), which clarifies usage beyond the schema's field descriptions.

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?

States a specific verb (Report) + resource (data-quality problem in a dataset or chart), enumerates concrete issue categories, and is unmistakably distinct from query/read siblings like get_engine_report or query_dataset. The first sentence alone gives a complete mental model.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly scopes the tool to 'during a QA pass' and lists five concrete trigger conditions (truncated dataset, unit contradiction, bad labels, zero-variance column, misleading chart, stale data). It even provides a when-not-to guideline: 'only report again if you observed the problem again.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources