Lumethic Photo Verification

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

It discloses the critical side effect that the verification becomes publicly viewable, explains that a public share link may be created or an invite-only share upgraded, and tells the agent to inform the user beforehand. It also mentions the response field 'share_effect' so the agent knows what to expect after calling.

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: it states the core action, then the constraints, then the important side effect, then the user-facing instruction, then the response clue. Every sentence contributes necessary information without 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 includes all essential context for a correct call: the maximum portfolio size, the title length limit and clearing behavior, the public visibility consequence, the notification requirement, and the response field to inspect. This is sufficient for the agent to understand the tool's full impact.

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 described in the schema and the description adds meaningful detail beyond the schema: title is optional, max 80 characters, empty string clears it, and verification_id is a UUID returned by specific tools. This gives the agent enough information to fill the parameters correctly.

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 action ('Add'), a resource ('account's verifications'), and a destination ('to the portfolio'), with explicit constraints (max 50, optional title max 80). It clearly distinguishes this from sibling tools like update_portfolio_item or remove_portfolio_item by emphasizing the public visibility side effect.

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 clear guidance by warning about the public visibility outcome and instructing the agent to 'Tell the user before calling it.' It does not explicitly compare with alternatives like share_verification, but the usage context is strongly implied and actionable.

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?

The description discloses a critical side effect: the public share link stays active after removal. This is not covered by the annotations (readOnlyHint=false, destructiveHint=false) and is essential for the agent to set user expectations. It also implies non-destructive behavior consistent with destructiveHint=false.

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 concise sentences. The first states the primary action, the second explains the side effect and the alternative. No redundant or vague language; the description is optimally sized for an agent to quickly parse.

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 tool with one parameter and one key side effect, the description covers everything needed: the action, the result on the share link, and the alternative when privacy is desired. There is no missing context that would cause an agent to misuse the tool.

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

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

The single parameter verification_id is fully described with its format (UUID) and provenance: 'as returned by verify_photo, verify_content_credentials or list_verifications.' This gives the agent exact instructions on where to obtain the value, far exceeding basic schema 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 clearly states the action: 'Remove a verification from the portfolio.' This is a specific verb with a specific object, and it distinguishes from sibling tools like add_portfolio_item, delete_portfolio, and share_verification. The clarification that the share link remains active further disambiguates it from unshare_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?

The description explicitly tells when to use an alternative: 'call unshare_verification as well if the user wants it private again.' This directly instructs the agent on the condition for using a sibling tool, leaving no ambiguity about when this tool is appropriate.

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 the side effect that the tag stays in the account's vocabulary, and it mentions the return value (remaining tags). This fully informs the agent about the tool's behavior without needing to inspect 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, using two sentences to convey all essential information. There is no redundant or irrelevant text, and the key points are front-loaded: the action, the object, and the non-destructive side effect.

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 low complexity and full schema/annotation coverage, the description is complete on its own. It explains the operation, parameters, return behavior, and side effect, providing sufficient context for an agent to use it correctly without additional documentation.

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 clearly described: verification_id as a UUID with reference to how it is obtained, and tag as either a case-insensitive name or a tag id. The schema coverage is 100%, and the descriptions add necessary context beyond the raw schema types.

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 ('Remove one tag'), the object ('from a verification'), and its scope (by name or tag id). It also clarifies the non-destructive nature by noting the tag remains in the account's vocabulary, 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 does not provide any guidance on when to use this tool versus alternatives such as add_verification_tags or set_verification_tags. No prerequisites or conditions are mentioned, so the agent must infer usage context from the sibling tool list.

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?

The description fully discloses the write nature of the operation ('Replace'), the idempotent behavior (setting exactly the given list), and the non-destructive aspect (it modifies tags but does not delete the verification). It also notes that an empty list clears tags, which is an important side effect.

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, consisting of three clear sentences. It front-loads the primary action and then adds constraints and return details without 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 is complete for an agent to use: it explains the operation, the input constraints, the effect, and the return value ('Returns the verification's tags after the change'). Combined with the output schema, 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 schema already provides 100% coverage with descriptions for both parameters (verification_id and tags, including constraints). The tool description repeats these constraints without adding new meaning about the parameters themselves, so it does not elevate beyond the baseline.

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 (replace), the resource (tags on a verification), and the exact semantics (with exactly this list). It distinguishes itself from sibling add/remove tag tools by indicating full replacement rather than incremental changes.

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 it (to set the full set of tags), the behavior for an empty list (clears them), and constraints (unknown names created, case-insensitive, 1-40 characters, no commas, max 20). This leaves no ambiguity about the operation's effects.

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

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

With annotations already declaring readOnly=false, idempotent=true, and destructive=false, the description adds useful behavior: it returns the share URL and invited emails, and it refuses anonymous verifications. It doesn't specify whether updating restricted sharing replaces or appends invite_emails, so there's a small transparency gap.

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

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

Four short sentences, front-loaded with the operation, then parameter semantics, output, and constraint. Every sentence earns its place with no filler or repetition.

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

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

The description covers required and optional parameters, allowed access_type values, the anonymous-verification restriction, and the return value, while the output schema covers return shape. It is complete for invocation, though a brief pointer to sibling tools or update/replace semantics would make it fully watertight.

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 every parameter already has a description in the schema. The tool description mostly restates those meanings and adds only 'you own' for verification_id, so it meets the baseline but doesn't add significant new parameter insight.

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

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

The first sentence names a specific operation ('Enable or update sharing') on a specific resource ('a verification you own'), and the access_type sentence defines the two modes. This makes it clear the tool is for creating or modifying sharing, not reading (get_verification_share) or removing (unshare_verification) it.

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 states when to use the tool and gives an explicit exclusion: anonymous verifications can't be shared. It also says invite_emails is optional and tied to granting access. It doesn't explicitly route to get_verification_share or unshare_verification, so it stops short of full alternative guidance.

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

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

The 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?

The description reveals important behavioral nuances: unpublishing always works, but other changes need a paid plan. This goes beyond the annotations to set user expectations about side effects and limitations.

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-organized, presenting all key information in three sentences without redundancy or irrelevant 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?

Given the output schema exists and the tool is an update operation, the description covers the essential behavior, constraints, and edge cases (clearing, omitting, limits, paid plan). An agent has enough context to use it correctly without further lookup.

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 detailed descriptions for each parameter (e.g., slug rules, max lengths). The description adds clarifying context about clearing and omitting fields, but most parameter meaning is already captured 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 (change portfolio fields) and enumerates the specific fields and publish/unpublish behavior. It leaves 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?

It explicitly explains how to clear fields (empty string), that omitted fields are left unchanged, and constraints on slug changes (max 3 per 30 days) plus the paid plan requirement. These are practical usage rules.

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 provide readOnlyHint=false and destructiveHint=false, so the description does not need to repeat those. The description adds valuable behavioral details: the maximum length of 80 characters and the special behavior of an empty string clearing the title. This goes beyond the schema and enhances transparency.

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 that covers the tool's purpose and key constraints without unnecessary words. It is perfectly sized for quick consumption by an agent.

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, an output schema is present, and the description clearly defines the input and behavior. There is no missing contextual information that an agent would need to invoke it correctly. The description is complete and self-contained.

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 documents both parameters fully, and the description reinforces their roles: 'title' is the value to set, and 'verification_id' identifies the item. The description adds extra semantics (max 80 chars, empty string clears) that are not in the schema, providing additional clarity for the 'title' parameter. 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 tool's function: setting an item's title. The verb 'set' and object 'item's title' make the purpose explicit. It is also distinguishable from sibling tools like update_portfolio, add_portfolio_item, and remove_portfolio_item, which handle different operations.

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

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

The description implies when to use this tool—whenever a portfolio item's title needs to be updated or cleared. It does not explicitly mention alternatives, but the scope is clear and self-explanatory. Slightly less explicit than ideal, but sufficient for an agent to infer 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?

Annotations already cover idempotency, read-only, and destructive hints. The description adds valuable behavioral context by noting that a rename shows on every verification carrying the tag and that an empty colour string clears the colour, while also clarifying partial-update semantics.

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, with the main action front-loaded and supporting details in short, clear sentences. No superfluous wording 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 provides enough information to call the tool correctly: how to identify the tag, what fields can be updated, and the effect on existing verifications. With an output schema present, return value details are not needed, though error cases are not mentioned.

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 all three parameters, so the baseline is high. The description adds cross-parameter meaning by explaining that omitting a field leaves it unchanged, which is important update semantics not fully captured in individual parameter 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 clearly states the tool renames and/or recolours a tag in the account's vocabulary, using a specific verb and resource. It naturally distinguishes this from sibling tools like delete_tag and list_tags by focusing on updating an existing 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?

The description explains how to perform the update (by name/id, omit fields to leave unchanged, empty string to clear colour) but does not explicitly state when to choose this tool over alternatives such as delete_tag or set_verification_tags. Usage context is implied, not directly contrasted.

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.