Pure Report — Neutral News

Send feedback to the operator

submit_feedback

Report a problem or request to Pure Report's operator and get a tracking ref back. Use this when the data looks wrong — a bias score or outlet lean that doesn't match the source, an event cluster mixing unrelated stories, a missing neutral writeup, a broken article — or to ask a methodology question or request a capability. Include the article_id or event_slug you were looking at; that context is what makes a report actionable. A human reads these: replies take time and are not guaranteed. Call check_feedback with the returned ref to read the reply.

Input Schema

TableJSON Schema

Name	Required	Description
`body`	Yes	The detail needed to act: what you expected, what you got, and how to reproduce it. Max 12000 chars.
`kind`	No	DEPRECATED alias for category; still accepted.
`subject`	Yes	One line, max 200 chars.
`category`	No	bug = broken or erroring; dx = developer-experience friction; data_error = wrong/miscategorised data; data_gap = missing coverage or field; feature = a capability request; question = methodology or usage; other. Defaults to bug.
`article_id`	No	Optional article the report concerns.
`event_slug`	No	Optional event slug the report concerns.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ref`	Yes
`status`	Yes
`message`	No
`how_to_check`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 3, 2026

changedInput schema / properties / body / description

Previous value: -"The detail needed to act: what you expected, what you got, and how to reproduce it. Max 4000 chars."New value: +"The detail needed to act: what you expected, what you got, and how to reproduce it. Max 12000 chars."

Changed4 schema fields changedAug 2, 2026

addedInput schema / properties / category

Added value: +{
+  "description": "bug = broken or erroring; dx = developer-experience friction; data_error = wrong/miscategorised data; data_gap = missing coverage or field; feature = a capability request; question = methodology or usage; other. Defaults to bug.",
+  "enum": [
+    "bug",
+    "dx",
+    "data_error",
+    "data_gap",
+    "feature",
+    "question",
+    "other"
+  ],
+  "type": "string"
+}

changedInput schema / properties / kind / description

Previous value: -"data_error = wrong/miscategorised data; bug = something broken or erroring; feature = a capability request; question = about methodology or usage."New value: +"DEPRECATED alias for category; still accepted."

changedInput schema / properties / kind / enum

Previous value: -[
-  "data_error",
-  "bug",
-  "feature",
-  "question"
-]New value: +[
+  "bug",
+  "dx",
+  "data_error",
+  "data_gap",
+  "feature",
+  "question",
+  "other"
+]

changedInput schema / required

Previous value: -[
-  "kind",
-  "subject",
-  "body"
-]New value: +[
+  "subject",
+  "body"
+]

AddedAug 2, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations provide only negative hints (not read-only, not idempotent, not destructive), so the description carries the burden. It adds crucial behavioral context: a human reads the feedback, replies take time and are not guaranteed, and a tracking ref is returned. This goes well beyond the schema and manages expectations appropriately.

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?

The description is a single focused paragraph that front-loads the main purpose and outcome. Every sentence earns its place: use cases, required context, human caveat, and follow-up action. There is no fluff or repetition of schema information.

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 the tool's complexity and the presence of an output schema, the description covers everything needed: what it does, when to use it, what context to provide, and what to expect. It even describes the returned tracking ref and how to use it, making the feedback loop fully transparent.

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 coverage is 100% with detailed descriptions, so the baseline is 3. The description adds value by explicitly instructing to include article_id or event_slug and explaining why ('that context is what makes a report actionable'). It does not repeat schema details for each field, but it highlights the most behaviorally important parameters.

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 opens with a clear verb+resource: 'Report a problem or request to Pure Report's operator and get a tracking ref back.' It distinguishes itself from sibling tools by naming check_feedback as the follow-up for reading replies, and by enumerating concrete feedback types (wrong bias, miscategorised events, missing writeup). This leaves no ambiguity about what the tool does.

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?

The description gives explicit 'Use this when...' scenarios, including data errors, methodology questions, and capability requests. It also tells the user what to include (article_id/event_slug) and points to check_feedback as the alternative for reading the reply, effectively providing both when-to-use and next-step guidance.

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

All Pure Report — Neutral News tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?