FavCRM

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

The description adds behavioral context beyond annotations: it sends a verification email (side effect). Annotations already indicate non-read-only, non-destructive, open-world. No contradictions.

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 extremely concise (two sentences), front-loaded with 'Step 1 of agentic team invite acceptance', and every sentence serves a purpose.

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

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

Given the tool's low complexity (single parameter) and availability of output schema, the description covers the essential workflow and next step. It could mention error handling, but the tool is part of a well-defined sequence.

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 the schema already provides a good description of the token parameter. The tool description repeats the origin of the token (create_team_member_invite or invite link), adding minimal extra value.

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 role as 'Step 1 of agentic team invite acceptance', describes the action (validates token, sends verification code), and differentiates from the sibling tool accept_team_invite_verify by naming it as the next step.

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 explicit sequencing by labeling itself 'Step 1' and instructing to call accept_team_invite_verify next. It gives context for when to use this tool (after receiving an invite token) but does not explicitly state when not to use it or alternative 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?

Describes side effects (joins user, returns key). Annotations (readOnlyHint=false, destructiveHint=false) are consistent; adds context beyond 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 concise sentences, front-loaded with step indication. No redundant 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?

Covers step order, verification, joining, key generation. Output schema exists, so return details are not required. Adequate for a multi-step flow.

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 already provides 100% parameter descriptions. Description adds no new parameter-level info, so baseline 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?

Clearly states it is step 2 of team invite acceptance, verifies code, joins user, and returns API key. Distinguishes from sibling accept_team_invite_request.

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

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

Explicitly positions as step 2, implying ordering. Lacks explicit when-not-to-use, but clear enough for agent selection.

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 declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false. The description adds that the document is stored as single and retrieval/embedding happens elsewhere, clarifying the tool's role. However, it does not disclose potential side effects (e.g., does adding a new document overwrite an existing one with the same name?), permissions needed, or error conditions. More context would strengthen 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 two sentences, each concise and front-loaded. The first sentence states the primary function, the second provides usage examples and a behavioral note. No extraneous information.

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

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

For a simple creation tool with an output schema and sufficient annotations, the description covers the main purpose, usage, and a key behavioral trait (retrieval handled elsewhere). It could mention content size limits or uniqueness constraints, but these are not critical for basic usage. Overall, it is complete enough for the complexity.

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

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

Both parameters (name, content) have descriptions in the input schema (100% coverage). The tool description does not add any additional parameter-level information. Baseline score of 3 is appropriate since schema descriptions are sufficient.

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 adds a free-form text document to the knowledge base, with explicit examples of use cases (policies, FAQs, internal notes). It does not explicitly differentiate from sibling tools like scrape_knowledge_url or list_knowledge_documents, but the purpose is specific enough: manual text addition vs other 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 provides explicit usage guidance: 'Use for pasted policies, FAQs, internal notes, brand voice references — anything the agent should be able to retrieve later.' This tells the agent when to choose this tool. It does not list exclusions or alternatives, but the sibling set implies other tools for other actions (e.g., scraping, listing).

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 indicate readOnlyHint=false and destructiveHint=false, which are consistent with appending (not destructive). The description does not disclose additional behaviors such as idempotency, side effects, or limits. It adds some context about block structure but lacks depth beyond the schema.

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

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

The description is concise: two sentences clearly state the purpose and the block object requirements. No extraneous information; it is well-structured and front-loaded.

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 has two required parameters, the description provides enough context for an agent to understand how to use it. The list of block types is helpful. However, it could be improved by noting when to use append versus other block manipulation tools (insert, replace, remove).

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

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

Schema coverage is 100%, so baseline is 3. The description repeats the block object format (id, version, type, data) and lists types, but these are already detailed in the schema. No additional parameter semantics (e.g., formatting, constraints) are provided beyond what the schema defines.

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 appends blocks to the end of a post, specifying the required block object structure and listing valid block types. This distinguishes it from sibling tools like remove_post_block, reorder_post_blocks, and replace_post_block.

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 state when to use this tool versus alternatives. While it mentions appending to the 'end of a post,' it lacks direct comparison with insert, update, or other block operations. The list of block types provides some guidance but no explicit usage conditions or 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?

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds that the survey is 'removed from active survey lists,' which provides behavioral context but does not explain reversibility, side effects, or permission requirements.

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 with 11 words. No extraneous information is included.

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 simplicity of the tool (one parameter, clear annotations, and an output schema that is presumably documented elsewhere), the description is adequate. It explains the core behavior and outcome, though it could be slightly more explicit about the soft-delete nature.

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 describes the only parameter (surveyId) with 100% coverage. The description does not add any additional meaning beyond what the schema provides.

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 (archive) and resource (survey), and implies the outcome (removed from active survey lists). However, it does not explicitly differentiate from potential sibling tools like delete_survey, though no such sibling exists in the list.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., simply hiding a survey, or other mutation tools). There is no mention of when not to use it or any prerequisites.

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

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

No behavioral details beyond the basic action. Does not disclose idempotency, error handling, or what happens if staff already assigned. Annotations are neutral.

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 short, clear sentences with no wasted words. Front-loaded with the main action.

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?

Adequate for a simple mutation tool with output schema. Lacks detail on behavior, but basic intent is clear.

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% with descriptions. The description repeats the schema hint for userId, adding no new meaning.

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: assigning a staff member to a booking service. It specifically mentions the source of userId, making the purpose 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?

Provides a hint on where to get userId, but lacks explicit guidance on when to use this tool versus alternatives like link_resource_to_service.

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 key behavioral traits: it verifies the job belongs to your company and succeeded, and it does not charge credits (credits charged at submit time). With annotations having readOnlyHint=false and destructiveHint=false, the description adds value by clarifying the verification step and credit policy. However, it could also mention the default polling behavior (pollIfRunning defaults to true) which is only in the schema.

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

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

The description is three sentences long: first sentence states purpose, second gives use cases, third adds key behavioral info. Every sentence is necessary, no fluff. It is front-loaded with the primary action.

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 complexity (5 parameters, output schema exists), the description covers the core purpose, use cases, and an important behavioral aspect (no extra charge). The schema and output schema handle parameter details and return values. It could be slightly more complete by explicitly describing the polling behavior when the job is still running, but the overall context is sufficient for an AI agent.

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 baseline is 3. The description does not add meaning beyond the schema: it mentions attaching a job output, which implies postId and jobId, but does not elaborate on optional parameters like assetIndex, pollIfRunning, or pollTimeoutMs. The schema already documents these adequately.

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 verb 'Attach' and the resource 'previously generated ai-media job's output as the post's featuredImage'. It distinguishes the tool from siblings like generate_post_cover and upload_post_cover_from_url by specifying its use case (reusing a previously generated job). The additional note about not charging credits adds clarity.

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 states when to use this tool: 'Use when generate_post_cover timed out (job kept running) or when reusing the same generation across multiple posts.' It also implies when not to use it (e.g., when generating a new cover or uploading from URL), and mentions prerequisites like the job belonging to the company and succeeding.

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 indicate readOnlyHint=false and destructiveHint=false. The description adds little behavioral context beyond stating the action. It does not clarify idempotency or behavior on duplicate tags, which would be useful given idempotentHint=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?

The description is two sentences, front-loaded with core action, and contains no unnecessary words. Every sentence adds value.

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, return values are covered. The description misses explicitly stating that multiple accounts can be tagged simultaneously (the schema's accountIds array). Otherwise, it is reasonably complete for a simple mutation tool.

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

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

Schema coverage is 100% with descriptions for both parameters. The tool description does not add additional meaning beyond the schema, so baseline score 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 identifies the verb 'Attach', resource 'tags', and target 'member/account'. It states the action and purpose ('useful for segmenting'). However, it uses singular 'a member/account' while the schema allows multiple accounts, slightly reducing precision.

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 a use case ('segmenting members after filtering') but does not give explicit guidance on when not to use or compare with alternatives. No sibling tool duplicates this functionality, so context is adequate but not strong.

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 indicate destructiveHint=true, so the description adds no new behavioral context beyond the optional reason. With annotations carrying the burden, a 3 is appropriate—description does not contradict but fails to elaborate on side effects or reversibility.

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, no redundant information. Front-loaded with the main action, optional parameter noted. Every sentence is purposeful.

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 cancellation tool, the description combined with annotations (destructiveHint, readOnlyHint) and output schema provides adequate context. Could mention potential side effects (e.g., notifications, refunds), but not required for basic understanding.

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%, with descriptions for both parameters. The description reinforces that reason is optional, but does not add extra meaning beyond what the schema provides. Baseline 3 is correct.

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 ('Cancel a booking') and the resource (booking). It mentions the optional reason parameter. However, it does not explicitly distinguish from sibling tools like complete_booking or confirm_booking, leaving some ambiguity.

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

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

No guidance on when to use this tool versus alternatives (e.g., complete_booking, mark_no_show). The description only states what the tool does, not when it is appropriate or inappropriate to use.

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 useful behavioral context beyond the annotations: it explains the destructive nature ('turns off auto-renew', 'prevents further billing cycles') and clarifies that existing paid periods remain valid. This enhances understanding without contradicting the destructiveHint annotation.

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 extremely concise, consisting of two short sentences that immediately convey the core purpose and key behavioral traits. No unnecessary words 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?

Given the tool's complexity (single parameter, clear annotations, and an output schema), the description adequately covers the essential behavioral context. However, it could be improved by noting prerequisites (e.g., subscription must be active) or idempotency implications.

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 description does not add any information about the single parameter 'subscriptionId' beyond what the input schema provides (a subscription ID). Since schema coverage is 100%, a score 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 verb 'Cancel a subscription' and explains the outcome (turns off auto-renew, prevents further billing). However, it does not explicitly differentiate from the sibling tool 'pause_subscription', which might also turn off billing temporarily.

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 when cancellation is desired and notes that existing paid periods remain valid. However, it does not explicitly state when not to use this tool (e.g., for temporary holds) or mention alternatives like 'pause_subscription'.

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, indicating a safe, non-destructive operation. The description adds behavioral context about what is checked (scopes, modules, subscription, quota), which is helpful beyond annotations. No contradictions.

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 highly concise: two sentences that front-load the core purpose and then specify parameter usage. Every word is necessary; 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?

With an output schema present, the description need not explain return values. It adequately covers the tool's purpose, the checks performed, and how to invoke it (which parameters to provide). For a preflight check tool, this is complete.

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% with clear descriptions for all 4 parameters. The description adds value by stating 'Provide toolName, quotaCode, or moduleCode,' implying that at least one of these three is required, which is not explicit in the schema (all are optional). This grouping aids parameter understanding.

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 preflights whether an intended operation is allowed by checking token scopes, enabled modules, subscription state, and quota. It specifies the resource ('operation') and action ('preflight'), making it distinct from siblings like 'get_plan_status' which shows current plan state rather than preflight checks.

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 context that the tool should be used before performing an operation to check permissions and quotas. However, it does not explicitly mention when not to use it or point to specific alternatives among siblings, so it lacks exclusion guidance.

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

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

Annotations indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that the copy is created in DRAFT status and appends '(Copy)' to the name, which is behavioral context beyond annotations. It does not detail return values, but an output schema exists.

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

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

A single, dense sentence that effectively communicates the tool's purpose and key behavior with no wasted words. Front-loaded with the core action.

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 primary behavior: duplication, resulting status, and naming convention. It is sufficient for a clone operation with an output schema. Could optionally mention that all other fields are copied as-is, but not essential.

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%, with descriptions for each parameter. The description adds value by explaining the default name behavior ('(Copy)' appended) and listing the allowed entity types, which matches the enum but provides context.

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: 'Duplicate an existing record'. It specifies supported entity types (product, tier, campaign, etc.) and indicates the result (DRAFT status, '(Copy)' appended). This distinguishes it from sibling create_* and update_* 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 implies usage for duplicating records but does not explicitly state when to use it versus create_* tools or mention any prerequisites or limitations. No exclusions or alternative tools are cited.

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 behavioral traits such as creating/updating accounts and applying points, stamps, and credit deltas. Annotations (readOnlyHint=false, destructiveHint=false) are consistent, and the description adds context about side effects 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 sentences long, front-loaded with the core purpose, and every sentence provides essential 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 adequately covers the tool's purpose and usage. An output schema exists, so return values need not be explained. For a tool with two parameters and a clear prerequisite, the description is sufficiently complete.

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 description adds meaning by linking both parameters (sessionId and rows) to the output of preview_customer_import. The input schema provides detailed descriptions for rows properties, and the description clarifies their origin, adding value over the schema alone.

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 verb 'Commit', the resource 'previewed customer import', and specifies the actions: creates/updates accounts and applies points, stamps, and credit deltas. It also distinguishes from sibling tools by referencing the prerequisite preview_customer_import.

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 instructs to pass the same rows and sessionId returned by preview_customer_import, providing clear when-to-use guidance. It does not explicitly state when not to use, but the context implies proper sequencing.

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 (readOnlyHint=false, destructiveHint=false) indicate a write operation but no destructive behavior. The description adds the side effect of commission calculation, which is an important behavioral trait. However, it does not disclose other potential effects like notifications or irreversibility.

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 extremely concise—two short sentences—and front-loads the main action. Every word is necessary, and there is no clutter.

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 (not shown) and the action's simplicity, the description covers the primary function. However, it lacks context about required preconditions (e.g., booking state) and side effects beyond commission calculation, leaving some gaps for an agent.

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?

With only one parameter (bookingId) and 100% schema description coverage, the schema already provides 'The booking ID to complete'. The description adds no further parameter-level information, so it meets the baseline of 3.

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

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

The description clearly states the action ('Mark a booking as completed') and identifies a side effect (triggers commission calculation). It is specific but does not explicitly distinguish from related sibling tools like confirm_booking or mark_no_show.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not specify prerequisites (e.g., booking must be in a certain state) or situations where it should not be used.

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 indicate not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds no additional behavioral context (e.g., state changes, side 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?

Single sentence, no fluff. Could be slightly more informative without losing conciseness, but currently efficient.

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?

Simple tool with one parameter and output schema. Description covers basic purpose, though missing details like confirmation side effects or error conditions. Adequate for low complexity.

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

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

The only parameter 'bookingId' is described in the schema as 'The booking ID to confirm'. The description adds no extra meaning beyond schema coverage (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 'Confirm a pending booking' clearly states the action (confirm) and resource (booking). It distinguishes from sibling tools like cancel_booking and complete_booking.

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

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

No guidance on when to use confirm instead of create, cancel, or complete. Lacks context like 'only use on pending bookings' or prerequisites.

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 indicate mutation but not destructive; the description adds context about optional enrollment but could mention uniqueness constraints or error scenarios.

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 that efficiently convey purpose and usage without redundancy, fitting the input schema's complexity.

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 high parameter count and output schema, the description provides sufficient high-level guidance; lacks details on specific parameter interactions but remains adequate.

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?

With 100% schema coverage, the description adds meaning by linking parameters like 'tierId' and 'enrollMembership' to the optional membership enrollment, going beyond bare 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 'Create a CRM account/customer' and specifies the optional membership enrollment, distinguishing it from the sibling tool 'enrol_membership'.

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 says when to use this tool (new account) and when to use 'enrol_membership' (existing account), providing clear context for 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 indicate mutable (readOnlyHint=false) and non-destructive (destructiveHint=false) behavior. The description adds 'for a member' and the workflow advice but does not elaborate on side effects like availability changes or notifications. No contradictions.

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: first states purpose, second provides essential workflow guidance. Every word contributes value, no fluff. Ideal conciseness.

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 (not shown), the description does not need to explain return values. It covers the main workflow but could mention that required parameters exist (though schema lists them). Sufficient for the complexity.

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

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

Schema coverage is 100%, and all parameters have descriptions. The description only generically mentions 'service, member, date, and time' without adding new meaning. Baseline 3 is appropriate as schema handles the detail.

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 'Create a new booking for a member' with a specific verb and resource. It distinguishes this tool from sibling tools like cancel_booking, complete_booking, and confirm_booking by focusing on the creation aspect and mentioning a prerequisite workflow.

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 advises to 'Use get_available_slots first to find valid times, then create the booking,' providing clear when-to-use guidance. It does not exclude alternatives but implies the proper workflow, earning a high score.

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 annotations (which show readOnlyHint=false), the description reveals that the broadcast is created as a draft and not sent, which is critical behavioral context. It adds the workflow step of admin review, though it could mention if repeated calls create multiple drafts.

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 uses two concise sentences, front-loading the purpose and immediately following with the key behavioral note. No wasted words, every sentence is essential.

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 has 5 parameters, nested objects, and an output schema, the description covers the core workflow (draft creation and admin review). It could optionally describe the response, but the output schema likely covers that, so completeness is adequate.

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 description. The description adds overall behavioral context (draft nature, admin review) that enhances understanding beyond individual parameter descriptions, but the parameter descriptions themselves are already clear.

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 specific action 'Create a DRAFT WhatsApp or SMS broadcast campaign' with the verb 'Create' and resource 'broadcast campaign'. It distinguishes from sibling tools like 'create_campaign' by specifying it's a draft and the channels, providing precise scope.

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 mentions that the broadcast is not sent and requires admin review, guiding when to use it (for creating drafts) and what happens after. However, it does not explicitly mention alternatives or when not to use this tool compared to similar tools like 'create_campaign'.

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 indicate non-readonly and non-destructive, so the description adds value by specifying that campaigns are created in DRAFT (consistent with schema) and providing alias details for recipientSource. It also clarifies email channelConfig beyond the schema. No contradictions, but lacks info on permissions or side 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?

Two sentences front-load the core purpose and key usage details. No extraneous information; every sentence serves a purpose. Efficiently sized for quick consumption.

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 complexity (8 params, nested object, output schema present), the description covers creation in draft, channel-specific config, and an alias. Schema captures the remaining details like status options and recipient sources. Output schema handles return values, so additional explanation is unnecessary. Slightly misses the push channel mention but overall complete.

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 covers all parameters (100% coverage), so baseline is 3. The description adds value by specifying plainTextBody as optional in email channelConfig and the recipientSource alias, which are not detailed in the schema. This enriches parameter understanding beyond the structured data.

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 it creates a marketing campaign and specifies channels (email, SMS, WhatsApp) and default status DRAFT. However, it omits the 'push' channel present in the schema, potentially causing confusion. It distinguishes from siblings like create_broadcast and update_campaign by focusing on campaign creation in draft state.

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 creating campaigns in draft but provides no explicit guidance on when to use this tool versus alternatives like create_broadcast or update_campaign. No when-not-to-use or exclusions are given, leaving agents to infer context from the tool name and schema.

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 (readOnlyHint=false, destructiveHint=false) indicate it's a non-destructive write operation. The description adds the fact that the table is flat and sub-categories need namespaced names, which is behavioral context. However, it does not mention error cases, uniqueness constraints, or the return structure despite an output schema being present.

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-loaded with the primary purpose. Every sentence adds value with zero 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?

Given the tool has 4 parameters, an output schema, and annotations, the description covers the core purpose and naming convention. It could mention uniqueness or return value, but overall it is adequate for an agent to understand the basic function.

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

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

Schema coverage is 100%, so baseline is 3. The description adds practical examples for the 'name' parameter (e.g., 'Equipment', 'Injection — Botox') and explains the naming convention for sub-categories. It does not add semantics for other parameters but the schema already handles them.

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 'Create a CMS post category' with examples like 'Equipment' and 'Injection — Botox', and distinguishes from other category tools by specifying 'CMS post category'. It also gives guidance on sub-category naming using namespaced names.

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 the tool (to create a post category) and provides guidance for sub-categories via namespaced names. It lacks explicit exclusions or comparisons with siblings but the context is sufficient for differentiation.

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 indicate readOnlyHint=false and destructiveHint=false, making the mutation nature clear. The description adds the constraint 'on an existing CRM account' but does not disclose additional behavioral traits such as potential duplicate handling or permission requirements. It does not contradict 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 a single sentence that directly states the tool's purpose with no extraneous words. It is optimally concise and front-loaded.

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 full parameter descriptions, the description is minimally adequate. However, it lacks details about prerequisites (e.g., account existence), the relationship to other contacts (especially isPrimary), and any side effects beyond creation. For a tool with 6 parameters, slightly more context would be beneficial.

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 provides descriptions for all 6 parameters (100% coverage). The description does not add any meaning beyond what the schema already offers, so baseline 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 action ('Create a contact') and the context ('on an existing CRM account'), using a specific verb+resource. It distinguishes from sibling tools like 'create_account' and 'update_contact'.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. For example, it does not clarify that the account must already exist or that 'update_contact' should be used for modifying existing contacts.

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 creates a draft and does not send, aligning with annotations (readOnlyHint=false, destructiveHint=false). It adds behavioral context beyond annotations by explaining the draft nature and inline appearance.

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 no extraneous information. Every sentence adds value: one for purpose, one for usage and behavioral caveat.

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

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

For a tool with full schema coverage and output schema, the description effectively covers purpose and usage. No gaps identified, but it does not address the return value or metadata parameter, which is acceptable given the schema.

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

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

Schema coverage is 100% with adequate parameter descriptions. The description adds no additional parameter meaning, so baseline 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 states the tool creates a draft reply suggestion that appears inline in the FavCRM Inbox composer, clearly specifying the verb and resource. It distinguishes from sibling tools by focusing on reply suggestions, which is unique among the list.

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 advises to use this tool for message.inbound events with replyPolicy='suggest' and clarifies that it does not send anything, providing clear context. However, it does not name alternative tools for other cases.

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 is consistent with annotations (readOnlyHint=false indicates mutation). It adds context: optional line items, server-side total calculation, and explicit return value. No contradictions.

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, 18 words, no fluff. Front-loaded with the primary action and returns. Every sentence earns its place.

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

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

The description adequately covers the tool's function, parameters, and return value. However, it omits prerequisites (e.g., accountId must exist) and potential error conditions. With output schema present, the gap is minor.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that lineItems are optional and that totals are computed server-side, which is not 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 uses a specific verb ('Create') and resource ('invoice'), clearly states the target ('customer'), and mentions the return of the invoiceId. This distinguishes it from sibling tools like 'create_booking' or 'create_post'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., customer must exist) or 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?

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description's 'Add a note' is consistent but adds no further behavioral context (e.g., whether notes are editable, or if there are limits). No contradiction.

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?

Single sentence with no wasted words. Front-loads the action and target, making it easy to scan.

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 note creation tool with good schema and annotations, the description covers the essential purpose and entity types. The existence of an output schema (not shown) reduces the need to describe returns, but a note about response could improve completeness.

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% with descriptions for all parameters. The description only lists entity types, which is partially redundant. No new parameter semantics 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 verb 'Add a note' and specifies the target resources: member/account, booking, ticket, or invoice. This distinguishes it from other create tools like create_ticket or create_invoice.

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

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

No guidance on when to use this tool versus alternatives (e.g., when to add a note vs create a task or write a message). No mention of prerequisites or 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?

Annotations already indicate the tool is not read-only and not destructive, implying a safe create operation. The description adds that it creates as a draft, providing context about the initial state. 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 a single, efficient sentence that immediately states the purpose and key elements. No wasted 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?

The description covers the main purpose and key fields. With output schema present, return details are not needed. It mentions draft state. However, it could provide more detail on conditions (triggerConfig) or prerequisites, but overall fairly complete for a creation 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?

With 100% schema coverage, the schema already documents each parameter. The description mentions trigger type and products with discounts, aligning with key parameters, but does not add new meaning beyond what the schema provides.

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) and resource (offer rule) and specifies it is created as a draft. It mentions key fields (trigger type, conditions, products with discounts), making it unambiguous and distinguishing from siblings like list_offer_rules or get_offer_rule.

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 explicit guidance on when to use this tool versus alternatives like create_promotion or when to use update for existing rules. The phrase 'as draft' implies initial creation, but no comparative context or exclusion criteria are given.

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

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

Annotations already indicate readOnlyHint=false, so the description's 'Create' confirms mutation. It adds useful behavioral context about the optional id parameter for legacy migration. However, it does not disclose other aspects like required permissions, rate limits, or side effects 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 two sentences, front-loaded with the core purpose, and every word earns its place. No unnecessary 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 covers the essential purpose and a specific migration feature. An output schema exists, so return value details are not needed. It is adequate for a creation tool with well-documented parameters, though it could mention prerequisites like authentication.

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 each parameter already has documented meaning. The description adds value for the id parameter by reiterating its migration purpose, but for other parameters it provides no extra semantics 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 'Create a shop outlet/location', which is a specific verb+resource pair. It distinguishes from sibling tools like 'list_outlets' and 'update_outlet' by explicitly being a creation operation.

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 creating outlets but does not explicitly contrast with sibling list, update, or other create tools. The mention of passing an id for legacy migration gives a narrow use case hint but no general guidance on when to use this tool over alternatives.

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 show readOnlyHint=false and destructiveHint=false; the description explains it creates a link (not directly mutating), but does not detail side effects like updating subscription status or Stripe API calls. With annotations covering basic safety, the description adds moderate 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 highly efficient sentences with no redundancy, front-loaded with the core action and usage condition.

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

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

With an output schema present, the description covers both use cases (new vs existing subscription) and the explicit condition for use, providing complete guidance for an agent to invoke 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 input schema has high description coverage (80%), so the description adds little beyond reinforcing the confirm requirement. Baseline 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 specifies it creates a Stripe Checkout link for new subscriptions or a Stripe Billing Portal link for existing subscriptions, and distinguishes from siblings like create_subscription or cancel_subscription by limiting usage to upgrade/billing fix requests.

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 states to use only after the user asks to upgrade or fix billing, providing clear context. However, it does not list alternatives or expressly exclude other scenarios.

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 annotations (which already indicate a write operation), the description discloses key behaviors: auto-derived excerpt from blocks if omitted, auto-generated slug with collision handling, and structured custom fields in meta validated against a schema. 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 a single paragraph that efficiently packs essential information without redundancy. It front-loads the main purpose and then provides supplementary details. Could be slightly better structured (e.g., bullet points) but remains concise and clear.

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 complexity (16 parameters, nested objects, output schema), the description covers prerequisites, key parameter behaviors, and sibling tool references. It is complete enough for an agent to understand when and how to use it effectively.

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?

With 100% schema description coverage, the baseline is 3. The description adds context for excerpt (plain-text only, auto-derived) and meta (structured, keyed by field schema) and slug auto-generation, providing value beyond the schema. Thus slightly above 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 explicitly states 'Create a new CMS post' and lists example types (blog_post, page, custom post type), making the verb and resource crystal clear. It also distinguishes itself from sibling tools like create_post_type by noting the post type must already exist.

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 explicit guidance: use list_post_types to discover existing types and create_post_type to add a new one if needed. This tells the agent when to use this tool versus alternatives, covering prerequisites and decision points.

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 indicate that this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds valuable behavioral context beyond annotations, such as the requirement to create the post type before posts, and the warning that fields are stored in meta on each post. However, it does not specify whether the operation is reversible or if there are permission requirements.

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 only three sentences, all essential. It front-loads the purpose, then provides usage sequence, and ends with a critical behavioral caveat. No wasted 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?

Given the tool's complexity (10 parameters, 3 required, output schema exists), the description covers the main workflow and constraints. However, it does not explicitly mention what the return value contains (e.g., the created post type ID), but since an output schema is present, this is partially compensated.

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

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

Since the input schema has 100% coverage for all 10 parameters, the baseline is 3. The description does not add additional meaning beyond the schema—it lists the purpose but not parameter-level constraints or syntax. For example, it doesn't elaborate on the slug auto-derivation or default values mentioned 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 explicitly states 'Define a new custom post type' with examples like 'treatment', 'service'. It clearly identifies the action (define) and the resource (custom post type), distinguishing it from sibling tools like create_post_type_field and create_post.

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 explicit when-to-use context: 'Required before creating posts of that type.' It also directs the user to a specific sibling tool for the next step: 'After creating a post type, use create_post_type_field to define its structured field schema.' This clear sequencing and exclusion of alternative uses (like using excerpt for structured data) is exemplary.

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 indicate readOnlyHint=false, so write behavior is expected. The description adds that the key becomes meta key and auto-derivation from label. It lacks info on uniqueness constraints, overwrite behavior, or permissions needed.

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, no unnecessary words, front-loaded with purpose. Efficiently conveys key 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?

Given the complexity (9 parameters, nested objects, output schema exists), the description covers the essential behavior. It could add details on duplicate key handling or field type constraints, but is largely 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?

Schema coverage is 100%, baseline 3. The description adds value by explaining that the key becomes meta key and clarifying the repeater usage pattern, going beyond the schema 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 clearly states the purpose: 'Add a custom field to a post type schema.' It also explains that the field key becomes the meta key, and distinguishes from storing data in excerpt, providing a specific verb and resource.

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

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

Provides explicit guidance for using repeater field type and advises against using excerpt for structured data. However, it does not compare to sibling tools like update_post_type_field or list_post_type_fields, missing exclusion criteria.

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 product is created as a draft, which is behavioral information not captured by annotations. Annotations provide no read-only or destructive hints, so the description helps by indicating the creation is not immediately activating the product.

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 conveys the key information without unnecessary words. It is front-loaded with the action and resource.

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 high schema coverage and the presence of an output schema, the description is fairly complete. However, it could mention that activation is required post-creation, but that is already implied by 'as DRAFT'.

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

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

Schema description coverage is 100%, so the schema already explains parameters thoroughly. The description adds no additional meaning beyond implying that price and memberPrice are decimal strings, which is already 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 ('Create'), the resource ('a new shop product'), and the initial state ('as DRAFT'). It effectively distinguishes from sibling tools like create_product_category by specifying the resource type.

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 context that the product is created as a draft and that the merchant can review and activate it from the portal. This implies a workflow step but does not explicitly state when to use this tool versus alternatives like update_product.

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 indicate this is a mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the creation behavior and subcategory hint, but does not disclose additional aspects like required permissions or side effects. The description provides marginal added value beyond 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, front-loads the core action, and includes a helpful usage hint. Every sentence serves a purpose; no wasted 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?

Given the presence of an output schema (not shown), the description does not need to explain return values. It covers the main action and subcategory use case. It could mention prerequisites (e.g., parent category existence), but it's reasonably complete for a simple creation 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?

Input schema has 100% coverage with descriptions for all 5 parameters. The description reinforces the parentId parameter for subcategories, but does not add significant new semantics beyond what the schema already provides. Baseline 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 'Create a product category', using a specific verb and resource. It distinguishes from other create tools by specifying 'product category' and hints at subcategory creation via parentId, which adds clarity.

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 a clear context for usage: create a product category, and use parentId for subcategories. However, it does not explicitly exclude use cases for sibling tools like create_category, so it lacks direct when-not guidance.

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

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

Annotations (readOnlyHint=false, destructiveHint=false) indicate it's a write operation, and the description adds the server-side uppercasing of codes. However, it lacks details on permissions, idempotency, or behavior on duplicate codes. Some behaviors are disclosed but not comprehensively.

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 provide the core purpose and critical parameter clarifications. Every word serves a purpose; no redundancy or unnecessary 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?

Given the tool has 17 parameters and an output schema, the description covers the essential aspects of creating a promotion. It explains the key parameters (type, value, code) but doesn't delve into optional parameters. An output schema exists, so return values need not be described. Overall, it provides sufficient context for correct usage.

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?

With 100% schema description coverage, the baseline is 3. The description adds value by clarifying the type enum meanings, giving an example for value, and noting code uppercasing. This goes beyond just repeating schema descriptions.

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

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

The description clearly states the tool creates a promotion/discount code, specifies the two possible types (percentage or fixed_amount), and explains how value is interpreted. It distinguishes itself from sibling tools like update_promotion, delete_promotion, list_promotions, and validate_promotion.

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

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

The description provides no guidance on when to use this tool versus alternatives like update_promotion or validate_promotion. No prerequisites, conditions, or typical use cases are mentioned.

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 provide no safety profile (no readOnlyHint, destructiveHint, etc.), and the description only says 'create' but doesn't disclose side effects, permissions needed, or whether creation is reversible. For a mutation tool, this is insufficient.

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 short sentences, no fluff, front-loaded with the action and context. 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?

Covers core purpose and usage context; output schema exists so return value is documented. Could mention constraints like name uniqueness, but overall adequate for a creation tool with 5 well-described params.

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% with detailed parameter descriptions. The description adds no extra meaning beyond the schema, so baseline 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?

Description clearly states 'Create a bookable resource' with examples (room, equipment, vehicle), distinguishing it from siblings like list_resources and link_resource_to_service.

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

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

Explicitly states 'Used by services that have requiresResource=true', providing clear context for when to use this tool. Does not mention alternatives or exclusions, but the usage context is well-defined.

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 only provide basic read/write hints; the description does not disclose side effects, permissions, or any behavioral traits beyond creation.

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

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

Two sentences, front-loaded with purpose, no wasted words; excellent conciseness.

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

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

Covers core purpose and type distinction; output schema exists but description doesn't mention return values, which is acceptable.

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 covers all parameters; description adds context by explaining the type distinction and criteria usage, which adds value 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 (create) and resource (customer segment), and distinguishes between STATIC and DYNAMIC types, which helps differentiate from other create 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?

Provides explicit guidance on when to use STATIC vs DYNAMIC, but lacks alternatives for updating segments or other scenarios.

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 indicate destructiveHint=false and readOnlyHint=false, so the description's mention of 'Create' adds little beyond acknowledging mutation. It doesn't detail permissions, side effects, or error conditions.

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

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

Two concise sentences with front-loaded purpose and a usage hint. Every sentence earns its place with no wasted 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?

Given the output schema exists and the complexity of 20 parameters, the description covers the main aspects and provides a necessary prerequisite. However, it could mention default behaviors or success criteria, though not strictly required.

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 schema already documents all parameters. The description provides a high-level summary but doesn't add meaning beyond the schema, resulting in a baseline score of 3.

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

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

The description clearly states the tool creates a bookable service and lists key attributes (duration, price, capacity, policies). It also distinguishes from sibling tools like create_service_category by mentioning the prerequisite step.

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 advises to use list_service_categories first when attaching to an existing category, providing a helpful prerequisite. However, it doesn't explicitly state when not to use or compare with alternatives.

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 indicate it's not read-only, not destructive, etc. Description adds minimal behavioral context (examples of categories) but does not discuss side effects, duplicate handling, or authorization. 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?

Single concise sentence with efficient front-loading of verb and object. No wasted 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 creation tool with well-documented parameters and an output schema, the description covers the essential purpose. Lacks usage guidelines but is otherwise complete.

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 all parameters are documented in the schema. Description does not add additional meaning beyond the schema, but provides a context example for category names. Baseline 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?

Clearly states the verb 'Create' and the specific resource 'service category' with an example ('Treatments', 'Classes') and purpose 'to group bookable services.' Differentiates from sibling 'create_category' by specifying 'service' category.

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

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

No guidance on when to use this tool vs. alternatives like 'create_category' or 'create_product_category.' No explicit when-not or prerequisites provided.

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 indicate the tool is not readOnly, not destructive (destructiveHint=false), and not idempotent. The description adds little beyond the obvious 'Create' action; it does not disclose side effects, authentication requirements, rate limits, or state that the package is immediately active. The agent must infer behavior from the schema and name.

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, concise and front-loaded with the core purpose. Every word is meaningful; no redundancy or filler. It efficiently communicates the essential 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?

Given the complexity (8 parameters, output schema exists), the description is adequate but not exhaustive. It covers the primary purpose and a key parameter usage, but lacks context such as prerequisites (e.g., services/events must exist), typical use cases, or explanation of other parameters like status or description. The output schema exists, so return value details are not required.

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% with descriptions for all 8 parameters. The description adds value by explaining the relationship between applicableType=SELECTED and applicableItems, clarifying their combined use for limiting to specific services/events. This semantic hint goes beyond the schema's default values and 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 creates a 'service package/prepaid session bundle', specifying the verb and resource. It distinguishes from sibling tools like create_service or create_product by focusing on bundled prepaid sessions. The addition of 'Use applicableType=SELECTED with applicableItems to limit the package to specific booking services or events' further clarifies its role.

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

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

The description provides explicit guidance on using applicableType=SELECTED with applicableItems to limit the package scope, which is helpful for correct invocation. However, it does not mention when not to use this tool or recommend alternatives like other create_ tools, leaving some ambiguity about usage boundaries.

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 indicate readOnlyHint=false and destructiveHint=false; description adds no further behavioral context (e.g., conflict handling, overwrite behavior, constraints).

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?

Single sentence is concise, front-loaded with the core action, no unnecessary 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?

Despite output schema existing, the description is too brief for a tool with 12 params (including staffId, resourceId, recurrence details). Lacks high-level context for optional parameters.

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

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

Schema coverage is 100%, so baseline is 3. Description does not add meaningful semantics beyond the schema (e.g., interaction between recurrence and byWeekday is not explained).

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

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

Description clearly states 'Create a bookable schedule window for a service' with recurrence specifics, distinguishing it from siblings like 'update_service_schedule' and 'list_service_schedules'.

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?

Implies usage for setting up service availability but lacks explicit guidance on prerequisites or when to use vs. alternatives like 'set_staff_availability' or 'update_service_schedule'.

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 provide no behavioral clues beyond readOnlyHint=false and destructiveHint=false. The description adds that it creates a recurring subscription and allows tier or custom settings, but lacks details on side effects (e.g., billing immediately, sending notifications, permissions required). Given the financial nature, more transparency would be beneficial.

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 short sentences, front-loaded with the action. No wasted words; every sentence adds value. Appropriate length for the tool's complexity.

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 the main purpose and parameter relationships. It does not describe what happens after creation (e.g., confirmation, immediate start) or mention defaults like autoRenew, but the schema handles parameter defaults. Slightly more behavioral context would elevate completeness.

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% with descriptions for all 8 parameters. The description adds meaningful context by linking parameters into two usage modes (tier vs. custom amount+cycle), which helps the agent understand how parameters relate beyond individual 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 action ('Create'), resource ('recurring subscription'), and scope ('for a member'). It distinguishes itself from siblings like cancel_subscription, pause_subscription, and get_subscription by emphasizing creation and binding to a membership tier or custom cycle.

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 creating new subscriptions and outlines two modes (tier-based or custom). It does not explicitly exclude other scenarios or provide alternatives, but the context is clear enough for an agent to infer when to use this tool.

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

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

Annotations already indicate readOnlyHint=false (mutation) and destructiveHint=false. The description adds that the survey can be published immediately or later, providing minimal behavioral context beyond what annotations offer. No mention of permissions, side effects, or other 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 two sentences with no wasted words. It front-loads the core purpose and provides a key usage hint about publishing. Every sentence earns its place.

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

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

Given the tool's complexity (9 parameters, nested objects) and the existence of an output schema, the description is adequate but not comprehensive. It covers the main use cases but omits details like required fields (title, questionBlocks) and optional parameters. The schema fills some gaps, but more complete description would improve the agent's understanding.

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% with descriptions for all 9 parameters. The description adds value by linking 'custom question blocks' to the questionBlocks parameter and mentioning the status parameter's behavior. This goes beyond the schema's descriptions, justifying a score above baseline 3.

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

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

The description clearly states the action 'Create a survey' and specifies it involves 'custom question blocks'. It is a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools like update_survey or create_survey_invitation, missing an opportunity to distinguish.

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

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

No guidance on when to use this tool versus alternatives. The hint about publishing later or immediate is about the status parameter, not about tool selection. The description lacks when-to-use and when-not-to-use 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?

Annotations are minimal (readOnlyHint=false, destructiveHint=false). The description adds 'token-auth' but does not disclose key behaviors like whether the invitation is sent immediately, authorization requirements, or side effects. More context beyond annotations is needed.

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 sentence of 14 words, no unnecessary words, front-loaded with action and resource. Extremely 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?

Given the complexity (9 parameters, some required, nested objects), the description is too sparse. It does not explain which parameters are required, how accountId vs. contactId interplay, or the purpose of recipient fields. Output schema exists but description should still provide enough context for parameter selection.

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 parameters are documented. The description adds some context by linking 'member/account or contact' to accountId/contactId, but does not explain the relationship between channel and recipient fields. Baseline 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 creates a token-auth survey invitation for a specific member/account or contact, using strong verb 'Create' and specific resource. It effectively distinguishes from sibling create_* tools by focusing on survey invitations.

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 creating survey invitations but provides no explicit guidance on when to use this tool versus alternatives (e.g., other invitation tools) or when not to use it. It lacks exclusion criteria or 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?

Annotations indicate readOnlyHint=false, so the mutation is expected. The description adds no extra behavioral detail beyond 'Create', which is sufficient but minimal.

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 front-loads the main action and optional parameters. No wasted 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 acreate tool with 7 parameters and an output schema, the description is adequate but lacks details on behavior (e.g., idempotency, duplication handling). It covers the essential 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?

Schema coverage is 100% with descriptions for all 7 parameters. The description does not add semantic value beyond what the schema already provides, meeting 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 ('Create') and resource ('a task'), with optional linking to CRM account or team member. It effectively distinguishes this tool from siblings like update_task or create_ticket.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions optional linking but lacks context on prerequisites, exclusions, or when not to use.

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 behavioral context beyond annotations: it specifies the return of a one-time accept token and the required verification process. It could further disclose side effects (e.g., email sending) or the creation of a pending invite record, but the provided information is sufficient.

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-loaded with the main action and return value. Every sentence adds value, and there is no superfluous 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?

Given the tool's complexity (multi-step verification) and the presence of an output schema, the description covers the essential workflow. It could be more complete by noting the pending state of the invite or the expiration, but it is still informative.

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 baseline is 3. The description does not add parameter-specific meaning; it only provides high-level context. The schema already documents each parameter adequately.

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: 'Invite a team member to this company and return a one-time MCP accept token.' It uses a specific verb and resource, and distinguishes from siblings by referencing the verification workflow (accept_team_invite_request and accept_team_invite_verify).

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 by explaining the required subsequent steps (verification through accept_team_invite_request and accept_team_invite_verify). However, it does not explicitly exclude alternative tools or state when not to use this one.

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 provide readOnlyHint=false and destructiveHint=false, but the description adds no additional behavioral context (e.g., permissions, side effects, or that the ticket may be sent for processing). It does not exceed what the annotations already convey.

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