Garden Agent Platform

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that paid content is excluded, which is a meaningful filter. However, it does not disclose what fields are returned, whether the list is paginated, ordered, or filtered by any other status (e.g., active vs. draft). For a list operation with no output schema, this is a significant gap.

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?

The description is a single, front-loaded sentence that immediately states the action and scope. The exclusion of paid content is provided in a second short phrase. There is zero redundancy or unnecessary text, making it appropriately concise for its simple purpose.

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?

Given the absence of annotations and an output schema, the description should explain what the tool returns (e.g., a list of product summaries, full objects, or just IDs). It only states what is excluded (paid content), not what is included. Also, it doesn't mention any ordering, pagination, or limit behavior. For a list tool, this is incomplete from an agent's perspective.

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 has zero parameters and the schema covers 100% (though empty), so no parameter documentation is needed. The description does not add parameter-specific meaning, but with no parameters, this is a baseline score of 4, reflecting that the schema is complete and the description doesn't need to compensate.

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 states a clear verb ('List') and a specific resource ('explicitly published Garden Agent products'). It also clarifies a key exclusion: paid content is not returned, which helps differentiate it from paid product readers. However, the term 'explicitly published' is somewhat vague, and it doesn't explicitly distinguish itself from search_products or read_free_product beyond the list-vs-single distinction.

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?

The description provides no guidance on when to use this tool over its siblings. It does not mention alternatives like search_products for filtered queries or read_free_product for single-item retrieval, nor does it state any prerequisites or conditions for use. The implied purpose is to list published products, but no explicit routing or exclusion criteria 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?

No annotations are provided, so the description carries the burden. It usefully conveys that the operation is a read of public data, implying no mutation and likely no authentication. However, it does not disclose error behavior, access restrictions, or what happens if the product does not exist.

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, well-structured sentence that front-loads the action and resource, then lists returned fields. No filler or repetition.

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?

The description is adequate for a minimal single-parameter read, but it omits the critical relationship to read_free_product and read_paid_product, and does not explain when preview is the appropriate choice. With no annotations or output schema, this leaves an agent uncertain about tool selection and expected behavior.

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 0%, and the description never mentions product_id or how to identify the product. While the schema defines length constraints, the semantic meaning of the identifier and its role are left undocumented, which the description should compensate for.

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 states a clear verb ('Read') and a specific resource ('one product's public metadata, summary, version hash, price, and license'), making the core purpose evident. However, it does not distinguish preview_product from the sibling tools read_free_product and read_paid_product, which also appear to read a single product.

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?

No guidance is given about when to use this tool versus read_free_product, read_paid_product, list_products, or search_products. The sibling names suggest a meaningful distinction, but the description leaves the selection entirely to inference.

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 carries the full burden. It conveys that the operation is a read and tied to a public snapshot, but it does not mention authentication needs, error behavior, return shape, or the role of expected_hash.

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?

The description is a single focused sentence with no filler and front-loads the key action and scope. It is concise without being a tautology, though it could safely add a bit more detail without losing clarity.

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?

Given there is no output schema and no annotation coverage, the description leaves important invocation details unspecified: parameter semantics, return contents, and selection criteria relative to sibling tools. It is adequate only as a high-level label, not a complete operational guide.

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 0%, so the description must explain parameter meaning, but it does not mention product_id or expected_hash at all. The agent has to infer that product_id identifies the product and that expected_hash is likely a consistency check.

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 uses a specific verb ('Read') and resource ('one product marked free') plus a scope qualifier ('current public snapshot'). It distinguishes itself from read_paid_product, though the relationship to preview_product is not explicit.

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 guidance on when to choose this tool over list_products, search_products, preview_product, or read_paid_product. Usage is only implied by the name and the phrase 'marked free'.

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 carries the behavioral burden. It discloses the critical side effect: exactly 0.01 USDT0 is paid on the configured Tempo network before reading. It does not detail what happens on failed payment, whether the payment is reversible, or what output format results, but the most important behavioral trait is disclosed.

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 tight sentence that front-loads the payment action and its exact amount/network, then the read action. Every word contributes, and there is no 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?

The description captures the payment side effect and basic operation, but with no output schema or annotations it leaves gaps: the purpose of expected_hash is unexplained, prerequisites such as account balance or prior setup are absent, and no failure behavior is described. It is adequate for a basic call but not fully complete for a payment-triggering tool.

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 0%, and the description names no parameter. 'Read one paid product' only weakly implies product_id as the selector, and it gives no meaning or usage guidance for expected_hash beyond the schema's 64-hex pattern. The description does not compensate for the missing schema descriptions.

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 states a specific verb ('read') and resource ('one paid product'), and the payment precondition clearly distinguishes it from sibling read_free_product. The paid/free contrast makes the tool's purpose crisp.

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?

It clearly implies use when the user needs a paid product rather than a free one, and it emphasizes that a payment must occur first. It does not explicitly exclude read_free_product by name, but the paid/free distinction gives clear context with no contradiction.

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 disclosure burden. It does reveal that paid content is not read and only metadata fields are searched, which is useful. However, it does not mention matching behavior, result limits, sorting, or error conditions.

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 clean sentence that front-loads the action and target, with no wasted words. Every phrase contributes: what is searched, what fields, and what boundary is respected.

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 single-parameter search tool, the description covers purpose, scope, and the paid-content boundary, while the schema handles the input constraint. The lack of an output schema leaves the return shape unspoken, but the tool name and described search fields make it predictable.

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 schema provides only a required 'query' string with length bounds and no description. The tool description compensates by explaining what the query searches across (IDs, titles, summaries) and what it does not access, giving the parameter operational meaning despite 0% schema coverage.

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?

Description states a specific verb ('Search') and precise resources ('product IDs, titles, and human-written summaries'). The qualifier 'without reading paid content' separates it from read_paid_product and other content-fetching siblings, making the purpose unmistakable.

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?

The description implies this is the query tool for product metadata, but it does not explicitly contrast with list_products or read_free_product. An agent can infer appropriate use, but there are no when-to-use/when-not-to-use statements.

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