Reecopedia

Report an answer issue

report_answer_issue

File a report that an answer built from Reecopedia search results was wrong, misleading or incomplete. The report (the query and the reason, nothing else — no personal data) enters Reecopedia's human curation queue and is reviewed weekly to correct the corpus and retrieval quality.

THIS TOOL WRITES. Use it only when the user has asked for the problem to be reported, and send only the original query and the reason the user gave. Do not call it on your own initiative and do not add anything the user did not say.

ANNOTATIONS — why each hint is set the way it is, based on this tool's actual behaviour. readOnlyHint=false: this is the only tool that writes; it appends one record (the query and the reason, nothing else) to Reecopedia's internal human curation queue. destructiveHint=false: the write is append-only; it modifies and deletes nothing that already exists. idempotentHint=false: two calls can append two records — de-duplication covers only an identical query+reason pair within the same hour. openWorldHint=false: the record stays in the internal queue; it is not sent anywhere outside Reecopedia.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes	The original search query the reported answer was built from.
`reason`	Yes	The user's reason why the answer was wrong (min 10 chars — e.g. which fact was incorrect, which source was misread, what was missing).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 7, 2026

changedInput schema / properties / query / description

Previous value: -"The original search query the bad answer was built from."New value: +"The original search query the reported answer was built from."

changedInput schema / properties / reason / description

Previous value: -"Why the answer was wrong (min 10 chars — e.g. which fact was\nincorrect, which source was misread, what was missing)."New value: +"The user's reason why the answer was wrong (min 10 chars —\ne.g. which fact was incorrect, which source was misread, what was\nmissing)."

AddedAug 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description goes well beyond the annotations by explaining the append-only nature, that no personal data is sent, that the report enters a human curation queue, and that de-duplication applies only to identical query+reason pairs within the same hour. It aligns with all annotations and adds meaningful behavioral context.

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 efficiently organized into purpose, usage rule, and annotation explanation. Every sentence carries operational or safety guidance, and there is no padding or redundant restatement of the tool name.

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?

Together with the schema and annotations, the description fully covers when to call, what data gets sent, what side effects occur, and privacy constraints. Nothing an agent needs in order to invoke this tool correctly is missing.

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?

The input schema already documents both parameters clearly and with 100% coverage, including that query is the original search query and reason has a 10-character minimum. The description reinforces the 'query and reason, nothing else' constraint, but it does not add much new per-parameter meaning beyond what the schema provides.

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 names a specific verb and resource: 'File a report' for answers built from Reecopedia search results that are wrong, misleading, or incomplete. It also differentiates this tool from the sibling search/read tools by explicitly stating it is the only tool that writes, making its purpose unambiguous.

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 explicitly states when to use the tool: only after the user has asked for the problem to be reported, and never on the agent's own initiative. It also gives clear exclusions: send only the original query and reason, and do not add anything the user did not say.

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

All Reecopedia 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?