validate_deliveryVerify delivery batch, profile, inventory, and declared review for consistency without certifying food safety.
Confere lote, perfil, inventário e revisão declarada, sem certificar segurança alimentar.
| Name | Required | Description | Default |
|---|---|---|---|
| delivery | 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, so safety is covered. The description adds one genuinely useful caveat beyond annotations: passing this check does not certify food safety, which prevents over-claiming downstream. It does not disclose what happens on failure (exception vs. issue list) or which rules are enforced, though an output schema exists that may carry results.
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?
A single dense sentence with zero filler, and the checked items are front-loaded ahead of the scope caveat. It is arguably too terse for a deeply nested payload, but nothing in it is wasted.
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?
With a large nested input schema, an output schema, and read-only annotations, the description supplies only the subject list and one disclaimer. For a validation gate whose entire value is knowing which constraints are enforced, this leaves the agent guessing about acceptance criteria and failure semantics.
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?
Top-level schema description coverage is 0%, but the description partially compensates by naming the four things being checked (batch, profile, ingredients, declared review), which maps onto the key Delivery fields. Beyond that mapping it adds no semantics for the deeply nested Profile, ResearchBatch, or SourceEvidence structures, leaving the agent to read the schema.
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?
"Confere lote, perfil, inventário e revisão declarada" gives a specific verb (confere/validates) plus the concrete artifacts it inspects, and the trailing "sem certificar segurança alimentar" bounds the purpose. It is clearly a delivery-payload validator, distinguishable in intent from validate_research, though it never names a sibling explicitly.
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?
Usage is implied rather than stated: the agent can infer this validates a Delivery object, presumably before final output. There is no explicit when-to-use, no ordering guidance relative to validate_research or plan_research, and no statement of what a failing validation means for the workflow. The scope exclusion is the only real guidance offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.