Picătura Naturii — Catalog doTERRA (MCP)

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

With no annotations, the description must carry the behavioral burden, and it does disclose the full output surface and its boundaries, which is the main trait an agent needs here. It is silent on error behavior for an unknown SKU and does not explicitly confirm read-only semantics, but for a single-record lookup the gap is minor.

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?

Two compact sentences: the positive scope is front-loaded, then the exclusions with sibling pointers. Every clause carries information; nothing is padding.

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?

There is no output schema and no annotations, so the description correctly compensates by enumerating returned fields and boundaries. It omits any mention of failure behavior (invalid/unknown SKU) and does not explicitly state read-only status, which keeps it just short of fully complete.

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?

Schema description coverage is 100% and the single sku parameter already documents exactness and gives an example ('DO-DRO-OG'). The description's phrase 'după SKU' and 'SKU-ul exact' repeats rather than extends the schema, so the baseline 3 applies.

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?

States a specific retrieval action on a named resource ('Identitatea unui produs după SKU') and enumerates the exact fields returned (nume, url, imagine, galerie, categorii, tag-uri, brand, cod de bare). It explicitly distinguishes itself from siblings get_product_offer and get_product_content, so an agent can route without opening any schema.

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?

Gives explicit negative scope ('Fără preț/stoc', 'fără conținut editorial') and names the alternative tool for each excluded concern (get_product_offer, get_product_content). This is the when-not/alternative pattern, not merely implied usage.

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

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

With no annotations at all, the description carries the full behavioral burden. It does disclose one genuinely useful trait — missing fields are returned as null and never inferred, which stops an agent from fabricating content. However, it says nothing about read-only safety, error behavior for an unknown SKU, language coverage, or rate limits, leaving meaningful gaps for a zero-annotation tool.

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?

Two tightly packed sentences with no filler; the field inventory is front-loaded immediately after the resource statement, and the null-semantics caveat follows. Slightly dense, but every clause carries information.

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 no output schema, the description must describe return values and it does, listing the content fields and the content_extra bucket plus the null convention. For a single-parameter read tool this is nearly sufficient; only error and permission behavior remain unaddressed.

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?

Only one parameter exists and schema description coverage is 100% (the schema already documents the exact SKU with an example). The description's phrase 'după SKU' adds nothing beyond the schema, so the baseline of 3 applies.

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?

States a specific verb+resource: retrieve editorial content for a product identified by SKU, and enumerates exactly what that content covers (ingredients, usage, precautions, benefits, custom mapped fields). It is clearly separable from siblings like get_product_offer (commercial data) and search_products (discovery), though it never explicitly contrasts itself with get_product, which likely also returns product data.

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 only implied: an agent can infer it should call this when it needs descriptive/editorial text rather than pricing or search. There is no explicit statement of when to prefer this over get_product or get_product_offer, and no prerequisites (e.g., that the SKU must already exist) are given.

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

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

With no annotations provided, the description carries the full burden and does disclose a meaningful behavioral trait: the source is always WooCommerce and always current, never served from editorial cache — a freshness/authority guarantee not present in the schema. It still omits behavior for an unknown SKU, permission requirements, or latency characteristics, which keeps it short of a 5.

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?

Two compact sentences with the returned data front-loaded and the source guarantee second; no filler. Slightly dense phrasing but every clause earns its place.

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 one-parameter read tool with a fully documented schema and no output schema, the description usefully enumerates the returned fields and the data source. It would be complete with a note on what happens for a missing/invalid SKU.

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?

Schema description coverage is 100% and the single SKU parameter is fully documented with an example, so the baseline is 3. 'după SKU' merely restates what the schema already specifies without adding format or matching rules.

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 names a specific verb+resource (fetch current price and stock for a product by SKU) and enumerates the returned fields (regular/discounted price, currency; quantity, status, availability). It implicitly separates itself from content-oriented siblings via 'Sursa e mereu WooCommerce', but never names get_product or get_product_content 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: call this when you need live price/stock for a known SKU. There is no explicit when-not guidance, no stated prerequisites, and no routing to alternatives such as get_product or search_products for other lookup patterns.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the inspected facets (version, schema, mapped field count), which implies a read-only diagnostic, but it says nothing about authentication needs, rate limits, or whether it is safe/non-mutating. Adequate but incomplete for a tool with zero annotation coverage.

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?

Two compact sentences, front-loaded with what is checked and then the diagnostic use case. No filler or redundancy.

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 zero-parameter, no-output-schema diagnostic tool, the description supplies the return substance (version, schema, mapped editorial field count), which is exactly what the missing output schema would otherwise cover. Only auth/environment caveats are absent.

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 tool takes zero parameters, so the baseline is 4; there is no parameter surface the description needs to explain. It correctly avoids inventing inputs.

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?

States a specific verb (Verifică) and resource (starea Canonical API-ului Picătura Naturii) and enumerates what is inspected: version, schema, and count of mapped editorial fields. It is clearly distinguishable from the sibling product-data tools, though it never names them 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?

'Util pentru diagnostic rapid' implies a diagnostic/troubleshooting context but gives no explicit when-to-use trigger, no prerequisites, and no alternatives or when-not guidance. Usage is only implied.

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

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

With no annotations, the description must carry the behavioral burden, and it does disclose two key traits: results are restricted to public products and contain only essential (abbreviated) data, which sets expectations about completeness. It stops short of covering auth needs, no-match behavior, or pagination semantics beyond the limit parameter.

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?

Two sentences, no wasted words, with the core search capability front-loaded and the routing hint second. Nothing is padded.

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?

No output schema exists, and the description compensates by stating what the response contains (public products, essential data) and where to go for more. For a 2-parameter search tool this is nearly complete, though it omits empty-result behavior and any pagination note beyond the limit cap.

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?

Schema description coverage is 100%, so both query and limit are fully documented in the schema; the description's list of search keys mirrors the query parameter but adds no new syntax or format detail. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb (search) and resource (Picătura Naturii products), enumerates the searchable keys (name, SKU, ID, barcode), and explicitly distinguishes itself from the get_product* siblings that return full details. An agent can separate this from get_product without opening the schema.

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?

Gives an explicit escalation path: use this tool to locate a product, then call get_product / get_product_offer / get_product_content with the SKU found here. That is a clear when-to-use-this vs when-to-use-alternatives rule, not just implied context.

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