Lumethic Photo Verification

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

Goes well beyond the given annotations by disclosing the actual effect of the write (a public share link is created, or an invite-only share is upgraded to public) and by enumerating the response values (none, created, upgraded). The public-visibility warning is consistent with the destructiveHint=true and openWorldHint=true 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?

Three tight sentences, front-loaded with the action and its limit, then the safety warning, then the return signal. Nothing is redundant and nothing essential 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?

Even though an output schema exists, the description helpfully names the decisive return field (share_effect) and its values. With only two parameters, a mutation annotation set, and umambiguous schema coverage, an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both the verification_id source (verify_photo, verify_content_credentials, list_verifications) and the title's 80-character limit; the description only restates the title cap and adds the portfolio-level limit of 50.

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 ('Add one of the account's verifications to the portfolio') plus a capacity constraint (max 50), which lets an agent tell it apart from update_portfolio_item or share_verification 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?

Gives an explicit pre-call instruction ('Tell the user before calling it'), which is real usage guidance, but it never names an alternative or exclusion (for example, when to use share_verification instead), so the guidance is clear but partial.

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 description discloses the main behavior: posting an internal comment, character limit, ownership, and authorship. It does not mention error conditions or response shape, but annotations (readOnlyHint false, idempotentHint false) are consistent and no contradictions exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loads the action and resource, and contains no redundant or filler content.

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 two-parameter tool with an output schema, the description provides enough context to call it correctly: what it does, constraints, use cases, and ownership. No additional details are needed.

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 descriptions cover 100% of parameters, and the description reinforces them by explaining that body is the comment text, that verification_id is a UUID returned by specific verification tools, and that the comment is internal and authored by the connected user.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Post') and identifies the resource ('internal comment on a verification you own'), which clearly distinguishes it from sibling tools such as add_verification_tags, list_verification_comments, or update_verification_comment.

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 explicitly states when to use the tool ('Use it for client feedback, decisions, or context worth keeping with the report') and notes the ownership requirement, but does not explicitly contrast it with alternative comment-management tools.

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 description explicitly states that existing tags are kept, unknown names are created, and the result (full tag list) is returned. The annotations confirm readOnlyHint=false and destructiveHint=false, aligning with the non-destructive additive behavior described. The idempotentHint=true is consistent with adding tags, though not explicitly mentioned in the description.

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 concise (three sentences) and front-loaded with the primary action. It avoids unnecessary details and structure is straightforward, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema (not shown but exists), the description adequately covers the input behavior and expected outcome. It lacks a mention of potential errors or edge cases (e.g., invalid verification ID), but for a simple add operation, the provided context is sufficient.

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?

Both parameters are required and fully described in the schema (verification_id as UUID, tags as array of strings with length and character constraints). The description reinforces the parameter semantics by repeating the tag constraints, and the schema coverage is 100%.

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 states the action (add tags to a verification), the specific behavior (keeping existing tags), and the side effect (creating unknown tags). It also mentions the return value (full tag list after change), leaving no ambiguity about the tool's purpose.

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 usage by specifying tag constraints (1-40 characters, no commas, case-insensitive matching) and the creation of unknown tags. It doesn't mention when to use this over the sibling 'set_verification_tags' or 'remove_verification_tag', but the behavior is clear enough for basic usage.

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

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

The description discloses that the portfolio starts unpublished and implies a paid-plan requirement, adding meaningful behavior beyond the annotations. It does not detail failure modes or post-creation effects, but annotations already indicate a non-readonly, non-destructive, non-idempotent mutation.

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 compact and well-structured: it opens with the core purpose and key constraints, then clearly walks through parameter requirements. No filler or redundant phrasing is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description covers essential context: creation behavior, account-level constraint, initial unpublished state, payment requirement, and all parameter constraints. It does not explain error responses or uniqueness handling, but the provided context is sufficient 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?

The schema already provides 100% description coverage for all four parameters, including formats and constraints. The description largely restates these details rather than adding new semantic relationships or cross-parameter context, so it stays at the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create'), the resource ('portfolio'), and key distinguishing constraints: one per account, starts unpublished, and paid plans only. This differentiates it from update/delete/get portfolio tools and from other create tools among 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?

It provides strong contextual guidance by noting one-per-account and paid-plan requirements, which tells the agent when creation is appropriate. It does not explicitly name alternative sibling tools or contrast with update_portfolio, but the constraints effectively convey usage conditions.

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 description transparently covers asynchronous generation, idempotent re-request behavior, retry of failed exports, and plan/allowance implications. It does not describe error cases for invalid verification IDs, but the disclosed behavior is otherwise thorough.

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 dense but well-structured, covering purpose, constraints, async flow, and idempotency without unnecessary filler. Each clause adds meaningful 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?

The description provides enough context for an agent to choose and call the tool, including the polling flow and download location. It does not detail the output schema fields, but the reference to get_psd_export_status and the existence of an output schema reduce the need for that detail here.

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 single parameter verification_id is fully described in the schema and enriched by the description, which explains that it must reference a completed RAW+JPEG verification and how it is returned (verify_photo, verify_content_credentials, or list_verifications).

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 states the tool's purpose: requesting a layered flicker-comparison PSD for a completed RAW+JPEG verification the user owns. It also names the specific layers and distinguishes the tool from the related get_psd_export_status tool.

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 explicitly explains when to use the tool, including prerequisites (completed RAW+JPEG verification you own), plan restrictions (Professional plan only), and the asynchronous workflow with the polling step via get_psd_export_status. This leaves little ambiguity about usage.

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

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

The description discloses that the tool does not actually upload the files itself but returns pre-signed URLs, and that the agent must PUT to those URLs and then call verify_photo with the returned object keys. This adds meaningful behavioral context beyond the sparse annotations, though it does not mention URL expiration or upload completion details.

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 two compact sentences that front-load the core function and immediately follow with actionable steps. Every sentence contributes essential information with no redundancy 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?

For a zero-parameter tool with an output schema, the description fully covers the workflow: obtaining URLs, uploading files, and completing verification with the returned keys. Nothing critical is missing for correct invocation and follow-through.

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 input schema has zero parameters and schema description coverage is 100%, so there are no parameter semantics to describe. Per the baseline for zero-parameter tools, this is effectively handled; the description focuses on the workflow and response usage instead.

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 states the tool's purpose: obtaining pre-signed S3 PUT URLs for uploading large RAW and JPEG files. It distinguishes itself from verify_photo by explaining that it handles the upload mechanism rather than inline bytes, making the resource and action 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 explains when to use this tool — for large files where inlining bytes would hit request-size limits — and outlines the next required step of calling verify_photo afterward. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to follow the intended flow.

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 description goes beyond the annotations by disclosing exact side effects: deleting 'all its items' while leaving 'verifications and their share links untouched.' It also adds an important behavioral safety instruction to 'Confirm with the user first.' This is consistent with the annotations, which mark the operation as 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 two short sentences with action and scope front-loaded. It covers the main behavior, exceptions, and a safety step without any 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?

For a destructive, zero-parameter tool with an output schema, the description provides the essential operational knowledge: what gets deleted, what remains, and the required user confirmation. Nothing critical is missing for invoking it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the input schema correctly reflects that with an empty properties object. With no parameters, the description does not need to explain parameter meaning, and the 100% schema coverage supports a baseline of 4.

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: 'Delete the portfolio and all its items.' This clearly distinguishes it from siblings like remove_portfolio_item by stating the full scope of deletion. The additional clause about verifications and share links further clarifies precisely which resources are affected.

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 that this tool should be used to delete an entire portfolio and that the user should be confirmed first. However, it does not explicitly mention alternatives such as remove_portfolio_item for deleting only one item, so the guidance is more implied than explicit.

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 description goes beyond the annotations by explicitly stating that the tag is detached from every verification and that the verifications themselves are untouched, providing clear side-effect information.

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 concise and well-structured, using two clear sentences to convey the primary action and the important side effect without unnecessary detail.

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 deletion tool with one parameter, the description provides sufficient context about what is deleted, what happens to related entities, and what is not affected, making it complete for an agent to use.

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 only parameter 'tag' is fully described with its type (string), accepted formats (name or id), and case-insensitivity, which adds meaningful semantic detail beyond 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 clearly states the action (delete) and the resource (a tag from the account's vocabulary), and distinguishes it from other tag-related operations like update_tag or remove_verification_tag by specifying it also detaches the tag from every verification.

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?

While it doesn't explicitly compare itself to alternatives, the description implies when to use it (to permanently remove a tag from the account vocabulary) and clarifies side effects on verifications, which helps an agent select it over related tools.

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 description goes beyond the annotations by disclosing an authorization constraint (author or admin only), which is a behavioral aspect not covered by the readOnlyHint or destructiveHint. It adds useful context without contradicting 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?

The description is concise and to the point, consisting of two short sentences with no unnecessary words or redundant information. It efficiently conveys the core action and a key constraint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and annotations that cover destructive behavior, the description is adequately complete for a delete operation. It adds the important authorization detail, making it sufficient for an agent to understand the tool's purpose and 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?

Both parameters (comment_id and verification_id) are described in the schema with references to related tools. The description itself does not add additional semantic information beyond what the schema already provides, 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 clearly states the tool's function: 'Delete a comment.' It is specific and unambiguous, and distinguishes it from sibling tools like add_verification_comment or update_verification_comment by indicating it is for deletion.

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 implicit usage guidance by specifying that deletion is allowed only for the author or admins, but it does not explicitly contrast with alternatives or state when to choose this tool over others. The context is clear from the sibling tools, but explicit guidance is missing.

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, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral context: the quota is monthly, tied to the authenticated account, and includes free-tier allowance semantics. No contradiction with 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 with no filler. The first sentence states the operation and its key outputs; the second provides a direct, actionable usage guideline. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless read-only tool with an output schema and full annotation coverage, this description is complete. It states what the tool returns, who it applies to (authenticated account), and when to call it. Nothing essential 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?

The tool has zero parameters and 100% schema coverage, so the baseline of 4 applies. The description adds no parameter-specific details because there are none to add, and it appropriately focuses on the returned quota information.

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 ('Get') and resource: the authenticated account's monthly verification quota, explicitly listing the returned fields (plan, used, limit, remaining). It also names the exact use case related to verify_photo, making it clearly distinguishable from sibling 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?

The description tells the agent when to call this tool: 'Call this before verify_photo to check the free-tier allowance.' This is clear context and links to a concrete precondition. It doesn't explicitly mention exclusions or alternatives, but none are necessary given the tool's unique role.

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 this as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations by stating the access constraint ('no public directory') and what data the caller can expect. No contradictions with annotations exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with no filler. The core purpose and returned fields are front-loaded, and the access constraint is stated efficiently in the second 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 one-parameter read-only tool with a rich output schema and clear annotations, the description is fully adequate. It specifies the input requirement, the data returned, and the key constraint, leaving nothing essential 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 100%, with the parameter already documented as a marketplace listing UUID. The description reinforces that the UUID must be known in advance, but adds little new meaning beyond the schema for the single 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 clearly states the operation ('Fetch a marketplace listing by id') and names the key returned fields: title, description, per-license pricing, terms, and sales totals. This makes the tool's purpose specific and distinguishable from sibling tools like list_my_listings or get_portfolio.

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 usage context by explaining that there is no public directory and the caller must know the listing UUID. This tells the agent when it can and cannot use the tool, though it does not explicitly name alternatives for discovering 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?

Beyond the read-only and idempotent annotations, the description adds that portfolios are for verified photos on paid plans, implying a potential requirement/failure mode. It also describes the return content. However, it does not mention error conditions or edge cases, but the annotations already cover the core safety traits.

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 concise and well-structured, with two clear sentences: one stating the action and return fields, and one providing contextual detail about the portfolio's nature. No unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully explains what the tool returns (slug, public URL, published state, and item details) and adds context about paid plans and verified photos. Even without an output schema, an agent would understand the expected data shape and purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so schema coverage is effectively 100%. The baseline is 3, and the description adds no parameter-specific details because none exist. This 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 clearly states the tool retrieves the account's verified portfolio and lists the key fields returned (slug, public URL, published state, and portfolio items with title, position, and shared status). This makes the purpose specific and distinct from generic 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?

The description does not explicitly differentiate this tool from siblings like get_verification or list_my_listings. It mentions it's for the account's portfolio, but there is no direct guidance on when to prefer this over alternatives. This is a clear gap given the large sibling set.

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 readOnlyHint and idempotentHint annotations already indicate no side effects, and the description adds transparency about the returned data (status, file size, canvas dimensions, downloads used, expiry). It does not contradict the annotations and gives a clear picture of the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that front-loads the action and resource, then compactly lists the returned fields. There is no redundant or extraneous 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 read-only polling tool with one well-documented parameter and an output schema, the description is complete. It specifies what statuses to expect and what data is returned, and the sibling list provides the related create_psd_export 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?

The schema fully documents the single verification_id parameter, including its UUID type and origin, so the description does not need to add much. The tool description itself adds no further parameter detail, matching the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Poll the state') and a specific resource ('a verification's PSD export'), which distinguishes it from sibling tools like create_psd_export and get_verification. It also lists the key output fields, so an agent knows exactly what this tool provides.

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 word 'Poll' implies this should be used after requesting an export, but the description does not explicitly mention create_psd_export or state when to prefer this over get_verification. Usage guidance is implied rather than explicit.

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 description contradicts the annotations. Annotations declare readOnlyHint=true, yet the description says 'Calling it records that an upgrade link was requested,' which implies a state-changing side effect. Even though the description usefully discloses that the link contains no credentials, the direct contradiction with readOnlyHint makes the behavioral model unreliable.

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 three sentences long and every sentence earns its place: purpose and trigger, link behavior and security property, and user-facing action plus side effect. It is front-loaded with the core purpose and contains no 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?

For a zero-parameter tool with an output schema, this description covers the essential context: what the link does, when to use it, what to do with it, and that it has no credentials. The only weakness is the readOnlyHint contradiction, which makes the side-effect information conflict with the annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema coverage is 100%, so there is no parameter semantics for the description to add. With no parameters, a baseline of 4 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 opens with a specific verb and resource: 'Get a link to upgrade the account's plan on the Lumethic website.' It also gives concrete trigger examples (QUOTA_EXCEEDED or NOT_ENTITLED errors) and tells the agent to show the link to the user. This is clearly differentiated from sibling tools like get_account_usage or get_listing.

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 explicitly identifies when to use the tool: after quota or entitlement errors, and states that the link should be shown to the user. It does not mention when not to use it or name alternative tools, but the context is clear enough for an agent to make the right call.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing wait behavior, wait_seconds semantics, early-return conditions under heavy load, the non-final response fields (waited_seconds, expected_wait, next_step), and the range of possible statuses. This is exactly the behavioral context an agent needs to poll correctly.

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 dense but every sentence earns its place: result scope, completion extras, wait behavior, polling loop, duration expectations, load behavior, and account scoping. It is front-loaded with the core purpose and then expands into operational details.

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 read-only polling tool with an output schema, the description covers the full invocation lifecycle: what to expect initially, how long to wait, what fields indicate non-completion, when to call again, and how to handle server-side wait skipping. Nothing needed for correct usage 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 coverage is 100%, so the baseline is 3. The description adds useful context on top: it explains what wait_seconds does in practice, how returning early works, and what a non-final response contains. This supplements the schema without repeating 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 names a specific verb and resource ('Retrieve a verification by id') and explains what the response contains (status, per-algorithm results, verdict for completed image_only verifications). It is clearly distinct from list_verifications by requiring a verification_id, but it does not explicitly name or contrast a sibling tool.

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?

Provides explicit polling guidance: call again and keep calling until status is completed or failed, expect several calls because analysis takes 1-10 minutes, and handle early returns under load. It does not explicitly say when to use this tool versus listing or creating verifications, but the polling workflow is well covered.

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 description states it 'gets' the configuration, indicating no side effects. This aligns with annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false). It adds a bit of context by enumerating the returned data, but does not go beyond the annotations in describing effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that directly states the tool's function without extraneous detail. It is concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description specifies exactly what the response will contain (access type, share URL, invited emails), which is sufficient even though the output schema is not shown. It provides all necessary context for the tool's use.

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 only parameter verification_id is well-described both in the schema and the description, including its type (UUID) and how it can be obtained (from verify_photo, verify_content_credentials, or list_verifications). This provides complete context for the 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 clearly states the tool retrieves the current sharing configuration of a verification, specifying the components (access type, share URL, invited emails). This distinguishes it from sibling tools like share_verification and unshare_verification which modify sharing settings, and get_verification which retrieves verification details.

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 a read-only usage for inspecting sharing settings, which contrasts with the modifying siblings. However, it does not explicitly say 'use this instead of share_verification' or provide conditional guidance, so it lacks an explicit when-to-use statement.

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 description accurately reflects the read-only nature of the operation, consistent with the annotations (readOnlyHint, idempotentHint, destructiveHint). It also adds behavioral detail about the response, mentioning pricing and sales totals, which is not fully covered by the annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no redundant phrasing. It front-loads the primary purpose and includes relevant output detail without wasting words.

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 paginated listing operation with an output schema and clear annotations, the description provides sufficient context. It explains the scope (owned listings) and output highlights (pricing, sales totals), making it complete without needing extra prose.

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?

Both parameters (limit and offset) have schema descriptions, achieving 100% coverage. The tool description adds no extra meaning beyond the schema; the parameter descriptions are standard pagination text and the bounds are already expressed 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 clearly states the tool lists marketplace listings owned by the account, using the specific verb 'List' and identifying the resource and scope. It distinguishes itself from sibling tools like get_listing by focusing on owned listings and including pricing and sales totals.

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 usage for retrieving one's own listings, but it does not explicitly reference alternatives or conditions for choosing this tool over others. No direct guidance is given for when to use list_my_listings versus get_listing or other list tools.

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, idempotent, non-destructive behavior. The description adds useful behavioral context by specifying it returns an account-level vocabulary with per-tag verification counts and noting how tags get assigned, without contradicting 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 with no filler; the core purpose and return fields are front-loaded, and the second sentence efficiently provides provenance and downstream usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool with an output schema and full annotations, the description supplies everything needed to invoke it correctly, including what the result is and how to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema leaves nothing to explain; per the rubric the baseline is 4. The description's mention of passing names to list_verifications is related downstream context rather than parameter documentation.

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 ('List') and resource ('the account's tag vocabulary') and enumerates the returned fields (id, name, colour, verification counts). This clearly distinguishes it from sibling tag operations like update_tag and delete_tag.

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 clear context for when to use the tool: to fetch the tag vocabulary and feed names into list_verifications' tags filter. It does not explicitly state when not to use it or name alternatives, so it falls 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?

The annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds that results are ordered oldest first, include author names, and are private to the owning account, which are meaningful behavioral details 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?

The description is two concise sentences with no redundancy. It efficiently conveys the action, ordering, author visibility, and privacy scope without unnecessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides sufficient context about ordering, author names, and privacy. Since an output schema exists (though not shown), return format is not required in the description. The tool is simple with one parameter, and the description covers the essential aspects 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?

The schema fully describes verification_id with examples of where it comes from (verify_photo, verify_content_credentials, or list_verifications). The description adds that the verification must be one you own, an additional semantic constraint not present 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 clearly states the action (list), the resource (internal comments on a verification), the ordering (oldest first), and the inclusion of author names. It distinguishes from sibling tools like add_verification_comment, delete_verification_comment, and update_verification_comment by focusing on listing.

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 specifies the condition 'on a verification you own' and notes that comments are private notes, which implies when to use it. However, it does not explicitly compare with alternative retrieval methods like get_verification, leaving some ambiguity about when to choose this over others.

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, idempotentHint=true, and destructiveHint=false, so the description need not repeat those. It adds behavioral context beyond the schema: ordering ('most recent first'), filter semantics (result true/false, tag_match all/any), and case-insensitive tags. No contradictions with 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?

The description is two sentences, with the primary purpose and ordering front-loaded. Every sentence earns its place: the first states what it does, the second covers filters and a prerequisite pointer. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and annotations cover safety, the description covers all essential aspects: purpose, filters, ordering, and a pointer to a sibling tool for tag discovery. Pagination is handled by schema parameters, and the read-only/idempotent nature is in annotations. Nothing critical 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%, so parameters are documented there, but the description adds semantic depth: it clarifies 'result' (true=authentic, false=not), explains 'tag_match' defaults and meanings, and notes case-insensitivity for tags. This goes beyond the schema's basic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('List'), resource ('verifications'), and scope ('the account's'), with ordering ('most recent first'). This clearly differentiates it from siblings like get_verification (single) and list_verification_comments (comments), leaving no ambiguity about what the tool does.

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 provides a clear usage context (listing with filters) and a specific pointer: 'Use list_tags to discover names.' While it does not explicitly name alternatives like get_verification, the purpose and filters make the intended use evident, and the tag discovery hint is a concrete usage guideline.

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, so the safety profile is covered. The description adds critical behavioral context beyond annotations: the public share link remains active after removal, and unshare_verification is needed to revoke it. It doesn't describe auth or rate limits, but for a simple mutation the side-effect disclosure is valuable.

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 with zero waste. The primary action is front-loaded, and the important caveat about the share link follows immediately. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a simple removal tool with an output schema, full parameter documentation, and annotations covering safety, the description supplies the key missing side-effect information (share link persistence). It could be slightly more complete by noting what happens to the verification itself or portfolio ordering, but it covers the essential behavioral surprise.

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 one parameter, verification_id, with 100% schema description coverage. The schema already explains that it is a UUID returned by verify_photo, verify_content_credentials, or list_verifications. The description adds no further parameter semantics, which is acceptable given the high coverage – 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 states a specific verb and resource: 'Remove a verification from the portfolio.' It distinguishes the action from portfolio-level deletion and hints at a related sibling (unshare_verification), though it doesn't explicitly contrast with all siblings like update_portfolio_item or delete_portfolio.

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 clear guidance on when to use this tool and a conditional follow-up: call unshare_verification if the share link should be made private. However, it does not explicitly state when not to use this tool or name alternatives beyond unshare_verification.

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 the crucial blast-radius detail that the tag itself survives in the account vocabulary — resolving the main fear a destructive-hinted tool raises. It also discloses the response shape ('Returns the remaining tags'), though it omits what happens when the tag is not attached.

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, then the key side-effect caveat, then the return. Nothing is redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, well-annotated tool with an output schema, the description covers action, side effect, and return adequately. The remaining gap is how it relates to sibling tag tools (add/set/delete_tag) and behavior on a missing tag, which is minor given idempotentHint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are fully documented in the schema, including the name-or-id flexibility and the UUID source. The description's 'by name or tag id' merely echoes that, adding no new format or resolution detail — baseline 3.

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 ('Remove one tag ... from a verification') with explicit scope ('one tag', 'by name or tag id'). The clause 'The tag stays in the account's vocabulary' implicitly separates it from delete_tag, though no sibling is 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?

Usage is only implied by the singular scope: this removes a single association, as opposed to add_verification_tags or set_verification_tags which are not mentioned. No explicit when-to-use/when-not guidance or prerequisites are given.

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

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

The description adds that verification_ids must contain every current item exactly once, which is a key behavioral constraint not fully captured by the readOnly/idempotent annotations. It does not describe error handling or side effects beyond the order specification.

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 concise, with no unnecessary words. It clearly states the action and the required input format in two short sentences.

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 reorder operation, the description is sufficient. It explains the requirement and order interpretation. It does not need details like permissions or return formats given the tool's simplicity and existing annotations.

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 parameter description in the schema already fully explains that it expects every current verification id in desired order. The tool description repeats this information without adding extra insight, so no additional value beyond schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it sets the display order for portfolio items, which is a specific action distinct from siblings like add or remove. The verb 'Set' and resource 'display order' are explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Does not explicitly mention when to use this tool over alternatives like add_portfolio_item or update_portfolio_item. It provides the requirement that all items must be included, which implies a full reorder, but lacks explicit 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?

Annotations already flag destructiveHint=true and idempotentHint=true; the description adds genuinely new context: unknown names are auto-created in the account vocabulary, matching is case-insensitive, and there is a 20-tag cap. It does not mention permissions or what happens to concurrently-edited tags, but the extra behavioral detail is substantial.

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 tight sentences, front-loaded with the core replace semantics, then constraints, then return value. No filler and every clause 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?

A destructive, idempotent mutation tool with an output schema is fully covered: replace behavior, side effects (tag creation), limits, and the return value are all stated. Nothing an agent needs to invoke it safely 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 coverage is 100%, so baseline is 3, but the description restates the constraint envelope (1-40 chars, no commas, max 20 per verification) in one place, giving the agent validation rules it might otherwise have to reconstruct. It does not explain the verification_id source (the schema does).

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 (replace) and resource (tags on a verification) with exact-replacement semantics, which cleanly separates it from add_verification_tags and remove_verification_tag in the sibling list. An agent can pick it without comparing 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?

The parenthetical '(empty list clears them)' makes the replace-vs-append distinction explicit, which is the key decision when choosing between this and the add/remove siblings. It never names those alternatives directly, so it stops 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 destructiveHint=true, idempotentHint=true and openWorldHint=true, and the description adds real context on top: the ownership requirement, the anonymity restriction, and that 'anyone_with_link' produces a public URL (the actual exposure risk). It doesn't spell out revocation or permission requirements, but the privacy implication of the public mode is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, no filler, with the core action and the access modes front-loaded ahead of the optional parameter and the constraint.

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 and the description notes the return values (share URL and invited emails), so return detail isn't required. Ownership and anonymity constraints are covered; only revocation/undo behavior is 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?

Schema coverage is 100%, so both access_type values and the restricted-only use of invite_emails are already documented in the schema; the description largely restates the enum meanings. It adds only marginal framing ('optionally pass invite_emails to grant access'), making the baseline 3 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?

States a specific verb+resource (enable/update sharing for a verification) plus a scope constraint (verification you own). It is clearly distinguishable from siblings like unshare_verification and get_verification_share.

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?

Explains the two access modes and that invite_emails is optional for granting access, and gives an explicit exclusion (anonymous verifications can't be shared). It doesn't explicitly name unshare_verification/get_verification_share as alternatives for related tasks, so it falls short of a full routing statement.

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 description explicitly discloses that sharing is disabled, privacy is restored, and the share link becomes invalid, which aligns with and enriches the destructiveHint annotation. It does not mention potential edge cases (e.g., whether already-fetched data remains accessible), but for a single-parameter unshare operation the stated side effects are sufficiently transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence that directly states the action and its consequences without any filler or redundant phrasing. It is well-structured and immediately scannable for an agent selecting a 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?

Given the tool's simplicity—one required parameter, a clear action, and an output schema that does not need explanation—the description provides all necessary context for correct invocation. An agent can confidently call this tool based on the stated behavior alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides complete coverage for the single parameter, including its type, title, and a description that explains the expected UUID format and lists example source tools. The tool description adds no extra semantic detail beyond what is already in the schema, so the parameter semantics meet the baseline without enhancement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Disable sharing') and clearly states the resource ('a verification') and the two resulting effects: making it private and invalidating its share link. This directly distinguishes the tool from its sibling 'share_verification' and leaves no ambiguity about its primary function.

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 clearly implies when to use the tool—whenever a previously shared verification needs to be unshared and its link invalidated. It lacks an explicit 'Use this tool when...' or a direct contrast with alternatives, but the action and consequence are so unambiguous that an agent can reliably infer the appropriate usage context.

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?

Adds substantial context beyond the annotations: a rate limit on slug changes (3 per 30 days), a paid-plan requirement for most changes, and the exception that unpublishing always works. Clearing behavior via empty string partially covers the destructiveHint=true risk, though it doesn't warn about slug-change breaking existing links.

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 tight sentences, each carrying a distinct rule (what's editable, clearing, rate limit, plan/exception). Front-loaded with the action and fields, trailing sentences add constraints and nothing is repeated.

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?

Output schema and rich annotations cover return shape and safety profile, and the description supplies the operational constraints an agent needs (limits, plan gate). Minor gap: no note on what happens to an existing slug's links when it changes.

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 already 100%, so baseline is 3, but the description adds the cross-cutting semantic that omitted fields are left unchanged and that slug is governed by create_portfolio's rules. That is meaning the schema does not state.

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?

Names the resource (portfolio) and the exact mutable surface: display_name, tagline, website_url, slug, and publish state. An agent can distinguish this from create_portfolio, update_portfolio_item, and delete_portfolio 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?

Explains the mutation semantics clearly ('omit fields to leave them', empty string clears) and flags the paid-plan gate and the unpublish exception, which is real routing guidance. It stops short of naming a sibling alternative (e.g. use delete_portfolio to remove, or update_portfolio_item for items), so it is not 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 flag destructiveHint=true, idempotentHint=true and readOnly=false, so the safety profile is covered. The description adds the useful detail that passing an empty string wipes the title, which explains the destructive hint, but it says nothing about permissions, ownership, or what happens with an invalid/expired verification_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?

A single front-loaded sentence with no filler; the constraint and the edge case are packed into the one sentence that earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema and annotations exist, so the description needn't explain returns or safety. However, for a mutation tool whose only identifying parameter is a verification_id, the description never explains how a portfolio item maps to a verification or what authorization is needed, leaving a real conceptual 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 100% and both parameters document themselves, including the 80-character limit and empty-string clearing. The description merely restates the schema's title semantics and adds no new meaning for verification_id, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Set') and field ('title'), including a constraint (max 80 chars) and the clearing behavior. The resource is only implicitly the portfolio item's title, and the description never connects 'item' to the required verification_id, but an agent can still tell what the tool does and distinguish it from update_portfolio.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this instead of update_portfolio, add_portfolio_item, or remove_portfolio_item, and no prerequisites or exclusions are stated. Usage must be inferred entirely from the tool 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 declare destructiveHint=true and idempotentHint=true, so the description need not restate safety. It adds useful context beyond annotations: a rename propagates to every verification carrying the tag, color format and empty-string clearing, and omission of a field leaves it unchanged. It does not address permissions or error behavior.

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 compact and front-loaded, moving from purpose to impact to parameter details in a single efficient paragraph. Every clause adds operational meaning without 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?

For a simple three-parameter update tool with rich annotations and an output schema, the description covers the key behavioral aspects: rename propagation, color clearing, and partial update semantics. Missing edge cases like tag-not-found or name conflicts are minor and not required to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents tag name/id, name constraints, and color format. The description repeats the color format and adds partial-update semantics ('omit a field to leave it unchanged'), but that is largely aligned with the schema's nullable/default fields.

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: renaming/recolouring a tag in the account's vocabulary, with lookup by name or tag id. Sibling differentiation is only implicit through the phrase 'account's vocabulary'; no sibling tool is named.

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 the tool is used when renaming or recolouring an existing tag, but it gives no explicit when-to-use/when-not guidance or alternatives such as delete_tag, list_tags, or set_verification_tags. The agent must infer usage from the purpose statement.

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 destructiveHint annotation, the description discloses that the old text is not kept and the comment is marked edited. It also notes the ownership constraint ('connected user wrote'), adding behavioral 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 compact sentences with the main verb and object first, followed by relevant constraints and effects. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the action, ownership constraint, and outcome. With an output schema present and no nested objects, it is sufficiently complete, though it could mention failure cases if the comment isn't owned.

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% and each parameter has a clear description, including how to obtain IDs. The description adds no further parameter-specific meaning, so 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 clearly specifies the action ('Replace the text of a comment'), the resource ('a comment the connected user wrote'), and the effect ('Marks it as edited; the old text is not kept'), which distinguishes it from add/delete comment 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?

The usage is implied by 'the connected user wrote' and 'Replace', but it does not explicitly state when to use this over add_verification_comment or delete_verification_comment, nor does it mention 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 (all false hints) carry almost no behavioral information, so the description rightly carries the full burden. It discloses the async nature ('analysis runs in the background and takes from about a minute to 10 minutes or more'), the immediate id return, the required polling pattern via get_verification, the free/quota trait, and the structured evidence_report shape. These are rich behavioral traits beyond what annotations provide.

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 long (roughly 8 sentences) but every sentence earns its place for a tool with async behavior and multiple input modes: purpose, exclusions, checks performed, quota, parameter routing, polling, and alternative. It is front-loaded with purpose and scope. Minor redundancy exists ('carries Content Credentials' and later 'embedded Content Credentials (C2PA)'), but overall density is justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 parameters, 3 input modes, background execution, output schema present), the description is complete: it covers triggering conditions, exclusions, the forensic checks performed, quota impact, polling instructions, and the verified alternative. Since an output schema exists, detailed return-value documentation is not needed. No significant operational gap remains.

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. The description adds genuine cross-parameter meaning by consolidating the three input paths ('attachment (image_file), inline as image_base64, or — for large files without attachments — call create_verification_upload and pass the returned image_object_key'), which helps an agent choose among the four parameters correctly. This exceeds the baseline without duplicating 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: 'Verify a single image's authenticity when the user asks whether it is genuine, AI-generated, manipulated, or carries Content Credentials'. It explicitly scopes to single still images with no RAW file, and names the exclusion ('Not for feedback on a photo... or for anything that is not a still image'), clearly distinguishing it from the sibling verify_photo.

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 explicit when-to-use, when-not-to-use, and alternative routing. It specifies the triggering condition (authenticity question, only image available), the exclusion (photo feedback, non-still images), the stronger alternative ('use verify_photo with a RAW + JPEG pair instead'), and the upload alternative (create_verification_upload for large files). Nothing is left to inference.

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

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

Beyond the annotations, it discloses key behavioral traits: the tool returns a verification id immediately, runs analysis in the background for about a minute to 10+ minutes, and requires polling get_verification until completion. It also transparently states that calls count against a monthly quota, with free tier at 5/month. No contradiction with 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?

The description is dense but efficient: purpose and exclusions first, then input routing, then async behavior and quota impact. Every sentence carries operational value, with no filler or repetition of schema details.

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 an 8-parameter asynchronous tool, the description covers all essential operational aspects: when to use, what inputs to provide, how to route large files, how to retrieve the result, and cost/quota implications. An output schema exists, so the description does not need to explain return values.

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?

Although schema coverage is 100%, the description adds strategic meaning by grouping parameters into three clear input modes: attachments (raw_file/image_file), inline base64 for small files, and object keys from create_verification_upload for large files. It also clarifies pairing requirements and size thresholds that the raw schema alone does not convey at a decision level.

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: 'Verify a photo's authenticity from a RAW camera file and its JPEG export.' It also scopes the tool to requests for proof or genuineness checks and explicitly excludes feedback on the photo itself, making its role unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states when to use the tool ('when the user asks for proof or a check that the photo is a genuine camera capture') and when not to use it ('not for feedback on the photo itself'). It also gives concrete input-mode guidance, including when to call create_verification_upload for large files. It does not explicitly contrast sibling verify_content_credentials, though the RAW+JPEG pairing makes the intended use clear.

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