Leafsight

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

While operational hints (readOnlyHint, destructiveHint) are covered by annotations, the description adds significant behavioral context by listing the contents of the response, such as 'what it looks like, common causes, what to do first, and its sources.' This gives the agent a richer expectation of the data provided.

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 tool definition is highly concise and well-structured. It front-loads the core action and content description, efficiently linking the tool's function to its required input (slug from search_guides) without any fluff.

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 with only two parameters, the definition is exceptionally complete. It covers the operational constraints (no sign-in), the input dependency (search_guides), and the detailed content of the expected output.

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?

Since the schema description coverage is 100%, the parameter semantics are already highly defined by the structured data. The description does not introduce new parameter meaning but rather contextualizes the type of data the parameters will access.

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 clearly identifies the resource (LeafSight plant problem guide) and the action (Read... in full), distinguishing it from other potential plant interaction tools. It specifically instructs the user on the necessary prerequisite data source ('Use a slug from search_guides').

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 definition provides critical usage context by stating 'No sign-in needed' and mandates that the slug must originate from 'search_guides.' This clear prerequisite knowledge guides the agent's workflow effectively.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context — and it does, disclosing the sign-in requirement and the 'as available in the user's app' caveat that some sections may be absent. It does not discuss what happens for an invalid or inaccessible plant_id.

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, both information-dense: the first front-loads the return contents that matter most for selection, the second carries the prerequisite and auth constraint. No filler or redundant restatement of the title.

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 carries the burden of describing the return payload, and it does so section by section, plus the auth prerequisite. Minor gaps remain around behavior on an unknown ID or partial data, but the essentials for a correct call are present.

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?

There is a single parameter and schema description coverage is 100%, with the schema already stating 'The plant_id from list_my_plants.' The description repeats that provenance verbatim, adding no format, length, or failure-handling detail 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?

The description names a single resource ('One saved plant') and then enumerates its exact contents: details and notes, recent assessments with care steps, next check-in, and active care tasks. That enumeration separates it from siblings like get_upcoming_checkins and get_result, which cover only one slice each, so an agent can pick the right tool without opening schemas.

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 gives a concrete routing instruction — obtain the plant_id from list_my_plants — which tells the agent the required preceding call. It stops short of stating when to prefer this over get_result or get_upcoming_checkins when the agent already has an ID, and gives no when-not guidance.

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?

The annotations already establish readOnly, idempotent and non-destructive behavior, so the description's job is additive — and it does add the authentication requirement and the caveat that fields are only present 'as available in the user's app', warning the agent that some of the listed fields may be absent. It does not describe behavior on an invalid or foreign result_id, which is the remaining 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?

Two sentences, zero filler: the returned content is front-loaded, then the identifier source and the auth prerequisite. Every clause carries information an agent needs before calling.

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 compensates well by enumerating the returned fields and flagging their optionality. Auth is stated and the id source is stated; the only missing piece is not-found/invalid-id behavior for a read-by-id 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 100% and the single parameter's schema text already says where result_id comes from. The description repeats that provenance rather than adding format, length or validity constraints, 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?

The description names a specific resource ('one past assessment from the user's account') and enumerates exactly what it carries: likely problem, severity, symptoms, causes and care steps. That content profile separates it cleanly from get_plant (plant record) and get_guide (care guide) without needing to open 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?

It tells the agent precisely where the required identifier comes from ('a result_id from list_my_plants or get_plant'), which is the key routing instruction for a by-id lookup, and adds a precondition ('Requires the user's Leafsight sign-in'). It stops short of explicit exclusions, e.g. whether a missing or unowned result_id errors versus returns empty.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the description is free to add real context — and it does: sort order, the overdue/due-today/upcoming status marking, and the Leafsight sign-in prerequisite. Return shape and whether the list can be empty are not covered, keeping it off 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?

Three short sentences, front-loaded with what is returned and in what order, then the optional flag, then the auth prerequisite. Nothing is redundant and no sentence could be dropped without losing 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?

For a zero-required-parameter read tool with rich annotations and no output schema, the description supplies the ordering, status vocabulary and auth requirement an agent needs. Only the return shape remains implicit, which is a minor gap at this complexity.

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 boolean is already documented as 'Also list watering, treatment and other care tasks.' The description restates this in near-identical terms, adding only the 'include_other_care' naming context, 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?

The description names the exact resource ('scheduled plant check-ins') and its ordering and status treatment ('soonest first, marked overdue, due today or upcoming'), which is enough to separate it from get_plant and list_my_plants. It lacks an explicit verb such as 'list' and never names a sibling outright, so it stops short of a 5.

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 only explicit routing guidance is for the flag: 'Set include_other_care to also list watering and treatment tasks,' which tells the agent when to toggle it. There is no statement of when to call this versus get_plant or list_my_plants, so usage is largely implied by the resource name.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety is covered. The description adds value beyond them by disclosing what is actually returned – each plant with its latest assessment and next check-in date, plus recent results not filed under any plant – and by flagging the sign-in requirement. Ordering, pagination or empty-account behavior are not addressed.

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?

It is a single front-loaded sentence that leads with the action and then the payload, with no filler. It is dense but every clause carries information; the only mild cost is that the trailing clause about unfiled results needs a second read.

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 carries the burden of describing return values, and it does so concretely. Combined with the annotations covering the safety profile, an agent has enough to invoke it correctly; only edge cases such as an empty plant list or sorting are unstated.

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 nothing for the description to disambiguate at the argument level. The only behavioral constraint, the required sign-in, is stated in prose, which is the right place for it.

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 opens with a specific verb and resource ("List the plants saved in the user's Leafsight account") and then enumerates the payload: latest assessment, next check-in date, and unfiled results. That scope implicitly separates it from get_plant/get_result, which return single records, but it never names those siblings, so the differentiation is left to inference.

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 makes the retrieval context clear (the user's own account) and gives one prerequisite, the Leafsight sign-in. It never says when to prefer this over get_plant or get_upcoming_checkins, and gives no exclusions, so the agent must infer routing from the sibling names alone.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: the return shape (titles, summaries, askleafsight.com links) and that no sign-in is required — both are things the annotations cannot convey. It does not mention result limits or pagination, which is the only remaining behavioral 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?

Three short sentences, front-loaded with the action and resource, then usage, then return shape. The parenthetical example list is somewhat long but earns its place by teaching query granularity and disambiguating scope. No filler or restated annotation fields.

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 only two fully documented parameters, no output schema, and annotations covering the safety profile, the description supplies everything an agent needs: what it searches, when to use it, what comes back, and that no auth is needed. Return values are described inline precisely because no output schema exists.

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%, with both the free-text query and the language enum documented in the schema, including an example query string. The description adds no additional semantics about query syntax, matching behavior, or how language interacts with the query text, 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?

The description opens with a specific verb and resource ("Search Leafsight's plant problem guides") and enumerates the covered domain — symptoms, pests, diseases, care mistakes — with concrete examples like root rot and powdery mildew. It implicitly separates itself from get_guide by scoping itself to "general questions about a plant symptom," but never names the sibling or contrasts the two retrieval paths 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?

"Use for general questions about a plant symptom" gives a clear positive trigger condition, and the examples show the granularity of query expected. There is no guidance on when NOT to use it (e.g., when the user already has a specific guide, in which case get_guide would apply), so it stops short of an explicit routing rule.

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