Daylily Catalog

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

Annotations already cover idempotency and non-destructiveness, so the repeated-call sentence adds little, but the description contributes real behavior beyond them: a connected account, the catalog:write OAuth scope, and account tier limits. The tier-limit statement is not elaborated, which keeps it from 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?

Four short sentences, front-loaded with the operation and scoping constraint, with no filler. 'Account tier limits apply' is the one vague clause that could have been made actionable.

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 two-parameter mutation with an output schema and full annotation coverage, the description supplies the missing essentials: auth scope, account requirement, ownership constraint, and idempotent behavior. Only the specifics of the tier limits and the parameter level are thin.

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 two parameters are bare strings with only length bounds. The description compensates partially by implying both IDs must reference owned resources, but adds no format, sourcing, or failure semantics for listingId/listId.

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 and resource ('Add one owned listing to one owned list') and constrains scope with the ownership qualifier, which separates it from sibling mutators like link_listing_to_cultivar and update_list. An agent can identify the operation 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?

Preconditions are implied (the listing and list must already be owned/created), but there is no explicit when-to-use guidance and no routing away from adjacent tools such as link_listing_to_cultivar or update_listing. The agent must infer the appropriate moment to call this.

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?

Beyond the annotations, it discloses real operational context: the non-Pro cap of one list, the OAuth scope required, and the idempotency contract of reusing requestId on retry, which meaningfully extends the terse idempotentHint flag. It stops short of describing failure behavior when the tier limit is hit or what a duplicate requestId returns, leaving some ambiguity for a mutation the agent may retry.

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?

Four short sentences, front-loaded with the action and followed by constraints and prerequisites in a sensible order. The closing "Account tier limits apply" is largely redundant with the earlier non-Pro cap sentence and could be dropped without loss.

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 flat three-parameter creation tool with an output schema (so return values need no explanation) and annotations covering the safety profile, this covers actionable prerequisites and the idempotency contract well. The main gap is the absence of any guidance on the title/description fields and on the expected outcome when the account tier limit is already reached.

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 carry parameter meaning, and it does so only for requestId, explaining uniqueness and retry reuse semantics that the UUID format field cannot convey. The title and description parameters get no treatment at all, so the agent must rely entirely on min/maxLength constraints for two of three params.

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?

"Create one list" states a specific verb and resource, and the singular "one list" plus tier-limit sentence makes the cardinality constraint clear. It does not explicitly distinguish itself from sibling mutators like daylily.create_listing or daylily.update_list, but the noun 'list' versus 'listing' is discernible from the name itself.

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 supplies prerequisites (connected account, catalog:write scope) and an account-tier constraint, which tells the agent when the call will succeed. It never says when to prefer this over alternatives such as daylily.update_list, nor does it state what to do if the account is already at its list limit.

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 write, open-world, idempotent, non-destructive behavior, so the description's job is to add context — and it does: the 25-listing cap for non-Pro accounts (including hidden listings), the connected-account prerequisite, and the catalog:write OAuth scope. The remaining gap is that failure behavior and the cost of hitting the tier limit are not described.

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?

Five short sentences with the purpose front-loaded and each sentence carrying distinct information (privacy flag, idempotency key, auth, limits). The closing "Account tier limits apply" is mildly redundant with the earlier 25-listing sentence.

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?

An output schema exists, so return values need not be explained, and the description covers auth, quota, and idempotency well. However, for a 7-parameter create call with zero schema-level parameter descriptions, leaving five fields undefined is a meaningful completeness gap.

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% across 7 parameters, so the description carries the full burden. It explains only hidden and requestId (including the non-obvious retry semantics); title, price, description, privateNote, and cultivarReferenceId get no meaning, format, or constraint guidance at all.

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?

"Create one listing" gives a specific verb and resource, and the singular framing distinguishes it from the sibling create_list (a different resource) and update_listing. It does not explicitly name an alternative tool, but the resource-level distinction is clear enough to pick correctly.

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 gives concrete operational guidance: use hidden=true for private drafts versus hidden=false to publish, and reuse requestId when retrying the same creation. It does not cover when to prefer update_listing over recreating, but the create-vs-retry context is well specified.

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=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds that only 'public' records are returned, which is useful behavioral context, but it omits what happens when neither identifier matches or when both are supplied (the schema's oneOf permits either, not both).

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 tight sentences with no filler, and the positive trigger is front-loaded ahead of the exclusion. Efficient, though it could have spent one more clause on identifier format rather than stopping where it does.

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?

An output schema exists, so return values need not be described, and the safety profile is carried by annotations. The definition is nearly complete for a two-key lookup; the remaining gap is the input format of normalizedName and the ambiguity of supplying both keys at once.

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 compensate; it does name both parameters and establishes that either identifier is an exact-match lookup key, which is real added meaning. However, it says nothing about how normalizedName should be normalized or what shape a cultivarReferenceId takes, leaving the caller to guess the input format.

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 and resource ('get the exact public cultivar record') and scopes it to the public catalog, which immediately distinguishes it from mutating siblings like link_listing_to_cultivar or update_listing. The named sibling search_cultivars further pins down its role.

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 trigger condition (user already has a cultivarReferenceId or normalizedName), an explicit exclusion ('Do not use it for fuzzy search'), and the exact alternative to call instead (daylily.search_cultivars first). This is the strongest form of routing 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds real value beyond them: the OAuth auth requirement and the fact that the returned URL is a 'resolved dashboard image URL' rather than a raw asset path. It doesn't discuss error behavior for unknown IDs, which keeps it below 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 with the core action front-loaded, followed by prerequisite routing and the auth note. Every sentence earns its place and nothing is redundant.

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 an output schema present, the description needn't explain return values, and annotations cover safety; the remaining essentials (scope, auth, ID discovery path) are all stated. The single omission is the semantics of referenceId, which is a modest gap for a three-required-parameter 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%, so the description must carry the burden, and it only partially does. It clarifies that 'type' means listing vs. profile (matching the enum) and that imageId is an image identifier discoverable via list_images, but it never explains that referenceId is the ID of the owning listing or profile — the one parameter most likely to be misconsumed.

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 and resource ('Get one owned listing or profile image by ID') plus the scope ('owned') and a notable output detail ('resolved dashboard image URL'). It is unambiguously distinguishable from siblings like list_images (which returns many) and get_listing (which returns the parent resource).

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?

Explicitly routes the agent to the prerequisites: it names three sibling tools (get_listing, get_profile, list_images) as the way to obtain image IDs first, and adds the OAuth requirement. The only small gap is that it doesn't spell out when not to use it, but the required-ID prerequisite covers the main failure mode.

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=true, destructiveHint=false, and openWorldHint=false, so safety is covered by structured data. The description adds meaningful context beyond that: the OAuth requirement, which is an auth prerequisite not visible in the annotations. It says nothing about failure modes for an invalid id, which keeps 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, front-loaded sentences: purpose first, sibling routing second, prerequisite last. No redundant restatement of the tool name or filler.

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?

A one-parameter read tool with an output schema, read-only annotations, and an explicit auth note is nearly fully specified. The only remaining gap is guidance on where the id comes from or what happens when it is invalid, which is a minor omission for a tool this simple.

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% for the single `id` parameter, so the description carries some burden and does indicate the value identifies one list. However, it adds no format, source, or example for the id (and the sibling reference uses the name "listId" while this tool's parameter is `id`), so it only marginally compensates for the undocumented 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?

States a specific verb and resource ("inspect one list by id") and enumerates what is returned (description, status, dashboard link). The singular scope plus the pointer to list_listings for members clearly separates it from sibling list/listing tools.

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 trigger ("when the signed-in user asks to inspect one list by id") and names the alternative tool with the argument to use for the adjacent operation (paged members via daylily.list_listings with listId). This is exactly the routing an agent needs.

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 cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantive behavior on top: a hard cap of 100 list memberships, a listsNextCursor truncation signal, an imagesHasMore flag, and an OAuth requirement. These are operational traits an agent cannot infer from the annotations or schema.

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 trigger condition is front-loaded, followed by compaction behavior, then follow-up calls, then the negative routing rule. Every sentence carries distinct information — no repetition of the schema or annotations.

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?

Covers trigger, scope, truncation handling, and auth for a single-parameter read tool. Even though an output schema exists and return values needn't be spelled out, the description still names the payload shape and the two continuation paths, leaving nothing an agent needs in doubt.

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 coverage is 0% and the single 'id' property is undocumented, but the description compensates by stating the value identifies 'one exact listing' — implying an id lookup rather than a name or slug match. It stops short of stating format or where the id comes from, so it is not fully complete.

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?

Opens with a specific verb and resource ('inspect one exact listing by id') and immediately enumerates what the record contains: private notes, images, linked cultivar data, and list memberships. It is clearly distinguishable from daylily.list_listings and the search siblings, which the description names 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?

Gives a positive trigger ('when the signed-in user asks to inspect one exact listing by id') and an explicit exclusion ('Do not use this for search or list expansion when daylily.list_listings can return the needed records in one paginated call'). It also routes follow-up work to daylily.list_lists and daylily.list_images with the exact parameters to pass.

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 establish readOnly, non-destructive, closed-world, so the safety profile is covered; the description adds OAuth requirement, the fact that story content is read-only via remote MCP, and the imagesHasMore pagination signal. Those are real behavioral facts not present in annotations or schema.

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?

Front-loaded with the when-to-use condition, then editing route, then pagination fallback. Most sentences carry weight, but 'The image IDs support reorder and dashboard removal review' is vague about what the agent should actually do and could be tightened or dropped.

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?

An output schema exists, so return shape need not be explained; the description covers auth, edit-routing, and pagination follow-up. The only loose end is not distinguishing this tool from get_public_profile or list_public_profiles when the caller's intent is ambiguous.

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. It does explain how to react to the imagesHasMore output field, which is a useful cue even though the output schema defines 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?

States a specific verb-resource pair ('get_profile' for the signed-in user's own Daylily Catalog profile) and enumerates the content surfaced: storefront copy, slug, location, images, public profile content. The phrase 'their own' implicitly separates it from get_public_profile, though the sibling is never named outright.

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 a concrete trigger ('signed-in user asks about their own profile'), routes edits to open_dashboard with edit_profile_content, and routes image discovery to daylily.list_images when imagesHasMore is true. It does not say when to use get_public_profile instead, which is the other obvious alternative.

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, non-destructive and open-world behavior, so safety is covered. The description adds meaningful disclosure beyond that: only public listing details are returned, with hidden listings and private notes excluded — exactly the filtering behavior an agent must know before quoting results to a buyer.

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, front-loaded with the use case and followed by the scope restriction. No filler, no repetition of schema field text.

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 an output schema present, the description need not explain return values, and it covers lookup modes and visibility filtering. The only gap is what happens when a listing exists but is hidden — whether that yields an error or a not-found — which matters for an agent's error handling.

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 coverage is 100%, so the baseline is 3, but the description adds the relationship the schema leaves implicit: id is one lookup path and sellerSlug plus listingSlug is the alternative, not cumulative filters. That disambiguation genuinely helps an agent decide which params to populate.

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 and resource ('get one public listing') and explicitly scopes the result to public data, which separates it from siblings like get_listing (non-public) and list_public_listings/search_public_listings (plural). An agent can pick this tool 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?

It gives a clear trigger ('when a buyer asks for one public listing') and the two acceptable lookup shapes. It does not name the plural siblings as alternatives for browsing, but the singular scope is stated clearly enough to imply the boundary.

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=true and destructiveHint=false, so the safety profile is covered. The description adds a useful enumeration of what comes back (profile, public lists, images, listing/list counts), but nothing about pagination, visibility rules, or what happens for an unknown slug. Adds some value beyond annotations, not rich context.

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 tight sentences: usage condition first, payload summary second, with no redundant or filler wording. Appropriately sized for a single-parameter read tool.

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?

A simple read tool with one fully documented parameter, an output schema, and safety annotations; the description covers the selection context. The return-value sentence is partly redundant given the output schema, but nothing an agent needs to call it correctly is 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?

Schema description coverage is 100% and the single sellerSlug parameter is fully documented in the schema. The description only restates that lookup is 'by seller slug', adding no format, resolution, or fallback details beyond the schema. 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 verb and resource (get a public grower/catalog profile) and qualifies the scope as 'public', which distinguishes it from the sibling get_profile and pairs with list_public_profiles. It does not explicitly say how it differs from get_profile, so sibling differentiation is implied rather than spelled out.

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 a concrete triggering context ('when a buyer asks about a public grower or catalog profile by seller slug'), which is clear enough to select it over listing/search siblings. It stops short of naming an alternative (e.g. use get_profile for your own profile) or stating exclusions.

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 show that this is a destructive, idempotent, open-world write, and the description adds details the annotations do not: the dashboard review gate before replacing a link, the required OAuth scope, the requirement for a connected account, and tier limits. It does not describe what exactly the link operation changes, such as whether the listing's stored name or fields are altered, which would have pushed it higher.

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?

Four short sentences, front-loaded with the action, then the constraint, then the prerequisites. No filler; each sentence carries operational 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 destructive, scope-gated mutation, the description covers the danger and the access requirements well, and an output schema exists, so return values need no explanation. It is still incomplete because syncName is undocumented in both the schema and the description, so the definition leaves a required decision unexplained.

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% on all three parameters, so the description must carry the full burden, and it does not. The two IDs are at least self-explanatory from their names, but syncName is left entirely undefined; an agent cannot tell whether setting it will overwrite the listing name from the cultivar, which is a behaviorally significant gap.

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 and resource: 'Link one listing to a cultivar reference,' making it clear what the tool does. It does not differentiate itself from the sibling tool sync_listing_cultivar_name, and the parameter syncName evidently relates to that tool's purpose, so an agent cannot fully distinguish the two straight away.

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 prerequisites that matter for deciding whether a call can succeed: a connected account, the catalog:write OAuth scope, and account tier limits. It also states a precondition for replacement, namely that an existing different link must be reviewed in the dashboard first. The explanation never names when to use this tool instead of sync_listing_cultivar_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?

Annotations already cover read-only, non-destructive and closed-world, but the description adds real behavior beyond them: pages are ordered by image ID while display order comes from the order field, pagination must be followed to null, and OAuth is required. It does not mention rate limits or whether all image types/variants are included.

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?

Front-loaded with the core purpose, then pagination mechanics, then the operational caveat. Four dense sentences with little waste, though 'preparing removal review for a large legacy image set' is slightly convoluted phrasing.

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?

An output schema exists, so return values need not be explained, and the description still covers ordering semantics, pagination termination, and the auth requirement. For a paginated read-only list tool this is essentially complete, with only minor parameter naming gaps.

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 carries the burden. It clarifies the 'type' parameter through 'listing or profile' and explains cursor semantics via 'follow nextCursor until null', but leaves 'limit' and 'referenceId' (the ID of the owned listing/profile) undocumented in both schema and description.

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 and resource ('Page every image ID') plus the scope ('for one owned listing or profile'), which clearly separates it from the singular sibling daylily.get_image. It does not explicitly name the sibling tools it is not, 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?

Gives concrete usage conditions: follow nextCursor until null before reordering or preparing removal review for a large legacy image set, which implicitly points at reorder_images. It does not state exclusions (e.g., when to use get_image or get_listing instead), so it is strong context without full 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?

Beyond the readOnly/non-destructive annotations, it discloses non-obvious behavior: rows are compact, a filtered page can be empty yet still carry a nextCursor, and OAuth is required. The empty-page-with-cursor warning is exactly the kind of trait an agent could not infer from structured fields and would otherwise misread as end-of-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?

Front-loaded with the use case and pagination rule, which are the highest-value facts. A few sentences restate guidance already present in the parameter descriptions (search_cultivars then filter by cultivarReferenceId appears in both), which is mild redundancy but not harmful.

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 13-parameter read tool with an output schema, the description covers authentication, pagination, and the search-vs-detail split well. Minor omissions remain: default/max page size behavior and any result ordering are left entirely to the schema.

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 already 92%, so the baseline is 3; the description adds a useful nuance by separating 'q or title' for unlinked/legacy listing titles versus cultivarReferenceId for indexed cultivar matching. It stops short of explaining limit or the price range interplay, so it modestly exceeds the baseline rather than fully replacing 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?

Opens with a specific verb and resource ('search, filter, or page through their own listings') and immediately scopes it to the signed-in user, which separates it from list_public_listings and search_public_listings. It also names get_listing as the detail counterpart, so the agent can distinguish it from siblings 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?

Explicitly states the triggering condition ('when the signed-in user asks to search, filter, or page through their own listings') and routes to alternatives: get_listing for private notes/images/full detail, and search_cultivars first when cultivar data is needed. It also spells out the pagination protocol (follow nextCursor until null, keep the same filters).

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: OAuth is required, results are paged via cursor/listingId, and the fields returned are named. It stops short of stating result ordering or maximum page behavior, which keeps it from 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?

Five short sentences, front-loaded with the trigger, then the filter, then the return shape, then the sibling handoff, then the auth requirement. Nothing repeats the name or the annotations, and every sentence carries usable 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 three-parameter read tool, the description covers trigger, filtering, paging continuation, sibling routing, auth, and even lists the returned fields despite an output schema existing. An agent can call it correctly without further context.

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 coverage is only 33%: cursor is documented in the schema, but limit and listingId have no description there. The description compensates for the important one, explaining that listingId pages the lists that contain one owned listing, and the paging intent of limit/cursor is implied by 'page the lists'. limit's bounds are still left entirely to the schema, so it is not fully compensating.

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 and resource ('browse their catalog lists') and adds a second use ('resolve a list name to an id'), which an agent can act on directly. It is clearly distinguished from daylily.list_listings, which is named as the tool for paging a list's members.

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 trigger ('when the signed-in user asks to browse... or resolve a list name to an id') and names the alternative tool plus the condition that selects it ('Use daylily.list_listings with listId to page a list's members'). The listingId filter case is also spelled out as a usage path.

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=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact, "Returns only public listings," which tells the agent results are visibility-filtered. It says nothing about pagination behavior, ordering, or result shape, so it adds some but not rich context beyond the annotations.

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, front-loaded with the trigger condition, and the required-parameter fact comes second. The filter list is largely redundant with the schema and could be trimmed, but it does help an agent scan capabilities at a glance.

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 17 parameters, an output schema, and full annotation coverage, much of the burden is carried elsewhere, so the short description is defensible. Still missing is how this differs concretely from search_public_listings and list_public_profile_lists, and any note on paging or default result sizing, which matters for a 17-parameter list 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 94%, so the schema already explains every filter, including subtleties like the broad "q" search and the cursor paging contract. The description's filter enumeration (listId, listTitle, cultivar, color, price, photos, hybridizer, parentage, year) restates the schema without adding semantics, and it omits cursor/limit entirely. Baseline 3 is appropriate 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 (browse) and a scoped resource (one seller's public catalog or one public list), which lets an agent distinguish it from the broad sweep implied by sibling search_public_listings. It does not name that sibling explicitly, so the differentiation is inferred rather than stated.

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 this when a buyer asks to browse one seller's public catalog or one public list" gives a clear situational trigger and implicitly excludes cross-seller discovery. No explicit when-not or named alternative (e.g. search_public_listings, list_public_profile_lists) is provided, which keeps it short of a 5.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered elsewhere, and an output schema exists to describe the return shape. The description's added value is the downstream chaining hint that the returned ids feed daylily.list_public_listings, but it says nothing about edge behavior such as an unknown or nonexistent sellerSlug (empty result vs. error). That is useful but thin beyond the structured data.

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 waste, with the selection condition front-loaded before the chaining instruction. Every sentence carries information the agent needs.

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 simple read-only lookup with full parameter documentation, an output schema, and rich annotations, the description covers the trigger condition and the next step an agent should take. Nothing essential for correct invocation is 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?

There is a single required parameter with 100% schema description coverage — the schema already explains that sellerSlug accepts a public seller profile slug or user id. The description adds no format, casing, or resolution guidance beyond that, 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 and scope — public lists/collections belonging to a seller — which separates it from siblings like daylily.list_lists (own lists) and daylily.get_list (single list). It frames the purpose as answering a buyer's question rather than stating a verb directly, which is slightly less crisp than 'List public lists for a seller' but the resource is unambiguous.

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 clear trigger condition ('when a buyer asks what public lists or collections a seller has') and an explicit follow-up step ('Use the returned list ids with daylily.list_public_listings'), which is strong forward guidance. It stops short of naming alternatives or exclusions — e.g. that this is not for the seller's own private lists or for listing search (search_public_listings).

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond them: results are scoped to active public catalogs with listings, paging is bounded, ordering is by seller id, and continued paging is via nextCursor.

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, then paging, then the alternative tool. Every sentence carries distinct information and none restates the tool name.

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?

An output schema exists, so return values and cursor field naming need not be re-explained here, and the description covers scope, ordering and paging. The one remaining hole is the limit parameter's meaning and bounds, which is relevant given a maximum of 100.

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 coverage is 50%: cursor is documented in the schema, while limit has only type/default/max/min and no description. The description reinforces paging via 'follow nextCursor' and 'bounded page', but never explains what limit controls, its default, or its cap, so it only partially compensates for the gap.

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 and resource (browse active public grower catalogs) plus the return shape (bounded page of seller summaries ordered by seller id). It also names the single-profile sibling, so an agent can distinguish list-vs-get without opening either 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?

Explicitly routes the agent to get_public_profile when one grower's full profile is needed, which is the main ambiguity for this tool. It does not address when to prefer list_public_listings or search_public_listings, but that distinction is implied by the resource (profiles vs listings).

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=true and destructiveHint=false, and the description reinforces this with the non-obvious clarification that 'a link never performs the change on navigation' — important because the listed use cases involve deletion and removal wording that could otherwise be read as destructive. It adds the OAuth requirement, which annotations do not cover. It does not describe pagination or what the screen handle looks like, but with annotations and an output schema that is a minor 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?

Four sentences, front-loaded with the triggering scenario, followed by alternatives, a parameter hint, a behavioral caveat, and an auth note. Every sentence carries information; the only mild density cost is the long enumeration of removal scenarios in the first sentence.

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 navigation tool with five parameters, an output schema, and full annotation coverage, the description covers purpose, alternatives, parameter provenance, the read-only nature of navigation, and OAuth. Nothing essential to correct invocation appears missing, though the semantics of each destination enum value are left to the schema.

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 80%, so the schema already documents id, blockId, imageId, listingIds. The description adds real value for blockId by specifying its provenance ('current blockId from get_profile') and implicitly maps the destination enum values to the use cases. It adds little beyond the schema for id, imageId, and listingIds, so the baseline of 3 is appropriate.

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 establishes that this tool surfaces a specific dashboard screen for a task (photos, profile story/URL edits, removal/deletion review) rather than performing the mutation itself, and it names sibling tools (manage_listing_images, manage_profile_images) it is not. The core verb 'opens a dashboard screen' is only implied through 'needs a precise dashboard screen', so it is clear but not crisply front-loaded as verb+resource.

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 concrete triggers (adding listing/profile photos, editing story or URL, reviewing deletion/removal/unlink/list-member-removal) and routes photo-adding to manage_listing_images or manage_profile_images instead. It also states the prerequisite of passing the current blockId from get_profile. It stops short of an explicit when-not-to-use statement for the remaining destination values.

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 destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the bar is lower, yet the description still adds real context: the mutation is partial ('Other images keep their relative order'), and it requires a connected account plus the catalog:write OAuth scope. It doesn't cover failure behavior or whether all images must be supplied, which keeps it below 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 the core action and ordering semantics before the prerequisites. No redundant restatement of the tool name or 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 an output schema present and rich annotations, the description covers the mutation's partial-reorder semantics and the auth/tier prerequisites an agent needs before calling. Edge cases such as unknown or already-first image IDs and error behavior are left unstated but are minor for 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 coverage is 0%, so the description must carry the load, and it does clarify that the supplied imageIds determine placement order and that referenceId targets exactly one owned listing or profile. It never explicitly states that referenceId is the listing/profile ID matching the type enum, leaving one small gap.

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 and resource ('Place selected images first ... on one owned listing or profile') with the exact scope: a single owned listing or profile. That distinguishes it cleanly from sibling read tools like list_images, get_image, and update_listing without needing to name them.

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 supplies prerequisites (connected account, catalog:write scope, tier limits) but never states when to choose this over alternatives such as update_listing or when not to call it. Usage is implied by the verb rather than explicitly guided.

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, openWorldHint and non-destructive behavior, so the description only needs to add scope. It does: results are explicitly public reference records, not user-owned data. It does not mention result size, pagination, or what an empty result means, 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?

Three short sentences, front-loaded with the purpose, then the exclusion with its alternative, then the parameter preference. No filler and nothing repeated from the schema.

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?

An output schema exists, so return values need no explanation, and the read-only, public-only nature is covered. Only pagination/limit behavior and the empty-result case are unaddressed, which is a small residual gap for a search 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 coverage is 83%, so the baseline is 3, and the description adds real selection guidance beyond the schema: prefer facet-specific fields over q when the user names a known facet. It does not address limit or its default, but that gap is minor given 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?

States a specific verb and resource ('find public daylily cultivar reference records') and enumerates the searchable facets (name, hybridizer, color, parentage, general text), which distinguishes it from daylily.get_cultivar and listing-oriented siblings.

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?

Explicit when-to-use, an explicit when-not ('a signed-in user's own inventory'), and the named alternative (daylily.list_listings). It also encodes a routing rule between the broad q parameter and field-specific filters.

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=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds real value beyond them: responses are 'short' and 'sourced' (bounded, cited answers) and the tool 'does not read member records', a privacy boundary the annotations do not express. An output schema exists, so the absence of return-format detail is acceptable.

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 front-loaded sentences with no filler; the usage directive comes first and the scope exclusion last. The domain enumeration is dense but each item maps to a distinct workflow, so it earns its space.

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-only lookup with a full output schema and clear annotations, the description covers purpose, covered topics, and the key negative constraint. The only material gap is how to formulate the query argument, which is minor given the single obvious parameter name.

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% for the single required 'query' parameter, and the description says nothing about it — no indication that it should be a natural-language question, no guidance on scope or phrasing, and no mention of the 2-200 character bounds. With low coverage the description is expected to compensate, and it does not.

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 and resource ('short, sourced help') and enumerates the covered domains (cultivar search, listing status, lists, photos, profile content, import, billing), which clearly separates it from the data-retrieval siblings. It never says outright that this is a documentation/help corpus rather than live data, but the phrase 'sourced help' plus the domain list makes the intent legible.

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 this for short, sourced help with...' gives an explicit when-to-use condition, and 'It does not read member records' is an explicit exclusion that steers the agent toward get_profile/get_listing for actual data. It stops short of naming those alternative tools, so the routing is implied rather than spelled out.

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, non-destructive), and the description adds real scope context beyond them: results are limited to public listings from active catalogs and exclude private notes and hidden listings. That is exactly the kind of visibility boundary an agent needs before quoting results to a buyer. It does not discuss rate limits or empty-result behavior, so not 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 sentences, front-loaded with the triggering condition, then the visibility guarantee, then the filtering/paging advice. Nothing is repeated from the schema and no sentence is filler.

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 an output schema present, the description does not need to explain return shapes, and it correctly focuses on scope, visibility, and pagination for a 17-parameter search tool. The remaining gap is disambiguation from the sibling read tools, which matter for tool selection at this catalog size.

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 94%, so the 17 parameters are already documented and the baseline is 3. The description adds only one piece of semantic guidance beyond the schema, the preference for specific filters over the broad q parameter; cursor usage is already spelled out in 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?

The description states a specific verb and resource ('search' over 'public Daylily Catalog inventory'), and enumerates the artifact types returned: growers, prices, photos, availability. It is distinguishable from mutation siblings like create_listing, but it never names the close read siblings (list_public_listings, get_public_listing, search_cultivars), so the agent must infer the boundary.

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 triggering situation ('when a buyer asks for public... inventory, growers, prices, photos') plus a filter-preference rule ('prefer specific filters over q') and a paging rule ('follow nextCursor until null'). It stops short of naming an alternative tool or stating when not to use this one, which keeps it below a 5.

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 disclose that the tool is destructive, idempotent, and not read-only, and the description adds useful operational context beyond that: it requires a connected account and the catalog:write OAuth scope, notes account tier limits, and advises re-reading the listing if the link changes. It does not explicitly spell out that existing title and slug values are overwritten, but the verb 'Set' plus the destructive annotation makes the risk clear.

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 short and front-loaded: the first sentence states the core action, followed by a usage note, authorization requirement, and limit warning. Every sentence contributes relevant information without unnecessary wording.

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 simple one-parameter mutation with an output schema and annotations, the description covers purpose, authorization, account-tier limits, and the link-change caveat. It still leaves a gap around how to obtain listingId and what happens when the listing is not linked to a cultivar, but the core behavioral context is otherwise 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?

Schema description coverage is 0%, so the description needs to compensate for the single listingId parameter but does not explain its format, source, or how to obtain it. The phrase 'one owned listing' does add the ownership constraint, but it leaves the parameter largely undocumented beyond what the schema property name already conveys.

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 and resource: setting one owned listing's title and URL slug to the name of its linked cultivar reference. This is clearly distinct from generic listing updates and from the link_listing_to_cultivar sibling, so an agent can distinguish the tool 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?

The description implies when the tool is relevant by referring to a listing's linked cultivar reference and noting that the listing should be read again if the link changes. However, it does not explicitly name alternatives such as update_listing for manual edits or link_listing_to_cultivar for establishing the link, nor does it state when not to use this tool.

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 destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it requires a connected account, a specific OAuth scope, tier limits, and most importantly, that the expectedUpdatedAt value from a previous read must be supplied for optimistic concurrency control. This is meaningful transparency not present in structured fields.

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?

Four sentences, each earning its place: purpose, concurrency token requirement, authentication/authorization, and tier limits. The purpose is front-loaded, and there is no redundant or vague wording.

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 tool has an output schema and rich annotations, so the description need not explain return values. It covers purpose, key parameter behavior, auth, and limits. A minor gap is that it doesn't state that at least one of title or description must be supplied (schema marks both optional), but overall it is complete enough for correct invocation.

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 compensate. It explains that 'expectedUpdatedAt' should be the updatedAt value from a list read, clarifying its role as a concurrency token. It also indicates that title and description are the editable fields. While it doesn't detail listId (obvious from name) or that title/description are optional, it adds critical meaning for the most non-obvious parameter.

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 ('Edit'), resource ('title or description of one owned list'), and scope ('owned', 'one'), which clearly distinguishes it from siblings like create_list, get_list, and update_listing. An agent can identify the tool's purpose 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?

The description provides clear context for when to use the tool—editing title/description of an owned list—and states prerequisites (connected account, catalog:write scope, tier limits). It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to decide when to invoke it.

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 destructiveHint=true and idempotentHint=true, but the description adds real value beyond them: partial-update semantics (omitted fields unchanged), null-clears-an-optional-field semantics, an optimistic-concurrency token, the required catalog:write OAuth scope and connected account, and account tier limits. It stops short of saying what happens on a stale updatedAt conflict or which fields are the destructive ones.

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?

Four short sentences, front-loaded with the action and scope, then the prerequisite, then edit semantics, then environment requirements. No sentence is redundant and nothing is buried.

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?

An output schema exists, so return values need no explanation, and the description covers the auth, scope, tier, concurrency, and partial-update dimensions an agent needs before calling a destructive mutation. The one real gap is conflict behavior when expectedUpdatedAt is stale, which matters for a tool with destructive and idempotent hints set.

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 carry the load, and it does explain the two highest-risk parameters conceptually: expectedUpdatedAt (take it from the read) and the null-vs-omitted convention that governs price, description, and privateNote. It adds nothing about individual field constraints or the meaning of hidden, so half the parameter surface is only defined by type and bounds in 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?

"Edit one owned listing" gives a specific verb (edit) and resource (listing) plus an ownership scope that separates it from read tools like get_listing and from the creation path create_listing. It does not explicitly name the nearest sibling (update_list) or state that it cannot touch other users' listings, but the intent is unambiguous.

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 establishes a clear workflow prerequisite ("Supply the updatedAt value from the listing read"), which tells an agent to read before writing. It also defines the two field-editing modes. It lacks explicit when-not guidance or a pointer to alternative tools for bulk/other edits, so it stops short of full routing 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?

Annotations already declare mutation and destructiveHint, but the description adds material context beyond them: a connected account is required, the catalog:write OAuth scope must be granted, and account tier limits apply. It also surfaces the optimistic-concurrency contract via expectedUpdatedAt. The remaining gap is that it never says what happens when a field is passed as null (whether that clears the value) or what occurs on an updatedAt mismatch, which matters for a tool flagged destructive.

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 front-loaded with the core action, then prerequisite, then sibling routing, then auth requirements — a sensible order with no filler sentences. It is slightly long at five sentences, but each carries distinct routing or permission information rather than restating the schema.

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 an output schema present, the description rightly omits return values, and it covers the access requirements and concurrency token an agent needs to call this safely. It falls short only on the mutation semantics of null field values and error behavior on a stale updatedAt, which is the notable omission for a destructive write with four optional parameters.

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 carry the load. It does explain expectedUpdatedAt well (source it from the profile read, null when no profile exists), but for title, location, and description it only lists names without noting that null is a meaningful clearing value or that these are partial updates. The maxLength constraints live only in the schema, leaving the null semantics undocumented in both places.

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 first sentence names a specific verb (Edit) plus the exact resource and fields (title, description, location of the member's public profile). It also routes the reader away from sibling tools (manage_profile_images, reorder_images, open_dashboard) for adjacent capabilities, so an agent can distinguish it from daylily.get_profile and daylily.update_listing without opening a 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?

The description states the precondition for calling (a prior profile read supplying updatedAt, or null when none exists) and explicitly names the alternative tools for image add/reorder and for URL/story changes. That is real when-to-use and when-not-to-use guidance rather than implied context.

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