validate_researchValidates structured culinary research evidence by checking source declarations and metadata; it does not access pages or prove factual veracity.
Verifica declarações documentais, sem acessar páginas ou provar sua veracidade.
| Name | Required | Description | Default |
|---|---|---|---|
| batch | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| ok | Yes | ||
| issues | Yes | ||
| checked_at | Yes | ||
| limitations | Yes | ||
| semantic_review_required | No |
Changes observed during successful MCP inspections.
v1.0.0Input schema / $defs / EditorialCountryEvidence / properties / verificationAdded value: +{
+ "default": "pending",
+ "description": "Qualificação declarada da relação editorial com o país; exige revisão semântica das evidências.",
+ "enum": [
+ "confirmed",
+ "pending"
+ ],
+ "title": "Verification",
+ "type": "string"
+}Input schema / $defs / SourceEvidence / properties / provenance_origin / descriptionAdded value: +"URL HTTP(S) da publicação original da receita, usada para identificar republicações; não informe descrição em prosa."Input schema / $defs / SourceEvidence / properties / provenance_origin / formatAdded value: +"uri"Input schema / $defs / SourceEvidence / properties / provenance_verificationAdded value: +{
+ "default": "pending",
+ "description": "Qualificação declarada da origem e da independência editorial; exige revisão semântica das evidências.",
+ "enum": [
+ "confirmed",
+ "pending"
+ ],
+ "title": "Provenance Verification",
+ "type": "string"
+}v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this by stating the tool does not access pages or prove veracity — useful confirmation that validation is purely over supplied declarations. However, it says nothing about what happens on failure, whether validation is blocking, or what criteria the checks apply, so value beyond annotations is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the verb and with zero filler. It is efficient, though the terseness is partly under-specification rather than disciplined compression.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool whose schema is a deeply nested research batch (sources, queries, tracks, reformulations, provenance evidence), a single sentence leaves the agent without the batch semantics, validation criteria, or placement in a research pipeline. An output schema exists, so return values need not be explained, but the input-side and workflow context are conspicuously missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single `batch` parameter is undocumented at the top level (0% schema description coverage per the signals). The description adds no meaning about what a batch must contain, that it holds up to 100 sources and queries, or how the seven-source expectation from the title relates to it — the agent must infer everything from the nested $defs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a verb ("Verifica") with an object ("declarações documentais"), so the basic action is graspable, but "documentary declarations" is vague — nothing indicates it validates a research batch of sources (the title mentions seven source-recipes, the description does not). It also gives no signal distinguishing it from the sibling validate_delivery or plan_research.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this tool, what preconditions must hold, or which alternative to use instead. The only guidance is negative scope ("sem acessar páginas ou provar sua veracidade"), which hints the tool must be invoked after sources are gathered but never says so explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.