Server Quality Checklist

Tool Scores

• list_scheduledA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces read-only behavior with 'Read-only, 0 credits.' It adds valuable context beyond annotations by explaining the per-channel outcome reporting ('Each fired item reports PER-CHANNEL outcomes'), which tells the agent exactly how results are structured and avoids a misleading single verdict. 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.

  Conciseness5/5

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

  The description is two sentences. The first sentence immediately states the core purpose, and the second adds a crucial behavioral detail (per-channel outcomes) plus a cost note. Every word earns its place, with no fluff. Front-loaded and efficient.

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

  Completeness4/5

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

  For a simple, parameterless listing tool, the description covers the key purpose and the most important nuance (per-channel outcomes). It also mentions read-only and 0 credits. However, it omits potential details like pagination, date ranges, or whether all items are included, but given the simplicity and the absence of an output schema, these are not critical gaps.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema coverage is 100% trivially. Per the rubric, a baseline of 4 is appropriate for 0-parameter tools. The description adds no parameter information, but none is needed.

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

  Purpose4/5

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

  The description clearly states the tool's scope: 'Show what is queued to post and what already went out.' It uses a specific verb (show) and resource (scheduled and past posts). However, it does not differentiate from the sibling list_published_posts, which might overlap with 'what already went out', so an agent may not know which to pick without further investigation.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives like list_published_posts, schedule_post, or cancel_scheduled. It does not state when not to use it or mention any exclusions. The only hint is the implicit purpose, but that is not sufficient for an agent to confidently choose this tool over siblings.

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

• set_auto_reloadA
  3.7/5.0
  Behavior4/5

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

  The description adds behavioral context beyond the annotations: it explains the operation runs server-side even without the app open, requires a saved card, and that members are blocked with a specific message. It also mentions the tool will guide the user if no card is present. Annotations already indicate idempotent and non-destructive, and the description aligns without contradicting. These extra details help the agent anticipate side effects and prerequisites.

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

  Conciseness4/5

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

  The description is moderately long but front-loaded with the primary action and then elaborates on prerequisites and access control. Each sentence adds meaningful information: the server-side behavior, the card requirement, the member restriction. It is not overly verbose and the structure is logical, though it could be tightened slightly without losing value.

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

  Completeness4/5

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

  For a tool with no output schema and three parameters, the description covers the key conditions: admin-only access, prerequisite of a saved card, server-side execution, and member handling. It also references buy_credits for pack-size details. It does not explicitly state the return value or error handling, but given the tool's simplicity and lack of output schema, this is adequate. The description is sufficiently complete for an agent to call it correctly.

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

  Parameters3/5

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

  The input schema provides 100% description coverage for all three parameters, so the baseline is 3. The description does not add additional parameter-specific semantics beyond what the schema already states. It does frame the threshold and top-up concept in the narrative, but that is more contextual than parameter-explanatory. No extra meaning is provided for the parameters themselves.

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

  Purpose4/5

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

  The description clearly states the action ('Turn automatic credit reloads on or off') with a specific resource (credit reloads) and scope (admin only). It provides context about the mechanism (threshold, top-up pack, server-side). However, it does not explicitly distinguish itself from sibling tools like buy_credits or billing_status, so it lacks direct differentiation but still conveys a precise purpose.

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

  Usage Guidelines3/5

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

  The description gives some usage guidance: it mentions the tool is admin-only and that members (read-only billing) receive an 'ask an admin' message, which indicates who should not use it. It also states the prerequisite of a saved card and notes that without one the tool guides the user. However, it does not explicitly compare with alternatives or state when to use this tool versus manual top-ups or buying credits, so the guidance is partial.

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

• mine_anglesA
  3.8/5.0
  Behavior1/5

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

  The description contradicts the annotation readOnlyHint=true by stating that passing brandId 'switches this key's active brand like use_brand', which is a state mutation. Since annotations declare the tool read-only, this is a direct contradiction. The description also adds credit cost, which is useful, but the contradiction is severe and lowers this score to 1.

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

  Conciseness4/5

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

  The description is dense but well-structured, front-loading the core action and then using a dash list for the output components. Every sentence provides useful information, but it is somewhat long and could be trimmed without losing meaning. It is efficient and easy to scan, earning a 4 rather than a 5.

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

  Completeness5/5

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

  The description fully explains what the tool returns (a ranked angle bank with tags, quotes, score, and hook) and the input (brandId or active brand). It also notes the credit cost. Since there is no output schema, the description carries the full burden of informing the agent about the result structure, and it does so comprehensively.

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

  Parameters3/5

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

  The schema already fully describes the single parameter brandId (including the 'omit to use the active brand' behavior), so schema coverage is 100%. The description adds the nuance about switching the active brand, but that is more of a behavioral side effect than parameter semantics. It does not clarify formats or types beyond the schema, so a baseline 3 is appropriate.

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

  Purpose5/5

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

  The description states a highly specific purpose: mining ad angles from real customer language across multiple sources, with a detailed output specification (ranked angle bank, tags, proof quotes, score, hook). It clearly distinguishes itself from the sibling competitor_teardown by naming it explicitly. The verb 'mine' and resource 'customer language' leave no ambiguity about what the tool does.

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

  Usage Guidelines5/5

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

  The description explicitly tells when to use this tool (for your own brand, with optional brandId) and when not to (for competitors, use competitor_teardown). It also notes the optionality of brandId and the side effect of switching the active brand, giving the agent clear decision criteria without needing to inspect other tools.

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

• search_threadsA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds value by disclosing the cost ('Spends about a credit') and the exact return format (compact JSON fields per post), which is useful behavioral context not present in the schema or annotations.

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

  Conciseness5/5

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

  Two tight sentences front-load the purpose and endpoint, then deliver return format and cost. There is no filler or redundancy; every sentence earns its place.

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

  Completeness4/5

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

  The description compensates for the lack of an output schema by specifying the per-post JSON fields. It also covers cost and use case, which is sufficient for a low-complexity read-only tool. Minor gaps like rate limits and pagination details remain, but they are not critical given the schema already documents limit defaults.

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

  Parameters3/5

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

  Schema description coverage is 100%: both parameters (`query` and `limit`) have descriptions in the schema. The description does not add parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

  Purpose4/5

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

  The description clearly states a specific verb ('search'), a resource ('Organic Threads keyword search'), and an endpoint, with an explicit use case ('trend + voice research'). However, it does not explicitly differentiate from the sibling tool 'search_threads_keyword', which appears to serve a nearly identical purpose, so it misses full sibling distinction.

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

  Usage Guidelines3/5

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

  The description provides the intended context ('short-form text/social posts for trend + voice research') but does not mention when to avoid using it or name any alternatives. There is no explicit guidance about choosing this over search_threads_keyword, search_instagram_hashtag, or other search tools.

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

• set_roleA
  3.8/5.0
  Behavior2/5

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

  The description states that confirm:true must be passed, but the schema does not list confirm as required, creating a conflict that could mislead an agent into omitting it. This is a behavioral hazard. The description does add context about roles (admin has billing access, member is read-only on billing) beyond the annotations, but the confirm discrepancy undermines transparency. No other behavioral traits (e.g., error handling, idempotency implications) are disclosed.

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

  Conciseness4/5

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

  The description is concise, two sentences, and front-loaded with the action. The first sentence states the action and role distinctions; the second adds the confirmation instruction. It's efficient without excess, though the confirmation instruction could be clearer about it being a mandate rather than optional.

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

  Completeness3/5

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

  For a simple role-change tool, the description covers the essentials: what changes, role meanings, and the need for confirmation. However, it omits expected behaviors like validation (e.g., what if email doesn't exist) or the response/return value. Since there is no output schema, the agent has no idea what the tool returns. The confirm conflict also affects completeness. Overall, adequate but with gaps.

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

  Parameters4/5

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

  The description adds meaningful value to the parameters: it defines what 'admin' and 'member' mean (full access incl. billing vs read-only on billing), and reiterates that confirm must be true. The schema already describes all three parameters with 100% coverage, but the description enriches the enum semantics and the confirmation requirement, going beyond the schema's basic descriptions.

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

  Purpose5/5

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

  The description clearly states the action ('Change a workspace member’s role') and specifies the resource (workspace member) and the two role options (admin vs member) with access details. It distinguishes itself from sibling tools like invite_member or remove_member by focusing on role modification. No ambiguity about what the tool does.

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

  Usage Guidelines4/5

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

  The description explains when to use it: a privilege change that requires confirmation with the user. It implies that the agent should confirm the person and new role before invoking. However, it does not explicitly mention alternatives or when not to use it, though the context of 'privilege change' is a clear indicator. The guidance is present but not exhaustive.

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

• update_onedrive_fileA
  3.8/5.0
  Behavior3/5

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

  The description is consistent with the annotations (readOnlyHint=false implies a mutation; destructiveHint=false and idempotentHint=true align with rename/move being non-destructive and repeatable). No contradiction. However, it adds little beyond what the operation name and annotations already imply—it doesn't disclose outcome behavior for partial success, reversibility, or what happens if both rename and move are combined, though the 'and/or' phrasing implies these are possible.

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

  Conciseness5/5

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

  Two tightly written sentences, front-loaded with the operation, then id sourcing, then the sibling alternative for deletion. Zero filler words; every clause earns its place.

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

  Completeness4/5

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

  For a 3-parameter tool with full schema coverage, present annotations, and no output schema, the description adequately covers the operation, parameter sourcing, and the route to the removal sibling. An agent can call it correctly with what's provided. Minor gap: it doesn't explicitly confirm that rename and move can be combined in one call.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents fileId, name, and moveToFolderId with descriptions. The description reinforces the rename/move mapping and clarifies the id source ('from list_onedrive_files'), which is mildly additive. With full schema coverage, the baseline of 3 applies since the description doesn't need to compensate for missing param docs.

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

  Purpose4/5

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

  The description states a specific operation ('Update a OneDrive item: rename (name) and/or move it into a folder (moveToFolderId)') with clear verbs and resources. It also names the sibling to use for the inverse operation (delete_onedrive_file), which helps distinguish it. It doesn't contrast with other related siblings like get_onedrive_file or convert_onedrive_file, but the core purpose is unambiguous.

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

  Usage Guidelines4/5

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

  Provides an explicit exclusion ('To remove an item, use delete_onedrive_file') and a sourcing hint ('Pass fileId (from list_onedrive_files)'). This routes the agent away from the wrong sibling for deletion and tells it where to obtain the required id. It stops short of enumerating the full set of siblings or stating exact conditions for move vs rename, but the guidance present is useful.

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

• draft_brandA
  3.9/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=false and destructiveHint=false, and the description adds meaningful context beyond that: it's 0 credits, it cannot ask the user (caller owns verification), and it warns that a domain can resolve to a different company than intended (bala.com vs shopbala.com). This discloses a real failure mode and the save:false workflow, which no annotation conveys.

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

  Conciseness4/5

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

  The core purpose is front-loaded in the first sentence, and the IMPORTANT paragraph is justified because it flags a critical verification pitfall that materially affects correct invocation. Slightly long, but each segment (purpose, credit cost, domain-mismatch warning, save semantics) earns its place.

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

  Completeness4/5

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

  For a 5-parameter tool with no output schema and minimal annotations, the description covers the input sources, the ambiguous-domain risk, the save semantics, and the credit cost. It could add the exact return shape beyond the partial {name, products, logo, …}, but what's needed to call it correctly and safely is present.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all five parameters (save, domain, platform, description, socialHandle) are already documented in the schema. The description names the three input sources and references save:false, which lightly reinforces parameter meaning, but adds little beyond what the schema provides — the baseline 3 for high coverage applies.

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

  Purpose5/5

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

  The description states a specific verb ('onboard a brand profile'), the resource (brand), three input sources (domain, free-text description, social handle), and the output shape ({name, products, logo, …} object). It clearly distinguishes itself from sibling brand tools (create_brand, update_brand, get_brand) by describing the draft-from-source behavior, so an agent can tell it apart without opening sibling schemas.

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

  Usage Guidelines3/5

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

  The description gives workflow guidance — results can be passed to plan_ad/generate, and the caller should verify name/summary and re-draft with save:false until confirmed. However, it never explicitly contrasts draft_brand with the sibling create_brand/update_brand tools or states when to pick one over the other, so the 'when to use vs alternative' guidance is implied rather than stated.

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

• list_google_business_questionsA
  3.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description explicitly says 'Read-only, 0 credits', reinforcing the safety profile. It adds valuable behavioral context: the interpretation of unanswered questions ('read as "this business does not respond"'), the fact that the reply names those unanswered, and the prerequisites. This goes beyond the annotations and explains subtle semantics that affect how an agent should interpret results.

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

  Conciseness4/5

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

  The description is three sentences, front-loaded with the main purpose immediately. It packs in essential details (data content, interpretation of unanswered questions, read-only/credit cost, prerequisites) without unnecessary fluff. It earns each sentence and is appropriately sized.

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

  Completeness3/5

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

  The tool is a simple read-only list with no output schema and three optional parameters. The description covers the data semantics and prerequisites but omits guidance on pagination (pageToken) and location targeting (locationId). For a tool with no output schema, the description should compensate for missing return details, but it does not explain the overall shape of the response or how the parameters interact. Adequate but with clear gaps.

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

  Parameters2/5

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

  Schema coverage is only 33% (only 'limit' has a description), and the description does not explain 'pageToken' or 'locationId' at all. The description does mention 'the brand’s Google Business Profile listing' but never ties that to the locationId parameter, leaving an agent to infer how to target a specific listing. With low schema coverage and no guidance in the description, parameter semantics are a significant gap.

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

  Purpose5/5

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

  The description states a specific verb ('list') and resource ('questions on a Google Business Profile listing'), and details what is returned (questions, answers, upvotes). It clearly distinguishes from siblings like list_google_business_reviews or list_google_business_posts by focusing on Q&A. The mention of 'the reply names the ones with no answer at all' also conveys the tool's scope precisely.

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

  Usage Guidelines3/5

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

  The description gives clear context for what the tool does and notes prerequisites ('Needs Google Business Profile connected and the project approved'). However, it does not explicitly state when to prefer this over related tools (e.g., answer_google_business_question) or provide exclusion criteria. The usage guidance is implied but not articulated as a comparison.

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

• list_swipefileA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that it lists 'every named collection' and the exact fields returned, plus the note that it's the 'SAME board' as the web app. It also says 'free,' which is not in annotations. While these are useful, they don't go far beyond what a read-only list operation implies given the schema. No auth, rate limits, or pagination details are mentioned, but those are not critical given 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.

  Conciseness4/5

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

  The description is front-loaded with the core action and resource, then lists returned fields, ties it to the web app, gives use cases, and concludes with read-only/free. Each sentence adds value, though it could be slightly trimmed. Overall, it's well-structured and not bloated.

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

  Completeness4/5

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

  For a simple list tool with no output schema, the description adequately covers what the tool returns (explicit field list), when to use it (use cases), and its read-only nature. It doesn't describe errors or edge cases, but the schema handles parameters. Given the low complexity and schema coverage, this is sufficient.

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

  Parameters3/5

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

  The schema covers both parameters (limit and collection) with descriptions, so schema_description_coverage is 100%. The tool description does not elaborate on parameter behavior beyond what the schema states. The phrase 'every named collection' implicitly relates to the collection filter, but it adds no new semantics. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb ('List'), a clear resource ('this workspace's SWIPEFILE'), and defines what that resource contains: every named collection and the ads/creatives with fields like advertiser, headline, body copy, media URL, platform, save date, and taste tags. It also explicitly ties it to the web app's Swipefile tab, making the scope unambiguous. This clearly distinguishes it from siblings like save_to_swipefile, which writes, and export_swipefile_deck, which exports.

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

  Usage Guidelines4/5

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

  The description gives explicit use cases: answering 'what have we saved?', mining the user's own taste before planning an ad, or finding a reference to remix. It also notes the tool is read-only and free. However, it does not explicitly name alternative tools for contrasting use or state when not to use this tool, though the use cases are concrete enough to guide an agent.

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

• pinterest_targeting_analyticsA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only, 0 credits' without contradiction. The description adds genuine behavioral context beyond the annotations: the 90-day lookback with max-90-day windows refused with reason, and unknown targeting types being refused BY NAME with per-level enum differences. This materially helps an agent predict failure modes.

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

  Conciseness3/5

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

  Every clause earns its place, covering the required param, scope semantics, date windows, and error behavior. However, it is long and written as dense rambling prose rather than terse structured guidance; the wordiness slightly hurts scannability for an agent parsing the description.

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

  Completeness3/5

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

  For a 10-parameter tool with no output schema and very low schema coverage, the description covers the critical required parameter and key error/date semantics (refusals, lookback window, per-level enums). But it says nothing about the return shape, and the since/until/columns/granularity/id parameters remain undocumented. Given the tool's complexity, this is a solid but incomplete treatment.

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

  Parameters3/5

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

  Schema description coverage is only 20% (targetingTypes and scope carry descriptions), so the description must compensate. It does explain targetingTypes and scope meaningfully, but since/until/columns/granularity accept a 'default account' and the id lists are left semantically unaddressed. The description partially compensates for the coverage gap but stops short of documenting the remaining eight parameters.

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

  Purpose5/5

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

  The description opens with the pointed question 'WHICH AUDIENCE SEGMENT actually delivered on Pinterest' and enumerates the breakdown dimensions (keyword, targeted interest, age bucket, gender, location, region, country, placement, app type, media type). This is a specific verb-resource-scope statement that clearly differentiates from generic siblings like pinterest_analytics by centering on audience segmentation via targetingTypes.

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

  Usage Guidelines4/5

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

  The description explicitly states that targetingTypes is REQUIRED and explains why (it is the breakdown dimension). It gives precise scope semantics — account covers the whole account, while campaign/adGroup/ad each require their own id list — and flags that Pinterest ships no all-of-them form at those levels. It doesn't name an explicit sibling alternative to prefer instead, but the when/how conditions are concrete.

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

• react_to_bluesky_dmA
  3.9/5.0
  Behavior4/5

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

  The description discloses meaningful behaviors beyond the annotations: it enforces the one-emoji rule locally, reports the reaction state as read back from Bluesky rather than the requested one, and notes it is free. These details help the agent anticipate validation and result behavior. Annotations (readOnlyHint: false, destructiveHint: false) are consistent and do not contradict the description.

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

  Conciseness4/5

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

  The description is front-loaded with the core function, then adds context about the one-emoji rule, return behavior, and cost. It is slightly wordier than necessary (e.g., 'a paragraph back would be worse than a thumbs-up') but remains efficient and well organized, with no wasted sentences.

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

  Completeness4/5

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

  For a simple mutation tool with four parameters and no output schema, the description covers the key aspects an agent needs: the action, the one-emoji constraint, the reported return value, and the cost implication. It does not mention error scenarios (e.g., invalid convoId) or authentication specifics, but these are less critical given the schema and annotations.

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

  Parameters3/5

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

  The schema provides full descriptions for all four parameters, including exactly-one-emoji guidance for value and the toggle behavior for remove. The tool description reinforces the one-emoji rule but adds no new parameter-level details beyond what the schema already covers, so it sits at the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the verb and resource: add or remove an emoji reaction on a single Bluesky DM. It distinguishes the tool from sending a reply by framing it as a light acknowledgement, but it does not explicitly mention sibling tools like send_bluesky_dm or read_bluesky_dm, so it stops short of full differentiation.

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

  Usage Guidelines4/5

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

  The description provides concrete usage context: use this for quick acknowledgements like a 'thanks' where a written reply would be excessive. It implies when not to use a text reply but does not explicitly name an alternative tool or state conditions that rule it out, so the guidance is useful but not exhaustive.

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

• recast_motionA
  3.9/5.0
  Behavior3/5

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

  Annotations provide no safety hints (all false), so the description carries the burden. It discloses that it is a paid render, which is a meaningful behavioral trait (cost). It also clarifies the input roles (motion vs identity) but does not mention output format, async behavior, or other side effects. While it adds some value beyond annotations, it leaves significant behavioral gaps for a generation tool.

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

  Conciseness5/5

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

  The description is three sentences, with the core purpose front-loaded ('Motion transfer'), followed by a clarifying analogy and a cost warning. Every sentence earns its place without redundancy. It is appropriately sized and easy to parse.

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

  Completeness3/5

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

  For a tool with 4 parameters and no output schema, the description covers the core concept and input roles but omits output expectations (e.g., whether it returns a video URL or a job ID) and potential prerequisites or limitations. Given the complexity of a paid generation task, more detail would be helpful, though the schema covers parameter specifics. This is adequate but not complete.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds conceptual clarification beyond the schema: 'The reference clip drives the movement; the image supplies the identity' reinforces the roles of the video and image parameters. This goes beyond the schema's literal descriptions and helps the agent understand the relationship, so a 4 is warranted.

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

  Purpose5/5

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

  The description clearly states the tool does motion transfer: it re-performs a reference video's motion with a different person/character, using the image for identity. This is a specific verb-resource pair that distinguishes it from other video tools like generate_video or generate_avatar. The mention of 'Paid render' adds a crucial operational detail. The description leaves no ambiguity about what the tool does.

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

  Usage Guidelines3/5

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

  The description implies the use case: when you have a reference video motion and want to apply it to a different subject. However, it does not explicitly state when to prefer this over alternatives, nor does it provide exclusions or conditions (e.g., when to use generate_video instead). The context is clear but there is no explicit guidance on alternative tool selection, so it earns a mid-range score.

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

• update_brandA
  3.9/5.0
  Behavior4/5

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

  Since all annotations are false, the description carries the full burden of behavioral disclosure. It explicitly says 'Patch SPECIFIC fields ... WITHOUT overwriting the rest — a read-modify-write on the saved brand', which clearly reveals the partial-update behavior. This is strong transparency, though it does not disclose idempotency or error handling.

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

  Conciseness5/5

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

  The description is concise and well-structured: a main action sentence, two usage examples, and a pointer to an alternative tool. It is front-loaded with the critical behavior (patch without overwrite) and contains no redundant information.

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

  Completeness3/5

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

  The description explains the patching behavior and provides usage examples, but it does not specify which brand is being updated (implicitly the current workspace brand, given sibling tools like list_brands and use_brand). It also does not mention any return value or error behavior, and there is no output schema. These gaps leave the invocation context incomplete.

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

  Parameters3/5

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

  The description lists all 10 patchable fields, which helps the agent know what can be updated, and adds the practical instruction 'Only pass the fields you're changing'. However, with only 60% schema coverage, it does not compensate for the four undocumented parameters (name, audience, category, positioning) by providing semantic explanations; it merely names them.

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

  Purpose4/5

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

  The description clearly states the tool patches specific fields of the workspace brand profile without overwriting the rest, and lists the fields in parentheses. However, it does not differentiate itself from the sibling 'change_voice', which could be a more specialized tool for voice changes, leaving some ambiguity for the agent to decide between them.

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

  Usage Guidelines4/5

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

  The description gives explicit usage examples ('change our voice to playful', 'we sell to dentists now') and points to 'draft_brand' for full onboarding, which is a clear alternative. It also instructs to pass only changed fields. It does not, however, mention other alternatives like 'change_voice', so the guidance is not fully comprehensive.

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

• youtube_channelA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with this by using 'Read'. Beyond that, the description adds the prerequisite that a connected channel is needed and specifies the exact data fields returned. This provides useful context without contradicting annotations.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the primary action and resource. Every clause earns its place, covering the action, data returned, purpose, and prerequisite without waste.

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

  Completeness4/5

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

  Given the low complexity (no parameters, read-only, no output schema), the description is adequate. It states the prerequisite and the data returned. A minor gap is not mentioning what happens if no channel is connected, but the prerequisite statement covers the main condition.

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

  Parameters4/5

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

  There are zero parameters, so schema coverage is trivially 100%. The baseline for 0 parameters is 4, and the description does not need to explain any parameter semantics. It correctly focuses on the operation and outcome.

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

  Purpose4/5

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

  The description clearly states the verb 'Read' and the resource 'the brand's connected YouTube channel', and specifies the data returned (title, counts). It is specific enough for an agent to understand the tool's scope, though it does not explicitly contrast with sibling tools like youtube_channel_report or youtube_bulk_report, so it misses the highest bar for differentiation.

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

  Usage Guidelines3/5

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

  The description implies usage for reporting ('for reporting') and states a prerequisite ('Needs a connected YouTube channel'). However, it does not explicitly mention when to choose this tool over alternatives like youtube_channel_report or youtube_bulk_report, offering no exclusion or alternative guidance.

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

• generate_avatarA
  4/5.0
  Behavior4/5

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

  The description discloses important behavioral traits not covered by annotations: it blocks for 1–3 minutes, spends credits, and requires a specific capability flag. These are significant for an agent to plan execution. However, it does not mention what the tool returns (e.g., a URL, file path) or any side effects beyond spending credits, so a 4 reflects good but not exhaustive transparency.

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

  Conciseness5/5

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

  Two sentences with zero filler. The primary action is front-loaded, and the critical constraints (blocking, credits, capability) are stated compactly. Every clause adds value.

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

  Completeness4/5

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

  For a generation tool with no output schema, the description covers the core purpose, blocking duration, credit cost, and capability prerequisite. The main gap is the absence of any mention of the output format (e.g., returns a media URL or file), which an agent needs to handle the result. Given the complexity, it is mostly complete but missing that return detail.

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

  Parameters3/5

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

  Schema description coverage is 100% and each parameter already has a clear description (e.g., image is a portrait, script is the spoken words, resolution lists options). The tool description adds minimal extra meaning beyond restating 'portrait image + script'. The baseline of 3 is appropriate since the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the tool renders a talking avatar / creator lip-sync clip from a portrait image and a script. It is specific enough to distinguish from siblings like generate_voice (audio only) or generate_video (generic video) by naming 'talking-avatar' and 'lip-sync'.

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

  Usage Guidelines3/5

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

  The description implies when to use (need a talking avatar) but does not explicitly contrast with alternatives or state when NOT to use it. The capability requirement (canAvatar) and blocking behavior suggest a specific use case, but no exclusions or comparative routing to other content-generation tools are provided.

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

• google_business_insightsA
  4/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond the annotations: it notes the tool is read-only and costs 0 credits (already in annotations), but also discloses the discontinued per-post insights caveat, advising not to promise that data, and mentions the connection requirement. No contradiction with annotations; it enriches the safety profile.

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

  Conciseness4/5

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

  The description is moderately long but well-structured, with the core purpose front-loaded. The note about per-post insights is important and placed clearly. Each sentence adds value—no redundancy or filler. Slightly verbose but acceptable.

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

  Completeness3/5

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

  Given there is no output schema, the description should explain the return shape, but it does not mention how results are returned (e.g., a summary object or list). It covers the metric list, read-only nature, and caveats, but fails to describe the response format, leaving a gap for an agent unsure what the tool actually returns.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters (days, metrics, locationId) in detail, including the metric enum list and behavior for unknown names. The description does not add extra parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description clearly states what the tool does with a specific verb ('performed') and resource ('Google Business Profile listing'), listing the exact metrics covered (impressions, calls, clicks, etc.). It also explicitly notes the listing-level scope, distinguishing it from per-post analytics and other platform insight tools like meta_page_insights or instagram_insights.

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

  Usage Guidelines4/5

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

  Provides strong context on when to use this tool ('For a local business this is the real-world demand signal... the number an ad campaign should be judged against') and includes a clear prerequisite ('Needs Google Business Profile connected'). It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for an agent to recognize its fit.

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

• list_jobsA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it returns recent jobs and a running count, which is helpful context, but does not disclose other behavioral aspects like pagination limits or ordering details. With annotations covering the main traits, this adds some value but not extensive disclosure.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the main action first, then the additional information, and ends with the intended purpose. It is concise, efficient, and free of any filler. Every word contributes to meaning.

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

  Completeness4/5

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

  For a simple list tool with no parameters, no output schema, and annotations covering safety, the description is complete. It clearly states what the tool returns (recent jobs and running count) and the purpose. It doesn't need to explain the data format since the title and name make the resource type clear. A 4 is appropriate as it covers the essentials.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema is empty with 100% coverage. Per the rubric, the baseline is 4. The description does not need to explain parameters, and adds nothing beyond that baseline.

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

  Purpose5/5

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

  The description states a specific verb ('List') and resource ('render jobs'), and adds the distinct capability of reporting how many are currently running. This clearly distinguishes it from the sibling get_job (singular) and other job-related tools like list_youtube_report_jobs. An agent can infer exactly what to expect.

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

  Usage Guidelines3/5

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

  The description gives a use case ('so you can report on or resume in-flight work') which implies when to use it. However, it does not explicitly contrast with alternatives like get_job for a specific job's details, nor does it state when not to use this tool. The guidance is implied rather than explicit.

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

• list_threads_postsA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the output fields (id, text, media, permalink, timestamp) and the 'recent' qualifier, which is useful but not deep. It doesn't discuss pagination, ordering, or authentication beyond what the schema/annotations imply. With annotations present, this is adequate but not exceptional.

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

  Conciseness5/5

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

  Two sentences with zero fluff. The purpose and output fields are front-loaded, and the downstream use case is stated compactly. Every phrase earns its place.

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

  Completeness4/5

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

  For a simple list tool with one parameter, the description covers the output fields and the reason to call it. It lacks any note on pagination beyond the limit parameter (which the schema covers) and doesn't mention prerequisites like having a connected brand, but those are implied. Overall it is sufficiently complete for a read-only listing operation.

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

  Parameters3/5

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

  The schema already documents the single 'limit' parameter with a range and default (1–50, default 15), and coverage is 100%. The description adds no additional meaning about the parameter, so it doesn't rise above the baseline for tools with high schema coverage.

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

  Purpose5/5

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

  The description states the exact verb (list), resource (recent posts on the brand's connected Threads account), and the fields returned (id, text, media, permalink, timestamp). It clearly distinguishes this from related tools like list_threads_replies or search_threads_keyword by specifying the post-level listing scope and the downstream tools that need a post id.

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

  Usage Guidelines4/5

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

  It explicitly states the primary use case — finding a post id for threads_insights, list_threads_replies, reply_to_thread, or delete_thread. This gives clear context for when to use it, though it doesn't mention exclusions (e.g., when not to use it) or explicitly contrast with search tools. Still, the guidance is both clear and actionable.

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

• post_editA
  4/5.0
  Behavior4/5

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

  Annotations are all-false flags (not read-only, not idempotent, not destructive), so the description carries most of the burden. It adds meaningful context: the operation returns a NEW video and leaves the original untouched (consistent with destructiveHint=false, and it creates output consistent with readOnlyHint=false), discloses flat cost (~2 credits), fast execution, and the explicit non-AI, non-generative nature. It does not cover failure modes, auth requirements, or delivery of the resulting video URL.

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

  Conciseness3/5

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

  The key distinguishing info is front-loaded ('MECHANICAL post-production on an EXISTING rendered video... NO AI model'), and every sentence carries information. However, it is one dense, run-on paragraph combining operations list, constraints, brand behavior, cost, and exclusions. Splitting the ops inventory from the routing/negative guidance would improve scannability, though nothing is wasted.

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

  Completeness4/5

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

  For a medium-complexity tool with 5 params fully described in the schema and no output schema, the description is fairly complete: input type (served mp4 URL), operations available, ordering/cap semantics, cost, brand override behavior, and the fact that it returns a new video. It could note how the new video is surfaced, but the bare 'returns a NEW video' plus 'get_job' sibling availability covers most agent needs.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds some value on top: the ops are 'applied in order' with a 6-op cap (cap also in schema), and brand params (name/domain/logo/accent) auto-load from the workspace with per-call override. It explains the append_card behavior the schema partly implies. This is helpful, but it does not compensate for any missing schema coverage since none is missing.

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

  Purpose5/5

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

  The first clause nails it: 'MECHANICAL post-production on an EXISTING rendered video (its served mp4 URL)' — specific verb, resource, and scope. It lists the exact whitelisted primitives (trim, speed, mute, audio_gain, fade_out, append_card, watermark, grain) and actively differentiates from generative siblings like generate_video and render_ad. An agent can immediately tell this from the video-rendering tools in the sibling list.

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

  Usage Guidelines4/5

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

  The description clearly defines the lane ('The lane for: append a branded end card...') with concrete example phrasing and gives an explicit negative rule: 'NEVER use generate_video/render_ad for these mechanical asks.' It does not, however, enumerate the closest mechanical cousins in the sibling list (edit_video, reframe_video, upscale_video) or state conditions that would route to them, so differentiation from those is left implicit rather than explicit.

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

• save_skillA
  4/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false, so it is clear this is a write operation. The description adds that it 'merges into the workspace Skills library', which is useful context about the state change. It does not disclose idempotency or behavior on duplicate names, but with annotations covering the basic write nature, this is acceptable.

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

  Conciseness5/5

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

  The description is two sentences, with the purpose front-loaded and concrete examples provided. It is efficient and contains no filler or redundancy.

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

  Completeness4/5

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

  The description adequately explains what a skill is, how to formulate its directive, and how it integrates with the skills library via list_skills. For a simple two-parameter tool with no output schema, this provides sufficient context for an agent to call it correctly. Minor gaps, such as duplicate-name behavior, are not critical.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both name and directive fully described. The description adds a general guidance to 'distill an imperative, self-contained directive' which reinforces the schema but does not introduce new parameter-specific information. Baseline 3 is appropriate since the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the tool saves a reusable custom SKILL, provides concrete examples (hook formula, UGC recipe, compliance rule, persona), and differentiates it from sibling tools like list_skills, get_skill, and delete_skill by referencing the workspace Skills library. It uses a specific verb+resource construction.

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

  Usage Guidelines4/5

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

  The description gives solid context: it is the save operation for reusable skills, and it mentions list_skills as the way to view built-ins and custom skills, which implies when to use it relative to viewing. However, it does not explicitly state when not to use this vs. other save tools (e.g., save_playbook) or provide exclusion conditions.

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

• score_adA
  4/5.0
  Behavior3/5

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

  Annotations already convey read-only and non-destructive behavior, so the description doesn't need to restate that. It adds context on what the prediction covers (e.g., goal fit, retention) but doesn't disclose limitations like URL accessibility or auth requirements. This is adequate but not rich 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.

  Conciseness5/5

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

  Two sentences with zero fluff. The first sentence front-loads the core function and output, the second gives usage guidance. Every clause earns its place, making it easy for an agent to parse quickly.

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

  Completeness4/5

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

  For a prediction tool with fully documented parameters and read-only annotations, the description covers the essential output (score, dimensions, strengths, fix) and usage timing. It doesn't discuss error handling or performance caveats, but these are minor given the tool's simplicity and annotation coverage.

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

  Parameters3/5

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

  Schema descriptions cover all three parameters (url, kind, intent) at 100% coverage, so the baseline is 3. The description adds minimal extra meaning—only implicitly linking intent to goal-fit scoring via the per-dimension list. It doesn't provide syntax or format details beyond the schema.

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

  Purpose5/5

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

  The description states a specific verb ('prediction') and resource ('ad'), and details the output: overall score, per-dimension breakdown, strengths, and biggest fix. This clearly distinguishes it from sibling tools like plan_ad or render_ad, which focus on creation rather than evaluation.

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

  Usage Guidelines4/5

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

  Explicitly says 'Use BEFORE spending on distribution, or to rank variants', giving clear context on when to invoke. While it doesn't name alternatives or provide exclusions, the timing guidance is actionable and sufficient for an agent to select this tool appropriately.

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

• search_redditA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's job is to add extra behavioral context. It does so by disclosing the credit cost ('Spends about a credit.') and the exact return shape (compact JSON with fields), which are not covered by annotations. This adds meaningful behavioral detail without contradicting the annotations.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loaded with the primary purpose and endpoint, then covering return format and cost. Every sentence earns its place with no fluff or redundancy.

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

  Completeness4/5

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

  For a read-only search tool with no output schema and fully documented parameters, the description covers the essential points: purpose, return payload structure, and cost. It omits details like rate limits or pagination, but these are minor for a simple search tool and the description is sufficiently complete for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so both parameters (query, limit) are already documented. The description does not add new parameter-specific semantics beyond the schema; it only reiterates the general use case. Given the high schema coverage, the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Reddit keyword search' with the endpoint, and clarifies its purpose as mining customer language for ad hooks. It is clearly distinct from other sibling search tools by platform, and the 'top-ranked' note signals its preferred status.

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

  Usage Guidelines3/5

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

  The description gives a use case (mining customer words for ad hooks and copy) but does not explicitly state when to choose Reddit over sibling search tools like search_tiktok or search_youtube. It lacks explicit when-not-to-use guidance or exclusions, relying on the user to infer platform relevance.

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

• append_to_docA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds the 'Hermoso can reach' limitation and clarifies the non-destructive nature by saying 'append', but doesn't disclose error behavior or side effects. With openWorldHint=true, the description adequately supplements but doesn't go beyond what annotations expect.

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

  Conciseness4/5

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

  Single sentence that front-loads the core action and scope. The phrase 'Hermoso can reach' is slightly verbose but necessary to convey the limitation. Minimal waste; could be trimmed slightly but is efficient.

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

  Completeness4/5

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

  For a simple append tool with two parameters and no output schema, the description covers the essentials: what it does, how to get the ID, and the reachability constraint. Error cases are not described, but given the low complexity and annotations, this is adequate.

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

  Parameters4/5

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

  Schema covers 100% of parameters, but the description adds meaning beyond schema. The schema's documentId description only mentions 'from create_doc', while the tool description extends it to include 'list_drive_files', providing a more accurate and complete source. Text description is straightforward.

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

  Purpose5/5

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

  Clearly states the verb 'append' and resource 'Google Doc', and further narrows scope to docs Hermoso can reach (created or user-provided). Distinguishes from siblings like create_doc, update_doc, and read_doc by focusing on appending to the end and specifying how to obtain the documentId.

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

  Usage Guidelines4/5

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

  Provides explicit guidance on when to use: when appending to the end of a reachable doc, and offers two methods to source the documentId (from create_doc or list_drive_files). It does not explicitly exclude alternatives like update_doc, but the scope is clear enough for correct selection.

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

• check_ad_policyA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is known. The description adds valuable behavioral details beyond this: it pulls live Meta policy pages, returns verbatim quotes, provides compliant rewrites, never edits creative, and charges a flat 1 credit. These details enrich the agent's understanding beyond the annotations without contradicting them.

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

  Conciseness4/5

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

  The description is front-loaded with the core purpose, then explains the method, differentiates it from editing, and gives usage guidance. Every sentence contributes value without excessive verbosity. It is reasonably concise given the amount of contextual information (cost, output format, use cases). Slightly longer than strictly necessary but well-organized.

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

  Completeness4/5

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

  Given the tool's complexity (live external data, verdicts, verbatim quotes, rewrites) and lack of output schema, the description covers the key operational aspects: return format (verdict, quotes, rewrite), non-destructive behavior, cost, and when to prioritize it. It does not mention rate limits or prerequisites, but these are not critical for basic invocation. The description is complete enough for an agent to use the tool correctly in most scenarios.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all parameters are adequately described in the schema. The tool description does not add any param-specific meaning beyond mentioning 'copy' implicitly and referencing categories in the usage guidance. It does not explain how to format or what to include for each parameter beyond the schema, so it does not exceed the baseline.

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

  Purpose5/5

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

  The description clearly states a specific action ('Pre-flight ad copy against Meta's REAL, live Advertising Standards'), identifies the resource (ad copy) and outcome (verdict pass/fix/block). It explicitly differentiates from editing tools by stating 'It's a check, not an edit', which helps distinguish from potential siblings like edit-oriented tools. The purpose is unambiguous and directly actionable.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use it: 'before you run it' and for specific regulated-adjacent categories or strong claims. It does not explicitly mention when NOT to use it or name alternative tools, but the guidance is sufficiently contextual to guide an agent. Missing an explicit when-not clause prevents a 5.

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

• error_detailA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only, 0 credits,' adding cost information. More importantly, it discloses that occurrences are 'redacted' and inputs are only a 'shape-only echo,' setting accurate expectations about the response — behavioral traits not present in 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.

  Conciseness4/5

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

  Three short sentences, front-loaded with the core purpose before enumerating the returned content. The closing 'This is what makes a bug reproducible' adds value framing without fluff. Compact and well-ordered, with only minor density in the field enumeration.

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

  Completeness4/5

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

  For a single-parameter, read-only tool with no output schema, the description gives ample context: how to obtain the key, what content to expect, redaction behavior, and cost. One could wish for explicit output structure given the absence of an output schema, but the field listing partially covers this. Quite complete for the tool's complexity.

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

  Parameters3/5

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

  Schema coverage is 100% with the single 'fingerprint' parameter documented as 'the fp value from list_errors.' The description repeats this source relationship ('by fingerprint (from list_errors)') but adds no new syntactic or format detail beyond what the schema already provides, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description states a specific verb (retrieve) and resource (one error group) keyed by fingerprint, explicitly naming its sourcing tool list_errors. It distinguishes itself from list_errors by describing the expanded content — full fields plus redacted occurrences — so an agent understands this is the detail complement to the listing tool.

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

  Usage Guidelines4/5

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

  The description makes the prerequisite explicit: the fingerprint comes from list_errors, implying the workflow of listing first and then drilling into a specific group. It does not name exclusions or explicitly state when not to use it, but the source relationship and the 'makes a bug reproducible' framing give clear usage context.

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

• fetch_assetA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this operation is safe and non-mutating. The description adds the behavioral detail that it returns two URL forms (clickable and download), which is helpful. However, it doesn't mention potential failure modes (e.g., invalid reference, auth) or any rate limits. Given the low annotation bar, a 3 is appropriate.

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

  Conciseness5/5

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

  A single, information-dense sentence that leads with the core purpose and specifies input constraints. There is zero fluff; every part of the sentence earns its place. The structure is exemplary for a simple utility tool.

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

  Completeness5/5

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

  The tool is simple (2 params, 1 required) and the description fully explains the output (both URL types). Since there is no output schema, the description carries the responsibility for return values, and it does so clearly. It also defines the accepted input format, so an agent has everything needed to invoke it correctly. Complete for its complexity.

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

  Parameters3/5

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

  Schema description coverage is 100%, both 'url' and 'name' are described in the schema. The tool description doesn't add parameter-specific detail beyond what the schema provides (e.g., no format examples or edge cases). Since the schema carries the full load, baseline 3 is correct.

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

  Purpose5/5

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

  The description clearly states the verb ('Resolve'), the resource ('a generated asset reference'), and the exact outcome (clickable absolute URL + download URL). It even specifies the accepted input forms (/generated/ path or any URL), making the purpose unambiguous. No sibling tool performs this action, so no differentiation is needed.

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

  Usage Guidelines4/5

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

  The description implies the use case: whenever an agent has an asset reference that needs to be converted to usable URLs. It doesn't explicitly state when not to use it or list alternatives, but given the absence of any similar sibling tool, this is clear context. The lack of exclusions is acceptable because there are no obvious competing tools.

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

• get_post_refillA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, lowering the disclosure burden. The description adds genuinely useful context beyond annotations: the operation is free (cost implication), it surfaces dry-run preview mode, and it reports which channels are blocked and why. 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.

  Conciseness4/5

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

  Two well-structured sentences that front-load the core purpose before listing the returned fields and the blocked-channels detail. Each enumerated item earns its place; slightly long but no wasted words.

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

  Completeness4/5

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

  With no output schema, the description carries the burden of explaining the return, and it does so thoroughly by listing every field an agent would care about. Simple zero-parameter invocation means nothing is missing for correct usage.

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

  Parameters4/5

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

  The tool has zero parameters and an empty schema, so the baseline is 4. The description compensates by detailing the output fields the call returns, which substitutes effectively for any parameter documentation.

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

  Purpose5/5

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

  The description names a specific verb ('Show') and resource ('the automatic posting refill for this brand') and enumerates the exact fields returned (on/off, dry-run mode, days ahead, render budget, next run, queued posts, blocked channels). This clearly distinguishes it from the mutating siblings set_post_refill and run_post_refill.

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

  Usage Guidelines3/5

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

  The description communicates read-only, free status-check context, which implies it is for inspecting configuration rather than changing or triggering it. However, it does not explicitly name the alternative tools (set_post_refill, run_post_refill) or give a contrastive condition for when to use them, leaving some routing to inference.

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

• hide_thread_replyA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the reversible toggle (hide/unhide) and clarifies the purpose, which is beyond what annotations provide. It does not contradict annotations and gives helpful behavioral context about reversibility.

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

  Conciseness5/5

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

  The description is a single sentence that front-loads the core action, includes both states (hide/unhide) and the use case. No wasted words; every phrase adds value.

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

  Completeness5/5

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

  With only two parameters, one required, and a simple boolean toggle, the description fully covers the operation: what it does, how to revert, and why. The schema provides replyId guidance (from list_threads_replies), and annotations handle idempotency and destructiveness. Nothing essential is missing for an agent to call it correctly.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description mentions 'hide:false' for unhide but that duplicates the schema's parameter explanation ('false to UNHIDE (default true)'). No additional meaning beyond the schema is provided, so no bonus above baseline.

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

  Purpose5/5

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

  The description states a specific action (hide/unhide) on a specific resource (a reply on a brand's Threads post) and gives the use case (spam/abuse moderation). This clearly distinguishes it from related tools like delete_thread (permanent) and moderate_meta_comment (different platform). No ambiguity.

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

  Usage Guidelines3/5

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

  The description implies when to use it (for spam/abuse moderation) but does not explicitly contrast it with alternatives (e.g., 'use delete_thread for permanent removal'). It does not state when not to use it, leaving the agent to infer from the sibling list. This is adequate but not explicit.

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

• list_connector_accountsA
  4.1/5.0
  Behavior4/5

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

  Annotations already carry readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds that the tool is 'free' (cost implication) and that it returns a selection state per account ('ticked ones'). It also emphasizes user choice over automation, which is useful behavioral context beyond the raw annotations.

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

  Conciseness4/5

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

  The description is long but well-structured: it leads with the core purpose, then explains what results look like, gives usage order, and lists providers. The provider list is redundant with the schema but not excessively so. The content is front-loaded with the most important information (including the instruction to call before set_connector_accounts).

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

  Completeness4/5

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

  For a simple tool with one parameter and no output schema, the description adequately explains what is returned (accounts with allowed flags), how to use it (before set_connector_accounts, let user pick), and that it is read-only and free. It does not detail the exact response structure, but that is acceptable given the absence of an output schema and the tool's simplicity.

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

  Parameters3/5

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

  The schema already documents the single provider parameter with a full enum and a description (coverage 100%). The description repeats the provider list without adding new semantics about how to choose a provider or any provider-specific constraints. Baseline 3 is appropriate since schema fully covers the parameter.

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

  Purpose5/5

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

  The description clearly states the verb (Show) and the resource (every identity a connected account can act as and which ones are allowed). It distinguishes itself from set_connector_accounts by explicitly positioning itself as the prerequisite call, and from list_connectors (which lists connectors, not accounts). The provider list enumerates the scope precisely.

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

  Usage Guidelines4/5

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

  Explicitly instructs to call it before set_connector_accounts and to let the USER pick, never guessing. This provides clear when-to-use guidance relative to a specific sibling. It does not discuss when not to use it or mention other alternatives like list_connectors, but the core sequencing is well covered.

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

• list_playbooksA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by confirming 'Read-only, free' and noting it matches the web app's Playbooks tab, but doesn't disclose return format, pagination behavior, or default ordering. Given the annotations cover safety, a 3 is appropriate.

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

  Conciseness5/5

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

  Four sentences with no waste. The first sentence front-loads the core functionality, the second ties it to a familiar surface (web app tab), the third gives usage guidance, and the fourth restates safety. Every sentence earns its place.

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

  Completeness5/5

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

  This is a simple list tool with 2 optional params, no output schema, no nested objects, and annotations covering the safety profile. The description covers what playbooks are, when to use it, and what the params do via schema. Nothing essential is missing for an agent to call it correctly.

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

  Parameters3/5

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

  Both parameters (full, limit) have schema descriptions with 100% coverage: 'full' explains it returns every hook/angle/play and 'limit' documents default and max. The description doesn't add parameter-specific details beyond the schema, so baseline 3 is correct.

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

  Purpose5/5

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

  States a precise verb+resource ('List the PLAYBOOKS saved in this workspace') and then defines what playbooks are (winning hooks, angles, formats, concrete plays) with operational context (kept from teardowns and angle mining). It is clearly distinct from sibling list_swipefile, which targets a different asset type.

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

  Usage Guidelines4/5

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

  Gives clear usage context: 'Read one before planning an ad so you re-run what already worked instead of starting cold.' This tells an agent when to call it, though it doesn't explicitly name alternative tools to consider or state when NOT to use it.

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

• list_product_photosA
  4.1/5.0
  Behavior1/5

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

  Annotation Contradiction: The description states that passing brandId 'switches this key's active brand like use_brand,' which is a side effect modifying the tool's active state. This contradicts the readOnlyHint=true annotation, which implies the tool does not modify any state. Thus the description directly contradicts the annotation.

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

  Conciseness5/5

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

  The description is concise and front-loaded, covering the main purpose, scope, cost, return value, and usage trigger in four sentences. Every sentence adds distinct value, with no redundancy, making it efficient for agents to parse.

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

  Completeness5/5

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

  For a tool with one optional parameter and no output schema, the description is complete: it states the return type (url + label), explicitly mentions cost (FREE), explains the scope, and addresses the side-effect of brand switching. Nothing critical is missing for an agent to invoke it correctly.

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

  Parameters4/5

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

  Although the schema already describes the brandId parameter with 100% coverage, the description adds important semantics beyond the schema: it explains that passing brandId also switches the active brand for the key, similar to use_brand. This additional behavioral detail is not present in the schema and helps agents understand the side effect.

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

  Purpose5/5

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

  The description clearly states the tool lists already-saved product photos, including the brand's product library and app-store screens, and notes it surfaces photos from other creations. It distinguishes itself from set_product_image by explicitly saying to call it before that tool, giving 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.

  Usage Guidelines5/5

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

  Provides explicit guidance: 'Call it before set_product_image to see the existing photos you can reuse.' Also clarifies when to pass brandId and that it switches the active brand like use_brand, giving clear context on how to use the tool relative to siblings.

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

• list_published_postsA
  4.1/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description consistently states 'Read-only, 0 credits,' so there is no contradiction. Beyond annotations, it discloses important data semantics: the 'captured' vs 'backfilled' distinction explains how the hook was derived, and the dash-for-engagement caveat ('that is NOT zero engagement') prevents misinterpretation. This is valuable behavioral context that the schema and annotations do not provide.

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

  Conciseness4/5

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

  The description is rich but not bloated. It front-loads the core listing purpose, then adds the provenance and dash annotations, and ends with a concise read-only flag. Every sentence earns its place, though the first sentence is slightly long with the full field enumeration. It is well-structured and readable rather than a wall of text.

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

  Completeness4/5

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

  The tool is complex due to cross-channel scope and data provenance, but the description covers the essential interpretive points: what fields are returned, the captured/backfilled distinction, and the dash-not-zero rule. It does not mention pagination behavior (beyond the limit parameter) or what happens when no posts exist, but those are minor. The absence of an output schema is compensated by the explicit field list. Overall it is sufficiently complete for correct invocation and result interpretation.

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

  Parameters3/5

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

  The schema description coverage is 100%: both 'limit' and 'channel' are fully documented with defaults, max values, and the list of channel options. The description adds only a mild reinforcement ('across all nine channels') but does not explain parameter formatting or edge cases beyond the schema. Since the schema carries the full burden, a baseline 3 is appropriate.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'List every post Hermoso has recorded publishing for this brand.' It enumerates the exact fields returned (channel, permalink, caption, format, hook, subject, engagement) and states it is the brand's history 'across all nine channels in one place,' which distinguishes it from channel-specific siblings like list_meta_posts or list_threads_posts. This makes the tool's role unambiguous.

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

  Usage Guidelines3/5

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

  The description implies a primary use case (

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

• list_reddit_commentsA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only, 0 credits'. It adds valuable behavioral detail beyond the annotations: the credit cost (0), the connection requirement, and the presence of a fullname field in each row for use with reply_to_reddit_comment. It does not mention rate limits, error behaviors, or pagination, but for a read-only list tool the added context is solid.

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

  Conciseness4/5

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

  The description is moderately sized but front-loaded with the core action and fields in the first sentence. The second sentence provides useful context about the value of the thread (questions, objections, customer wording) and ties it to sibling tools. The third sentence explains the output's utility for replying, and the final sentence states read-only, credits, and connectivity. Every sentence earns its place; it's slightly longer than necessary but not bloated.

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

  Completeness4/5

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

  For a list tool with no output schema, the description covers the key return fields (author, text, score, own-reply flag, timestamp) and the integration point (fullname for reply_to_reddit_comment). It states prerequisites and credit cost. It does not explain sort options or limit behavior, but those are already in the schema. Given the simplicity of the tool and the richness of the schema, the description is complete enough for an agent to invoke it correctly.

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

  Parameters3/5

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

  Input schema coverage is 100% with each parameter already described (sort enum, limit range, postId types). The description adds no additional parameter-level meaning; it only implies that postId can be a permalink or fullname via the schema, but the description doesn't elaborate. The mention of 'fullname' is about the output rows, not the input parameters. Thus the description does not enhance parameter understanding beyond what the schema already provides, aligning with the baseline 3.

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

  Purpose5/5

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

  The description clearly states the verb 'Read' with a specific resource: 'the comments under one of the connected account’s Reddit posts'. It lists the exact fields returned (author, text, score, whether it's the poster's own reply, and when), which makes the purpose unambiguous. It also explicitly distinguishes itself from siblings by naming list_meta_comments and list_youtube_comments as the counterparts on other channels, so an agent can easily tell it apart.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool: it positions it as the Reddit source for 'the same raw material for ad copy' that the Meta and YouTube comment tools provide. It also includes a prerequisite ('Needs Reddit connected') and hints at the downstream use case via 'the fullname to pass to reply_to_reddit_comment'. However, it does not explicitly state when NOT to use it or mention alternative tools beyond the two named siblings, so it stops short of a full exclusion list.

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

• list_youtube_captionsA
  4.1/5.0
  Behavior4/5

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

  The description adds behavior beyond the annotations by explaining the concept of a caption track versus burned-in captions, noting that auto-generated tracks are 'read-only and cannot be edited or deleted,' and stating 'Read-only, 0 credits.' Annotations already declare readOnlyHint: true and destructiveHint: false, so the description enriches but does not contradict them. It stops short of covering response format or rate limits.

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

  Conciseness4/5

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

  The description is four sentences long, each adding value: the primary action, the conceptual distinction, the read-only caveat, and a practical use case. It is front-loaded with the core action and flows logically, though slightly verbose for a simple list tool.

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

  Completeness4/5

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

  Despite lacking an output schema, the description hints at the list structure ('Each row says whether YouTube generated it automatically (isAutoGenerated, trackKind ASR)') and covers prerequisites, constraints, and use cases. It is fairly complete for an agent to decide when and how to call it, though it does not describe pagination or return formats.

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

  Parameters3/5

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

  Schema description coverage is 100%, so parameters are already documented (e.g., format with enum and default, download as captionId or language code). The description reinforces the download behavior and mentions the read-only nature of auto-generated tracks, but it does not add substantially new parameter meaning beyond the schema. Baseline of 3 is appropriate given high coverage.

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

  Purpose5/5

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

  The description clearly states the tool's actions: 'List the caption/subtitle tracks on one of the connected channel’s videos, and optionally DOWNLOAD one as text.' It specifies the verb (list/download), the resource (caption tracks on a video), and distinguishes caption tracks from burned-in captions, which also separates it from sibling management tools like manage_youtube_caption.

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

  Usage Guidelines4/5

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

  It provides a concrete use case ('Downloading is also the fastest way to get an existing video’s full script back for repurposing') and a prerequisite ('Needs a connected YouTube channel'). It implies read-only usage via the 'read-only' statement, which steers away from editing, but it does not explicitly name alternatives like manage_youtube_caption or list_youtube_comments.

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

• mark_bluesky_convo_readA
  4.1/5.0
  Behavior4/5

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

  Annotations already mark this as non-read-only and non-destructive; the description adds value by revealing that the reported unread count may differ from the requested scope ('Reports the unread count — or the number of conversations — Bluesky reads back, not the one requested'). This is a meaningful behavioral nuance beyond the structured annotations. The 'Free' note adds cost transparency. No contradictions with the annotations.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the core action, then scope, then use case, then return-value caveat, then cost. It avoids redundancy with the schema, though the 'Free.' at the end is borderline extraneous and the phrasing 'Bluesky’s own mark-all' is a bit wordy. Overall, every sentence carries purpose, but a slight trim would improve it.

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

  Completeness4/5

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

  For a tool with 3 optional parameters, no output schema, and straightforward semantics, the description covers the essential behaviors: scope (single vs. all), optional narrowing via status, the return-value difference, and the use case. It doesn't explicitly state what happens when all parameters are omitted but implies 'mark everything.' The schema fills in the rest. No critical missing context for an agent to call it correctly.

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

  Parameters3/5

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

  Schema coverage is 100% and each parameter description in the schema is detailed (e.g., convoId's 'OMIT to mark EVERY conversation', status's enum with refusal behavior). The tool description reinforces the convoId omission and status narrowing but doesn't add new semantic info beyond the schema—e.g., it doesn't mention messageId at all. With high schema coverage, the baseline is 3, and the description only marginally enhances parameter meaning (like the explicit 'from list_bluesky_convos' source for convoId, which is already in the schema).

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

  Purpose5/5

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

  The description opens with a specific action and resource ('Clear the unread count on Bluesky DMs') and immediately clarifies the two scope modes (one conversation vs. whole account), which distinguishes it from sibling tools like list_bluesky_convos or read_bluesky_dm. The verb 'mark' and resource 'convo' are explicit, and the 'not the one requested' return-value note further pins down its behavior.

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

  Usage Guidelines4/5

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

  It gives a concrete trigger ('Useful after triaging an inbox') and explains the benefit relative to list_bluesky_convos, explicitly stating that using this tool prevents the next list_bluesky_convos from surfacing the same threads. It doesn't list explicit alternatives to avoid (e.g., 'use read_bluesky_dm if you only want to read a single message'), but the context and the schema's convoId guidance (from list_bluesky_convos) provide enough usage direction. No exclusions stated, but the guidance is solid.

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

• meta_post_insightsA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it explains that metrics with no value are reported as 'MISSING' and should not be read as zero, and it clarifies that impression-family metrics have been replaced by Meta's own identifiers. This helps the agent interpret results correctly.

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

  Conciseness4/5

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

  The description is reasonably concise given the amount of metric detail it packs. It front-loads the primary purpose, then enumerates metrics by platform with a semicolon, and ends with the critical MISSING note. Every sentence adds value; no fluff. While slightly long, the structure is clear and efficient.

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

  Completeness4/5

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

  For a read-only tool with three parameters and no output schema, the description covers the essential context: what metrics are returned, the two platform variants, and the special behavior for missing values. It does not discuss pagination or rate limits, but those are likely not critical for a single-post call. The description provides enough for an agent to call the tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameters (pageId, postId, target) are already fully documented in the schema. The description adds little beyond what the schema states—it reinforces the post-level scope and hints that target changes the metric set, but this is also present in the schema's description for target. Thus, it does not significantly enhance parameter understanding.

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

  Purpose5/5

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

  The description clearly states the tool returns performance metrics for a single organic post, and enumerates exactly which metrics per platform (Facebook and Instagram). It distinguishes itself from sibling tools like meta_page_insights (page-level) and instagram_insights (account-level) by emphasizing 'single post' and 'organic', making its scope unambiguous.

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

  Usage Guidelines4/5

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

  The description provides a concrete use case: 'find which organic posts earned their reach before turning one into a paid ad.' This gives clear context for when to use it. However, it does not explicitly name alternative tools (e.g., meta_page_insights) or state conditions when NOT to use it, leaving the exclusion to inference from the 'single post' phrasing.

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

• plan_variationsA
  4.1/5.0
  Behavior4/5

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

  Annotations are all false (readOnlyHint, idempotentHint, destructiveHint all unset), so the description carries the full behavioral burden. It discloses the key trait beyond annotations: it is planning-only and renders nothing itself, which prevents an agent from expecting visual output. It also clarifies that distinct hooks/mechanics/audiences are produced. No contradiction with annotations; readOnlyHint=false is consistent with this being a plan-generating (not necessarily side-effect-free) operation.

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

  Conciseness4/5

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

  Two compact sentences with the primary purpose front-loaded. The pipeline to generate_image and score_ad is conveyed efficiently via the dash. Minor redundancy exists ('LLM planning only' and 'renders nothing itself' restate the same point), but there is no wasted verbiage overall.

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

  Completeness4/5

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

  For a planning tool with no output schema and uninformative (all-false) annotations, the description provides solid operational context: what it produces (distinct angles, hooks/mechanics/audiences, headlines, visual briefs) and how it fits the downstream pipeline. The main gap is that it never describes the return structure, which would be valuable absent an output schema, but the workflow context is otherwise sufficient for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100% — all four parameters (brand, count, product, language) are already documented in the schema with their defaults and constraints. The description adds no parameter-level meaning, which is acceptable because the schema does the heavy lifting. Baseline 3 applies since the structured fields fully cover parameter semantics.

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

  Purpose5/5

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

  The description uses a specific, vivid verb ('Fan a brief into N DISTINCT ad angles') and names the resource and output artifacts (headlines + visual briefs). It differentiates itself from siblings by explicitly chaining to generate_image and score_ad and by stating 'LLM planning only; renders nothing itself,' which disambiguates it from render_ad and generate_image. An agent can distinguish this from plan_ad and mine_angles without opening schemas.

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

  Usage Guidelines4/5

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

  The description clearly implies usage — produce multiple ad-angle candidates from a brief, then hand each to generate_image and score_ad. The 'LLM planning only' clause sets a boundary for when this is the right tool (planning stage, not rendering). However, it does not explicitly name alternatives such as plan_ad or mine_angles, nor state when to prefer them, so exclusions are left implicit rather than stated.

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

• save_to_swipefileA
  4.1/5.0
  Behavior4/5

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

  Annotations already indicate idempotentHint=true, but the description adds valuable behavioral detail: creates the collection if missing, de-dupes by moving rather than duplicating, and is free. It explains persistence and downstream effects on future ad planning. No contradiction with annotations. It stops short of describing error conditions or return values, but the added context is strong.

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

  Conciseness4/5

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

  The description is information-dense, with each sentence carrying meaning: action, analogy, usage scenarios, persistence effect, dedupe behavior, and cost. It's longer than minimal but justified by the tool's complexity. The front-loading is good — the primary action and analogy come first. The final 'Free' is slightly extraneous but harmless.

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

  Completeness4/5

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

  For a tool with no output schema, the description covers the core aspects: what it does, when to use, behavioral details (creation, dedupe, persistence), and root sources. It lacks explicit error handling or return value info, but given that it's a save operation with idempotency hints, this is acceptable. It sufficiently equips an agent to call it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100% for both `items` and `collection`, giving baseline 3. The description adds context about the collection being named and creatable, and clarifies the items array types with examples, but does not introduce parameter syntax beyond the schema. It adds nothing critical about the parameters themselves, so a 3 is appropriate.

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

  Purpose5/5

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

  The description opens with a specific verb+resource ('Save one or more ads/creatives to a named SWIPEFILE collection') and immediately distinguishes itself from siblings by noting it's the 'headless twin of the ♥ on every ad card' — clear differentiation from list_swipefile and export_swipefile_deck. The purpose is singular and unambiguous.

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

  Usage Guidelines4/5

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

  Explicitly states when to use it: 'Use it whenever research turns up something worth keeping' and lists concrete sources (competitor ad from search_meta_ads / pull_competitor_ads, organic post, own renders). It does not name alternative tools or say when not to use it, but the context is clear enough that an agent can decide. It also explains downstream effects (persists to workspace board, feeds taste signal).

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

• tiktok_category_benchmarkA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and non-destructive behavior. The description adds valuable context beyond annotations: the data is TikTok's own cross-account averages (not the brand's), it's free, and authorization is required. This enriches the behavioral picture without contradicting any hints.

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

  Conciseness4/5

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

  The description is concise and well-structured: it front-loads the purpose, then lists metrics, provides pairing guidance, and ends with constraints and auth. Each sentence earns its place, though it could be slightly tightened without losing meaning.

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

  Completeness4/5

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

  There is no output schema, but the description enumerates the exact metrics the response will contain (mean likes, comments, shares, etc.), and clarifies the data source and authorization requirement. This is sufficient for an agent to understand what to expect, though it doesn't specify format or pagination, which is minor for a benchmark endpoint.

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

  Parameters3/5

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

  The schema has a complete enum of 25 allowed values for businessCategory, so the parameter is self-documenting. The description's statement that businessCategory must be one of TikTok's twenty-five published values merely restates the schema constraint. It adds little semantic depth, so a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool returns industry averages for a TikTok business category in terms of specific metrics (likes, comments, shares, etc.), and explicitly distinguishes it from tiktok_account_insights by noting it provides cross-account averages, not the brand's own numbers. This makes the resource and scope unambiguous.

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

  Usage Guidelines4/5

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

  It provides explicit usage guidance by pairing with tiktok_account_insights to answer comparative questions, and mentions a prerequisite (TikTok account authorization). It doesn't state explicit when-not-to-use conditions, but the pairing directive gives clear context for when this tool is the right choice.

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

• tiktok_mention_top_termsA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint, and the description reinforces that with 'Read-only, free.' It adds the authorization requirement (brand-insights permission) and the counting scope (top 1,000 posts over 90 days). It also explains the two-endpoint behavior and that BOTH makes two calls—useful context beyond the schema. 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.

  Conciseness4/5

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

  The description is a single paragraph with several dense sentences, but each adds value: purpose, distinction from alternatives, endpoint behavior, counting scope, preconditions, and authorization. It's front-loaded with the purpose and avoids fluff. Minor inefficiency: some redundancy with annotations (read-only) but acceptable for completeness.

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

  Completeness4/5

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

  No output schema, so the description must explain return values—it does (top 20 each). It covers the business-account precondition, authorization, counting scope, and endpoint selection. It doesn't mention pagination or error cases, but for a simple read-only analytics tool, the essential information is present. The two-endpoint complexity is well explained.

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

  Parameters3/5

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

  Schema coverage is 100%, so both parameters are documented in the schema. The description adds meaning by explaining that kind:'KEYWORDS' or 'HASHTAGS' calls only one endpoint, while BOTH makes two calls, and that regions narrows which posts are counted. This is helpful but not essential, given the schema already describes the parameters adequately. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description states precisely what the tool returns: top 20 keywords and top 20 hashtags from captions of mentioning posts. It clearly distinguishes this from sibling tools by explaining it answers 'what people say' rather than 'which posts', and notes the two-endpoint nature. The verb and resource are unambiguous.

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

  Usage Guidelines4/5

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

  It explains the distinction from post-level tools and notes the business-account precondition common to mentions tools. It doesn't explicitly name alternatives or state when NOT to use it, but the context is clear that this is for language analysis, not post enumeration. The kind parameter guidance is also present.

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

• use_brandA
  4.1/5.0
  Behavior4/5

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

  Annotations already note idempotentHint=true and destructiveHint=false. The description adds meaningful behavioral details beyond that: persistence across surfaces (hosted connector, no env vars/restart) and membership verification for shared workspaces. It enriches the agent's understanding of state and side effects without contradicting annotations.

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

  Conciseness4/5

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

  The description is somewhat long (four sentences) but each sentence adds essential context: purpose, accepted inputs, shared-workspace nuance, and persistence. It is logically organized and front-loads the core action before diving into edge cases. No wasted words.

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

  Completeness4/5

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

  For a single-parameter tool with no output schema, the description covers the essential scenarios: own brand, shared brand, input formats, persistence, and access verification. It does not explain the return value, but that is not expected without an output schema. The definition is complete for correct invocation.

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

  Parameters3/5

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

  Schema coverage is 100% and the schema already describes the 'brand' parameter thoroughly (id, name, profile id). The description reinforces these options but adds only incremental nuance about shared workspace verification. Since the schema carries the main meaning, this is a baseline 3.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: "Pin which brand this connection acts on" for multi-brand accounts. It distinguishes itself from siblings like list_brands (which lists) and create_brand/delete_brand (which manage) by focusing on the active selection. The wording is specific and avoids tautology.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use it (multi-brand accounts, own or shared) and explicitly references list_brands as the source of valid inputs. It doesn't explicitly say 'use this when you need to switch the active brand' but the function is evident. It lacks explicit exclusion of alternatives, but the context is sufficient.

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

• collect_post_metricsA
  4.2/5.0
  Behavior5/5

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

  Annotations already declare idempotentHint=true and destructiveHint=false, but the description goes far beyond them: it explains accrual and skipping, how missing metrics are recorded as ABSENT (never zero), how failures become 'could not tell', the default skipping of X due to billing, and the requirement to inform the user about credits. This rich disclosure about side effects, cost, and data handling is exactly what an agent needs and exceeds annotation coverage.

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

  Conciseness4/5

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

  The description is longer than average but every sentence carries necessary information: accrual schedule, skip behavior, ABSENT vs zero, failure handling, billing for X, and the reporting of skips. It is structured with punctuation and a clear flow. It could be slightly tighter, but the density is justified for a tool with multiple behavioral nuances. Front-loads the core action.

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

  Completeness5/5

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

  For a tool with no output schema and moderate complexity, the description is remarkably complete. It tells the agent what it does, when to call it (due readings), how it handles data quirks (ABSENT, 'could not tell'), billing implications (X costs credits), and the need to inform the user. It also notes that skips are always reported, preventing misinterpretation. Nothing critical for selecting or invoking the tool is missing.

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

  Parameters3/5

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

  Schema description coverage is 100%, so both 'max' and 'includeMetered' already have clear descriptions in the schema. The tool description reinforces the billing aspect of includeMetered ('tell the user it costs credits BEFORE you do') but does not add fundamentally new parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description opens with a clear, specific verb+resource: 'Fetch fresh performance numbers for this brand's recorded posts and store them as a time-series.' It precisely defines scope ('this brand's recorded posts') and the accrual model (24h and 7d readings), making it distinct from per-platform metrics tools like x_post_metrics or bluesky_post_metrics. Even without naming siblings, the behavior clearly separates it.

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

  Usage Guidelines3/5

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

  The description implies when to use it—when metrics are due per the accrual schedule—but does not explicitly contrast it with alternatives or state when not to use it. It says 'this collects whichever readings are due and skips the ones already taken,' which gives a condition, but no explicit route to sibling tools or exclusions. This is adequate but not explicit.

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

• create_docA
  4.2/5.0
  Behavior4/5

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

  The description goes beyond the annotations by disclosing the required Drive connection, noting that one connection covers Drive, Sheets, and Docs, and stating that the tool returns the document id and URL. This adds behavioral context (prerequisites, output) that annotations do not provide. No contradiction with the annotations (readOnlyHint=false, destructiveHint=false) is present.

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

  Conciseness5/5

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

  The description is two sentences with no redundancy. It front-loads the main action and scope, includes valuable examples, and tucks the prerequisite and return-value information into a compact second sentence. Every word earns its place.

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

  Completeness4/5

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

  For a simple two-parameter creation tool, the description covers the core essentials: what, examples, return value, and prerequisites. It lacks explicit clarification on whether a title is mandatory (schema has no required parameters, but the description implies title is needed), which would be a minor gap. Overall, it's sufficient for an agent to invoke successfully.

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

  Parameters3/5

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

  The schema already fully describes both parameters (text as 'body text to insert', title as 'document title') with 100% coverage. The description adds minor clarification by restating that title is for the document title and text is optional body text, but it doesn't introduce new parameter-specific details beyond what's in the schema. The baseline of 3 is appropriate given high schema coverage.

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

  Purpose5/5

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

  The description states the specific verb-resource pair ('Create a new Google Doc') with clear scope (in the user's Drive) and provides concrete examples (export ad copy, creative brief, report). It clearly distinguishes this creation tool from sibling tools like append_to_doc, read_doc, and update_doc, which handle different operations on existing docs.

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

  Usage Guidelines4/5

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

  The description makes the primary use case explicit by describing what the tool accomplishes and giving example scenarios. While it doesn't explicitly state when NOT to use it (e.g., for editing existing docs), the clear scoping to 'new' docs implicitly differentiates it from update/append tools, and the prerequisite note about Drive connection adds practical guidance.

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

• get_onedrive_fileA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only'. It adds value by specifying the exact metadata returned (webViewLink, webContentLink, etc.), which is beyond what annotations convey. No contradiction exists; the description complements the annotations with concrete output details.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the main purpose, lists the returned fields, and includes the input requirement. There is no wasted language; every clause earns its place.

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

  Completeness4/5

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

  For a simple read-only fetch with one parameter, the description adequately covers input (fileId from list_onedrive_files) and output (specific metadata fields). It does not mention error cases or permissions, but given the readOnlyHint annotation and the absence of an output schema, these are not critical gaps. It is sufficiently complete for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100% – the only parameter fileId is described as 'the OneDrive item id (from list_onedrive_files)' in the schema. The description repeats this source, adding no new semantic meaning beyond what the schema already provides. Thus, it meets the baseline of 3 but does not exceed it.

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

  Purpose5/5

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

  The description clearly states it fetches metadata for a single OneDrive item, listing specific fields (name, type, size, modified time, webViewLink, webContentLink) and says to pass fileId. This distinguishes it from sibling operations like update_onedrive_file, delete_onedrive_file, and convert_onedrive_file, as it is a read/fetch operation.

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

  Usage Guidelines4/5

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

  The description tells the agent to pass fileId from list_onedrive_files, providing a clear prerequisite and flow. It explicitly mentions 'Read-only', aligning with its intended use for inspection. It does not name alternative tools for when not to use it, but the context is strong enough for correct selection.

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

• hermoso_creditsA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds what data is returned (balance, spent credits, recent calls) but does not disclose additional behavioral traits beyond the annotations. It is consistent with annotations and adds some value, but not much beyond what annotations cover.

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

  Conciseness5/5

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

  The description is a single efficient sentence. It front-loads the primary purpose ('Return the account credit balance') followed by supplementary details and a usage hint. No wasted words.

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

  Completeness4/5

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

  For a zero-parameter read-only tool, the description is complete enough. It tells the agent what it returns and when to use it. Minor ambiguity about 'recent priced calls' exists, but it doesn't hinder invocation. The lack of an output schema is acceptable given the simplicity.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. There is no need for the description to explain parameters. It correctly implies no inputs are required.

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

  Purpose5/5

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

  The description states a specific verb ('Return'), a clear resource ('account credit balance'), and specifies exactly what is returned: the balance, credits spent on calls, and recent priced calls. It also includes a usage hint ('Check before kicking off paid generation') that clarifies its role. This distinguishes it from siblings like buy_credits (purchase) and billing_status (likely broader billing info).

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

  Usage Guidelines4/5

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

  The description explicitly tells the agent when to use this tool: 'Check before kicking off paid generation.' This is clear contextual guidance. It doesn't name alternative tools or when not to use it, but the purpose is obvious and the hint is actionable.

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

• list_drive_filesA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only.' It adds valuable context beyond annotations by explaining the scope limitation (drive.file scope only exposes created files and user-picked files, never the entire Drive). This sets clear expectations about what data is accessible, which is not visible from annotations alone. 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.

  Conciseness5/5

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

  The description is concise and well-structured, starting with the primary purpose, then scope, then usage details. Each sentence earns its place: scope clarification, use case, filter options, pagination, and read-only note. No fluff or redundancy.

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

  Completeness4/5

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

  For a listing tool with no output schema, the description covers essential aspects: scope, filters, pagination, and read-only nature. It hints at return contents (file ids) but does not describe the response format. Given the annotations and simplicity of the tool, this is fairly complete, though a short note on return shape would make it more complete.

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

  Parameters3/5

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

  Schema coverage is 100%, so all six parameters are documented in the schema. The description mentions query, folderId, onlyFolders, and pageToken but essentially restates the schema descriptions ('filter by query', 'contents of a folder'). It does not add new semantics, examples, or edge-case behavior beyond what the schema already says. Baseline of 3 applies because the schema carries the load.

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

  Purpose5/5

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

  The description clearly states the tool lists Google Drive files and folders that Hermoso can access, specifying the scope (created files plus user-picked ones) and explicitly distinguishes from the full Drive. It also says this is how to find the id of a user-picked file, giving a concrete use case. This is specific and differentiates from sibling tools like get_drive_file or save_to_drive.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use the tool (finding file ids, filtering by name/folder/type, paginating) and implies it is for listing rather than other operations. It does not explicitly name alternative tools or state when not to use it, but the purpose is obvious. The mention of pagination and filters gives practical guidance.

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

• list_errorsA
  4.2/5.0
  Behavior5/5

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

  Annotations already indicate read-only and non-destructive, and the description reinforces this with 'Read-only, 0 credits'. It also discloses critical behaviors beyond the annotations: redaction of free text/tokens/emails/creative, grouping by fingerprint with side classification, sorting defects-first, and the workspace scoping with an admin-key exception. These details materially inform the agent's expectations about data safety, output shape, and access boundaries.

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

  Conciseness4/5

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

  The description is composed of several dense sentences, each adding a distinct fact (grouping, side classification, redaction, scoping, filters, credits). It is longer than the bare minimum, but every sentence contributes actionable information and the most defining trait (grouping) is front-loaded. It is structured well but could be tightened without losing meaning.

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

  Completeness5/5

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

  Given that there is no output schema, the description thoroughly explains what the returned rows represent (grouped, with hit count, first/last seen, side, redaction behavior) and how to filter. It also covers access scoping and the read-only nature. An agent has everything needed to call it correctly and interpret the response, making it complete for a list-diagnostics tool.

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

  Parameters3/5

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

  The input schema covers 100% of the parameters with per-parameter descriptions (kind, limit, since, surface). The tool description mostly references the filter values ('surface', 'kind') without adding new semantics beyond the schema. Since the schema already does the heavy lifting, a baseline of 3 is appropriate; the description does not deepen parameter understanding further.

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

  Purpose5/5

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

  The description states a specific verb ('list'), a precise resource ('errors recorded against this workspace'), and clarifies the grouping by fingerprint with hit counts and side classification. It distinguishes itself from the many publishing/social tools and even from the sibling 'error_detail' by its aggregate, grouped nature.

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

  Usage Guidelines3/5

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

  The description conveys that this is a read-only, zero-credit diagnostic tool scoped to the workspace, which implies when it might be used. However, it does not explicitly contrast it with alternatives like 'error_detail' or state when not to use it. The usage context is present but not framed as a when/when-not decision, leaving the selection to inference.

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

• list_memoryA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explaining memory is 'durable' and 'shape every future ad', which provides behavioral context beyond the safety profile. It also explicitly states 'Read-only, free', consistent with annotations. No contradiction, and it adds useful context about the tool's impact.

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

  Conciseness5/5

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

  Two sentences with zero waste. The core purpose is front-loaded, then the definition of memory, its significance, and the read-only/free notes. Every clause earns its place.

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

  Completeness4/5

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

  For a simple listing tool with no output schema and two optional parameters, the description adequately explains what memory is and that the tool lists it. It doesn't describe the return format, but that's not required without an output schema. The schema covers parameter details. It's complete enough for an agent to call correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters (limit with default/max, category with allowed values). The description adds no additional meaning about parameters; it doesn't reference them. Baseline of 3 is appropriate given full schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool lists the workspace's Memory, a specific resource, and explains what that memory contains (brand, audience, taste, do/don't rules). This distinguishes it from other list tools like list_brands or list_playbooks, and from memory-related siblings like remember and forget.

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

  Usage Guidelines4/5

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

  The description implies this is for viewing memory in a read-only manner and notes it's 'free', but it does not explicitly state when to use this over alternatives like remember (save) or forget (delete). It provides good context about memory's role in future ads but lacks explicit when-not/alternative guidance. Since siblings are well-known, the purpose implies usage clearly.

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

• list_threads_repliesA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds behavioral context beyond annotations: the conversation flag changes the scope from direct replies to the entire thread, and the ordering note about reply_to_thread implies a workflow dependency. This adds value beyond the structured fields.

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

  Conciseness5/5

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

  Two sentences with no filler. The main action is front-loaded, and the key caveat about conversation is stated clearly. Every word earns its place; it is highly concise and well-structured.

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

  Completeness4/5

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

  For a simple read-only list tool with 3 well-documented parameters, the description covers the essential usage, including the conversation flag and sequencing. It does not describe pagination or return format, but the schema covers limits, and no output schema exists, so the description is adequate. Slight gaps (e.g., no mention of error cases) are minor given the tool's simplicity.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters (postId, limit, conversation). The description reiterates the conversation behavior (also in schema) and adds the 'Use before reply_to_thread' guidance, but that is not parameter semantics per se. Since the schema carries the full parameter documentation, the description adds little beyond it, warranting a baseline of 3.

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

  Purpose5/5

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

  The description states a specific verb ('Read') and resource ('replies on a Threads post'), which is unambiguous and distinguishes it from siblings like list_threads_mentions or search_threads_keyword. The title reinforces this. It clearly tells the agent what the tool does.

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

  Usage Guidelines4/5

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

  Provides explicit contextual guidance: 'Use before reply_to_thread so you answer with the actual conversation in view.' This gives sequencing advice. It also explains the conversation flag's behavior ('true = the whole thread'). However, it does not explicitly state when NOT to use it or name alternative tools (other than the sequencing hint), so it lacks full when-not/alternatives coverage.

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

• list_tiktok_comment_repliesA
  4.2/5.0
  Behavior5/5

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

  Annotations declare readOnlyHint and openWorldHint, but the description adds significant behavioral disclosure: TikTok does not return replies to a hidden comment, so an empty list has a specific meaning. It also states the auth requirement and that it is free, enriching beyond annotations without contradiction.

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

  Conciseness5/5

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

  The description is compact—two sentences—with the core purpose front-loaded, then a sibling contrast, a critical behavioral warning, and auth/read-only note. Every sentence serves a distinct purpose; no filler.

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

  Completeness3/5

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

  Given 7 parameters, low schema coverage, and no output schema, the description covers purpose, differentiation, and a key edge case, but omits pagination (cursor, maxCount), filtering (status), sorting (sortField/sortOrder), and return format details. It is not fully complete for an agent to call this tool correctly without further schema guidance.

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

  Parameters2/5

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

  Schema coverage is only 29% (videoId and commentId have descriptions). The description adds no explanation for cursor, status, maxCount, sortField, or sortOrder, and does not clarify how these parameters interact. It only references commentId provenance from list_tiktok_comments, leaving most parameters opaque for the agent.

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

  Purpose5/5

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

  The description states a specific verb (list), resource (replies to a single comment), and scope (all replies on a post owned by the authorized account). It explicitly contrasts with list_tiktok_comments, which only attaches three replies, making the tool's purpose and differentiation unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear usage context: it requires the TikTok account authorization (pointing to tiktok_account_status) and warns that an empty result against a hidden parent means 'cannot read' not 'no replies', advising to check parent status. It contrasts with list_tiktok_comments, but does not explicitly enumerate all alternative tools or conditions for 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.

• list_whatsapp_templatesA
  4.2/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantial behavioral context beyond annotations: Meta's ambiguous error message, language sensitivity (en vs en_US), variable count requirements, and the warning against reading count from the preview. Also mentions 0 credits and Meta connection requirement.

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

  Conciseness3/5

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

  The description is verbose and uses ALL CAPS for emphasis, which is somewhat heavy-handed. It front-loads the purpose but then spends several sentences explaining why status matters, error messages, and variable counts. While informative, it could be condensed without losing value. The structure is logical but not concise.

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

  Completeness4/5

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

  With no output schema, the description compensates by explaining key output fields (status, language, variables) and their significance. It also covers prerequisites (Meta connected) and cost (0 credits). It doesn't enumerate all possible output fields, but the essential ones for correct usage are thoroughly addressed.

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

  Parameters3/5

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

  Schema coverage is 100%, so all parameters are already documented. The description's comments about language and variables relate to output fields, not input parameters. It doesn't add new meaning to the input schema, but it reinforces the importance of the status and language filters. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it lists WhatsApp message templates on a Business Account and highlights the review status, which is a key differentiator from siblings like send_whatsapp_message or create_whatsapp_template. The verb 'list' and resource 'WhatsApp message templates' are explicit and unambiguous.

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

  Usage Guidelines4/5

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

  Provides strong contextual guidance: explains when you'd need this tool (before sending, to verify APPROVED status and get exact variable count) and a prerequisite (Meta connected). It doesn't explicitly name alternative tools or say when not to use, but the usage context is clear enough to route an agent correctly.

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

• list_youtube_commentsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only, 0 credits' and 'Needs a connected YouTube channel.' It adds useful context like return fields and ordering ('newest first') and the cost implication (0 credits), which goes beyond the annotations. No contradictions found.

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

  Conciseness5/5

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

  The description is three concise sentences, each earning its place: purpose, analogy to a sibling, and return/cost/prerequisite details. It is front-loaded with the core action and avoids redundancy, making it efficient for an agent to parse quickly.

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

  Completeness4/5

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

  For a simple list tool with 2 params and no output schema, the description covers essential aspects: purpose, return fields and ordering, cost, and prerequisite. It does not mention whether replies are included or error behavior, but given the straightforward nature and the 100% schema coverage, these are minor gaps and the description is sufficiently complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both videoId and limit thoroughly. The description does not add any additional parameter-specific semantics beyond what the schema provides, so it meets the baseline but does not elevate it.

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

  Purpose5/5

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

  The description clearly states the action ('Read the comments under a video on the connected channel') and the resource (YouTube video). It also distinguishes this tool from its Meta counterpart by explicitly referring to list_meta_comments, making its scope unambiguous among numerous platform-specific siblings.

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

  Usage Guidelines4/5

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

  The description provides context that this is for gathering 'questions, objections and exact wording real viewers use' for ad copy, and draws an explicit comparison to list_meta_comments, implying when to use this tool versus the Meta equivalent. However, it does not explicitly state exclusions or alternative tools for other platforms, though the mention of 'connected YouTube channel' implies the prerequisite.

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

• moderate_meta_commentA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context beyond annotations: hide is reversible and invisible to the commenter, delete is permanent and requires confirmation. This clarifies the irreversible nature of delete and the confirmation requirement, enhancing the safety profile.

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

  Conciseness5/5

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

  Two sentences with zero waste. The purpose is stated first, then usage guidance and the critical warning about permanence and confirmation. Every sentence earns its place, and the structure is front-loaded with the most important information.

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

  Completeness4/5

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

  For a comment moderation tool, the description covers the essential behavioral aspects: actions, reversibility, confirmation requirement, and context (Facebook/Instagram). It doesn't mention output format or error handling, but given the simplicity and that annotations cover the safety profile, it's complete enough for an agent to invoke correctly. Sibling tools provide similar patterns.

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

  Parameters3/5

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

  The input schema has 100% description coverage, including param meanings (action enum with default, pageId when to omit, confirm required only for delete, commentId source). The description reinforces these but doesn't add new parameter-specific semantics beyond what the schema already provides. It does add a behavioral preference (hide over delete) that indirectly affects action choice, but that's more usage guidance.

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

  Purpose5/5

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

  The description states a specific verb ('Moderate') and resource ('comment on the brand’s Facebook or Instagram post'), and lists the exact actions (hide, unhide, delete). It clearly distinguishes from sibling tools like comment_on_meta_post or reply_to_meta_comment, which serve different purposes.

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

  Usage Guidelines4/5

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

  It provides explicit guidance: 'Prefer hide over delete' with reasoning (reversible, invisible to commenter), and states that delete is permanent and requires confirm:true. While it doesn't explicitly say when to use this tool vs alternatives, it gives clear decision criteria within the tool and implies that for commenting/reply one should use other tools.

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

• publish_to_shopify_productA
  4.2/5.0
  Behavior5/5

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

  Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical asynchronous behavior: Shopify processes the image server-side, so a PROCESSING status is success, not failure. It also explicates an account eligibility constraint and cost-free nature. This adds significant value beyond what annotations convey, with 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.

  Conciseness5/5

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

  The description is compact and front-loaded: the core action is stated in the first clause, followed by key parameter guidance, then critical async behavior, and finally constraints. Every sentence contributes essential information without repetition or fluff.

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

  Completeness4/5

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

  For a mutation tool with no output schema, the description covers the essential operational context: how to identify parameters, what async processing means, success criteria, and eligibility. It lacks details about the response structure (e.g., whether a media ID is returned) but given the async nature and that the agent mainly needs to know success, this is adequate. Minor gaps prevent a 5.

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

  Parameters3/5

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

  The schema already provides full descriptions for all three parameters (100% coverage). The description adds minimal extra meaning: it reaffirms that imageUrl should be a public https URL (already in schema) and clarifies that productId comes from list_shopify_products (also in schema). The alt parameter is not elaborated further. Baseline 3 is appropriate since the schema carries the explanatory load.

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

  Purpose5/5

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

  The description clearly states the verb 'Attach' and resource 'finished image to Shopify product listing as product media'. It uses specific language that distinguishes it from general publish tools, naming the exact target resource (Shopify product listing). This differentiates it from similar sibling tools like set_product_image which may have broader scope.

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

  Usage Guidelines3/5

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

  The description provides operational constraints (pass productId from list_shopify_products, use public https imageUrl, only for Shopify App Store installs) but does not explicitly state when to use this tool versus alternatives. It does not mention when not to use it or name alternative tools for similar tasks, such as set_product_image. Guidance is implied but not explicit.

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

• reframe_videoA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=false, so the agent knows it's a mutating operation. The description adds valuable behavioral details: it is a 'Paid render' and 'returns the served URL of the reframed video', which explains cost and output. This goes beyond the annotations and does not contradict them.

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

  Conciseness5/5

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

  Two concise sentences with zero waste. The first sentence states the core purpose and includes an example, the second adds cost and return information. Information is front-loaded efficiently.

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

  Completeness4/5

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

  With only two parameters and no output schema, the description explains the return value (served URL) and cost (paid render). It does not mention potential limitations like supported formats or file size, but for a tool of this simplicity, the essentials are covered.

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

  Parameters3/5

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

  Schema coverage is 100% — both 'video' and 'aspectRatio' have descriptions. The tool description adds an example of aspect ratio conversion but no new parameter semantics beyond the schema. Per baseline, a score of 3 is appropriate when the schema already does the heavy lifting.

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

  Purpose5/5

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

  The description states a specific verb ('reframe'), a resource ('video'), and the exact purpose ('to a different aspect ratio') with a concrete example (16:9 → 9:16). This clearly distinguishes it from sibling tools like edit_video or clip_video, which focus on other video transformations.

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

  Usage Guidelines4/5

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

  The description implies usage for aspect ratio conversion and mentions 'smart subject tracking' and 'Paid render', but does not explicitly compare with alternatives or state when not to use. Since no sibling tool handles aspect ratio specifically, the intended use is clear, yet the lack of explicit exclusions prevents a perfect score.

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

• reply_to_threadA
  4.2/5.0
  Behavior5/5

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

  Annotations indicate this is a write operation (readOnlyHint=false) but not destructive. The description adds critical behavioral context: it publishes publicly under the brand's account and requires user confirmation. This goes beyond annotations by explaining the irreversible public impact and the need for user consent.

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

  Conciseness5/5

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

  The description is two sentences with no redundancy. It front-loads the primary purpose and immediately adds the crucial warning about public publication and user consent. Every word earns its place.

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

  Completeness4/5

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

  With no output schema, the description could mention the response format (e.g., success or error details), but the tool is straightforward: it posts a reply. The critical behavioral guidance about user confirmation is present, and the parameter semantics are fully covered by the schema. Missing minor details like rate limits or specific platform restrictions, but these are not clearly necessary for a 2-param tool.

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

  Parameters3/5

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

  Schema coverage is 100%, so both parameters are already described in the schema. The description adds no extra detail about the parameters beyond confirmation that they are needed. The baseline of 3 is appropriate when the schema covers the parameters adequately.

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

  Purpose5/5

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

  The description states a specific verb ('Post a reply') and resource ('a Threads post'), and clarifies it can be the brand's own or someone else's. This clearly distinguishes it from sibling tools like list_threads_replies, hide_thread_reply, and delete_thread.

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

  Usage Guidelines3/5

  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 vs alternatives, though the interaction with list_threads_posts or list_threads_replies is implied by the context. It lacks explicit guidance on when not to use it or mentions of alternatives like comment_on_meta_post for cross-platform replies.

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

• save_creatorA
  4.2/5.0
  Behavior4/5

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

  Annotations are all false (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), so the description carries the full burden. It discloses key non-obvious behaviors: saving is FREE and renders nothing, and it explains the nuanced consent and source requirements for real people. This adds meaningful context beyond the annotation fields and helps the agent avoid misuse. It does not mention overwrite or duplicate behavior, but for a save action this is not a critical omission given the explicit 'Add a portrait' framing.

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

  Conciseness4/5

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

  The description is detailed but not bloated. It front-loads the core purpose and then adds necessary usage and constraint context. The use of all-caps 'LIKENESS' and 'REAL' draws attention to critical distinctions. Each sentence contributes information without redundancy. It could be slightly tighter, but it remains well-structured and readable.

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

  Completeness5/5

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

  For a tool with 7 parameters, 2 required, and no output schema, the description covers all essential aspects: main purpose, usage flow, prerequisites (public URL, consent), parameter semantics reinforcement, and behavioral notes (free, renders nothing). It even implies interactions with sibling tools (list_creators, generate_avatar). Nothing critical is missing for an agent to call it correctly and safely.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description largely reiterates what the schema already states (e.g., image is a public URL, name is what to call the creator, look is canonical appearance). It adds emphasis on the source and consented constraints, but these are already in the schema. It does not introduce new parameter-level meaning beyond clarifying the relationship to other tools (e.g., URL reused in generate_avatar/video), which is more usage guidance than parameter semantics. Thus, 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: add a portrait to the workspace's reusable CAST so the same person can star in future ads. It explicitly identifies the API as the headless twin of the app's '＋ ▸ Pick a creator ▸ save' flow, which distinguishes it from sibling tools like list_creators, delete_creator, and generate_avatar. The verb 'Add' plus the resource (portrait to CAST) is specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use the tool: anytime you need to save a person to the reusable CAST for future ads. It explains the flow (pass a portrait URL and name, then list_creators returns them and the URL can be reused in other tools). It gives a critical usage rule about source and consented parameters, and indicates that saving is free and renders nothing. It does not explicitly name alternatives or state when NOT to use it, but it implies that once saved, you should use list_creators to retrieve existing creators, which is adequate guidance.

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

• search_threads_keywordA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds the 'PUBLIC' scope and emphasizes non-destructive search, but does not disclose additional behavior like pagination, rate limits, or result structure. Given the annotation coverage, this is adequate but not rich.

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

  Conciseness5/5

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

  Two sentences with zero fluff. The core action is front-loaded, followed by use cases and a sibling distinction. Highly efficient and well-structured.

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

  Completeness4/5

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

  For a straightforward search tool without an output schema, the description provides enough context: what it searches, when to use it, and how it differs from search_threads. It does not detail result format or pagination, but the implied output (matching posts) suffices given tool simplicity.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameters q and searchType are fully documented. The description mentions 'keyword or topic' which aligns with q, but adds no extra semantics beyond the schema. Baseline of 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool searches PUBLIC Threads posts for a keyword or topic, with explicit use cases (competitor listening, customer language). It also distinguishes itself from search_threads, which reads a specific profile, making the purpose unmistakable.

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

  Usage Guidelines5/5

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

  The description explains when to use this tool (keyword-based search of public posts) and explicitly contrasts it with search_threads, which targets a specific profile. This guides the agent on appropriate selection among siblings.

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

• search_threads_locationsA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that it searches a 'public place index' and returns location ids, which is mild behavioral context. It does not disclose any additional behavior like pagination caps or fuzzy matching, but given the annotations suffice for safety, a 3 is appropriate.

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

  Conciseness5/5

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

  The description is three sentences with zero fluff. The primary purpose is front-loaded, followed by the usage context and a direct instruction on how to consume the output. Every sentence earns its place, making it easy for an agent to parse quickly.

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

  Completeness4/5

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

  Given that annotations cover the read-only nature and schemas document all parameters, the description is nearly complete. It explains the returned data (location ids), the use case, and downstream consumption. Minor gaps like pagination or result limit are not mentioned, but for a simple search tool they are acceptable; a 4 reflects that it's solid but could include a note about result constraints.

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

  Parameters3/5

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

  The input schema provides complete descriptions for all three parameters (q, latitude, longitude) with 100% coverage. The description mentions searching by name or lat/long, which is already clear from the schema. No additional parameter-level meaning is added beyond what the schema already provides, so baseline 3 stands.

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

  Purpose5/5

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

  The description states a specific verb ('Search'), a specific resource ('Threads’ public place index'), and the output ('get location ids'). It clearly distinguishes this from a keyword search by specifying it's for geotagging physical locations, and the downstream usage (pass to post_to_meta) further clarifies its unique role among siblings like search_threads_keyword.

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

  Usage Guidelines5/5

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

  Explicitly states when to use: 'Use this when the brand has a PHYSICAL location' and provides a concrete example list. It also tells the agent exactly what to do with the result, including the target parameter for post_to_meta. This gives clear context without needing to reason about alternatives.

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

• upload_tiktok_comment_imageA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description adds substantial context beyond that — the all-three-must-be-passed-back constraint, 5MB/format/dimension limits, and the TikTok account authorization requirement. 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.

  Conciseness4/5

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

  Purposefully front-loaded with the core purpose, followed by operational constraints in a dense but relevant sequence. Long for a single-parameter tool, yet every clause (dimension matching, limits, auth) is operationally necessary; nothing is filler.

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

  Completeness5/5

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

  For a simple one-param tool with no output schema, the description is fully self-sufficient: it explains the return trio, the coupling requirement, size/format/dimension limits, the local-file conversion path, and the authorization prerequisite. Nothing an agent needs to invoke it correctly is missing.

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

  Parameters3/5

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

  Schema coverage is 100%; the schema already describes imageUrl as a public URL and mentions upload_file. The description repeats slightly more detail (that upload_file produces such a URL) but does not add meaningful semantics beyond what the schema provides. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description opens with a specific verb+resource: 'Turn a public image URL into the imageUri that comment_on_tiktok_video needs.' It states exactly what the tool produces (imageUri plus dimensions) and immediately names the consuming sibling tool, so an agent can tell it apart from upload_file and other upload utilities.

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

  Usage Guidelines4/5

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

  Provides clear context: it is a prerequisite step for comment_on_tiktok_video, notes when a raw URL will be rejected (new comment vs. reply), and points to upload_file for local files. It does not name explicit exclusions or 'when not to use' beyond the auth caveat, so it stops short of a full 5.

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

• upscale_videoA
  4.2/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, which are consistent with a tool that creates a new output. The description adds critical behavioral context: 'Paid render' informs the agent that this operation incurs cost, and 'returns the served URL' clarifies the return format. This goes beyond the annotations by disclosing financial impact and output type. It doesn't mention any potential delays or failure modes, but for a one-parameter tool, the added context is valuable.

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

  Conciseness5/5

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

  The description is a single, dense sentence that conveys the action, resolution factor, usage context (final delivery), cost (paid), and the output (served URL). Every word adds value, and the most important aspects (action and purpose) are front-loaded. No wasted text.

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

  Completeness4/5

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

  For a tool with one parameter and no output schema, the description covers the essential aspects: what it does, that it's paid, and what the return is. It doesn't mention whether the operation is synchronous or asynchronous, or any constraints on the input video (e.g., maximum resolution, format). However, given the simplicity, this is nearly complete and sufficient for an agent to decide when to invoke it. Minor gaps keep it from a 5.

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

  Parameters3/5

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

  The input schema covers the sole parameter 'video' with a description 'the source video URL' (100% coverage). The tool description does not add any parameter-specific details beyond what the schema provides, such as accepted formats, size limits, or how the URL should be hosted. Since schema coverage is high, the description meets the baseline but doesn't enrich parameter understanding beyond the schema.

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

  Purpose5/5

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

  The description states exactly what the tool does: 'Upscale a video to higher resolution (2x)' with a clear resource (video) and purpose ('for final delivery'). It distinguishes itself from siblings like clip_video, stitch_video, or edit_video by focusing specifically on resolution upscaling. This is a specific verb+resource pairing with no ambiguity.

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

  Usage Guidelines4/5

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

  The phrase 'for final delivery' gives clear contextual guidance on when to use this tool (when preparing a video for final output). It also notes 'Paid render,' implying it should be used when the user is willing to pay for higher quality. However, it does not explicitly mention alternatives or when NOT to use it, such as if the video is already at the target resolution or if a cheaper preview is sufficient. This is slightly above average but lacks explicit exclusions.

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

• analyze_videoA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint true, openWorldHint true, and destructiveHint false. The description adds useful behavioral context beyond this: it mentions 'Costs ~a transcription call,' which warns about resource consumption. It also specifies the outputs (transcript, beat list, timestamps) without contradicting any annotation.

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

  Conciseness5/5

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

  Two sentences, no fluff. Front-loaded with the core function, then adds usage context and cost. Every sentence earns its place, and the structure is efficient.

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

  Completeness5/5

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

  For a tool with a single parameter and no output schema, the description adequately explains the return value (transcript, beat list, duration, timestamps) and the expected use case. It even mentions cost, which helps the agent plan. Nothing critical is missing.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameter is already documented ('the video URL...'). The description does not add extra meaning about the parameter itself. Baseline of 3 applies because the schema fully covers it.

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

  Purpose5/5

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

  Description states a specific verb ('Break down') and resource ('video ad'), and precisely lists what it produces: verbatim transcript, beat list, duration, and sampled frame timestamps. It clearly distinguishes itself from sibling tools like finish_video or clip_video, which have different purposes.

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

  Usage Guidelines4/5

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

  Provides explicit context: 'Use to study a reference/competitor ad before remixing its structure.' This clearly indicates when to use it. It does not mention alternatives or when not to use, but for a single-purpose analysis tool, the guidance is sufficient.

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

• create_onedrive_folderA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate a non-read-only, non-destructive write operation. The description adds value by disclosing the return format (folder id + webViewLink), the optional nesting behavior, and the semantic distinction from save_to_onedrive's folder name. It does not contradict annotations and covers the key behavioral aspects beyond the structured metadata.

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

  Conciseness5/5

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

  The description is three sentences, front-loaded with the core purpose, then return value, then usage and a caveat. Every sentence earns its place with no redundancy or filler. It is efficient and well-organized.

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

  Completeness5/5

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

  For a simple two-parameter tool with full schema coverage and clear annotations, this description is complete. It explains the return value (compensating for the lack of an output schema), provides usage guidance, and disambiguates from a similar sibling. Nothing essential is missing for correct invocation.

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

  Parameters3/5

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

  Schema coverage is 100%, with both 'name' and 'parentId' already described in the input schema. The description reiterates the nesting behavior but does not add new parameter-level meaning beyond what the schema provides. Since the schema covers parameter semantics, the description's additional context is useful but not required, landing at the baseline of 3.

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

  Purpose5/5

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

  The description states a specific verb and resource ('Create a folder in the user's OneDrive'), explains its purpose ('to organize saved files'), and distinguishes itself from close siblings like save_to_onedrive and create_drive_folder by explicit naming and context. It also mentions the return value, making the tool's role unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear usage guidance: it explains how to use the returned id (as moveToFolderId for update_onedrive_file or as parentId for nesting) and explicitly warns about the difference from save_to_onedrive's folder name. While it doesn't enumerate all alternatives, it effectively prevents common misuse and gives actionable next steps.

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

• delete_playbookA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds valuable behavioral context: it records a cross-device delete to prevent reappearance on sync, and explains it is 'minor + re-creatable' so no confirmation is needed. This goes beyond the annotations and gives an agent insight into side effects. 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.

  Conciseness5/5

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

  Two succinct sentences: the first states the action and id source, the second explains cross-device behavior and the lack of confirmation. No extraneous words, and important details are front-loaded.

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

  Completeness5/5

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

  For a single-parameter, no-output-schema tool, this description is fully adequate. It covers how to get the id, the side effect (cross-device delete), and why no confirmation is needed. Combined with annotations for destructive/idempotent hints, nothing essential is missing.

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

  Parameters3/5

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

  The schema already fully describes the id parameter (type, required, description). The tool description repeats the instruction 'from list_playbooks', which adds a small hint about provenance but does not substantially augment the schema. With 100% schema coverage, baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the action ('Delete a saved playbook by id'), specifies the resource (playbook), and tells the agent exactly where to get the id ('from list_playbooks'). It distinguishes this tool from other delete operations (e.g., delete_creator) by naming the resource type. This is specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description implies usage context: you must first call list_playbooks to obtain the id. It does not explicitly name alternatives or state when not to use it, but the resource specificity is high and the id source instruction is a clear prerequisite. A slight gap is absence of explicit comparison to sibling delete tools, but the resource target makes it obvious.

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

• dub_videoA
  4.3/5.0
  Behavior4/5

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

  Annotations are neutral (readOnlyHint: false, destructiveHint: false), so the description carries the burden of disclosing behavior. It clearly states that it does NOT re-render, preserves visuals/timing/edit, transcribes/translates/re-voices/lip-syncs, and returns the served URL. It also discloses that it is paid. This adds significant behavioral context beyond annotations, though it omits potential limitations like processing time or input format constraints.

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

  Conciseness4/5

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

  The description is moderately long but every sentence earns its place: it explains the mechanism, the simple invocation, the script override nuance, and the cost/return. Key facts (no re-render, pass video+language, paid, returns URL) are front-loaded, making it skimmable. A slight trim could tighten it, but it remains focused.

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

  Completeness4/5

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

  With no output schema, the description correctly specifies that it returns 'the served URL of the localized video.' It covers all four parameters, the cost, and the behavioral specifics. Missing details like asynchronous processing or video size limits are non-essential for basic usage, so the description is virtually complete for an agent to invoke it correctly.

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

  Parameters4/5

  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 a description. The tool description enhances this by explaining the script parameter's override purpose ('pass script only to override what it heard') and adding nuance about the voice parameter's default selection. This goes beyond mere schema repetition, adding practical guidance without being redundant.

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

  Purpose5/5

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

  The description states a specific verb ('localize') and resource ('finished video') with a clear outcome (transcribed, translated, re-voiced, lip-synced back onto the same footage). It distinctly differentiates from siblings like clip_video or edit_video by focusing on language localization without re-rendering, leaving no ambiguity about what the tool does.

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

  Usage Guidelines4/5

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

  The description explicitly tells the agent to 'Just pass the video and the language', making the core usage obvious. It also provides a conditional for the script parameter (use only when auto-transcript fails) and mentions the tool is paid, which is a cost guideline. However, it does not explicitly contrast with alternative tools, though no direct sibling exists that performs dubbing, so the context is sufficiently clear.

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

• find_competitorsA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context beyond that: it mentions the tool is 'Claude grounded by web search' (indicating web-based grounding) and clarifies the behavior of each mode. However, it does not elaborate on the 'company' mode's exact output, leaving a minor gap in transparency.

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

  Conciseness5/5

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

  The description is concise and front-loaded: it opens with the core purpose, then efficiently covers modes and cost in a few short sentences. Every sentence adds useful information—purpose, grounding, mode details, and cost—with no redundancy or filler.

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

  Completeness3/5

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

  For a tool with no output schema, the description does not describe the return format (e.g., list of brand names/domains) or any prerequisites like domain formatting. The 'company' mode is mentioned but its behavior is not explained. Given the tool's moderate complexity (2 params, modes), the description is somewhat incomplete, though the core purpose is clear.

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

  Parameters4/5

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

  Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds meaning by explicitly stating the default mode ('competitors (default)') and the exclusion behavior ('excludes the searched company'), which goes slightly beyond the schema's enum descriptions. This adds value but does not dramatically compensate for any missing param details.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Discover a brand's competitor / similar / adjacent brands from its domain.' It names the specific resource (brands) and the input (domain), and differentiates from sibling tools like pull_competitor_ads or competitor_teardown by focusing on brand discovery rather than ads or analysis. The modes are also mentioned, adding specificity.

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

  Usage Guidelines4/5

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

  The description provides usage context by explaining the three modes and their behavior (competitors excludes searched company, inspiration includes it, company presumably returns the company itself), and notes the cost ('0 credits'). However, it does not explicitly state when to use this tool versus related siblings (e.g., competitor_teardown) or when not to use it, leaving some room for inference.

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

• format_sheetA
  4.3/5.0
  Behavior4/5

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

  The description adds behavioral context beyond annotations: it states it changes formatting but not cell values, and explains how to skip individual operations via parameters. Annotations already declare idempotent and non-destructive, and the description enriches this with specifics about freezing and auto-size.

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

  Conciseness4/5

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

  The description is longer than typical, but every sentence adds value. It front-loads the purpose and then explains usage and parameter specifics. The rhetorical flourish about 'the difference between a spreadsheet someone reads and one they close' is not wasteful, but could be trimmed without loss.

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

  Completeness4/5

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

  For a formatting tool with no output schema, the description covers the core use case, parameter semantics, and behavioral details. It does not mention error handling or authorization, but those are covered by annotations (idempotent, non-destructive) and are not critical for correct invocation.

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

  Parameters4/5

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

  Schema coverage is only 33% (only tab and freezeRows have descriptions). The description compensates by explaining the defaults and how to override each operation (tab, freezeRows, boldHeader, autoResize). It does not detail sheetUrl/spreadsheetId, but those are conventional identifiers.

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

  Purpose5/5

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

  The description clearly states the specific actions (bold header, freeze, auto-size) and the resource (exported sheet). It also distinguishes itself from create_sheet by describing it as a follow-up formatting step, not a creation or data mutation tool.

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

  Usage Guidelines4/5

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

  It provides a concrete trigger ('Worth calling right after create_sheet') and explains why (raw export with unsized columns). It also notes that it changes no cell value and is never gated, implying non-destructive use. However, it does not explicitly name alternatives for editing values or when not to use it.

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

• list_bluesky_convosA
  4.3/5.0
  Behavior4/5

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

  Annotations already cover read-only and non-destructive hints. The description adds valuable behavioral detail: the need for a privileged app password, that errors for a chat-capable password are a password property not a connection issue, and that unknown filter values are refused by name rather than silently dropped. This goes beyond the annotations without contradicting them.

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

  Conciseness4/5

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

  The description is substantial but every sentence earns its place: purpose, return details, cost, password nuance, and filters. It's front-loaded with the primary function and then layers prerequisites and edge cases. It could be slightly tighter, but the complexity justifies the length and it remains scannable.

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

  Completeness4/5

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

  Given there is no output schema, the description adequately covers what the tool returns (conversation participants, unread counts, request status) and explains the key prerequisite (privileged app password). It also addresses filter behavior and error semantics. Combined with the annotations, an agent has enough to call it correctly without missing critical details.

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

  Parameters4/5

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

  With 80% schema description coverage, the schema documents most parameters. The description augments this by explaining the meaning of 'request' (someone not followed), the purpose of filters (readState, status, kind), and the error handling for unknown filter values. It adds context to the enum parameters that plain enum values wouldn't convey.

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

  Purpose5/5

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

  The description states a specific verb (reads) and resource (DM conversations) with the exact data returned: who each is with, unread count, and request status. It immediately distinguishes itself from siblings on other platforms (list_x_dms, list_meta_conversations) by naming Bluesky and the AT Protocol.

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

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly explains when to use the tool (to read DM conversations) and provides prerequisites (privileged app password), which is essential context. It does not explicitly say 'use this instead of X', but the platform-specific focus and filter descriptions remove ambiguity. It also states it's free and requires no vendor approval, which helps an agent decide.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_instagram_mediaA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only, 0 credits,' adding the credit cost and the scope of 'own recent media.' It also discloses the media type 'story-era,' adding behavioral 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with zero waste. Core functionality is front-loaded, followed by practical usage context and a cost note. Every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with 2 optional parameters and no output schema, the description fully covers what it returns, why it exists (media ID resolution), and its read-only nature. No missing information prevents an agent from calling it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already documented (limit 1–50 default 15, pageId omitted when single Page). The tool description does not add any parameter-specific details, so the baseline of 3 applies as the schema carries the full burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists recent media from the connected Instagram Business account and enumerates the returned fields (id, caption, media type, permalink, timestamp, like/comment counts). It is specific and distinct from siblings by framing it as the source of media IDs for other tools, e.g., meta_post_insights.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells when to use this tool: to resolve media IDs ('resolve “my latest reel” yourself') and to pass IDs to meta_post_insights. It names an alternative tool for insights, providing context, but does not list explicit exclusions (e.g., using other listing tools for non-Instagram media).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_libraryA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses key behaviors: it returns assets with kind, model, age, and served URLs, and orders them newest first. It also states it is 'Free, read-only', which aligns with and reinforces the annotations (readOnlyHint, idempotentHint, destructiveHint). It adds value beyond annotations by describing the output content and ordering.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that front-loads the purpose and includes all essential details without redundancy. Every clause earns its place, covering scope, ordering, return fields, and a pointer to a related tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing tool, the description is complete: it explains what is listed, the ordering, what is returned, and how to use the results (open URLs or pass to fetch_asset). Since annotations already cover safety and schema covers parameters, nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides complete descriptions for both parameters (kind with enum and default, limit with default and max). The description does not add new information about the parameters, but given 100% schema coverage, the baseline of 3 is appropriate. It does not need to compensate for any gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: browse the workspace's Library and list image/video assets generated in the Studio, newest first. It is specific about what is returned (URLs, kind, model, age) and distinguishes itself from related tools like fetch_asset by noting it returns served URLs rather than download links.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use this tool (browsing the Library) and explicitly mentions fetch_asset as the alternative for obtaining download links, which guides the agent on differentiation. It does not explicitly state when not to use it, but the alternative mention and 'read-only' note offer sufficient guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_meta_catalog_productsA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and destructiveHint, but the description goes beyond by explaining that rejected products persist in the catalog, are counted, and never appear in ads. It also states cost ('0 credits') and reinforces the read-only nature. For a read-only listing tool, this is rich behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but every sentence contributes: purpose, key fields, rejected-product behavior, use case, page vs count clarification, and cost. It's front-loaded with the core definition and avoids filler, though a slightly tighter structure could improve scannability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description does a good job explaining what data is returned and its significance. It covers the main fields and the pagination nature, but it omits details like how to request the next page or any error conditions, leaving minor gaps for an agent executing multi-page requests.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers both parameters with descriptions (limit range and catalogId origin), and schema coverage is 100%. The description adds no extra meaning about the parameters themselves—it only relates the count to another tool. Thus it meets the baseline for fully documented schemas without adding value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly names the action (lists products), the target resource (a Meta catalog), and the specific fields returned, including the key 'REVIEW STATUS'. It explicitly distinguishes itself from related tools like list_meta_catalogs by stating it returns a page rather than a count, so an agent can tell them apart without opening schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides a concrete use case (confirming catalog contents before spending, diagnosing under-serving ads) and contrasts itself with list_meta_catalogs for the total count. However, it does not explicitly name alternatives like list_meta_product_sets or state when not to use this tool, leaving some inference to the agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_meta_commentsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds crucial non-obvious behavior: replies are nested and not returned by the post, requiring a recursive call with the comment id. Also discloses that each row shows reply counts, which informs the agent about output structure. Annotations already cover readOnly/non-destructive, so description enriches with reply semantics.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences with no fluff. The reply explanation is dense but necessary. Front-loads purpose and use case, then addresses the complexity. Well-structured for an agent to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers the key pitfalls (reply nesting, pagination caveat via schema) and provides actionable guidance. Does not enumerate all output fields, but without an output schema, the description still gives sufficient context for a read operation. Slightly incomplete on pagination behavior, but schema compensates.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  While schema covers 100% of parameters, the description adds meaning beyond schema: explains that postId can be a comment id to retrieve replies, and clarifies the purpose of count/cursor in context. This is valuable semantic addition beyond the basic schema text.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a clear verb-resource pair: 'Read the comments under a Facebook Page post or Instagram media object'. Distinguishes itself from sibling write/moderate tools by positioning as the read step. The mention of 'customer questions, objections and exact language' adds useful context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says it's 'the first step before replying or moderating', giving clear when-to-use context. Provides detailed instruction for fetching replies by setting postId to a comment id, which is essentially an alternative usage path. Doesn't explicitly list exclusion criteria (e.g., use list_meta_posts for posts), but the distinction is implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_meta_conversationsA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false plus openWorldHint=true, and the description never contradicts them. Beyond that it adds substantial operational disclosure: it reads inbox AND message requests by default, each thread is labeled with its folder origin, an empty list is explicitly NOT 'nobody messaged you' (it names measured causes including an app-level Instagram capability), the warning not to tell users to toggle Instagram settings, and the 'Read-only, 0 credits' cost note. This is deep beyond-annotation behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence carries operational value, but the description is a single dense wall of text with ALL-CAPS emphasis that makes it shouty and harder to skim. The empty-list and app-capability warnings justify some length, but phrasing like 'one question to a person, two edges to Meta' is cryptic, and the content could be tightened and sectioned without losing information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with four optional parameters spanning two surfaces and subtle message-request semantics, this description is remarkably complete: it explains defaults, per-thread provenance, the empty-list failure mode, the unrecoverable app-capability cause, cost, and safety. Despite having no output schema, it conveys the return shape (who, when, counts, unread, folder origin) clearly. Nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3 — and the schema already documents the critical folder-refusal behavior, the platform enum meaning, and the limit/pageId semantics. The description reinforces the platform 'both surfaces / two edges to Meta' idea and the folder default, but most of the parameter value lives in the schema. It adds marginal framing rather than new semantic content, so 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource — listing DM threads across Facebook Page and Instagram, with the exact fields returned (who wrote, last-write time, message count, unread count). It is clearly distinguishable from siblings like read_meta_conversation (reads one thread) and the other DM-listing tools (list_telegram_dms, list_x_dms, list_inbox), and the opening 'THIS IS WHERE THE BUYING QUESTION GETS ASKED' gives the agent a concrete sense of what the data is for.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly routes to the one-thread alternative ('Read one thread with read_meta_conversation') and explains the platform narrow-vs-both choice and the folder default ('Omit to read inbox + other'). It does not, however, contrast this tool with the generic sibling list_inbox or spell out a when-not-to-use condition beyond the empty-list caution, so the exclusions are implied rather than fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_shopify_productsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds value beyond this: it specifies the ordering (newest-updated first), the prerequisite (only for Hermoso-installed accounts), and clarifies that data is real, not guessed from the website. It also reinforces read-only and free status, which is redundant but not contradictory. This adds meaningful behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a tight three-sentence structure that front-loads the core purpose and field list, then packs in usage context, ordering, prerequisite, and a note about reliability. Every sentence earns its place without fluff, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with pagination, the description covers the key aspects: it lists the fields returned, mentions the cursor-based pagination is handled via the schema, and gives the critical relationship to publish_to_shopify_product. Annotations cover safety, and the schema covers parameters, so nothing an agent needs to call this correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters (limit and cursor), so the schema already documents their meaning and defaults. The tool description does not add any additional parameter-specific semantics beyond the schema, which meets the baseline of 3 for full coverage. No further explanation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb ('list') and resource ('real Shopify products') with a specific field list (id, title, description, price, images, storefront URL). It also explicitly differentiates itself from siblings by naming it as the source of productId for publish_to_shopify_product, making it unambiguous which tool to pick when needing product data.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit usage context: it is where productId for publish_to_shopify_product comes from and serves as ground truth about what the brand sells. It also states a prerequisite (only works for accounts created via the Hermoso App Store) and notes it is read-only and free. It doesn't explicitly mention when to avoid this tool or name alternative list tools, but the context is clear enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_youtube_report_jobsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces 'Read-only, 0 credits' adding the cost context. More importantly, it discloses a behavioral limitation: the bulk API only returns data for days after a job existed. This goes beyond what annotations capture, so it adds valuable behavioral context without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a compact three sentences with no fluff. It front-loads the core purpose, then gives the critical usage warning and cost info. Each sentence earns its place; it could be slightly tightened, but it is well-structured and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter list tool with no output schema, the description provides sufficient context: what it returns, why to call it, and a key limitation. It doesn't describe pagination or result structure, but that's minor given the simplicity. The sibling context (e.g., youtube_bulk_report, delete_youtube_report_job) further clarifies its role.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and schema coverage is trivially 100%, so there is nothing to document. Per the rubric, 0 params scores a baseline of 4. The description does not need to add parameter semantics and adequately covers what an agent needs to call it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states what the tool does: lists YouTube BULK reporting jobs on the channel, including which report each generates, its report type id, and schedule time. It also ties the purpose to a concrete use case (checking if thumbnail-CTR history is accumulating), which makes it unambiguous and distinct from siblings like list_youtube_videos or youtube_bulk_report.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear when-to-use guidance: call it before promising a user a number, to verify data availability and accumulation start date. It also discloses a timing constraint (bulk API only answers about days after a job existed). It does not explicitly name alternatives or say when NOT to use it, but the context is strong enough to guide an agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_youtube_videosA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark readOnlyHint=true, so the description adds beyond that by revealing that unlisted and private videos are included, that it costs 0 credits, and that a connected YouTube channel is required. These are useful behavioral details not present in annotations, though not exhaustive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose and return fields, then usage guidance, and finally differentiators. Each sentence contributes value and there is no fluff, though it is slightly longer than strictly necessary for the amount of unique information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with one optional parameter and no output schema, the description covers the key aspects: what is returned, when to use it, how it fits with other YouTube tools, and the caveat about unlisted/private videos. It lacks pagination or error details, but these are minor for such a simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter 'limit' has a schema description that fully covers it (default 25, max 50), providing 100% coverage. The tool description adds nothing about the parameter, so the schema carries the entire load. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly what the tool does: lists the connected channel's own uploads with id, title, publish date, and privacy status. It explicitly differentiates from youtube_channel (counts only) and search_youtube (public index), making it unambiguous which tool to use.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use instructions: call whenever the user names a video loosely and match it yourself, only ask when ambiguous. It also explains the tool's role as the source for videoId for other YouTube tools and contrasts with siblings, leaving no room for misinterpretation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_youtube_playlist_itemsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds genuinely valuable context beyond these: 'Removing an entry does NOT delete the video, only its place in the playlist' — which contextualizes the destructiveHint=false and prevents the agent from over-fearing removal. It also discloses credit cost (0 credits), the zero-based position convention, and the connected-channel requirement. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but every sentence earns its place: the itemId/videoId caveat is essential, the non-destructive removal note prevents misinterpretation, and zero-based positions affect correctness. It front-loads the core purpose and then layers in nuances logically. Could be trimmed slightly, but nothing is filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a three-mode tool with 5 params and no output schema, this is remarkably complete: it covers per-action parameter requirements, the identifier semantics, the non-destructive behavior, positional convention, credits, and prerequisites. The only minor gap is that it doesn't describe what REMOVE and MOVE return, though it does mention ADD's return (itemId). Given the complexity, this is well-covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, but schema strings are terse ('required for add', 'required for remove and move'). The description goes well beyond the schema by explaining the critical itemId vs videoId distinction and WHY it matters (videos can appear multiple times in a playlist), how to source itemIds, and that positions are zero-based. This meaningfully reduces the chance of the agent passing the wrong identifier.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with three specific verbs and a clear resource: 'Add a video to a playlist, remove an entry, or move an entry to a new position.' It explicitly names the three actions (add/remove/move) and the target (playlist entries), and repeatedly distinguishes entries from videos, which separates it from sibling tools like manage_youtube_playlist and manage_youtube_channel_section. No ambiguity about what this tool operates on.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete usage rules: ADD takes playlistId + videoId, REMOVE and MOVE take itemId (not videoId), with the rationale that a video can appear multiple times. It also states how to obtain itemIds via list_youtube_playlists and the prerequisite of a connected YouTube channel. It doesn't explicitly name exclusion cases ('don't use this for X'), but the action-selection guidance and workflow are clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• meta_page_insightsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, which establish safety. The description adds meaningful behavioral context beyond annotations: it clarifies the organic scope and introduces the MISSING data handling rule ('must never be reported as zero'), which is critical for interpreting responses. This goes beyond what annotations convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately long but packed with essential information. It front-loads the primary purpose and differentiators, then covers scope and data handling. Every sentence earns its place, though some redundancy exists (e.g., 'organic' repeated). It is well-structured but could be tightened slightly without losing clarity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description lists the key metrics returned (views, engagements, video views, follows, counts, Instagram headline numbers) and explicitly mentions the MISSING data behavior. It also differentiates from related tools. This is sufficient for an agent to understand what to expect, though it does not detail response format or units, which is acceptable without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, meaning both parameters (pageId and period) are already documented in the schema. The description does not add new semantics beyond what the schema provides; it reiterates the scope but does not explain parameter syntax or format further. This meets the baseline for fully documented parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description precisely states the tool's function: it retrieves organic performance metrics for a linked Facebook Page and the connected Instagram account, listing specific metrics like views, engagements, video views, follows, and counts. It clearly distinguishes from siblings by naming alternatives (meta_insights for paid, instagram_insights for full Instagram) and specifying this tool's organic focus.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance on when to use this tool versus alternatives: 'use meta_insights for paid ad performance, and instagram_insights for the full Instagram set and its audience demographics.' It also gives practical parameter advice, such as omitting pageId when exactly one Page is connected, and notes the default period, making it clear when to call this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pull_competitor_adsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds valuable behavioral context: 'Spends credits,' 'Meta only,' 'deduped, sorted, with the right page resolved,' and 'real live ads.' This goes beyond the structured data without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the key purpose ('FAST PATH') and scope. The supporting rationale about Meta having the richest creative is useful but slightly verbose. Each sentence earns its place, and it avoids redundancy with annotations.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a query tool with no required params and a complete schema, the description clearly conveys what it returns (real ads, deduped, sorted) and how to use it. It omits output structure, but that is not expected absent an output schema. It also flags credit cost, which is important for agent planning.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are already described. The description does not add new meaning beyond the schema (e.g., it restates defaults like limit 30 and country 'US'), providing marginal added value. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('pulls a named brand's real live ads from the META ad library') and distinguishes it from research_ads and Google/LinkedIn-specific tools. It immediately identifies the key scope (Meta only) and the differentiating factor (fast path for named brands), so an agent can select it correctly without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit routing: 'Prefer this over research_ads whenever the brand is named' and 'For Google or LinkedIn specifically, use search_google_ads or search_linkedin_ads.' This leaves no room for mis-selection and clearly states when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• read_meta_conversationA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true and destructiveHint=false, but the description goes far beyond by disclosing the reply-window computation (based on last message, not thread updated time), the Instagram truncation behavior, and the availability of replyTo. It clearly states read-only and 0 credits, aligning with readOnlyHint. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core function, then explains the critical reply-window nuance, and ends with platform-specific caveats. Every sentence contributes unique value, though the length is slightly above average. It is well-structured and lacks fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with subtle behavior, the description covers the main gotchas: reply window semantics, Instagram truncation, and the replyTo field. Since there is no output schema, it appropriately explains return expectations. It does not mention error cases or pagination beyond limit, but that is not essential for this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 75% (3 of 4 params have descriptions). The description adds value for `platform` by explaining the Instagram 20-message ceiling, but does not clarify `pageId` or add details for `limit` beyond the schema. Given moderate coverage and modest description contribution, it meets the baseline but does not exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool reads messages in a single DM thread, oldest to newest, with inbound/outbound markers. It distinguishes itself from sibling tools like list_meta_conversations (which lists threads) and reply_to_meta_message (which sends replies) by emphasizing the reply-allowed check and the replyTo id. The verb and resource are specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Read this before drafting' — signaling when the tool should be used (prior to composing a reply). It also explains the 24-hour reply window nuance and Instagram's 20-message truncation, guiding interpretation. However, it does not explicitly name alternative tools or provide 'when not to use' conditions, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• reddit_post_statsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true and destructiveHint=false. The description reinforces this with 'Read-only' and adds non-annotation context: '0 credits' (cost) and 'Needs Reddit connected' (prerequisite). It also discloses the return fields. There is no contradiction with annotations, and the additional info goes 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loading the action and return data, then providing usage context and prerequisites. No filler or repetition. Every sentence contributes value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter read-only tool with annotations covering safety, the description fully covers what it does, when to use it, prerequisites (Reddit connected), cost (0 credits), and return contents. Since there is no output schema, the description compensates by listing returned fields. Nothing critical is missing for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides full coverage (100%) for postId with a description explaining valid formats: 'the id returned by post_to_reddit, its t3_… fullname, or the full reddit.com permalink'. The description does not add further parameter detail, so baseline 3 is appropriate since the schema already documents the one parameter thoroughly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Read'), a clear resource ('one of the connected account’s Reddit posts'), and enumerates the exact data returned (score, comment count, upvote ratio, flair, removal status). It distinguishes itself from sibling operations like list_reddit_posts, edit_reddit_post, and delete_reddit_post by focusing on post performance metrics. The title 'How a Reddit post did' reinforces this.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use it: for 'how did that post do' or to judge which framing a community rewarded before writing the next one. It implies a read/analytics context but does not name specific alternatives or exclusions. Given the large sibling list, it could have pointed to list_reddit_posts for listing, but the purpose is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• reply_to_youtube_commentA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond annotations by explicitly stating 'This is PUBLIC and immediate' and requiring user confirmation ('show the user the exact reply text and get an explicit yes before calling'). This is valuable behavioral context not present in the annotations (which only note readOnly=false, idempotent=false, destructive=false). It also states the channel connection requirement. It could have elaborated on rate limits or error conditions, but given the annotations already cover basic safety, a 4 is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with no filler. It front-loads the core action ('Post a public reply'), then immediately highlights the critical warning about publicity and user confirmation, and finally provides the prerequisite and ID sourcing. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with annotations covering the safety profile (readOnly=false, idempotent=false, destructive=false) and no output schema, the description covers everything an agent needs: the action, the public/immediate nature, the confirmation step, how to obtain the ID, and the channel prerequisite. No additional information would materially improve correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%—both parameters have descriptions ('the reply, shown publicly under the video' and 'id of the comment to reply to (from list_youtube_comments)'). The description adds a minor hint about sourcing commentId from list_youtube_comments, but this only slightly supplements the schema. Per the rubric, a baseline 3 is correct when the schema already fully documents parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Post a public reply to a comment on the connected channel, as the channel.' It clearly distinguishes this tool from sibling reply tools (e.g., reply_to_meta_comment, reply_to_reddit_comment) by naming the YouTube context and the connected-channel prerequisite. It also specifies the source of the comment ID, making the action unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear contextual guidance: 'Get commentId from list_youtube_comments' and 'Needs a connected YouTube channel.' It also instructs the agent to obtain explicit user confirmation before calling. It doesn't explicitly state when not to use it versus alternatives, but the platform-specific nature makes that implicit. Minor gap: no mention of alternatives like moderate_youtube_comment, but the use case is distinct.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• request_featureA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey that this is not read-only (readOnlyHint: false), not idempotent (idempotentHint: false), and not destructive (destructiveHint: false). The description adds the behavioral context that the request is 'free, no credits' and that 'the use case is what gets built,' which suggests the request has real-world impact on Hermoso's roadmap. However, it does not disclose what happens after submission (e.g., whether a confirmation is returned, how long it takes, or whether multiple submissions are allowed), which leaves some behavioral ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact (about 60 words) and front-loaded with the primary action. The first sentence states the tool's purpose, the second provides usage conditions and examples, and the third gives content guidance. Every sentence adds value: the 'Free, no credits' is a key differentiator, and the instruction on including the use case is critical for effective feature requests. There is no redundant phrasing or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool whose sole function is to submit a feature request, the description covers the essential context: what it does, when to use it, and how to structure the request. With no output schema required, there is no need to describe return values. Annotations (openWorldHint: true) indicate external effects, and the sibling set clearly positions this tool as distinct from others like 'report_bug' and 'hermoso_capabilities.' Thus, the description is complete for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides thorough descriptions for both 'summary' and 'details' (schema coverage 100%). The description goes beyond this by reinforcing the importance of the use case over the feature name, explicitly instructing 'Say what the user was trying to achieve, not just the feature name.' It also echoes the details parameter's guidance, which helps the agent prioritize the content of the request. While it does not add new parameter-level details, it adds a strategic lens on how to fill them, thus improving parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear verb and resource: 'Ask the Hermoso team for a capability that doesn't exist yet.' It then enumerates concrete examples (unsupported platform or channel, missing model, export format) and distinguishes itself from the sibling 'report_bug' by focusing on requests for new capabilities rather than defect reports. The statement 'Free, no credits' further clarifies its unique purpose among the large sibling set.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states 'Use this when you need something Hermoso genuinely can't do' and lists scenarios, which is strong usage guidance. It implicitly differentiates from 'report_bug' (which handles defects) but never names it directly. It also implies not to use it for existing capabilities, though an explicit 'when not to use' is absent. The guidance to 'Say what the user was trying to achieve' provides clear direction on framing the request.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• save_to_driveA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal write (readOnlyHint: false) and non-destructive (destructiveHint: false). The description adds crucial context beyond that: the drive.file scope limitation (only reaches files created by the tool or user-picked), the connector requirement, and the return of webViewLink. This significantly helps an agent anticipate behavior and constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately long but every sentence provides value: purpose, parameter usage, prerequisites, return type, and a critical scope note. It is logically ordered, starts with the core purpose, and uses a NOTE to highlight the most important constraint. No fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given four optional parameters, no output schema, and the need to handle multiple file sources, the description covers all necessary details: different file input paths, connector prerequisite, scope limitation, return format, and folder behavior. It is complete enough for an agent to invoke correctly, though it doesn't detail error cases or pagination (not required).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover the parameters (100% coverage), but the description adds meaning: it clarifies the single vs. multiple URL relationship (url vs urls), the required upload_file workflow for non-Hermoso files, and that folder is created if new. This goes beyond the schema's bare definitions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States exactly what it does: 'Save a Hermoso render — or ANY file — into the user’s connected Google Drive.' It names the primary resource and the alternative file types, and the verb 'save' clearly separates it from sibling tools like list_drive_files, get_drive_file, update_drive_file, and save_to_onedrive. The scope is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit instructions: use url/urls for render URLs, or call upload_file first for local files and pass the returned URL. Also notes the connector requirement and that one connection covers Drive, Sheets, Docs. Does not explicitly mention exclusions vs other Drive operations, but the intent is clear from the 'save' verb and the workflow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_youtubeA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing credit cost, 'Organic' (non-paid) nature of results, and ranking behavior ('ranked by views'). 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two efficient sentences with zero waste. Purpose is front-loaded, the return format is compactly specified as a JSON key list, and the cost warning earns its place. Nothing redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Complete for a simple 2-param search tool. Annotations cover safety, schema covers the parameters, and the description explains the return format (compact JSON fields), ranking, purpose, and cost. No output schema exists, but the description explicitly enumerates response fields, so nothing an agent needs is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so both query and limit are already documented with descriptions. Out of curiosity, the description adds the 'ranked by views' context that clarifies how limit interacts with result ordering, but it doesn't add meaningful syntax or format details beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb (search), resource (YouTube), and endpoint (/v1/youtube/search), plus the intent ('videos to mine for hooks/angles/long-form structure'). It clearly distinguishes itself from sibling search tools like search_tiktok and search_instagram, and from the many youtube_* management tools (post_to_youtube, update_youtube_video, etc.).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Gives a clear context for use — organic keyword search for mining hooks/angles/long-form structure — which tells an agent when this is the right research tool. It also discloses the cost ('Spends about a credit'). However, it doesn't explicitly name alternatives or state when-not-to-use, so an agent must infer that other search tools (search_tiktok, search_threads) are the choice for other platforms.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• stitch_videoA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare false hints; the description adds meaningful behavior: 'Blocks until done' and 'Spends credits'. It also implies a render/creation operation, consistent with readOnlyHint=false. This gives the agent awareness of cost and synchronous behavior beyond the structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but every sentence is purposeful: purpose, usage conditions, model dependency, and behavior. It front-loads the core function and spends no words on fluff. Slightly verbose but well-structured and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers the essential decision framework (when to stitch vs not), model limits from hermoso_capabilities, and behavior (blocking, credits). The scene object structure is only lightly described in the schema ('visual + optional voiceover/seconds'), but the description does not elaborate; however, the schema already provides that hint. Without an output schema, some return details are missing, but overall it's sufficiently complete for an agent to call correctly in most scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with each parameter described (model, voice, scenes, etc.). The description adds context about model max and duration defaults indirectly but does not go beyond the schema. Since the schema already documents parameters, a baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear verb and resource: 'Render a multi-scene STITCHED video (≥2 scenes)'. It immediately differentiates itself from single-pass generation tools like generate_video/render_ad by stating the condition (spots longer than one clip). This precisely identifies the tool's unique role among many video-related siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use ('ONLY for spots LONGER than ONE clip of the chosen model') and when not to ('never stitch those'), and names the alternatives (generate_video/render_ad). It also references hermoso_capabilities for model-specific limits, giving concrete decision criteria. This is textbook usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tiktok_creator_infoA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover readOnlyHint=true and destructiveHint=false, lowering the bar. The description adds genuinely useful behavioral context beyond that: TikTok's requirement that actual options be shown and a privacy level picked (never assumed or defaulted), the account-dependence of the returned values, and the dependency on TikTok being connected. It also discloses that the same privacy levels apply to photo posts. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The purpose is front-loaded in the first clause, and every subsequent sentence earns its place: the required user-interaction behavior, the sequencing, the photo-post edge case, and the connection prerequisite. It is longer than the minimal definition, but the density is justified because each sentence conveys a distinct operational fact rather than padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema present, the description responsibly enumerates the return values (privacy levels, comments/duet/stitch, video length, nickname), covers the required pre-condition (TikTok connected via Settings ▸ Connectors), explains the follow-on step, and flags the non-obvious slideshow case. Minor gaps remain around exact return formatting and error behavior for a disconnected account, but against the sibling set this is well covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has 0 parameters and an empty schema at 100% coverage, so the description carries no parameter burden — the baseline of 4 applies. There is nothing for the description to explain regarding inputs. This is correct and needs no additional param documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Read the connected TikTok creator's REAL posting options BEFORE posting.' It enumerates exactly what is returned (privacy levels, comments/duet/stitch availability, max video length, nickname), which separates it from siblings like post_to_tiktok, tiktok_account_status, and list_tiktok_videos. The 'REAL' emphasis makes clear this returns account-specific options rather than generic defaults.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit operation order: 'Call this first, show the options, get the user's pick, then call post_to_tiktok.' It also states the tool must run 'BEFORE posting.' This is strong sequencing guidance. It lacks explicit when-not-to-use phrasing or named alternatives, but the mandated 'call this first' ordering effectively distinguishes it from post_to_tiktok, so only the absence of explicit exclusions keeps it from a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• append_to_sheetA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and idempotentHint=false, signaling a mutating, non-idempotent operation. The description adds the reachability constraint (created vs. user-shared sheets) which is valuable context beyond annotations. No contradiction exists, and it explains the source of valid spreadsheet IDs.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no fluff. It front-loads the core purpose and then delivers key details about eligibility and the rows format. Every phrase contributes to understanding, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple append tool with three parameters and no output schema, the description covers the essential information: what it does, which sheets are valid, how to obtain IDs, and the format of rows. The optional range parameter is documented in the schema, so the description need not repeat it. It is complete enough for an agent to call correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for all parameters, giving a baseline of 3. The description adds meaningful context beyond the schema by explaining that spreadsheetId can come from create_sheet or list_drive_files, which clarifies the allowed values. For 'rows', it repeats the schema description, but the added id-source info justifies a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action 'Append rows' and the resource 'Google Sheet', and explicitly defines the set of reachable sheets (created by Hermoso or handed over via file picker). This distinguishes it from sibling tools like update_sheet, clear_sheet_range, and read_sheet, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives concrete guidance on how to obtain the spreadsheetId — via create_sheet or list_drive_files — and specifies the condition of which sheets are eligible. It does not explicitly state when not to use the tool versus alternatives, but the tool name and purpose make that distinction clear, so the guidance is adequate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• change_voiceA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds valuable behavioral context beyond the annotations: it is paid, preserves performance/lip-sync/background sound, and returns a served URL. Annotations only indicate mutability and non-destructiveness, so the description enriches the agent's expectations. It does not mention whether the operation is synchronous or returns a job ID, but the core behaviors are well disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, zero fluff. The primary action is front-loaded, followed by usage guidance and a paid/return note. Every sentence earns its place and the description is easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with two straightforward parameters and no output schema, the description covers the key aspects: what it does, when to use it, cost, and return value. It omits any note about processing time or async behavior, which could be relevant given sibling tools like get_job, but for basic invocation the description is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema (100% coverage), including examples for voice and a default value. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states a specific action ('Swap the narration of a finished video into a different voice') and resource ('finished video'), and explicitly contrasts with dub_video for language translation. The description makes it unmistakable what this tool does and how it differs from a closely related sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit usage guidance: 'Use when the user likes the video but wants a different narrator voice; use dub_video only for language translation.' This names the alternative and the condition for selection, leaving no ambiguity about when to pick this tool over its sibling.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_google_business_postA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes beyond annotations by stating the action is immediate and irreversible ('CANNOT be undone'), and explicitly advises confirming with the user first. This adds meaningful behavioral context that the destructiveHint and readOnlyHint annotations alone do not fully convey, such as the need for user confirmation and the instantaneous effect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four sentences with no redundancy: the first two cover the action and consequence, the third explains how to get the identifier, and the fourth the prerequisite. All sentences earn their place, and the most critical information (irreversibility and confirmation) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a delete operation, the description covers the key aspects: effect, irreversibility, source of the post ID, and connection prerequisite. It lacks details about error cases (e.g., post not found) and response behavior, but with no output schema and a simple delete action, these are minor gaps. Could benefit from a note on what happens if the post is already deleted, but overall sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides a full description for postId, including the format (accounts/.../locations/.../localPosts/...). The tool description reinforces this by saying 'Pass the full post name from list_google_business_posts' but adds no new information beyond what the schema covers. Therefore, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Remove' and the specific resource ('a Post from the brand’s Google Business Profile listing'), explicitly noting it affects Google Search and Maps. It distinguishes itself from other delete_* siblings by naming the exact platform and linking to list_google_business_posts as the source of the post identifier.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear usage context: confirms with the user first, instructs to pass the full post name from list_google_business_posts, and states the prerequisite that Google Business Profile must be connected. It does not explicitly mention when-not-to-use or name specific alternatives, but given the specialized nature, the guidance is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_onedrive_fileA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds recoverability ('moves to the OneDrive recycle bin') and a confirmation requirement beyond what annotations already state (destructiveHint=true). This gives the agent important behavioral context for a mutation, meeting the lowered bar set by annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, zero waste, with the action and critical safety note front-loaded. The structure is clean: what it does, where it goes, how to call it, and a safety directive.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a delete operation with destructiveHint, it covers the essentials: the action, recoverability, how to get the ID, and the confirmation requirement. No output schema is present, but delete typically returns minimal info, so this is adequate. Missing edge cases like non-existent files aren't critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers both params, but the description enriches them: it specifies fileId comes from list_onedrive_files and that confirm:true is required (aligning with the schema's 'REQUIRED true' description). This helps the agent construct valid calls.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb+resource: 'Delete a OneDrive item' with the key behavior of moving to the recycle bin. Clearly distinguishes from siblings like delete_drive_file by specifying OneDrive specifically, so an agent can immediately know what it's for.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit instructions: 'Pass fileId (from list_onedrive_files) + confirm:true' and emphasizes confirming with the user first. While it doesn't name alternatives or when-not-to-use, the guidance is clear and actionable for this destructive operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• export_swipefile_deckA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description thoroughly discloses behavioral mechanics beyond the annotations: it explains the drive.file scope limitation (why it cannot modify existing decks), the handling of expired ad-library links (falls back to textual description, reports count), returns presentation id+URL, and the connector prerequisite. Annotations only indicate readOnly=false, openWorld=true, idempotent=false, destructive=false; the description adds substantial operational depth that an agent needs to call it correctly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the core purpose, then progresses to behavioral constraints and prerequisites. It is longer than strictly necessary (~150 words) but every sentence serves a distinct function (purpose, return value, new-deck behavior, expiry handling, connector requirement). Slight over-explanation of the expiry edge case could be trimmed, but overall it earns its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, it explicitly states the return value (presentation id + URL). It covers failure modes (expired links), scope limitations, and the required connector setup. It also handles the fact that all parameters are optional by stating defaults. Nothing an agent needs to call this tool correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — each parameter (limit, title, collection) already has explicit descriptions including defaults. The main description adds no additional meaning about parameters beyond what the schema provides. Per the rubric, with high schema coverage the baseline is 3; the description doesn't elevate it further.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Turn a SWIPEFILE COLLECTION into a real Google Slides deck', and enumerates exactly what each slide carries (creative, brand, copy, run dates, platform). It also differentiates from siblings by noting 'until now the swipefile’s only export was JSON', making it clear this is the dedicated Slides export. No ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states the clear use case ('the thing a marketer actually presents') and provides critical constraints: creates a NEW deck every time, cannot add to an existing deck due to drive.file scope, and requires Drive connected (with explicit settings path). It implicitly contrasts with JSON export and other Drive file tools (e.g., create_doc, create_sheet) by positioning it as the presentation-specific exporter, though it does not name alternatives explicitly. That is sufficient context for an agent to decide when to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• generate_textA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are all false, offering no behavioral hints, so the description carries the full burden. It discloses the default copywriter system prompt, the raw:true escape hatch to bypass it, and that the tool is paid by length—valuable behavioral context not in the schema. It doesn't contradict annotations, though it omits error handling and response format.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, information-dense paragraph where each sentence earns its place: purpose, scope, exclusions, default behavior, parameter tips, and cost. No redundancy or filler; the most critical scoping info is front-loaded before the parameter notes.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple prompt-based generation tool, the description covers purpose, usage boundaries, default behavior, and cost. It omits an explicit return-type description and error cases, but these are well-implied for text generation, and the schema handles parameter documentation. The tool's complexity is low enough that this is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed parameter descriptions for prompt, model, and raw. The description adds only minor reinforcement (e.g., 'Claude orchestrator' for model) but doesn't introduce new semantic meaning beyond the schema. Baseline 3 is appropriate because the schema already does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names the verb 'generate' and resource 'text' against a specific writing-model catalog, and enumerates concrete use cases (ad copy, hooks, scripts, rewrites, brainstorms). It explicitly distinguishes itself from ad-assembly tools (plan_ad → render_ad) and other generation siblings (image, voice, video), making its purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives direct when-to-use (prompt-only text generation) and when-not-to-use (for a finished on-brand creative use plan_ad → render_ad) guidance. It also explains the raw:true option for non-marketing copy, providing clear selection criteria against alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_tiktok_mentionA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover readOnlyHint and destructiveHint, so the description's addition of the 48-hour data retention, auth requirement ('NEEDS THE TIKTOK ACCOUNT AUTHORIZATION with the brand-insights permission'), and the fact it's free and read-only adds meaningful behavioral context beyond annotations. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single paragraph but dense with critical info: purpose, use case, urgency (48h), alternative, param requirement, and auth. Every sentence adds value, and the key constraint (48h) is front-loaded. Slightly long but justified by the number of important caveats.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 3 params, no output schema, and existing annotations, the description covers purpose, usage context, data availability, alternatives, auth, and read-only nature. An agent has all necessary information to decide when to call this and what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline applies. The description reiterates itemId is required even for comments and that commentId selects comments, but the schema already explains this. No additional semantic value beyond what's in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Read the full detail of a SINGLE mention'), identifies the resource (TikTok mention), and distinguishes post vs comment via commentId. It also contrasts with sibling tools (list_tiktok_mentions, list_tiktok_mention_comments) by noting it serves the webhook use case, making it easy to differentiate.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use (webhook events with only ids) and when not (anything older than 48 hours, pointing to list_tiktok_mentions or list_tiktok_mention_comments). Also clarifies itemId is required even for comments, and mentions the 48-hour data guarantee as a critical constraint.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• invite_memberA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate it is not read-only and not idempotent, but the description adds critical behavioral detail: it SENDS a real email invite/share link and is an account change. It also mandates confirm:true, which is not in annotations. This goes beyond the structured metadata and is highly relevant for an agent to understand the real-world impact.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, front-loaded with the core action, and the critical warning about confirming with the user and needing confirm:true. No wasted words; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an invitation tool that sends a real email, the description covers the essential behavioral and usage constraints. It doesn't describe the return format, but that is not critical for calling the tool correctly. The role meanings and confirmation requirement are the key details, and they are present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds meaning beyond the schema for role (explains permissions) and for confirm (emphasizes it's required to actually send). This is valuable clarification that the schema's brief descriptions do not provide.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb (invite), the resource (someone to this brand workspace), and the method (by email). It also explains the role semantics (member read-only on billing, admin full), which distinguishes it from other team management tools like remove_member or set_role. The purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context: use to invite someone by email, and it warns to confirm the exact email and role with the user and call with confirm:true. It doesn't explicitly state when not to use or name alternatives, but the guidance is actionable and sufficient for correct invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_google_business_reviewsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds non-obvious behavior: read-only and free (0 credits), requires Google Business Profile connection and API approval, and warns that an empty page doesn't mean no reviews. These are not implied by annotations and are valuable for correct invocation, covering prerequisites and error nuances.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence adds value: core purpose, strategic context, field explanation, warnings, prerequisites. It is front-loaded with the main content and structured logically, making efficient use of words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description lists the response fields and warns about pagination edge cases, and covers prerequisites and error handling. Minor gap: it doesn't explicitly describe pagination token behavior beyond the empty page warning, but overall it is complete enough for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 75% of parameters with descriptions; the description doesn't add any parameter-specific guidance beyond what's in the schema, so it stays at the baseline of 3. It does not compensate for the undocumented pageToken parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the tool lists reviews with specific fields (star rating, reviewer, text, date, reply status) and clearly calls it a read operation. It also distinguishes it from the reply tool by mentioning the reply field, making its purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides context for when to use (to work the list of unanswered reviews) and advises against computing average ratings from one page, but doesn't explicitly differentiate from sibling tools like list_google_business_questions or google_business_insights. The guidance is clear but lacks explicit alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_meta_pagesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns a connect hint if the user hasn't connected Meta, which is useful behavioral context. It doesn't contradict annotations and provides additional info beyond what structured fields convey, though it doesn't detail other behaviors like pagination.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loading the core action and scope, then adding usage context and a prerequisite. Every clause serves a purpose, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple listing tool with no parameters and no output schema, the description covers the essential context: what it returns (a list of pages/ad accounts), when to use it, and a prerequisite. Could mention return format or connection-failure behavior in more detail, but these are minor for this scope.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and the schema coverage is 100% with an empty object. The description adds nothing about parameters because there are none to explain. Baseline for 0 params is 4, and the description appropriately avoids extraneous detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('List') and resource ('Facebook Pages with any linked Instagram business account and ad accounts') on the connected Meta account. It also provides context for its use, distinguishing it from posting tools by naming post_to_meta and create_meta_campaign. This is unambiguous and differentiates the tool from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly instructs to use before post_to_meta/create_meta_campaign to pick the target, providing clear when-to-use context. It also notes the prerequisite of having Meta connected. However, it does not mention alternatives or when not to use this tool, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_meta_webhook_eventsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and non-destructive, but the description adds critical behavioral details: the empty-feed ambiguity, the need to check meta_webhook_status, and the fact that Hermoso restarts rebuild the feed from a durable mirror with only recent history. This is beyond the annotations and essential for correct interpretation of results.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but each sentence contributes: it starts with the core purpose, provides a motivational contrast, specifies scoping, and then gives a critical warning about empty feeds. The all-caps warning is attention-grabbing but not wasteful. It is well-structured and front-loaded, earning a high score despite its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's input, output nature (events with arrival times), scoping rules, and the empty-feed edge case. Given there is no output schema, the description sufficiently explains what to expect. The limit and field parameters are already documented in the schema, and the description adds the needed behavioral context. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with clear descriptions for each parameter (field, limit, pageId). The tool description does not add additional meaning or context beyond what the schema states; it mentions event types that map to field values but adds no new semantic detail. Hence the baseline score of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the tool's function explicitly: it lists Page events Meta pushed to Hermoso, enumerating event types (comments, mentions, lead forms, DMs) and noting arrival times. It also specifies the scope (Pages the brand can see) and distinguishes it from manual checking. This is a specific, non-tautological statement that clearly differentiates the tool from other list tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use the tool — to learn about events as they happen rather than when someone checks — and includes an explicit conditional: if the feed is empty, check meta_webhook_status to disambiguate subscription vs. no events. It does not explicitly name alternative tools for other scenarios, but the usage context is sufficiently clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_onedrive_filesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'Read-only' and explains pagination and search semantics, which are beyond the annotations. It does not contradict annotations and provides useful behavioral context about how the tool operates.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences with no redundant wording. It front-loads the primary purpose and then covers the key modes and pagination in a logical order. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only listing tool, the description covers the necessary modes, pagination, and filtering. It lacks details on error handling or sorting, but these are not critical for a basic list operation. The sibling list_drive_files differentiates Google Drive, and the mention of 'OneDrive' clearly sets the scope.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are already documented. The description adds value by explaining how the parameters combine (e.g., root vs. folder vs. search, pageToken as cursor) and emphasizes the default behavior. This transcends mere schema repetition.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the verb 'list' and the resource 'files & folders in the user's OneDrive', and enumerates three distinct modes (root, folder, search) plus a folders-only filter. This makes it easy to understand what the tool does and how it differs from generic listing tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage modes are clearly explained: 'root by default', 'folder’s contents (folderId)', 'name search (query)', and pagination with pageToken. It does not explicitly mention alternatives like get_onedrive_file or save_to_onedrive, but the self-contained guidance is sufficient for typical listing use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_pinterest_pinsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, but the description adds meaningful behavioral context: it is 'Read-only, 0 credits,' it mentions timeouts on account-wide listing, and it details the fields returned including promotion status. There is no contradiction with annotations. The description goes beyond the annotation by alerting to performance risks and providing a cost indicator, though it does not elaborate on pagination behavior — but that is covered by the cursor parameter.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately long but every sentence adds value. It front-loads the core function, then lists return fields, then emphasizes the pinId source, then gives the boardId preference, then states read-only/cost/connection needs. The use of capitals for the pinId note is attention-grabbing but not excessive. It is concise enough for the information density.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description fully specifies the returned row's fields (id, title, description, destination link, alt text, board, creation date, promotion status). It also covers prerequisites ('Needs Pinterest connected'), cost ('0 credits'), and a performance caveat (timeouts). An agent has everything needed to decide when and how to call it and what to expect, making it a complete description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — each of the three parameters (limit, cursor, boardId) has a clear description in the schema. The tool description does not add much beyond the schema; it reinforces that boardId should be preferred but doesn't redefine parameter semantics. Given the high coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists Pins, either for a specific board or across all boards when boardId is omitted. It specifies the exact resource (Pins) and identifies the fields returned. It also differentiates from sibling tools like list_pinterest_boards, which list boards, and post_to_pinterest, which creates a Pin — so an agent can distinguish it immediately.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly explains when to use this tool: it is the source for pinId that other Pin tools need, because post_to_pinterest only returns an id at creation. It also advises 'Prefer passing a boardId' due to known timeouts on account-wide listing, and notes the requirement 'Needs Pinterest connected.' This gives clear, actionable guidance on when and how to invoke it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_teamA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and destructiveHint, and the description reinforces this with 'Read-only' while adding the extra 'free' (cost) information not present in annotations. It also discloses the returned fields, providing useful behavioral context beyond the structured data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the core action and scope. It contains no fluff and every word adds value, earning a top score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only list tool, the description is largely complete: it states what is listed and the returned fields. It does not mention pagination or error handling, but these are not critical for a simple list operation, and the description covers all essential information an agent needs to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema description coverage is 100% (empty schema). With no parameters to document, the description correctly omits parameter details, and the baseline for 0-parameter tools is 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('List') and resource ('members of the current brand workspace') and enumerates the fields returned (email, role, status). It is unambiguous and distinguishes itself from sibling mutation tools like invite_member or remove_member.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by specifying the scope ('current brand workspace') and implies read-only usage, but it does not explicitly name alternatives or state when not to use it. Since the action is straightforward, the context is sufficient for an agent to decide when to call it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_telegram_chatsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds significant behavioral context beyond that: it explains the 24-hour update window, the webhook caveat, and explicitly states 'Nothing is consumed — no update offset is confirmed, so this cannot eat the bot’s pending updates.' This directly addresses side-effect concerns and data source limitations, going well 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average, but every sentence earns its place: it front-loads the purpose, then delivers critical caveats (non-exhaustive list, webhook effect, non-destructive nature). It is structured to lead with the answer and then preempt misinterpretations. A bit verbose, but not wasteful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description fully covers what the tool returns and when it might be incomplete or empty. It addresses edge cases (no messages, webhook), explains the update window, and reassures about side effects. An agent has all necessary information to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage for the single parameter 'limit' with a description of range and default. The tool description does not mention this parameter or add any additional meaning. Since the structured schema already documents it, the baseline of 3 is appropriate; the description adds no extra value here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb (find) and resource (chat ids), and explicitly scopes it as 'this Telegram bot can be addressed by'. It immediately distinguishes itself from a full chat list by saying 'this is NOT the list of chats the bot belongs to', differentiating it from potential sibling tools like list_telegram_dms.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear guidance on when to use it: to get addressable chat ids, and warns when it will fail to show chats (channels without message activity, webhook configuration). It even advises 'post to it by @username or numeric id anyway' for absent channels. It does not explicitly name sibling tools but effectively tells the agent what this tool is and is not for.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_threads_mentionsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds important scope context: 'anywhere, not just under your own posts', which clarifies the tool's behavior beyond what annotations provide. It also frames the output as useful for ad copy and mine_angles, though that's purpose rather than behavior. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with zero waste. The first sentence states the core function and scope; the second provides value context and a clear alternative. It is front-loaded and precise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with one parameter and no output schema, the description provides enough context: it clearly states what is returned (posts with mentions) and how to use it. It lacks details on ordering or pagination, but these are minor for a read-only list tool. It is complete enough for an agent to call correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and the single parameter 'limit' is already fully documented in the schema. The description does not add any additional parameter semantics, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb (list), resource (mentions of the brand on Threads), and scope (anywhere, not just under own posts). It also explicitly names the sibling tool list_threads_replies and differentiates from it, 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.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says when to use this tool: for brand listening, gathering objections, questions, and exact customer language. It also directs to use list_threads_replies instead when the user wants conversation under a specific post. This is clear when/when-not guidance with a named alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_threads_profile_postsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover readOnlyHint and openWorldHint, but the description adds critical behavioral detail: it is read-only, costs 0 credits, requires a Threads connection, and—most importantly—explains that an empty list does not prove the account has no posts, listing three specific reasons (private, <100 followers, unapproved permission). This goes far beyond the annotations and prevents a potentially dangerous misinterpretation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than typical but every sentence carries weight: it states the purpose, gives workflow context, and includes a critical warning. The most important caveat is emphasized with capitalization. It could be tightened slightly (e.g., repeating 'for' clauses), but it remains efficient given the behavioral nuance it must convey. Front-loading the purpose is done well.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool with only two parameters and no output schema, the description is comprehensive. It covers the return type (recent public posts), the workflow context, authentication requirements, cost, and the critical empty-list caveat. An agent has everything needed to call it correctly and interpret results appropriately.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for both parameters, including accepted username formats and the limit default. The description adds no additional parameter meaning beyond what the schema states; it only mentions 'limit' indirectly via 'how many posts' which is already in the schema. With full schema coverage, the baseline of 3 applies, and the description does not materially elevate it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as reading a public Threads account's posts, calls out the raw material for specific workflows (teardown, mine_angles, ad copy), and differentiates it from siblings like threads_profile (profile info) and list_threads_posts (own posts). It explicitly says 'Use it after threads_profile, or on its own when you already know the handle,' which distinguishes its scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: use after threads_profile or when you know the handle, and then use the returned content for drafting posts or planning ads. It does not explicitly name an alternative tool for cases like private accounts, but the caveat about empty lists guides the agent on when not to conclude absence of posts. This is strong guidance, though it lacks an explicit 'when not to use' statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_tiktok_brand_hashtag_postsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the annotations (readOnlyHint, openWorldHint, non-destructive). It discloses two bug-like behaviors (case-sensitive matching and empty matched_hashtags when filtering a single tag), the requirement that hashtags be enabled before any results return, the 1,000-post/90-day cap, and the authorization requirement. This is rich behavioral context that materially changes how an agent should interpret results. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense and front-loaded with the core purpose, then delivers behavioral caveats in all-caps for emphasis. While long, every sentence contributes critical operational detail. It could be more tightly structured (e.g., bullets), but it is not padded with fluff, so it earns a 4 rather than a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the major context: the hashtag mechanism, setup requirements, authorization, caps, and behavioral quirks. However, with 8 parameters and no output schema, the lack of explanation for five parameters means an agent may not know how to use pagination, field selection, or sorting. Overall it is fairly complete for a complex tool but not fully so, hence a 4.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 38% (only days, hashtag, and maxCount have descriptions). The description does explain the 'hashtag' parameter's case-sensitivity and the 'days' implicit limit (90 days), but it does not address 'cursor', 'fields', 'regions', 'sortField', or 'sortOrder'. Given the low schema coverage, the description was expected to compensate for these, but it leaves five of eight parameters undocumented, which is a significant gap for an agent trying to call the tool correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb (list) and resource (public posts with enabled brand hashtags on TikTok), and explicitly distinguishes it from its sibling 'list_tiktok_mentions' by noting it's the hashtag half vs. @-mentions. This makes the tool's purpose unambiguous and differentiates it from similar tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance: it names the alternative (list_tiktok_mentions) and when to use it, explains how to use the 'hashtag' parameter (omit for all, pass one to narrow), and specifies a prerequisite (hashtags must be enabled via other tools, with a 24-hour waiting period). This is actionable and prevents misuse.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_x_dmsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true and openWorldHint=true, but the description goes far beyond: it discloses credit billing per message returned, the 30-day retention limit with no date filter, the lack of a conversation-list endpoint requiring event-based grouping (with the consequence that old conversations may not appear), and the reconnection requirement for pre-shipment accounts. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but information-dense; every sentence contributes (purpose, usage examples, costs, data retention, implementation details, auth). It front-loads the core purpose and then proceeds logically through operational caveats. While slightly verbose, it avoids fluff and earns its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description explains the return format (conversations, newest first, with message content) and covers billing, data retention, grouping behavior, and authentication requirements. For a read-only tool with no output schema, this is fully complete — nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter already has a descriptive comment (e.g., maxResults includes billing warning, paginationToken explains walking history). The tool description repeats the cost warning and default but adds no new semantic information beyond what the schema provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Read the direct messages sent to the connected X account and group them into conversations, newest first'. It clearly differentiates from sibling DM tools (list_telegram_dms, list_bluesky_convos) by explicitly tying to 'X' and providing example user intents. The purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides concrete usage triggers ('any new DMs on X', 'what did they say') and routes replies to send_x_dm. It also warns about cost and data retention caveats. However, it does not explicitly contrast with other platform DM tools or state 'use this only for X', though the X-specific naming makes that implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_youtube_playlistsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true and destructiveHint=false, but the description adds substantial extra context: it states 'Read-only, 0 credits' (credit cost beyond annotations), explains the output fields per playlist, and details the critical distinction between videoId and itemId for playlist entries, including the reason (a video can appear more than once). This goes well beyond the annotation hints and informs correct downstream usage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense yet efficient. The first sentence states the core purpose, the second covers the optional parameter usage, and the third (IMPORTANT) conveys a critical nuance. Every sentence earns its place, and the critical information is front-loaded. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description must explain the return shape, and it does: playlists carry id, title, description, privacy, video count; entries are returned in order and carry both videoId and itemId. It also notes pagination indirectly via the pageToken parameter in the schema. Credit cost and prerequisite are stated. Missing minor details like exact pagination behavior or other optional fields, but overall it is complete enough for an agent to call correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter already has a clear description. The tool description adds marginal semantics for playlistId by reiterating its effect ('get that ONE playlist plus its entries'), but the limit and pageToken are not elaborated beyond the schema. Since the schema does the heavy lifting, a baseline of 3 is appropriate; the description adds little that isn't already knowable from the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'List the playlists on the connected YouTube channel' and enumerates exactly what is returned (id, title, description, privacy, video count). It also distinguishes the optional playlistId mode as 'get that ONE playlist plus its entries'. This clearly separates it from sibling tools like manage_youtube_playlist_items or list_youtube_videos.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance: 'Pass a playlistId to get that ONE playlist plus its entries' versus omitting it to list the channel's playlists. It also mentions the prerequisite ('Needs a connected YouTube channel') and references the related management tool (manage_youtube_playlist_items) to clarify the id semantics. It does not explicitly state exclusions or alternatives, but the conditions for use are clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_bluesky_convoA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description adds crucial behavioral details: self-only delete, irreversible leave, accept idempotency reporting, and auth requirement. This fully discloses the risky aspects of the tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy but every sentence serves a purpose, covering actions, caveats, and prerequisites. It's front-loaded with the action list, and the bolded warnings draw attention to the most important risks. Slightly verbose but efficient for its complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a multi-action mutation tool with no output schema, this description covers all necessary context: the full action set, edge cases (already-accepted requests), irreversible operations, auth requirements, and ID sourcing. Nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with descriptions. The description adds context by explaining the deleteMessage action requires messageId and that convoId comes from list_bluesky_convos, but these are also in the schema. It doesn't significantly amplify schema meaning, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly lists the verbs (ACCEPT, MUTE, LOCK, LEAVE, DELETE) and the resource (one Bluesky DM conversation), and differentiates it from siblings by pointing to list_bluesky_convos and read_bluesky_dm for IDs. It's unambiguous and specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly instructs when to use this tool (acting on a conversation) and provides critical caveats for deletion and leaving, plus the source for convoId. It doesn't explicitly name alternatives to exclude, but it gives actionable guidance for correct use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_meta_partnership_creatorA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Exceptional disclosure beyond the annotations: adding is a request-not-approval with a delayed acceptance window; Meta answers the ADD with HTTP 500 (code 1) while actually performing it (measured 4/4); metaWriteError alongside success means the write happened and must not be retried; the verdict 'unknown' means the list couldn't be re-read, not that nothing changed; removal flips status to 'Canceled' rather than deleting. This aligns with idempotentHint=true (don't retry) and destructiveHint=false (no delete), adding deep context the annotations cannot express.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long, but nearly every sentence carries a distinct and consequential fact (the HTTP 500 quirk, request-vs-approval, verdict semantics, the dual-verb justification). The core purpose is front-loaded. It is denser than strictly necessary — the dual-verb rationale and the measured-quirk note could be trimmed — but given the tool's genuine complexity, the length earns most of its keep.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description fully carries the burden of explaining the reply semantics (verdict values applied/already/unchanged/unknown, metaWriteError handling). It covers both lists, both directions, failure modes, retry guidance, and the id-type restrictions. Nothing an agent needs to call it correctly and interpret the result is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the input schema's own parameter descriptions are already rich (creator accepts either form, tag-approval takes numeric ids only, rejection behavior). The tool description mostly reinforces the allowAds/allowTagging semantic distinction already present in the schema. It adds useful narrative framing but does not materially extend what the schema documents, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a precise verb+resource statement: "Add a creator to — or remove one from — this brand's Partnership Ads lists," immediately naming the two lists (allowAds, allowTagging). It clearly differentiates from siblings like list_meta_partnership_creators (the read counterpart) and instagram_profile (the id-resolution tool referenced as a prerequisite). No ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides strong contextual guidance: when both lists default off, when to use instagram_profile to convert handles to ids (for allowTagging), when to use creatorIds, and how to interpret the reply. It does not explicitly name list_meta_partnership_creators as the read-back alternative or state a when-not-to-use condition, but the routing advice for prerequisites and the two lists is clear enough that an agent knows when to invoke it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_youtube_captionA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the annotations (which only mark destructiveHint=true). It discloses that ASR tracks are refused by name, that deletion is confirm-gated and immediately removes captions for viewers and stops YouTube indexing, that tracks can be re-uploaded, and that credits are 0. It also clarifies that a connected channel is required. These are critical behavioral traits that the agent needs to know before invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a moderately long paragraph but each sentence contributes unique information: purpose, parameter specifics, ASR restriction, delete consequences, and prerequisites. It is front-loaded with the core purpose and then expands into nuances. While not extremely concise, the density is justified given the tool's three actions and multiple constraints.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of three actions, eight parameters, and no output schema, the description is thorough. It covers prerequisites (connected channel), parameter usage (body vs URL), behavioral expectations (ASR refusal, delete gating, immediate effects), and resource implications (0 credits). Nothing essential for correct invocation is missing; return format is not a concern since no output schema exists.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for all 8 parameters, so the baseline is 3. The description adds valuable semantics beyond the schema, such as emphasizing that `text` is the file body, not a URL, and explaining that `language` must not be guessed because YouTube uses it to decide viewer visibility. It also notes that ASR tracks are refused, tying `action` to the trackKind restriction, and mentions that `captionId` comes from list_youtube_captions, which is in the schema but reinforced contextually.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb-resource combination: attach, replace, or delete a caption track on a connected channel's video. It clearly distinguishes this from sibling tools like list_youtube_captions (which only lists) and update_youtube_video (which updates general video metadata) by focusing on caption tracks, and mentions the three distinct actions explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides context about when to use this tool (e.g., to attach a real subtitle track, replace one, or delete one), and explains that ASR tracks cannot be edited/deleted and that you should upload your own to replace them. However, it does not explicitly contrast this tool with alternatives like list_youtube_captions or suggest when not to use it, leaving some inference required.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• read_bluesky_dmA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description adds substantial behavioral details: it reverses the wire order to present chronologically, indicates whether each message was sent by this account, and distinguishes deleted messages from empty ones. These are non-obvious traits an agent must know to interpret results correctly, and none contradict 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: it starts with the core purpose, then adds three essential behavioral nuances (chronological order, sender indication, deleted-message handling), and ends with the convoId source. Every sentence carries unique, valuable information with no filler, making it efficient for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with full schema coverage and annotations covering safety, the description is nearly complete. It covers ordering, sender info, deleted handling, and the source of convoId. It doesn't describe the output format, but with no output schema that isn't required. A tie to pagination via cursor is implied by the description's mention of walking back through older messages, though not explicitly explained here (it is in the schema). Given the complexity, this is slightly incomplete but adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters (convoId, limit, cursor) are already documented in the input schema. The description adds minimal extra meaning beyond reinforcing that convoId comes from list_bluesky_convos. It doesn't explain limit/cursor semantics beyond what the schema provides, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Read a Bluesky DM conversation in CHRONOLOGICAL order', specifying the verb (read), resource (Bluesky DM conversation), and a key distinguishing behavior (chronological order). It effectively differentiates from siblings like list_bluesky_convos (lists conversations) and send_bluesky_dm (sends messages) without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides usage context by explicitly pointing to 'Get a convoId from list_bluesky_convos', indicating the prerequisite tool. It doesn't explicitly name alternatives or state when not to use this tool, but the context is clear enough for an agent to select it for reading rather than sending or listing. A score below 4 would penalize the missing exclusion, but the clear purpose makes it largely self-evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• read_docA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already carry readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is known. The description adds meaningful context beyond that: the drive.file scope boundary ('reaches nothing else in the user's Drive'), the open-world dependency on a prior picker action, and the specific failure mode for unpicked files. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Longer than average, but every clause earns its place — scope, access model, parameter alternatives, error behavior, return type, and safety are all covered in service of a genuinely non-obvious usage model. The key constraint (what Hermoso can reach) is front-loaded. Slightly dense, but not padded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Complete for a read-only tool. No output schema exists, but the description explicitly states 'Returns the plain text.' Error-handling guidance, access preconditions, both parameters, and the scope limitation are all disclosed. The openWorldHint is reinforced by explaining the picker mechanism. Nothing an agent needs to invoke this correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds minor value by noting documentId comes from create_doc and that docUrl is a paste-able Google Docs URL with the id extracted from it, which slightly clarifies intent beyond what the schema states. Baseline 3 is appropriate given high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource — 'Read the text of a Google Doc' — and immediately defines the scope boundary ('Hermoso can reach'). It is clearly distinct from siblings like list_drive_files, create_doc, and append_to_doc, and tells the agent exactly what it returns (plain text) without needing to open any schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Excellent usage guidance. It explains the enabling precondition (doc must have been created by Hermoso or picked via the file picker), how to discover an id (list_drive_files), the two accepted input forms (documentId or docUrl), and even routes error handling ('file not found = user has not picked it, ask them to pick rather than retrying'). No exclusions are left implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• remove_memberA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint:true and readOnlyHint:false. The description adds valuable context beyond annotations: the member loses access, it is reversible via re-invitation, and confirmation with the user is required. It does not contradict annotations and enriches the behavioral understanding, though it could detail side effects like data handling but that is not necessary given annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no redundancy. The main action and consequence are front-loaded, followed by the critical usage instruction. Every word adds value, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the destructive nature, the lack of an output schema, and the full schema coverage, the description covers the essential steps: what the tool does, the required confirmation, and the reversibility. It does not mention what happens to the member's associated data, but that is not critical for invoking the tool. The instruction to confirm with the user is a key safety measure that is included.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both email and confirm. The description adds semantic value by explaining the confirm parameter's purpose ('REQUIRED true' in schema) and clarifying that the email is the identifier for the member. It goes beyond the schema by specifying the workflow: confirm with user, then call with confirm:true.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the exact action: 'Remove a member from this brand workspace by email' with the consequence 'they lose access'. It clearly differentiates from siblings like 'invite_member' and 'set_role' by specifying the remove operation and the email identifier. It is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear usage instruction: 'Confirm the exact person with the user, then call with confirm:true.' It also implies the destructive nature and that removal is reversible ('you can re-invite them later'), giving context. However, it does not explicitly contrast with alternative tools, but the unique confirmation requirement and destructive nature make the usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• reply_to_google_business_reviewA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly discloses the upsert behavior ('THIS IS AN UPSERT: a listing has exactly one reply per review, so replying to a review that already has an answer REPLACES it rather than adding a second'), the verified-listing requirement ('Google only accepts replies on a VERIFIED listing'), and the confirm-gating for destructive deletes ('Deleting is public and immediate, so it is confirm-gated'). These go beyond the annotations (which only indicate destructiveHint and idempotentHint) and provide critical operational details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately sized but every sentence carries operational value: purpose, upsert semantics, verification requirement, confirmation for deletion, content quality guidance, and prerequisites. It is front-loaded with the core purpose and scoping. While it could be slightly condensed without losing meaning, the density is high and it avoids redundancy with the annotations, making it effectively concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (dual action, upsert behavior, deletion gate), the description covers all necessary aspects: the upsert replacement rule, the requirement of a verified listing, the confirm-gated destructive delete, content quality advice, and the integration prerequisites. The absence of an output schema means the description doesn't need to explain return values, and none are critical. An agent has everything needed to invoke this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents all five parameters with clear descriptions (e.g., 'delete: true removes the existing reply instead of writing one', 'comment: the public reply text — required unless you are deleting', 'confirm: required for delete:true', 'reviewId: from list_google_business_reviews', 'locationId: which listing — omit when only one is shared'). The description's mention of confirm-gating reinforces the confirm parameter, but it does not add substantial new meaning beyond what the schema provides. With 100% schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the primary function (publicly answering a customer review) and the secondary function (deleting an existing reply), with the specific resource (Google Business Profile listing) and context (brand's listing). It clearly distinguishes this tool from siblings like answer_google_business_question (which handles questions, not reviews) and post_to_google_business (which creates new posts). The verb 'answer' and the dual nature are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool—when responding to or removing a reply to a review on a verified Google Business Profile. It states the prerequisite ('Needs Google Business Profile connected and the project approved') and gives qualitative guidance on reply content ('Write the reply in the brand's voice and answer the specific complaint'). However, it does not explicitly name alternative tools (like answer_google_business_question) or state when not to use this tool, but the purpose is clear enough for an agent to route correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• reply_to_meta_commentA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses a critical non-obvious behavior: the reply is PUBLIC and posted as the brand, requiring user approval. Annotations only indicate it is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false); they do not capture the public-facing nature or the approval workflow. This is a substantial value-add 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, the first stating the core action and scope, the second adding the crucial public/approval constraint. No fluff, front-loaded, and every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with a well-covered schema and no output schema, the description covers the essential behavioral and usage context. Minor gap: it does not explicitly mention that commentId should come from list_meta_comments, but that is already in the schema description. Overall complete for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are already documented. The description adds a workflow note about showing exact wording, which subtly touches on the 'message' parameter, but it does not explain individual parameter semantics beyond what the schema provides. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb ('post a public reply') and resource ('a comment on the brand's Facebook or Instagram post'). This distinguishes it from siblings like comment_on_meta_post (which comments on a post) and reply_to_inbox_item (inbox replies), making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: it is for replying to comments on brand posts, and requires showing the wording to the user first. It does not explicitly name alternative tools or when not to use it, but the purpose statement strongly implies when it applies, which is adequate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• run_post_refillA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) by disclosing that dryRun defaults to true, that passing dryRun:false queues posts onto real public accounts, that captions are screened and dropped if they fail brand voice rules, and that the plan can be shorter than the cadence. This is rich, explicit behavioral context that annotations only hint at, making it highly transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the purpose, then covers safety and behavioral details. It uses all-caps emphasis effectively to highlight critical warnings. It is slightly dense with multiple clauses, but every sentence earns its place. A small trim could improve readability, but overall it's well-structured and not overly verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description does an excellent job of explaining what the tool returns: the exact posts it would queue, including caption, creative, channels, and per-channel visibility, and notes that dropped captions are explained in the notes. It also covers edge cases like force and stored dryRun. For a mutating tool of this complexity, nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides full descriptions for both parameters (force and dryRun) with 100% coverage. The tool description adds some context about the default and safety implications but does not materially extend the parameter semantics beyond what the schema already conveys. Per the rubric, a baseline of 3 is appropriate when schema coverage is high.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: run the refill now instead of waiting for its daily turn. It specifies the action (run) and the resource (posting refill), and distinguishes it from related tools like get_post_refill (which likely reads the refill plan) and set_post_refill (which configures it) by emphasizing immediate execution. The purpose is unambiguous even without opening the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear usage context: run now instead of waiting for the daily turn, and explicitly warns to show the preview before ever passing dryRun:false. However, it does not explicitly name alternatives like get_post_refill for preview-only scenarios, though the DRY BY DEFAULT feature effectively covers that. The guidance is present but not exhaustive about sibling differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• save_to_onedriveA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a non-read-only, non-destructive write operation. The description adds valuable extra context: it returns a webViewLink, requires OneDrive to be connected, and creates folders if new. This goes beyond the annotations and schema, though it doesn't cover error handling or duplicate-name behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that efficiently packs purpose, workflow, return value, and prerequisites. There is no filler or repetition, making it easy for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (4 params, no output schema), the description covers the necessary context: return value, prerequisites, and input handling. Minor gaps like explicit limits (up to 20 URLs, already in schema) and error behavior are not critical for successful invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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. The description adds meaning by explaining the relationship between url and urls (singular vs. array) and the upload_file workflow, which clarifies when each parameter is used beyond the schema definitions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Save') and resource ('Microsoft OneDrive'), and clarifies the scope ('a Hermoso render — or ANY file'). It clearly distinguishes from sibling operations like list/get/update/delete on OneDrive files, and from save_to_drive (Google Drive).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance for different input types: pass a Hermoso render URL directly, or call upload_file first for local/external files. Also notes the optional folder (created if new) and the connection prerequisite. Doesn't explicitly name alternatives like save_to_drive, but the OneDrive-specific instructions are sufficient for correct selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_linkedin_adsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable context: the return format (compact JSON with specific fields), the unique advantage (LinkedIn exposes real impression counts), and a cost warning ('Spends about a credit'). This goes beyond what annotations provide without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with zero filler. The core purpose is front-loaded, followed by the usage distinction, then the return format and unique value proposition. Every sentence earns its place and the structure is optimal for quick agent parsing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has annotations covering safety, a fully documented schema, and a brief description of the output format (compact JSON with fields), the description covers the essentials. It does not mention pagination or default ordering, but these are not critical for a search tool and the schema covers the limit parameter. It is sufficiently complete for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage with descriptions for all 5 parameters (limit, company, keyword, companyId, countries), so the baseline is 3. The description only mentions three of the parameters (company name, keyword, companyId) and adds no additional syntax or format details beyond what the schema already documents, so it does not elevate above the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the exact action (structured LinkedIn Ad Library search) and the searchable fields (company name, keyword, or companyId). It also explicitly differentiates itself from the sibling tool research_ads by framing this as 'targeted B2B pull' versus 'open-ended research', so an agent can easily decide which to use.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a direct when-to-use instruction ('use for a targeted B2B pull') and explicitly names the alternative tool ('use research_ads for open-ended research'). This leaves no ambiguity about the context for this tool versus its sibling.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• send_bluesky_dmA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows it's a mutating but non-destructive operation. The description adds valuable context: the 1000-character limit (unusual vs posts), refusal reasons (DMs off, only follows, blocked, suspended, does not exist), and the automatic conversation opening. This goes beyond the annotations and helps set expectations for error handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three tight sentences with zero fluff. The core action is first, followed by the character-limit nuance, then refusal behavior, all front-loaded and essential. No redundancy with the schema or annotations.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 5 params and no output schema, the description covers the main entry points (convoId vs to), the key constraint (1000 chars), and the failure modes. It doesn't describe the return value, but the absence of an output schema makes that less critical. The dryRun param is well-covered in the schema. Overall, the description provides sufficient context for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so all parameters are documented. The description adds meaning beyond the schema by explaining the DID resolution for `to` and implying mutual exclusivity between `to` and `convoId`. It also reinforces the 1000-character limit in text, which aligns with the schema description. This extra context justifies a score above the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the exact action: 'Send ONE direct message on the connected Bluesky account.' It distinguishes from siblings like post_to_bluesky by explicitly noting the character limit difference (1000 vs 300) and states there is 'deliberately no broadcast form,' making it clear this is for one-on-one messaging, not public posting.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly explains the two modes: reply into an existing conversation (convoId) or start a new one with a handle (to), and mentions that the handle is resolved to a DID. The dryRun param is described in schema as a check-first option, and the description's 'no broadcast form' implies alternatives exist but doesn't explicitly name them. It provides strong situational guidance without needing to enumerate every alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_connector_accountsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already include idempotentHint=true and destructiveHint=false, but the description goes beyond: it clarifies that the operation REPLACES the current selection, that leaving out an account un-shares it, that an empty list refuses publishing (fails closed), and that the server re-verifies every id against the live connection. This adds critical behavioral context not present in annotations, such as the fail-closed design and validation logic.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense and informative but somewhat long, including a redundant list of providers that duplicates the schema enum and a trailing 'Free.' that appears out of place. The core action is front-loaded, and the behavioral warnings follow logically. It could be trimmed slightly without losing value, but it remains well-structured for an agent to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity—multiple providers, side effects on publishing permissions, and failure modes—the description covers essential aspects: replacement semantics, empty-list behavior, fail-closed design, id verification, and a user-interaction cue. There is no output schema, so return-value explanation is not required. The description leaves little for an agent to guess.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers both parameters (provider and accountIds) with descriptions, achieving 100% schema coverage. The description adds marginal value: it reiterates that ids come from list_connector_accounts and that an empty array shares nothing—both already in the schema. The provider enumerations are listed in the description but duplicate the enum in the schema. No new semantic layer is provided beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a precise action: 'Set WHICH of a connector's accounts this brand is allowed to post to and spend from', followed by a concrete list of account types (Facebook Pages, Google Ads customers, LinkedIn Pages, etc.). It clearly distinguishes itself from sibling tools like list_connector_accounts (listing vs. setting), disconnect_connector, and leave_connector by focusing on permission assignment. The verb+resource is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance: 'Pass ids from list_connector_accounts' and 'Ask the user which accounts they mean; posting as the wrong Page is a public mistake.' It communicates the replacement behavior and the empty-list consequence, but does not explicitly state when _not_ to use this tool versus alternatives like leave_connector. However, the context is strong enough that an agent would infer when to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• update_drive_fileA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds operational details: trash is reversible (untrash with trash:false), moving can remove a file from an old folder via removeFromFolderId, and permanent deletion is excluded. This goes beyond the binary annotation flags and clarifies 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The main description is a single, information-dense sentence that front-loads the tool's purpose and lists all operations with their parameters. A second sentence handles the cross-reference to delete_drive_file. No filler or repetition of schema details, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no output schema, the description covers the required input (fileId), all operation types, the source of values, and the key alternative for permanent deletion. It does not mention the success/return format, but that is a minor gap given the simplicity of operations. It also doesn't explicitly state that multiple operations can be combined, which is implied by the parameter list.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema describes each parameter individually with 100% coverage, but the description adds crucial relational context: it explains that moveToFolderId and removeFromFolderId work together to move a file out of an old folder, and it names the source of fileId (list_drive_files). This adds meaning beyond the schema's isolated property descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Update a Drive file' and immediately enumerates the three distinct operations: rename (name), move (moveToFolderId and removeFromFolderId), and trash/untrash (trash:true|false). It names specific parameters and explicitly contrasts with delete_drive_file for permanent deletion. This is a precise verb+resource definition that clearly differentiates from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an explicit alternative: 'To delete permanently, use delete_drive_file.' It also directs the user to obtain fileId from list_drive_files, establishing a prerequisite. It does not explicitly state when not to use this tool for creating files, but the title and operations make that obvious. Slightly shy of a 5 because it doesn't spell out scenarios like 'use save_to_drive for new files'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• clear_sheet_rangeA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint=true and idempotentHint=true, but the description goes far beyond annotations by disclosing the two-call confirmation mechanism, the 'nothing is cleared' behavior without confirm, the confirmCells echo purpose, and the post-clear readback verification. This is rich behavioral context that annotations alone do not convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy but every sentence carries essential operational information: the destructive warning, the confirmation flow, the echo rationale, and the alternative. It is structured logically, starting with the action, then the destructive warning, then the workflow. While not terse, it avoids redundancy and earns its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even without an output schema, the description explains what the user gets back (the number of filled cells on the unconfirmed call, and a confirmation only if the range is truly empty). It also warns about the common range-mistake scenario. This is sufficient for an agent to correctly perform the two-step destructive operation, though it does not describe error cases or edge conditions beyond that.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With only 40% schema description coverage, the description compensates substantially. It explains the confirm workflow, the confirmCells parameter ('echo back the filled-cell count'), and gives an A1:Z1000 example for range. It does not detail sheetUrl/spreadsheetId, but those are common and not critical for a destructive tool whose main parameters are well explained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Empty a range of cells') on a specific resource ('a Google Sheet') and explicitly differentiates from a sibling ('To remove a whole tab instead, use manage_sheet_tabs'). It also clarifies that rows remain in place, leaving no ambiguity about what clearing entails.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a detailed when-to-use and when-not-to-use guide. It explains the mandatory two-step confirmation workflow, warns about the no-default-range policy, and explicitly names the alternative tool for removing whole tabs. This leaves no inference needed for safe invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_sheetA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and openWorldHint=true, so the write nature is known. The description adds the requirement of a Google Drive connection (one connection covers Drive, Sheets, Docs) and clarifies that rows are optional, which goes beyond the schema. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences with no filler. The purpose is front-loaded, followed by usage details and a prerequisite. Every sentence contributes meaningful information for the agent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with two optional parameters and no output schema, the description covers everything needed: purpose, row format, return value (id + URL), and a connection prerequisite. The examples help the agent understand common use cases. Nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 adds value by clarifying that rows are optional, providing examples of what rows might contain, and noting that the first row is treated as headers. This complements the schema without redundancy.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource ('Create a new Google Spreadsheet in the user's Drive') and provides concrete examples (export a swipefile, ad list, performance report). It clearly differentiates from siblings like append_to_sheet and update_sheet by focusing on creation of a new spreadsheet.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context (creating a new sheet, optionally with rows) and includes a prerequisite (Google Drive connected). It does not explicitly name alternative tools or when not to use it, but the purpose is unambiguous enough that an agent can infer when to use it vs. modifying existing sheets.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_creatorA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds key behavioral details beyond annotations: it records a cross-device delete to prevent reappearance, clarifies that ads rendered with the person remain untouched, and notes that the portrait can be saved again. These are not covered by annotations (which only mark destructive/idempotent), so they add significant context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the action, then efficient details about scope and re-save. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter delete tool with annotations covering destructive/idempotent, the description covers cross-device behavior, side effects (ads untouched), and reversibility (save_creator). There is no output schema, so return values are not a concern. An agent has all needed info to call correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes the 'id' parameter as the creator id from list_creators, and the description repeats that without adding new details. Since coverage is 100%, the description adds no extra semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Remove') and resource ('saved creator from this workspace’s cast'), and identifies the id source ('from list_creators'). It clearly differentiates from siblings like save_creator by focusing on deletion and scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description says the deletion only drops the roster entry and that the same portrait can be saved again with save_creator, implying the alternative for re-adding. It also notes no confirm is needed, providing a usage cue. It could be more explicit about when not to use it (e.g., if wanting to fully remove permanently), but it gives clear context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_skillA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint and idempotentHint, but the description adds useful context: it is 'Minor + re-creatable' and explicitly states no confirm is needed. It also discloses the constraint that built-in skills cannot be deleted, which is behavioral info beyond the annotations. There's no contradiction with the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no fluff. The primary action and scope are front-loaded, followed by the exclusion and confirmation guidance. Every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter delete tool with no output schema and annotations covering safety, the description is sufficient. It covers what is deleted, how to identify it, what's excluded, and the confirmation behavior. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with the id parameter already described as 'the custom skill id (from list_skills)'. The description essentially repeats this source reference, adding no new semantic detail beyond what the schema provides. Baseline 3 is appropriate given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Delete'), the resource ('workspace's CUSTOM skills'), and the scope ('by id (from list_skills)'). It also distinguishes custom skills from built-in skills/recipes, which are explicitly excluded. This differentiates it from any other delete operations in the sibling list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use context: delete custom skills, not built-in ones. It also gives the source of the id (list_skills) and explains that no confirmation is needed due to the minor, re-creatable nature, guiding the agent on when it's safe to proceed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_x_postA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond annotations. While destructiveHint=true already signals danger, the description explicitly states irreversibility ('CANNOT be undone'), instructs user confirmation, and discloses that credits are consumed. It also clarifies scope (connected account's posts) and the connection requirement, providing substantial behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with no filler. It front-loads the most critical information (permanent deletion) and then provides necessary caveats (confirmation, credits, connection). Every sentence serves a purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple destructive action with one parameter, the description covers the essential elements: what it does, how to use it safely (confirmation), and prerequisites (connection, credits). It is sufficiently complete for an agent to invoke it correctly without additional details about response format.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter 'id' is fully described in the schema with 'the numeric X post id — the last part of the post URL', and the tool description does not add additional meaning beyond what the schema provides. Since schema coverage is 100%, the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Permanently delete'), the resource ('one of the connected account’s posts on X'), and emphasizes the irreversible nature. This distinguishes it from sibling tools like edit_x_post, x_post_insights, or delete_bluesky_post by specifying the platform and scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit guidance to confirm the post with the user first, which is critical for a destructive action. It also notes prerequisites ('Needs X connected') and that credits are charged. However, it does not explicitly mention alternatives or when not to use it (e.g., when editing would suffice), though the platform-specific wording and context make it reasonably clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• finish_videoA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations all set to false (readOnlyHint, destructiveHint, idempotentHint), the description carries the full behavioral burden and does so thoroughly. It discloses that the original is untouched (non-destructive), gives time and cost estimates (~30s, a couple of credits), explains the aesthetic effect of grain ('less AI'), and warns against fabricated stats. This is rich, specific behavioral context that goes far 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph, but every sentence carries information: purpose, modes, constraints, and side effects. It front-loads the core action and the result (new video, original untouched). It could be slightly more streamlined, but there is no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 7 parameters and no output schema, the description covers the essential context: it explains both modes, how they interact, the return behavior ('Returns a NEW video'), and the non-destructive guarantee. It does not specify the exact output format (e.g., URL object), but for a post-processing tool that returns a video, that level of detail is likely sufficient. Minor gaps like error handling are not critical given the clarity elsewhere.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by explaining the visual and strategic purpose of pills and grain, clarifying that the agent authors the copy with character limits (repeated from schema but reinforced), and describing how grain works alone or with pills. This complements the schema without redundancy.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb ('Post-process') and a precise resource ('EXISTING rendered video (its served mp4 URL)'), immediately distinguishing this from generation or editing tools. It names the two modes (reviewer finish and grain pass) and the visual elements (header, sub-pill, proof pills), leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly constrains when to use it: it requires an existing rendered video URL from a previous render/job, and states it is a post-processing step ('no AI model'). It does not explicitly name sibling alternatives like edit_video or upscale_video, but the strong precondition and the mention of 'proven direct-response reviewer finish' effectively distinguish it. The guidance is clear enough for an agent to route correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• forgetA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds critical context beyond these: it records a cross-device delete (so it won't reappear), and explains the action is minor/re-creatable and thus requires no confirmation. This materially enriches the behavioral model for an agent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, no fluff. The first sentence states the core action and source of id; the second explains side effects and the no-confirm rationale. Information is front-loaded and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, single-parameter tool with no output schema, this description covers the action, the id source, cross-device persistence, reversibility, and why no confirmation is needed. Nothing essential is missing for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and both the schema and description state the id is from list_memory. The description adds no additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States the exact verb 'Delete' and resource 'saved Memory item', and explicitly references the id source (list_memory). Clearly distinguishes from sibling tools like remember and list_memory by identifying the delete operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Conveys clear usage context: use this when you have a memory id (from list_memory) and want to remove it. It does not explicitly mention when not to use it or alternatives, but the context is unambiguous enough for an agent to select it correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_drive_fileA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description explicitly restates 'Read-only' (consistent, not contradictory). It adds value beyond annotations by listing the metadata fields returned, which helps the agent anticipate the response shape even without an output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with zero filler: the first states the action and return fields, the second gives the parameter source and read-only nature. It is front-loaded and every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read tool with one parameter and no output schema, the description fully covers the return fields and parameter origin. Annotations handle the safety profile. Nothing the agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides a description for fileId, and the description adds the crucial origin hint ('from list_drive_files'), which is not in the schema. This gives the agent actionable context for obtaining a valid value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Fetch') and resource ('one Drive file's metadata'), and enumerates the exact fields returned (name, type, size, modified time, webViewLink, webContentLink). It clearly distinguishes from siblings like list_drive_files (which lists many) and update/delete_drive_file (which mutate).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides a clear source for the parameter ('Pass fileId (from list_drive_files)'), which acts as an explicit usage hint. It doesn't explicitly list when not to use, but the purpose is unambiguous and there is no competing sibling for single-file retrieval.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_settingsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by specifying that the tool is 'free', matches the web app settings, and enumerates the returned settings, which provides behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loads the core purpose, and every clause adds information (scope, contents, parity, read-only/free). No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only tool with no output schema, the description is complete: it states what settings are returned, confirms it matches the web app, and notes it is free. There is nothing an agent needs to invoke it correctly that is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and an empty schema, so the baseline is 4 per the calibration. The description correctly implies there are no inputs, and it doesn't need to explain parameter formatting since none exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description specifies a clear verb ('Read'), a resource ('this account's app settings'), and enumerates the exact settings included (language, theme, weekly email toggle). It also notes parity with the web app's Settings pane, which distinguishes it from the many sibling tools that operate on different resources (e.g., voice, posts, connectors).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating what it reads and that it is read-only and free, but it does not explicitly redirect away from alternatives like update_settings or mention when not to use it. The context is clear, but there is no explicit guidance on alternate selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_skillA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by stating 'free' (cost context) and specifying that it loads the 'full SKILL.md workflow instructions', which clarifies what the tool returns. This goes slightly beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences, both front-loaded with the primary purpose and immediately after, the prerequisite and usage guidance. No redundant phrasing or filler; every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read-only tool, the description is complete. It names the source (list_skills), what is returned (full SKILL.md instructions), the cost (free), and how to use the result. No output schema exists, and the description sufficiently covers what an agent needs to know.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and the only parameter 'name' already has a descriptive schema entry ('bundle name from list_skills, e.g. hermoso-generate'). The description adds no additional parameter-specific details beyond what the schema provides, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Load') and a specific resource ('bundled skill's full SKILL.md workflow instructions'), and it clearly differentiates from the sibling list_skills by indicating this tool loads the instructions rather than just listing names. It also notes it is read-only and free, which reinforces the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says the name comes 'from list_skills', establishing a prerequisite and guiding the agent to call list_skills first. It then instructs to 'Follow the loaded instructions to run that workflow with the other tools', explaining how to use the result, which is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_google_business_postsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds '0 credits' and 'Needs Google Business Profile connected,' which are operational prerequisites and cost details not covered by annotations. It also discloses the state field's possible values, enriching beyond the structured data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, information-dense sentence that front-loads the core purpose ('List the Posts currently on the brand's Google Business Profile listing') and follows with the returned fields and usage guidance. No wasted words; every clause adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only list tool, the description is comprehensive: it details the returned fields, including state enums, gives usage scenarios, notes the prerequisite of a connected profile, and credits cost. With no output schema, this description gives the agent everything needed to call and interpret the result correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters: limit has 'how many to return, max 100 (default 20)' and locationId has 'which listing, from list_business_locations — only needed when there is more than one.' The description does not add any new meaning beyond what the schema already provides, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it lists the Posts on the brand's Google Business Profile listing, enumerating the fields returned (text, topic type, state, button, timestamps). It distinguishes itself from sibling tools like list_google_business_reviews (reviews vs. posts) and delete_google_business_post (listing vs. deletion) through the verb and resource specificity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states two usage scenarios: 'to see what is already showing before writing another' (implying before post_to_google_business) and 'to get the id of one to remove' (implying before delete_google_business_post). This gives clear when-to-use guidance without needing to name alternatives directly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_meta_product_setsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint and destructiveHint annotations, the description discloses additional behavioral details: the operation is read-only and costs 0 credits, empty lists indicate a catalog issue rather than an empty response, and zero-product sets can bind silently leading to wasted ad spend. These are not implied by the annotations and add significant transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured, starting with a clear definition, then usage guidance, edge cases, and cost. It is somewhat lengthy but every sentence adds value; no fluff. Could be slightly tighter but remains efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers the main purpose, workflow context, and critical edge cases, plus cost. However, it does not describe the return structure (e.g., whether counts are included), which could be helpful given there is no output schema. Minor gap but overall complete for practical use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already documents both parameters thoroughly (catalogId with a note about numeric ids, limit with range and default). The description does not add new parameter-specific meaning; it references catalogId usage in the workflow but doesn't elaborate 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.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists product sets within a catalog, explicitly distinguishing it from sibling tools like list_meta_catalog_products and list_meta_catalogs. It defines what a product set is and clarifies its role in ad creation, 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.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance on when to use this tool: before building a catalog ad, passing the chosen id as productSetId to create_meta_adset or create_meta_ad. It also warns about edge cases like empty lists pointing at the catalog and zero-product sets binding without error, which are essential for correct usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_sheet_tabsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'Read-only, free,' reinforcing safety and cost behavior, plus explains its role as a discovery step. It doesn't contradict annotations and adds modest extra context beyond what annotations already provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences efficiently convey purpose, usage guidance, and safety, with the core function front-loaded and no redundant content. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description compensates by enumerating the fields returned (name, sheetId, row/column count, position) and explaining its role relative to other sheet operations. It provides all necessary context for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: both sheetUrl and spreadsheetId are described in the schema. The description does not add any new parameter semantics beyond what the schema already specifies, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists tabs in a spreadsheet with specific fields (name, sheetId, row/column count, position). It also differentiates itself as a prerequisite for several sibling tools, making its purpose and scope unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly instructs when to call this tool: before naming a tab in update_sheet, clear_sheet_range, manage_sheet_tabs, format_sheet, and before proposing deletion. It also explains the reasoning (to learn actual content instead of guessing names), giving clear contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_skillsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by stating 'Read-only, free' and explaining what skills are and how they relate to other tools. It does not contradict annotations and gives useful behavioral context beyond the structured data.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no fluff. It front-loads the core purpose ('List the bundled Hermoso SKILLS') and then adds relevant context and a call-to-action. Every word earns its place, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with no parameters and no output schema, the description is complete. It tells the agent exactly what is listed, what those items are, and how to get more detail (get_skill). There is no missing information an agent would need to invoke this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema is empty with 100% description coverage. Since there are no parameters to explain, the description is not required to add parameter details. The baseline for 0 parameters is 4, and the description fully compensates by explaining what the tool lists and why.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'List' and the resource 'bundled Hermoso SKILLS', and elaborates that these are multi-step workflow instructions (SKILL.md) that orchestrate other tools. This distinguishes it from sibling tools like get_skill and list_playbooks by specifying the exact content being listed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit next-step guidance ('Call get_skill to load a bundle'), which helps an agent understand when to use this tool and what to do after. However, it does not explicitly contrast this with other list tools (e.g., list_playbooks, list_creators) or state when NOT to use it, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_tiktok_mention_commentsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral detail: it caps results at top 1,000 by comment likes, warns that TikTok deprioritizes bare @-mentions (so they may not appear), specifies sorting keys, and states the required authorization permissions (brand-insights and comment-list). These are important non-obvious behaviors that go beyond the annotations and help agents set expectations and interpret results correctly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-structured: it opens with the core purpose, then differentiates from a sibling, lists preconditions, notes limitations (cap and deprioritization), and closes with sorting and auth requirements. Every sentence contributes unique information with no filler. It is slightly long but justified by the number of critical constraints; the front-loading of the core purpose aids quick comprehension.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (7 parameters, no output schema), the description covers essential contextual aspects: scope, limitations, sorting, preconditions, and auth. It does not describe the return format, pagination mechanics, or available output fields, but the openWorld hint and standard list-tool patterns mitigate some of this. It is nearly complete but missing some implementation details an agent might need for full integration.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 43% (days, regions, maxCount have descriptions; cursor, fields, sortField, sortOrder do not). The description partially compensates by explaining sorting options (VIDEO_LIKES, COMMENT_CREATE_TIME, COMMENT_LIKES) which align with the sortField enum, and mentions the 1,000 result cap (related to maxCount but distinct). However, it does not explain cursor pagination or fields selection, and given low coverage, it leaves gaps. It adds some value but not full compensation for undocumented parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('list'), resource ('comments and replies'), and scope ('anywhere on TikTok whose TEXT @-mentions the connected account's handle'). It explicitly differentiates from sibling tool list_tiktok_mentions by clarifying it covers conversational comments while the sibling covers post captions. This makes the tool's unique purpose immediately clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly contrasts with list_tiktok_mentions ('This is the conversational half of brand monitoring, where list_tiktok_mentions covers post captions'), providing clear selection criteria. It also lists the four preconditions (public post, 90 days, adult author, BUSINESS account) and warns that an empty list does not mean silence, giving agents practical guidance on interpretation. This is comprehensive usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_youtube_channel_sectionA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (destructiveHint, readOnlyHint, etc.), the description reveals critical runtime behavior: writes go public immediately, there is no undo for deletes, the action is confirm-gated, and the list endpoint lags a write by several seconds in both directions with measured evidence. This exceeds the annotation coverage and gives the agent concrete expectations about side effects and timing.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence carries weight: the purpose is front-loaded, and the warning about read-back lag is placed near the end where it's most relevant after actions are explained. The all-caps emphasis draws attention without padding, though the text could be condensed without losing meaning. It's appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 10 parameters, four actions, and no output schema, the description covers the essential operational context: action behaviors, parameter requirements per type, the confirm gate, immediate publicity, and the discrepancy between writes and reads. It doesn't spell out the exact return structure of list, but it states that writes report what YouTube returned and deletes report as accepted, which is sufficient for an agent to interpret results correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema already describes every parameter (100% coverage), the description adds significant cross-parameter semantics: it maps `type` values to whether they take playlist ids, channel ids, or neither, and clarifies that `title` only applies to multiplePlaylists and multipleChannels. This goes beyond the schema's per-field descriptions and resolves ambiguity the schema alone leaves open.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with an unambiguous statement of what the tool manages — the shelves on a channel homepage — and explicitly enumerates the four actions (list, create, update, delete). It also flags a unique selling point (placing a chosen playlist above YouTube's default layout) that distinguishes it from any conceivable sibling tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes clear when to use the tool by describing its purpose and constraints: it's the only place to control channel-homepage shelf ordering, and it warns against treating a list as read-back. It doesn't name alternative tools because none exist in the sibling set, but it gives strong contextual guidance on the right situation (e.g., before the layout is public, and with confirm for delete).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_youtube_playlistA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare destructiveHint=true and openWorldHint=true, but the description adds critical behavioral nuances: UPDATE merges and leaves omitted fields unchanged, DELETE does not delete videos but does delete links/embeds, and confirmTitle is required for public or non-empty playlists. It also notes 0 credits and the channel requirement. These details go well beyond the annotation flags, making the tool's side effects clear.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, dense paragraph organized by action type. It contains no filler and every sentence adds necessary nuance, but the length might benefit from bullet points for readability. Still, it is efficient and front-loaded with the core action before diving into specifics.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 7 params, destructive behavior, and confirm gates, the description covers default privacy, merge semantics, delete scope, confirm conditions, and the safe alternative. It also mentions the channel requirement and credit cost. Without an output schema, this is sufficient for an agent to call correctly, though it could mention what the response contains after a successful operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for all 7 parameters. The description enriches these: privacy defaults to private on create, omitted title/description on update means leave unchanged, and confirmTitle must match exactly for certain deletes. These semantic clarifications are not in the schema and meaningfully improve agent decision-making.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the tool creates, updates, or deletes a playlist on the connected channel, which is specific verb+resource. It is clearly distinct from sibling manage_youtube_playlist_items (items) and list_youtube_playlists (listing). The title reinforces this, so an agent can easily understand the tool's purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers concrete guidance on when to use update vs delete, explicitly recommending update with privacy=private as a reversible alternative to destruction. It also explains when confirmTitle is needed. However, it does not explicitly contrast with sibling tools like manage_youtube_playlist_items, though the action-level guidance is strong enough for most calls.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• meta_webhook_statusA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds critical behavioral context: it reads straight back from Meta rather than from stored data, states it is read-only and costs 0 credits, and warns that an unsubscribed Page is completely silent and indistinguishable from a quiet one. This goes well beyond the annotation hints and provides the agent with reasoning to avoid false conclusions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a well-structured paragraph that front-loads the core function ('What Meta ACTUALLY has recorded'), then delivers a critical usage warning, and closes with a cost note. Every sentence earns its place; there is no fluff or redundancy. It is long enough to be informative but not verbose, and the urgent 'CHECK THIS' phrase is placed immediately after the purpose for high salience.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only status tool with one optional parameter and no output schema, this description is complete. It explains what the tool returns (the subscription fields), when to use it (before diagnosing webhook issues), and the behavioral caveat about silent pages. Nothing an agent needs to invoke it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% description coverage for the single optional parameter 'pageId', fully documenting it. The description does not add any additional semantic detail about the parameter beyond what the schema provides. Since the schema carries the load, a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the precise function: reading what Meta has actually recorded for the app on a Page — the fields it will push, retrieved directly from Meta. It clearly distinguishes itself from sibling tools like subscribe_meta_webhooks or unsubscribe_meta_webhooks by emphasizing the read-back aspect, and from list_meta_webhook_events by focusing on subscription state rather than events. The purpose is unambiguous and actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'CHECK THIS BEFORE CONCLUDING THAT WEBHOOKS ARE NOT WORKING' and explains that an empty event feed is not evidence until the subscription is confirmed. This provides a clear when-to-use rule and a diagnostic rationale. It doesn't explicitly name alternative tools, but the guidance strongly routes the agent to this tool first in troubleshooting scenarios. It also notes '0 credits', a financial consideration.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinterest_audience_insightsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds crucial behavioral details: it is read-only and costs 0 credits, there is no date range (current snapshot only), affinity index is a comparison not a count, and size_is_upper_bound semantics. These significantly enrich the agent's understanding of output behavior and constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is relatively long but each sentence adds substantive value: scope, audience types, reporting guidance, date behavior, credits. It front-loads the core purpose and structures information logically. It could be trimmed slightly (e.g., the 'SAY THIS WHEN REPORTING' parenthetical), but it remains focused and efficiently packed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides a strong conceptual outline of what will be returned (interest categories, demographics, affinity index, size flag) and explains key semantics. It does not enumerate exact fields or response structure, but for an agent deciding whether to call and how to interpret results, it is sufficiently complete for the tool's simple two-parameter interface.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description adds meaning to the insightType parameter by detailing the three enum values and their roles (baseline vs. comparative audiences), going beyond the schema's minimal description. It does not directly explain adAccountId, but the schema coverage is 50% and the description compensates for the key parameter. The affinity index explanation also clarifies potential interpretation of output fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns audience composition data (interest categories with affinity indices, demographics) rather than performance metrics, and explicitly names the three audience types including the baseline. It distinguishes itself from performance reports and sibling analytics tools like pinterest_analytics, so the purpose is unambiguous and specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states this is an input for creative briefs, not performance reports, providing clear context for when to use. It also gives explicit reporting instructions for affinity index and size upper bound. However, it does not explicitly name alternative tools or state when not to use it beyond the performance-report distinction, leaving some inference to the agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_to_metaA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses extensive behavioral traits beyond the annotations, including immediate publishing, the need to confirm with the user, that Instagram collab invites require acceptance and may be declined, that crossreshareToIg has no confirmation, that certain parameter combinations are refused rather than silently downgraded, and that scheduling is only supported for Facebook. This goes far beyond the readOnlyHint/idempotentHint annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is very long and dense, covering many edge cases in a single block of text. While it is front-loaded with the core purpose and carousel explanation, it could benefit from more structured formatting or conciseness. It is informative but not concise; every sentence earns its place, but the overall length may slow down an agent's parsing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (25 parameters, no output schema, and only basic annotations), the description is remarkably complete. It covers platform-specific behaviors, refusals, prerequisites, grouping axes for analytics, safety retries, and many nuanced scenarios. An agent has enough information to call the tool correctly in a wide variety of situations without additional context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already has 100% coverage with descriptions for every parameter. The tool description adds significant additional meaning, such as explaining that imageUrls is an ordered list for a carousel (not multiple posts), the collaborator behavior, and the hook/subject grouping logic. This goes beyond the schema's per-property descriptions, providing valuable context an agent needs to use parameters correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Publish' and the resource (a connected Facebook Page, its linked Instagram, or the brand's Threads account). It explicitly differentiates between the three targets and thoroughly explains the carousel vs. multiple-post distinction. This makes the tool's purpose unambiguous and distinguishes it from other posting tools for different platforms.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives detailed context on when to use the tool (e.g., for carousel posts, Instagram collabs, and multi-slide creatives) and even states prerequisites (connected Meta account with posting permission). However, it does not explicitly mention alternatives or when NOT to use it compared to sibling tools like post_to_x or schedule_post. The guidance is strong but lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• rememberA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate it's a write operation (readOnlyHint false) and not destructive, but the description adds valuable specifics: it merges into existing Memory, never overwrites, and de-dupes on identical text. It also discloses the impact on future ads. This exceeds what annotations alone convey, though it doesn't cover every edge case (e.g., maximum size).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first establishes purpose with concrete examples, the second provides behavioral guidelines (lasting vs one-off, merge, de-dupe). It is concise, front-loaded with the core verb and resource, and every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple write-only tool with two parameters, no output schema, and no nested objects, the description covers everything an agent needs to call it correctly: what to save, how to phrase it, when it applies, and how it behaves (merge, de-dupe). It even notes the long-term effect on future ads. Nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters described, so baseline is 3. The description enriches the 'text' parameter by giving examples and clarifying that it should be a durable fact or preference, which is more specific than the schema's 'the fact/preference, concise'. It also hints at categories (Brand, Audience, Taste) without explicitly mapping to the category parameter, adding context beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('Save'), a resource ('durable fact or PREFERENCE... into the workspace Memory'), and the target domain (brand, audience, creative taste). It distinguishes itself from siblings like 'forget' and 'list_memory' by explicitly framing itself as the tool for saving lasting facts.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use it ('For lasting things, not one-off requests'), which implicitly tells the agent when not to use it. However, it does not explicitly name alternatives (e.g., 'use forget to remove facts' or 'use list_memory to see existing memories'), though that's a minor gap given the obvious sibling relationships.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• remix_staticA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  While annotations are all false (no readOnly, etc.), the description adds several behavioral details: it bills as one image generation, it switches the active brand as a side effect, and it ensures source brand traces are removed. These are beyond typical expectations and would affect the agent's usage, such as side effects and cost. It does not explicitly state any destructive actions, but given the tool is generative and the side-effect of brand switching is disclosed, it earns a 4 rather than a 3.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single paragraph that front-loads the core purpose ('One-click STATIC-AD REMIX') before elaborating on behavior, parameters, and alternatives. It is reasonably concise, though slightly verbose with repeated emphasis ('STATIC', 'IMAGES ONLY'), but every sentence delivers value—it explains the branding outcome, parameter usage, side effect, alternative, and billing. It's well-structured and wouldn't benefit much from trimming.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with only two parameters and no output schema, the description covers all essential aspects: what it does, how to pass the required image, optional brand selection, the side-effect of brand switching, the billing implication, and a clear alternative for video. It does not specify the exact return format, but given the absence of an output schema and the simplicity of the operation, this is not a significant gap. The tool appears complete 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.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%—both `imageUrl` and `brandId` have descriptions in the schema—so the baseline is 3. The tool description adds meaningful extra semantics for `brandId`, explaining it switches the active brand like `use_brand`, which is not in the schema description. It also reinforces `imageUrl` as the input image. This goes beyond the schema, so a score of 4 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's function: rebuilding a static image ad as an on-brand version while preserving layout and energy. It explicitly states it is for STATIC images and names the sibling tool `render_ad` for video ads, making it distinguish from related tools. The inclusion of 'SAME layout, composition and energy' plus brand customization specifics leaves no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear guidance on when to use this tool: for static (image) ads only, and explicitly points to `render_ad` as the alternative for video ads. It also explains the optional `brandId` behavior, noting it switches the active brand like `use_brand`, which helps the agent understand the context in which to provide that parameter. This meets the criteria for explicit when/alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• report_bugA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=false and idempotentHint=false, covering the safety profile. The description adds beyond annotations: 'Free, no credits' clarifies cost, and 'Report a bug ... to the team' indicates it submits a report rather than performing a local action. This adds useful behavioral context without contradicting the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, then expands logically into when-to-use, exclusions, and submission guidance. Every sentence earns its place, and it avoids redundancy with the schema. It is informative without being verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple reporting tool with no output schema, the description covers everything an agent needs: what counts as a bug, when to use it, when not to, and what to include. The low complexity and clear annotations make this complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% — all three parameters are described in the schema with details for summary, details, and severity (including enum meanings). The description reinforces what to include in 'details' but does not add new meaning beyond the schema. It meets the baseline of 3 for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Report a bug in Hermoso to the team' — a specific verb, resource, and audience — then enumerates concrete examples of genuine misbehavior (tool errors, wrong/malformed results, broken renders, documented behavior mismatch). It explicitly differentiates from request_feature for missing capabilities, so an agent can immediately tell it apart from the sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states when to use the tool ('Use this when something in Hermoso genuinely misbehaves') and when not to ('Do NOT use it for out-of-credits, a policy refusal, or a missing capability') and names the alternative (request_feature). This leaves no ambiguity about tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• schedule_postA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses substantial behavior beyond what readOnlyHint=false/openWorldHint=true convey: channels are attempted independently so one failure never blocks others; google_business is held back (0 QPM) and refused at enqueue; posts go live publicly by default and are never quietly downgraded to draft/unlisted; impossible visibility combinations are refused at schedule time rather than failing later; alt-text carry/not-carry matrix per channel; and the collaborators invite is sent when the post fires and stays pending. No contradiction with the annotations — this is exactly the kind of context the annotation fields cannot express.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense wall of prose with heavy CAPS emphasis and no section breaks or headings, making it hard to scan across 52 parameters and 11 channels. It is front-loaded with the core purpose and every sentence does earn its place given the enormous complexity, but the monolithic block structure is a genuine readability cost. Appropriately sized for the surface, poorly organized.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 52-parameter, 11-channel tool with no output schema, the description is unusually complete: it covers per-channel id requirements and refusal timing, visibility semantics and which channels support which value, alt-text carry/not-carry behavior, polling rules, collaborator invite timing, and post-publish verification tools (instagram_collaborators). Nothing an agent needs to call this tool correctly is missing; even return behavior ('the per-channel result says which') is referenced.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with rich per-property descriptions, so the baseline is 3. The tool description still adds genuine cross-channel meaning the schema cannot capture: the live/held-back channel status, the multi-slide carousel ordering rule, title derivation from the caption's first sentence, the YouTube caption-is-title distinction, and which id is required for which channel. This is additive value beyond the structured fields, though the schema already does heavy lifting for most parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb-resource pair — 'Queue a post to go out at a future time' — plus explicit scope: one or more of ten named channels (facebook, instagram, threads, tiktok, youtube, linkedin, x, pinterest, bluesky, telegram). This is clearly distinct from sibling immediate-posting tools (post_to_x, post_to_tiktok, post_to_meta) and from lifecycle tools (reschedule_post, list_scheduled, cancel_scheduled). An agent can tell when to reach for this tool without opening any schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives strong when-to-use context: 'This is how you run a content calendar: schedule now... you do not need to be around,' and it defines the 'just queue it' semantics via useQueue. It names a rich set of prerequisite helper tools (list_pinterest_boards, list_linkedin_pages, list_meta_pages, list_business_locations, list_hooks, upload_file, list_telegram_chats) and tells the agent to resolve ids FIRST. However, it never explicitly names the immediate-publishing sibling tools as the alternative to use instead, so the exclusion is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_google_adsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and destructiveHint, so the safety profile is covered. The description adds valuable behavioral detail: it deliberately fetches the low-credit BASIC variant and explains the detailed variant is not exposed, plus the exact return JSON shape. This goes beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two dense sentences with zero waste. Every clause adds new information: purpose, usage, credit cost, return format, and an alternative. The key differentiator (known brand vs open-ended) is front-loaded, and the cost/return specifics are packed efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only lookup with optional parameters and no output schema, the description is complete: it states the return format, the intended use case, the alternative for open-ended research, and the cost trade-off. With annotations covering security, nothing an agent needs to invoke it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — every parameter has a description, so the schema does the heavy lifting. The description does not add new meaning beyond echoing domain vs advertiserId, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it is a 'Structured Google Ads Transparency pull for ONE advertiser' with specific identifiers, and explicitly contrasts with research_ads. This differentiates it from sibling ad-search tools and tells the agent exactly what resource it acts on and the scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says 'use when you know the brand; use research_ads for open-ended research.' Also explains it fetches the cheap BASIC listing, implying when cost matters. This is unambiguous when-to-use guidance with a named alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_instagramA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds behavioral context beyond annotations: it specifies the endpoint, notes the 'organic' nature, indicates a credit cost, and describes the compact JSON return format and ranking by plays. This extra transparency about cost and return format is valuable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences with zero redundancy. The primary purpose and unique surface are stated first, followed by the output format and cost. Every sentence earns its place, and the description is well-structured and easily scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity (2 parameters, no output schema), the description is complete: it explains the endpoint, differentiates from siblings, details the return fields, notes the ranking criterion, and mentions the credit cost. No essential information is missing for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with both 'query' and 'limit' documented ('keyword to search reels for' and 'max reels returned (1–25, default 8)'). The description does not add additional meaning to the parameters themselves beyond the schema; it only mentions output format and cost. Hence, the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('search'), resource ('Instagram REELS'), and scope ('keyword search'), names the exact endpoint, and explicitly distinguishes it from other IG surfaces ('our only IG keyword surface; profile/hashtag pulls go through fetch_social_data'). It also describes the output structure and ranking, making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells when to use this tool vs alternatives by noting it is the only keyword surface and that profile/hashtag pulls go through fetch_social_data. It also mentions the credit cost, which helps in decision-making. No other usage guidance is needed for a simple search tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• send_x_dmA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the minimal annotations. It discloses that the message cannot be taken back, that sending incurs credit costs, that X may refuse delivery based on recipient settings, and that connectivity may require a one-time reconnection. It also explains the idempotency key's role in preventing duplicate sends. This provides a complete behavioral profile for a side-effecting action, covering risks, costs, and failure modes that annotations alone do not convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-organized: it leads with the core action, then parameter-specific details, followed by a prominent safety warning, usage constraints, failure behavior, cost, and connectivity prerequisites. Every sentence adds actionable information, and the critical consent requirement is highlighted in capital letters. No fluff or redundancy; the structure is efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's real-world side effects (sending a private message to a person), the description covers all essential operational context: safety (explicit consent), recipient identification nuances, idempotency for retries, credit costs, provider-side refusal, and connectivity requirements. It also references companion tool list_x_dms for obtaining IDs. Nothing an agent needs to make an informed call is missing, and the lack of an output schema is offset by clear expectations of refusal behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides rich, 100% coverage for all four parameters, including the numeric vs handle distinction for participantId and the source of conversation IDs. The description reinforces the 'one message to one recipient' rule and the idempotency key's purpose, but these largely repeat or apply what the schema already documents. Since the schema carries the heavy lifting, the description adds only marginal extra semantic value, so a baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (send a direct message), the resource (from the connected X account), and the two distinct modes (existing conversation via conversationId, or to a named account via participantId). It distinguishes itself from sibling social DM tools by specifying X, and the detail about starting a new conversation makes its scope unambiguous. No ambiguity remains about what this tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear guidance on when to use each parameter (conversationId vs participantId), and gives explicit exclusions (never send the same message to multiple people, X may refuse if recipient settings don't allow). It also instructs the agent to obtain explicit user consent before calling. However, it does not explicitly contrast with alternative DM tools (e.g., send_bluesky_dm) or state conditions under which one tool should be chosen over another, leaving some inference required from the tool's own name.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• unsubscribe_meta_webhooksA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations marking destructiveHint and idempotentHint, the description enriches this by detailing the exact scope ('removes the WHOLE subscription'), the side-effect-free nature ('Nothing published or posted is affected'), and the critical verification behavior ('THE ANSWER IS THE READ-BACK...'). It also notes the credit cost ('0 credits'), providing full transparency of what the tool actually does and how to interpret results.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence adds value: the core action, the all-or-nothing caveat, the safety note, the verification method, and the credit cost. Information is front-loaded with the primary purpose, and nothing is redundant. The length is justified given the subtlety of the operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is complete for a destructive operation with a single optional parameter. It explains the behavior, the verification step, the side effects, and the cost. It doesn't include a return format, but that's not expected given no output schema, and the read-back description hints at the response. Combined with annotations, an agent has everything needed to call and interpret this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the only parameter (pageId) with a clear description ('Facebook Page id — omit when only one Page is connected'). The tool description doesn't add further parameter semantics beyond restating the context. With 100% schema coverage, a baseline of 3 is appropriate, as the description doesn't reduce ambiguity but also doesn't need to.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly what the tool does: 'Remove this app’s webhook subscription from a Page, so Meta stops pushing its events.' It uses a specific verb ('Remove') and resource ('webhook subscription from a Page'), and explicitly contrasts with sibling tools like subscribe_meta_webhooks by noting the full-subscription removal. This clearly distinguishes it from related tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides practical guidance: it explains the all-or-nothing nature (Meta’s DELETE takes no field list) and tells the user to call subscribe_meta_webhooks if they want to keep some fields. It also clarifies the effect ('Nothing published or posted is affected; only the notifications stop') and the verification method via read-back. However, it doesn't explicitly mention when to use meta_webhook_status or other alternatives, leaving some room.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• update_settingsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare idempotentHint and non-read-only, but the description adds critical behavioral context: changes are account-wide, affect all brands, apply to MCP renders as well as in-app, and take effect on the next call. It also clarifies language must be plain English. These are meaningful traits beyond what annotations convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is slightly long but every sentence contributes: purpose, per-parameter detail, partial-update hint, scope, and timing. It is front-loaded with the purpose and uses clear structure. It could be trimmed slightly but is not verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 3-parameter settings tool with no output schema, the description covers what an agent needs: scope, effect timing, partial updates, and parameter syntax. It does not mention error handling or validation, but those are not essential for this simple tool. Overall, it is adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already describes each parameter (100% coverage), but the description adds depth—for language, it details that it affects all generated content and specifies the plain-English format; for theme and watchEmail, it confirms the allowed values. This exceeds the schema's brief descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with the precise verb+resource: 'Change this account's app settings.' It then names each settable parameter and its meaning, making the tool's function unambiguous. It is clearly distinct from sibling tools like get_settings (read-only) or enable_tools (tool toggling).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance: 'Only pass what you are changing' (partial updates) and 'Account-wide (every brand)', which clarifies scope. It also notes that changes take effect on the next call. Even though it does not explicitly contrast with siblings, the context is clear enough for an agent to know when to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• clip_videoA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations present (readOnlyHint:false, destructiveHint:false), the bar is lower, but this description adds exceptional behavioral context: the ~7-credit hold and settlement, the subject-aware reframe algorithm ('a SINGLE crop offset that is held for that clip's whole length'), refund-on-failure behavior, default burned-in subtitles, and the explicit warning that timing is approximate ('never promise that'). It even tells the agent to read reframedToSubject/reframeWhy/captionsBurned rather than assume. Nothing contradicts 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long, but nearly every sentence earns its place: each segment maps to a real agent decision (input choice, exclusion handling, cost awareness, reframe behavior, captions toggle, timing caveat, result-field reading). The core purpose is front-loaded in the first sentence, followed by mechanism, then operational details. It could be tightened slightly, but for a tool with this many edge cases the density is justified.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Since there is no output schema, the description carries the full burden of explaining returns, and it does: 'RETURNS clips[] — each with its OWN served mp4 URL, title, hook, ready-to-post caption, 0-100 score and source timecode — not a single video', plus the interpretable fields reframedToSubject, reframeWhy, captionsBurned, captionNote, and truncated. Inputs, outputs, constraints, cost, and edge-case behavior are all covered, leaving no critical gap for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema's own parameter descriptions are already rich (video lists all accepted URL types; captions explains the mute-watching rationale; aspectRatio covers defaults and 'keep'). The description adds complementary behavioral context around parameters — the ~600MB/size gate for `video`, the no-speech-window rule for `captions`, and the read-back fields that interpret results. Value is additive but partially duplicative of the schema, so 4 rather than 5.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource+outcome: 'Cut ONE long video into several RANKED, ready-to-post short clips', immediately followed by concrete use cases (podcast, webinar, interview, conference talk, long ad → Reels/Shorts/TikTok). It clearly differentiates from video siblings — reframe_video (reframes), dub_video (audio), stitch_video (concatenates), edit_video — by centering on the 'cut into ranked clips' operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives strong context on accepted input formats and explicit exclusions: 'NOT supported: TikTok / Instagram / Facebook links, and anything age-restricted, private, members-only, geo-blocked or still LIVE', plus actionable advice ('ask for a direct file or an upload rather than retrying'). It also states hard constraints (min ~15s, ~600MB, ~40min window). It stops short of naming sibling tools as explicit alternatives for non-clipping tasks, so it loses a point.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• comment_on_tiktok_videoA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations carry readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds significant behavior beyond these: TikTok silently hides spam comments with no error signal, the raw-URL refusal on a new comment (vs. replies), and the verification loop. No contradiction — a write operation aligns with readOnlyHint=false. The silent-failure disclosure is exactly the kind of external behavior annotations cannot express.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Dense but front-loaded: core action and constraints first, then the image flow, then the critical silent-spam warning, then auth. Every sentence earns its place for a tool with this complexity. Minor detraction is the heavy all-caps emphasis (TIKTOK SILENTLY HIDES, NEEDS THE TIKTOK ACCOUNT AUTHORIZATION), which is stylistically loud but does flag genuine risks.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Complete for a write tool with five parameters, a cross-tool upload dependency, a silent-failure mode, and an auth gate. The description covers the action, input constraints, the prerequisite upload flow, how to verify success (read-back), and the auth requirement. No output schema exists, but the description's note about the absence of failure signals effectively documents the response semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 five parameters — baseline 3 applies. The description adds marginal value: it clarifies videoId refers to an owned post and stresses passing imageUri+imageWidth+imageHeight 'together,' but the schema's 'required with imageUri' and 'raw URL is NOT accepted' already carry most of that weight. The description does not need to compensate for a coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a precise verb-resource pair — 'Write a NEW top-level comment on a TikTok post the authorized account owns.' It distinguishes itself from both reply_to_tiktok_comment (explicitly noting a reply is the one place a plain URL is accepted) and post_to_tiktok, so an agent can disambiguate without opening other schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Extensive and explicit guidance: the text-or-image requirement, the mandatory pre-upload via upload_tiktok_comment_image, the contrast against reply behavior, the read-back verification method via list_tiktok_comments, and the auth prerequisite pointing to tiktok_account_status. It leaves nothing to inference and directly steers toward the correct sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• competitor_teardownA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses credit costs ('spends credits, free when you pass ads'), the conditional data source (auto-pulls Meta ads when `ads` omitted), and that it auto-tailors outputs to the saved brand. These go beyond the annotations (readOnlyHint, destructiveHint) which only cover safety. No contradiction; the tool is read-only yet consumes credits, and this is clearly stated.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy but every sentence carries operational information: outputs in caps, the contract, the credit behavior, and auto-tailoring. It front-loads the core purpose and uses structural markers (CONTRACT) for clarity. Minor redundancy (spending mention twice) but nothing trivial. Efficiency is high given the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema and only safety annotations, the description is remarkably complete. It specifies inputs, the conditional behavior, cost implications, and the nature of outputs (playbook components). The only missing piece is exact output format, but the enumerated deliverables suffice for an agent to know what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all three parameters. The description enriches meaning: for `ads`, it explains the two modes (supply or omit) and the consequence of omission; for `competitor`, it adds that domain sharpens page match. This adds contract-level semantics not present in the field descriptions, justifying above the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens by stating a specific verb-resource pair ('Tear a competitor's ad strategy down into an actionable playbook') and enumerates concrete outputs (opening-hook MIX, longest-running THEMES, WHITE SPACE, COUNTER-PLAYS). It clearly distinguishes itself from sibling research tools like research_ads or search_meta_ads by focusing on a strategic teardown rather than raw data retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'CONTRACT' section explicitly tells an agent when to pass `ads` (after a pull_competitor_ads / search_meta_ads call) versus when to omit it (auto-pull, spending credits). It implies the tool is for creating a playbook, contrasting with pure research tools. It could name alternatives more explicitly, but the usage context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_brandA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that the tool switches to the new workspace, that it is free but triggers a ~50-credit research cascade only when draft_brand is run, and that re-running with the same name returns the existing workspace. These details go beyond the annotations (idempotentHint, destructiveHint) and add meaningful behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is five sentences and each adds value, front-loading the core action and expanding with scope, usage, and cost. It is slightly long but well-structured, efficiently packing information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity and lack of output schema, the description covers all necessary aspects: workspace isolation, typical usage, idempotence, and cost implications. An agent has enough information to invoke it correctly without further clarification.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes both parameters (name and activate) with 100% coverage, so the description adds no parameter-specific meaning beyond the schema. It mentions workspace isolation and switching, which indirectly relates to 'activate', but not explicitly; this meets the baseline for full-schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool adds a new brand workspace and switches to it, enumerating the isolated contents (brand profile, memory, swipefile, etc.). It also explicitly distinguishes from sibling tools draft_brand and update_brand, leaving no ambiguity about the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states when to use this tool ('for a second brand or a new client') and when to use alternatives ('draft_brand to FILL a workspace, and update_brand to edit one'). It also clarifies the idempotent re-run behavior, which helps an agent decide correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_bluesky_postA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the destructiveHint annotation by detailing the irreversibility ('no trash and no undelete'), the cascade deletion of likes/reposts/replies/quotes, and the rationale for confirmText as a safety mechanism. It also discloses credit cost and the connection prerequisite, which are not in annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence serves a purpose for a destructive operation. It front-loads the critical warning ('PERMANENTLY delete') and then flows logically through the confirmation process, ID formats, and constraints. Some redundancy could be trimmed, but the density is justified.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers identification via AT-URI or record key, the two-step confirmation flow, when confirmText is necessary, ownership restrictions, credit cost, and connectivity requirement. For a complex destructive tool with no output schema, nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover all three parameters, but the tool description adds practical guidance: the 40-character threshold for confirmText, the alternative record-key format, and the note that confirm is 'REQUIRED true'. This enriches the schema's bare definitions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'PERMANENTLY delete one of the connected Bluesky account's OWN posts', stating a specific verb, resource, and ownership constraint. It immediately distinguishes this tool from other platform-specific deletes (delete_x_post, delete_telegram_message, etc.) by referencing the connected account and Bluesky platform.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an explicit two-step workflow: call without confirm first to preview, then call with confirm:true after user approval. It also specifies when confirmText is required (once the post has any engagement). However, it does not explicitly name alternative tools for other platforms, though the platform-specific scope makes the intended use case clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_threadA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the annotations. While annotations declare destructiveHint:true and readOnlyHint:false, the description explains the irreversibility, the two-step confirmation process, the purpose of confirmName, the 100-deletion daily quota, and the unknown effect on replies. It also notes the cost ('0 credits'). This is rich behavioral disclosure that adds substantial context beyond the structured annotations, and there is 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long and dense, but every sentence contributes critical safety-critical information. It is front-loaded with the irreversible warning and the two-step workflow. While not concise in length, it is efficiently structured and avoids redundancy. Given the high-stakes nature of the operation, the length is justified, though it could potentially be tightened without losing essential guidance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the workflow, parameters, quota, and the ambiguity around replies, which is substantial. However, it does not explicitly describe the return format for the confirmed deletion call (beyond implying a success/failure). It does detail the unconfirmed call's response (post text, views, likes, etc.), but the confirmed call's output is left unspecified. Given the absence of an output schema, a bit more detail on the success response would improve completeness, but overall it's fairly complete for a destructive tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema coverage is 100%, the description adds significant meaning to the parameters. It explains that confirm must be true only after explicit user agreement, and it elaborates on confirmName's role as a safeguard to prevent blind deletion of the wrong post, specifying when it becomes required (after engagements). It also identifies postId as coming from list_threads_posts. This goes well beyond the schema's field descriptions, enhancing parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'PERMANENTLY delete one of the brand’s Threads posts.' It uses a specific verb and resource, and the permanence is highlighted. Although it doesn't explicitly contrast with sibling delete tools for other platforms, the title and content unambiguously scope it to Threads, making it distinct from tools like delete_x_post or delete_bluesky_post.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides detailed usage guidance: call without confirm to preview, then call again with confirm:true after user approval, and adds confirmName conditionally. It also explains the quota limit and mentions threads_publishing_limit. However, it does not explicitly say 'use this tool instead of delete_x_post for Threads,' but the platform-specific naming and sibling list make the appropriate context clear. The workflow is explicitly described, which is strong usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_tiktok_post_ad_authorizationA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description richly exceeds the annotations: it discloses the confirm-gating mechanism and its rationale, the external refusal condition while campaigns are ACTIVE, the dry-run no-op returning the change sentence, and the inverted read-back semantics (success = TikTok no longer reports a code; a still-present code means 'not confirmed'). This is exactly the kind of context annotations cannot convey. It is consistent with idempotentHint and destructiveHint — 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but front-loaded with the core purpose, and every sentence adds distinct information — gating rationale, refusal condition with mitigation, dry-run behavior, read-back inversion, auth prerequisite. The heavy ALL-CAPS emphasis is stylistically noisy, and the confirm warning is somewhat repeated across sentences, but for a destructive tool with external-state quirks the density is justified.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description correctly bears the burden of explaining return semantics, and it does: the dry-run 'returns the sentence describing exactly what would happen,' and success/failure is defined via the inverted read-back. It also covers prerequisites (pause active campaigns, TikTok account authorization), making the tool fully callable without external lookup.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3: itemId is described as 'the TikTok post id' and confirm as 'REQUIRED true — call without it first to see exactly what would change.' The description adds genuine value beyond the schema by explaining what 'without confirm' actually does (returns the sentence, changes nothing) and why confirm is a safety gate, enriching the semantics of the confirm parameter without duplicating the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening sentence states a specific verb and resource — 'Delete the Spark-Ads authorization code for a post the authorized account owns' — making the operation unambiguous even against siblings like set/get/extend_tiktok_post_ad_authorization. The ownership scope ('the authorized account owns') disambiguates which posts are eligible.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear operational sequencing: call without confirm first for a dry-run, pause active campaigns/ads before the call, and ensure TikTok account authorization is in place via tiktok_account_status. It does not explicitly route to or exclude the sibling set/extend authorization tools, so it stops short of a full when/when-not comparison.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• extend_tiktok_post_ad_authorizationA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations give readOnlyHint:false and destructiveHint:false, but the description adds rich behavioral detail: the ADD-not-SET semantics with TikTok's own example, the allowed values (7/30/60/180/365), the requirement that ad authorization must already be active, and the non-obvious return behavior ('The reply reads the new window back, because TikTok's own response body is empty'). It also flags the account authorization need. This goes far beyond annotations, fully disclosing side effects and constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but every sentence carries critical information: purpose, add-not-set warning, allowed values, prerequisite, and return behavior. It is front-loaded with the primary action before clarifying nuances. The use of caps and dashes emphasizes key points without becoming rambling. Slightly dense but efficient for the complexity it covers.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 2-parameter mutation tool with no output schema, the description covers everything needed to call it correctly: what it does, how the time period is computed, allowed values, prerequisites (both ad-authorization state and TikTok account auth), and what to expect in the reply. There are no missing pieces; the tool is self-sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: both itemId and authorizationDays have descriptions. The description adds extra semantic depth to authorizationDays by explaining the add-not-set behavior with an example and reiterating allowed values and the default. itemId is straightforward and the description doesn't add more, but the added value on the key parameter justifies a 4 rather than baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Extend how long a post the authorized account owns stays promotable as a Spark Ad' and immediately adds the code-regeneration behavior. It clearly distinguishes from siblings (set_tiktok_post_ad_authorization, get_*, delete_*) by stating it extends an existing authorization, not setting or retrieving. The add-not-set clarification further nails the exact behavior, making it unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states two prerequisites: ad authorization must already be ON (via set_tiktok_post_ad_authorization) and TikTok account authorization is required (referencing tiktok_account_status). It implies this tool is for extending an existing authorization, not initial setup, but does not explicitly list when not to use it or mention alternative extend tools (there are none). Slight gap in explicitly contrasting with set_* but the prerequisite note effectively routes usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fetch_app_screensA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses it modifies the brand by saving screens (consistent with readOnlyHint false), is free and keyless, and requires a confident match. It clearly explains failure behavior ('returns 0 and saves nothing') and instructs to relay plainly. This adds significant context beyond the annotations, which already state idempotent and non-destructive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense and efficient. It front-loads purpose, then gives usage, failure, and success details. Some marketing emphasis (e.g., 'REAL', 'FREE') adds flavor but each sentence contributes value. Slightly verbose in tone, but overall well-structured and not wasteful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with only two optional parameters and no output schema, the description fully covers when to use it, what happens on success and failure, and where data is saved. It also mentions that screens are immediately usable. Nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters (appName and brandId) are fully described in the schema (100% coverage). The description minimally repeats appName's default but does not introduce new semantics. Since the schema already carries the parameters' meaning, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it pulls App Store screenshots into the workspace brand, with a specific verb and resource. Mentions the use case (app-ui-tour template) which helps disambiguate from other asset tools. The definition is specific about the source (App Store) and destination (brand).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly provides conditions for use: when the brand has 0–1 app screens and the user wants make_template_ad(template:'app-ui-tour') or asks to 'pull my app's screenshots'. Also advises against retrying on ambiguous matches, giving both positive and negative guidance. This leaves no ambiguity about when to invoke the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_tiktok_post_ad_authorizationA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true and destructiveHint=false, and the description reinforces that by saying 'Read-only, free.' Beyond annotations, the description discloses a critical behavioral quirk: unlike typical tools that return a not-found error, this tool gets a TikTok error when there is no authorization code, which the description interprets as likely meaning authorization was never turned on. This is valuable context beyond what annotations offer and helps the agent interpret failure modes correctly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences long, each carrying essential information: purpose, critical warning about authorization expiry, and error interpretation with a pointer to the setup tool. It is front-loaded with the primary purpose and then adds behavioral context. The use of ALL CAPS for emphasis on key points is somewhat heavy-handed but not confusing. It's concise given the amount of behavioral nuance it conveys, though it could be slightly tightened.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with one parameter and no output schema, the description fully equips an agent: it states what it returns, warns about the authorization window, explains error behavior, and points to prerequisites and related tools. There is nothing missing that an agent would need to call this tool correctly and interpret the result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides 100% coverage with a clear description for the single required parameter 'itemId' as 'the TikTok post id'. The tool description does not add additional parameter semantics, but since the schema already fully documents the parameter, the baseline score of 3 is appropriate. The description's mention of 'the authorized account owns' implies that the post must belong to the account, but that's scope, not parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Read'), a resource ('Spark-Ads authorization status'), and a scope ('of a post the authorized account owns'). It explicitly lists what the tool returns (promotable, authorization code, window) and distinguishes itself from sibling tools like set_tiktok_post_ad_authorization and extend_tiktok_post_ad_authorization by the action performed. An agent can immediately understand the tool's purpose and how it differs from related tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage context: check the end time before building a campaign, indicating when this tool is relevant. It also explains a common failure mode (TikTok errors when no authorization code) and directs to the alternative set_tiktok_post_ad_authorization. Additionally, it states a prerequisite (needs TikTok account authorization) and refers to a specific tool for checking that (tiktok_account_status). This is comprehensive when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• google_business_accountA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds substantial extra context: it specifies the exact data fields returned, clarifies the scope (exactly one account, parent of a listing), states it costs 0 credits, and lists the prerequisite ('Needs Google Business Profile connected'). This goes beyond the annotations to give a complete behavioral picture.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than the absolute minimum, but every sentence serves a purpose: core purpose, data fields, usage context, scope limitation, and prerequisite. It is front-loaded with the core function and then narrows to exclusions. The only slight inefficiency is the list of account types could be seen as verbose, but it is useful. Overall it is well-structured and not redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read tool with one optional parameter, the description is fully complete. It explains what data is returned (fields are listed), when to use it, what it does not do, and the prerequisite (Google Business Profile connected). Even without an output schema, the agent knows exactly what to expect. No missing information that would prevent correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There is only one optional parameter (locationId) and the input schema already provides a full description: 'which listing, from list_business_locations — only needed when more than one is shared with this brand.' Schema description coverage is 100%, so the description does not need to add parameter details. The tool description adds no extra parameter semantics, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific verb and resource: 'Read the Google Business Profile ACCOUNT that owns one of the brand’s listings' and enumerates exactly what data it returns (name, type, role, verification, permission). It also differentiates from the sibling list_connector_accounts by explicitly stating it reads exactly ONE account and never lists other accounts, so an agent can distinguish it without opening the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance: 'Use it to answer “can we actually edit this listing?” and “whose account is it on?” before offering an edit that Google would refuse anyway.' It also names the alternative for the other case: 'that roster belongs to the account picker (list_connector_accounts),' and explains when it is not appropriate (when you need to list all accounts). This fully routes the agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• google_business_search_keywordsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark readOnlyHint=true and destructiveHint=false, but the description adds high-value behavior: low-volume terms are suppressed with impressions=null and below=<threshold>, counts are unique users not impressions, only ~12 months of history, read-only with 0 credits, and requires connected profile. This is exactly the kind of context that prevents misuse.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a dense paragraph but every sentence adds value: purpose, contrast with sibling, suppression warning, unit clarification, retention, and operational requirements. It is front-loaded with the core purpose. Not perfectly structured (could use bullets) but appropriately sized for the complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description explains the meaning of key fields (impressions=null, below) and the uniqueness of the data. All operational prerequisites (connected profile, credits, read-only) are stated. With 4 optional params and rich annotations, nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so all four parameters are documented. The description adds no new parameter-specific semantics beyond the schema (e.g., it doesn't explain limit or months more than the schema does). Baseline 3 is appropriate since schema carries the semantic load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly what the tool returns: the actual search terms users typed before the business listing appeared. It explicitly contrasts with sibling google_business_insights, distinguishing 'HOW MANY' vs 'WHICH WORDS', making the purpose unambiguous and differentiated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description names the direct use case (input to Google Ads keyword set, page titles, profile description) and explicitly contrasts the sibling tool google_business_insights, telling the agent which to use when. It also gives critical reporting guidance for suppressed terms, which is a when-to-use instruction in disguise.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• leave_connectorA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (destructive, idempotent, non-read-only), the description discloses that only your contribution is removed, teammates' accounts remain functional, and nothing changes at the provider. It also notes that reconnecting shares again, adding context about reversibility and scope.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than necessary but every clause adds value: explanation of the multiContributor context, precise side effects, and the alternative. It is front-loaded with the core action. Slight verbosity prevents a 5, but no redundancy exists.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive, shared-connection mutation, the description covers what happens, who is affected, and when to use it, plus directs to list_connectors for verification. No output schema exists but none is needed; the agent has everything to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and the schema description already explains the provider parameter with examples. The tool description does not add extra meaning about the parameter beyond the schema; it references 'this brand' but doesn't clarify the mapping further. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'remove YOURS from this brand' with specifics: drops stored credential, stops sharing your accounts. It distinguishes from disconnect_connector by naming it as the alternative for connections you own, so an agent can differentiate without opening the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says 'Use this instead of disconnect_connector when the connection is not yours to remove' and explains why disconnect_connector is different (revokes at provider, only creator can call). This gives clear when and when-not guidance with a named alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_connectorsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description explicitly says 'Read-only, free,' aligning with and reinforcing that. Beyond annotations, it discloses a subtle behavioral trait: connections with out-of-date permissions are flagged, explaining why retries or waits cannot help and directing the user to the reconnect path. This adds substantial context not encoded in structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than typical, but every sentence serves a purpose: it enumerates the output, explains the permission flag, gives a diagnostic trigger, and indicates the remediation path. The core purpose is front-loaded, and the extra detail is directly useful, not filler. It could be trimmed slightly, but it earns its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only listing tool with no parameters and no output schema, the description is highly complete. It tells the agent exactly what the output includes (provider, status, label, available providers), what the special flag means, when to call it, and how to fix the underlying issue. Nothing essential is missing for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema is empty (0 parameters), so the baseline is 4. The description correctly spends no space on parameters and instead focuses on output and behavior, which is appropriate for a zero-parameter tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the exact action (list connected third-party accounts) and the specific resources included (Meta, Google Ads, Google Drive/Sheets/Docs, YouTube, LinkedIn, OneDrive, Slack, etc.), along with the returned fields (provider, status, label) and the additional capability (available providers). It is specific enough to distinguish from sibling tools like list_connector_accounts, even without an explicit comparison.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete usage trigger: 'Check this FIRST when a connected provider starts refusing things.' It also explains the underlying cause (permission set baked into the token at consent time) and the fix (reconnect in the browser). It does not explicitly name alternatives or when not to use it, but the scenario is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_inboxA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true and destructiveHint=false, which the description aligns with. Beyond that, it discloses critical behaviors: unconnected channels are silently skipped, failures are named in `notes`, DMs fold to one item per conversation, and X incurs per-API-call costs. This adds substantial context beyond annotations, especially around failure handling and billing, which is essential for correct use. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy but densely packed with essential information, each sentence earning its place. It is front-loaded with the tool's core function, then usage guidance, then critical behavioral details and pricing. While it is verbose, the structure is logical and avoids fluff, though a slightly more compact version could be imagined without losing value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema and high complexity (multiple channels, edge cases), the description is remarkably complete. It covers what happens on unconnected channels, failures, DM consolidation, and cost implications for X. It also references how to obtain conversationId for DMs. An agent has all the necessary context to call it correctly and interpret results, including the `notes` field behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how conversationId is used (to include DMs and its origin sources) and the DM folding behavior, which clarifies the parameter's role. It also implicitly ties the `sources` parameter to the channel names listed, adding semantic richness beyond the schema's enum-like list.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear purpose: aggregating all comments, replies, mentions, reviews, and DMs across multiple channels into one list. It enumerates the specific channel types (Facebook, Instagram, Threads, YouTube, Reddit, Google Business, Bluesky, X, Meta DMs, Telegram) and distinctly positions itself as the unified 'inbox' compared to per-channel list tools like list_meta_comments or list_x_dms. It also ties to the reply_to_inbox_item sibling, clarifying its role in the workflow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use it: "Use this for 'what do I need to reply to', 'any new comments', 'any new DMs', 'how are people responding'." It also contrasts with per-channel tools by saying "every other source only re-reads what the per-channel tools already read," implying this is the aggregated alternative. It does not explicitly say when NOT to use it (e.g., when you need deep per-channel analytics), but the context is clear enough for an agent to choose this for a unified view.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_reddit_postsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the exact fields returned (id, title, subreddit, score, comment count, removed status, editability), which is behavioral detail beyond the annotations. It also explains the purpose and why the tool exists. It explicitly states 'Read-only, 0 credits' which aligns with readOnlyHint=true and destructiveHint=false. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately long but each sentence carries value. It is front-loaded with the core purpose and a bolded callout for the critical postId source. The structure flows from purpose to usage note to requirements. It is not overly verbose, though it could be slightly tightened.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with 0 required parameters and no output schema, the description is thorough. It covers purpose, usage context, prerequisites, and the content of returned data. There is no missing information an agent would need to call it correctly; even the reason for the tool's existence is explained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — all three parameters (sort, limit, cursor) have descriptions in the schema. The description does not add extra semantic meaning beyond what the schema provides. It mentions the default for sort but that is also in the schema. Thus, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'list' and the resource 'the connected Reddit account’s OWN submissions', listing the specific fields returned. It distinguishes itself from other Reddit tools by emphasizing that it returns the account's own posts and explicitly notes it is the source of postId for every other Reddit tool. This differentiates it from search_reddit and other listing tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: it tells the agent that postId comes from this tool, and contrasts with post_to_reddit which only gives an id at publish time. It also states prerequisites ('Needs Reddit connected') and clarifies it is read-only with 0 credits, giving clear context on when to invoke it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_telegram_dmsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description goes far beyond by disclosing the 24-hour data retention, the fact that older messages are unrecoverable, the webhook caveat, the inability to message first, and the connector requirement. These are non-obvious behavioral traits that an agent must know to avoid false conclusions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but well-structured, with the core purpose front-loaded. It contains multiple warnings and caveats, but each serves to prevent misinterpretation of Telegram's unusual behavior. However, it is somewhat verbose, repeating the 24-hour point and including extra warnings that could be condensed without loss.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a seemingly simple read operation with no output schema, the description covers all critical context: data retention window, webhook conflict, message-first constraint, connector requirement, cost, and error-reporting guidance. It also hints at the output structure (chatId and message grouping). This is exceptional completeness for a tool with complex platform limitations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% because the single 'limit' parameter is already described in the schema, including its range, default, and the fact that it refers to raw updates not rows. The description adds no additional information about the parameter, so the baseline 3 applies. It does not compensate further, but the schema is sufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a precise verb ('Read'), a specific resource ('messages sent to the connected Telegram bot'), and the output scope ('newest message from each chat, newest chat first'). It clearly explains the purpose ('see who is waiting on a reply') and references the sibling 'post_to_telegram' for the follow-up action, making the tool's role unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage context: it tells the agent when to use it (to read incoming messages), what to do with results (reply via post_to_telegram), and crucial caveats (24-hour rolling window, webhook incompatibility, bot cannot message first). It also states the prerequisite via Settings ▸ Connectors ▸ Telegram. This is comprehensive guidance that prevents misuse.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_tiktok_brand_hashtagsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations. It discloses eligibility rules (three caption appearances, substring rule), the 50-tag limit per brand, the caveat that new/test accounts may return empty, and confirms read-only/free behavior. These are crucial behavioral details that an agent needs to set expectations and avoid misuse.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense and covers many necessary caveats, but every sentence adds operational value. It is longer than average, but for a tool with this many behavioral nuances, the length is justified. It is well-structured, starting with the core purpose and then layering constraints.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list tool without an output schema, it covers the input semantics, limits, auth, and edge cases thoroughly. The only minor gap is that it does not describe the shape of the returned data (e.g., fields like name, enabledDate, removable), but given the tool's simplicity, this is not a significant omission.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents both parameters (kind with enum, username with description). The description adds substantial value by explaining what ENABLED vs AVAILABLE mean, and for username it clarifies that it is normally resolved from authorization and only needs to be passed if that read is refused. This goes beyond the schema and helps correct invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('list') and resource ('brand hashtags TikTok tracks for this account') and immediately distinguishes the two flavours (ENABLED vs AVAILABLE). It precisely conveys what the tool returns and the differentiation between the two kinds, making its purpose unambiguous and distinct from any sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explains when to use each flavour (ENABLED vs AVAILABLE), the qualification criteria for tags, and the caveat about test accounts. It also notes the authorization requirement and that it is read-only. While it does not explicitly contrast with sibling manage_tiktok_brand_hashtags, the 'Read-only' mention and the name make the intended usage clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_watch_findingsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare readOnlyHint and destructiveHint, but the description adds critical behavior beyond that: it clearly states 'Read-only and free — it returns the stored results of past runs and never triggers a check.' It also explains the seed:true semantics, which is essential to correctly interpret results. These nuances are not present in annotations, so the description fully covers them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a dense paragraph of about five sentences, but every sentence contributes necessary context (scope, state fields, seed semantics, read-only behavior, and pointer to set_competitor_watch). It is not as tight as a two-sentence version, but there is no fluff or repetition. Front-loading the core read action keeps the most important info first.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a non-trivial return shape (findings plus watch state) and an ambiguity around seed:true. The description explains both the content and the seed nuance, clearly states what it does NOT do (trigger a check), and even references the web app's Ad Spy tab for orientation. Given there is no output schema, this description is sufficient for an agent to know when and how to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents both parameters (limit and competitor) thoroughly. The description does not add any additional parameter-specific detail beyond what the schema provides; it only mentions the behavior generically. Thus baseline 3 is appropriate since the schema carries the semantic weight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Read what the standing COMPETITOR WATCH has found' and details exactly what is returned (new ads plus watch state). It also distinguishes itself from siblings like set_competitor_watch by explicitly stating it never triggers a check, so an agent can tell them apart without opening schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete use cases: 'Use it to answer "what are our competitors running that's new?", to feed a teardown, or to save something worth keeping with save_to_swipefile.' It also names the alternative for triggering a check explicitly: 'set_competitor_watch({runNow:true}) is what runs one.' This provides clear when-to-use guidance and exclusion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• make_template_adA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are all-false, so the description carries the full burden — and it delivers richly. It discloses render time (~30 seconds), cost (a couple of credits), audio behavior (music bed only when a track is on file, never a paid generation; SFX always present unless silenced), output types per template (VIDEO/IMAGE/MULTI-IMAGE with a PNG images[] for carousel), and that image URLs are server-localized. Exceptionally thorough.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is an enormous single paragraph of dense run-on text and deep parentheses that is hard to scan, even though nearly every sentence carries real information. It front-loads the purpose well, but 13 interleaved template specs, character limits, and style guidance would benefit from structured separation. Size is justifiable given complexity, but structure is not.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Complete for a high-complexity tool with no output schema. It enumerates every template variant, its duration, config contract, content constraints (character/word limits, 'never invent stats'), audio behavior, and cost structure. Nothing an agent needs to call it correctly or to pick a template is missing, including the credit implications.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema's single config param is a bare '{}' object with no properties defined, so schema coverage is nominal. The description compensates overwhelmingly — it documents all 13 templates with their full config contracts (e.g., imessage-chat thread/messages/endCard, value-prop hook/claims limits, myth-vs-fact pairs with bracket escape hatch). An agent could construct a correct config purely from this text.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource ('Render a NATIVE-STYLE TEMPLATE ad from pure HTML') and immediately distinguishes itself from model-driven tools by stating 'no AI video/image model in the loop'. With siblings like render_ad, make_explainer, and product_sizzle present, this differentiation is essential and well-executed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly frames when to use it ('Perfect for native-feel social ads at volume') and imposes clear content authorship rules ('YOU author the content — short, casual, believable — never marketing-speak'). It does not name alternative tools or state explicit when-not-to-use conditions, which the parenthetical about the model-free approach partially covers.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_linkedin_postA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructive and non-read-only behavior, but the description adds critical specifics: delete is immediate and public, edit only affects text, and a visual change requires a new post. It also implies confirmation requirements. This goes beyond the annotations without contradicting them, though it could elaborate on reversal or side effects for completeness.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is efficient, with each sentence carrying essential information. It front-loads the core purpose and then packs constraints and usage nuances into a compact, structured text. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no output schema, it covers the essential aspects: purpose, parameters, constraints, and confirmation. It could mention error handling or side effects, but the key operational details (immediate deletion, copy-only edits) are present. The userId/Page context is implied by 'personal profile or company Page.'

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 75% (action lacks a description), but the description compensates by explaining the postUrn requirement (full urn from publishing) and the semantics of action values. It adds context that the schema does not fully provide, such as the text being the only editable copy and confirm being mandatory for delete.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb (edit or delete), the resource (a published LinkedIn post), and the scope (personal profile or company Page). It also distinguishes itself from sibling tools like delete_x_post or edit_x_post by specifying LinkedIn and the specific actions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly tells the agent when to use this tool versus not: edit only changes copy, if a visual change is needed it says 'a new visual means a NEW post — tell the user instead of promising a swap.' It also specifies that delete is immediate and public and requires confirm:true, giving clear conditions for use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_tiktok_brand_hashtagsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description provides extensive behavioral detail beyond annotations: the 24-hour delay before a new hashtag is counted, the 7-day removal lock, the read-back validation (the 200 is not the answer), the auth requirement, and the acceptance criteria (must be on available list or contain account handle). This is far more than the annotations (readOnlyHint:false, etc.) convey, and nothing contradicts 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence carries essential operational constraints: limits, timing rules, acceptance criteria, read-back semantics, and authorization. Not a word is wasted, though it does feel dense. It's well-structured with clear flags like 'TWO TIMING RULES THAT ARE EASY TO TRIP.' Appropriate for the complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has two modes, strict timing rules, validation requirements, and non-obvious success criteria. The description covers all of these: the action enum, capsule limits, 24h count delay, 7-day removal lock, required tag validity, and the read-back check. It even notes the auth scope. Nothing essential for correct invocation is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 75%, so most params are documented in the schema. The description adds critical constraints not in the schema: ADD takes up to 10 per call, 50 total per brand, REMOVE takes exactly one (with rationale), and the 24h/7-day timing effects. It also clarifies the 'hashtag' vs 'hashtags' usage. This adds substantial value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb+resource: 'Enable or disable the hashtags TikTok counts as this brand's.' This distinguishes it from sibling tools like list_tiktok_brand_hashtags (which lists) and list_tiktok_brand_hashtag_posts (which shows posts). The scope is precise and immediately understood.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains when to use ADD vs REMOVE and includes important timing constraints that affect usage. It doesn't explicitly name alternatives or state when NOT to use this tool, but it's clear that this is the toggle tool while siblings handle listing. Guidance is strong but could be more explicit about alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_youtube_playlist_imageA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint:false, destructiveHint:false) already indicate mutation, but the description adds critical behavioral details: the HTTP 500 'Internal error encountered' masking real errors, the imageUrl must be Hermoso-hosted (nothing else fetched server-side), and the need for a verified YouTube channel. These are beyond annotations and significantly aid an agent in anticipating and diagnosing failures. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-structured, opening with the core purpose and then detailing constraints, actions, and error behavior. Each sentence carries relevant information; the HTTP 500 explanation is a bit verbose but important for agent behavior. It is not as succinct as the gold standard but remains efficient given the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with four parameters, an enum, and a multi-step chain, the description covers all crucial aspects: purpose, action semantics, URL constraints, error handling (including the misleading HTTP 500 and its resolution path via verification), and the relationship to sibling tools. No output schema exists, but the description does not need to explain return values. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters, each with a short description. The description adds meaningful context: action defaults to 'list', imageUrl must be a Hermoso-hosted URL up to 50MB and must come from make_thumbnail, a Hermoso render, or upload_file; imageId for delete comes from action:'list'. This goes beyond the schema's terse hints, making the constraints actionable.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'PUT A CUSTOM COVER ON A PLAYLIST' — a specific verb and resource. It clearly explains the three actions (list, set, delete) and distinguishes itself from siblings by noting that make_thumbnail renders artwork and playlist tools own the playlist. This is unambiguous and differentiates it from related tools like set_youtube_thumbnail.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains the chain context (last call after make_thumbnail or upload_file), states what each action does, and gives explicit requirements for imageUrl (Hermoso-hosted, ≤50MB). It also mentions the channel verification prerequisite and contrasts with the sibling set_youtube_thumbnail on unverified channels. It does not explicitly say 'use this instead of X' but the context is clear. A minor gap is the lack of guidance on when to choose 'list' vs 'set' beyond their descriptions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_to_google_businessA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are minimal (readOnlyHint false, destructiveHint false, etc.), but the description adds critical behavioral context: it publishes immediately and publicly, requires explicit user confirmation before calling, and explains platform quirks like Google ignoring the button link on OFFER posts and CALL buttons dialing the listing's number. These details are beyond the annotations and are essential for safe, correct usage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-organized: it leads with the core action, then constraints (no video, immediate publish, consent), then usage hints (locationId, connection), then platform-specific rules. Every sentence contributes new information; it is lengthy but warranted given the tool's complexity. It is not tautological or padded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 15-parameter publishing tool with no output schema, the description covers essentials: prerequisites (connection, locationId), behavioral caveats (immediate public publish, confirmation), special cases (event/offer requirements, offer link ignoring, call button), and points to schema for parameter details. Nothing an agent needs to call it correctly is omitted.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and many parameters have rich descriptions (e.g., hook explains grouping semantics). The tool description supplements this by clarifying cross-parameter constraints: EVENT/OFFER require title and startDate, OFFER uses redeemOnlineUrl instead of link, and CALL ignores link. This adds meaningful meaning beyond the schema, though it does not enumerate every parameter—that is already handled by the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Publish a Post to the brand’s Google Business Profile'. It clearly distinguishes this from other post_to_* siblings by naming the platform (Google Search and Maps) and stating it accepts only text, one photo, and a CTA button. The 'NO VIDEO' note further narrows scope, making the tool's purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete usage guidance: call list_business_locations first when managing multiple listings, requires a connected Google Business Profile (with Settings path), and specifies that EVENT/OFFER posts need a title and start date. It does not explicitly name alternative tools for other platforms, but given the tool name and the ecosystem, this is implicitly clear. The guidance is thorough enough to route an agent correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_to_redditA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations only indicating it's a write operation (readOnlyHint false), the description carries the full burden of behavioral disclosure. It explicitly states the post publishes immediately and publicly, warns about self-promotion penalties and account bans, and explains flair detection behavior. This is excellent transparency for a high-risk action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence earns its place—critical warnings about public publishing and policy violations are front-loaded. It's structured as a coherent block, not a wall of text. A slight length reduction for non-essential details would push it to 5, but it's efficient given the high-stakes nature.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 13 parameters and no output schema, the description covers all essential operational aspects: prerequisites (Reddit connection), key constraints (one subreddit, community-specific), error handling (flair detection), and strategic considerations (hook/subject analytics). An agent has everything it needs to call this tool correctly and safely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 85%, so parameters are largely documented in the schema itself (e.g., hook, subject, kind). The tool description adds no extra meaning beyond what the schema already provides; it only references imageUrl and flairId in passing. Per the rubric, high coverage sets a baseline of 3, and the description doesn't elevate it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Submit a post to ONE named subreddit'. It enumerates the supported post types (text, link, image) and specifies the account context (connected Reddit account). This clearly distinguishes it from sibling posting tools like post_to_x or post_to_linkedin, which target different platforms.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use and when-not-to-use guidance. It warns against posting to multiple subreddits, instructs the agent to refuse blasting requests, and highlights the requirement to get user confirmation before posting. This is far beyond a generic posting tool—it provides actionable decision rules.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• reply_to_inbox_itemA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint:false and destructiveHint:false. The description adds meaningful behavioral context: public/private posting behavior, routing to the correct channel, the X exception, and the need for user approval beforehand. It does not contradict annotations, though it omits auth or rate-limit details, which are not hinted in annotations either.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is slightly long but well-structured, front-loading the most critical information (composite ID and routing) before explaining behavioral nuances. Each sentence carries operational weight, with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter tool with no output schema, the description covers all essential aspects: ID format, routing, public/private visibility, exception handling, and the mandatory approval step. An agent has everything needed to invoke the tool correctly without ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters have descriptions. The description goes beyond the schema by explaining the composite ID structure with examples ('facebook:123_456', 'google_business:accounts/1/locations/2/reviews/3') and clarifying that a bare platform id is refused. This adds valuable semantic depth for the id parameter; text is straightforward as defined.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Answer') and resource ('inbox item'), and uniquely identifies the ID format ('composite ID') with concrete examples. It clearly distinguishes this tool from platform-specific reply siblings by emphasizing that it routes to the correct channel automatically, so an agent understands it is the universal reply entry point.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit usage context: the reply is posted as the brand, is PUBLIC on most sources and PRIVATE on the two DM sources, and requires user go-ahead. It names the one exception (X) and directs to post_to_x instead, providing a clear when-to-use and when-not-to-use guide.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• reply_to_meta_messageA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description delivers far more than the sparse annotations (readOnlyHint:false, openWorldHint:true) require. It discloses the real-person consequence with a mandatory confirmation gate, the 24-hour window check behavior with and without conversationId, the outbound 'refuses with the real reason' behavior, the platform-specific ID scoping, and 'ACCEPTED IS NOT DELIVERED.' It also flags the 0-credit cost. No contradiction exists with the annotations — the write nature aligns with readOnlyHint:false.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Information is densely packed and the critical safety warning is front-loaded ('THIS REACHES A REAL PERSON... get a yes, then send'). Every sentence carries weight. The heavy ALL-CAPS emphasis ('HERMOSO SENDS REPLIES ONLY', 'ACCEPTED IS NOT DELIVERED') is stylistically noisy and the recipientId guidance is duplicated between the schema and description, so it could be tightened despite being well ordered.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a safety-critical, platform-variant tool with no output schema, the description covers everything an agent needs: the confirmation gate, the 24-hour window rule and its failure mode, per-platform ID scoping with provenance, the response-only boundary, delivery semantics, and credit cost. Nothing required for a correct call is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 60% schema coverage the description compensates substantively: it explains that recipientId is a page-scoped (Messenger) vs Instagram-scoped ID that cannot be derived from a username/handle, and it attaches concrete behavioral consequences to conversationId (enables pre-send window check vs. disclosed 'could not be checked'). The platform property's scoping impact is clarified. However, pageId remains undocumented in both the schema and description, so it is not a 5.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The first sentence states a specific verb and resource: 'Send a text reply to someone who has messaged the brand.' It immediately distinguishes itself from sibling reply tools (reply_to_meta_comment, reply_to_thread, send_whatsapp_message) by scoping to Messenger/Instagram DMs. The platform scope and reply-only boundary make 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly frames when to use it — replying to someone who has messaged the brand — and states hard boundaries: proactive messages and message tags are deliberately not offered, messaging_type is always RESPONSE. It routes the agent to read_meta_conversation for the replyTo ID. However, it never names a sibling tool as an explicit alternative (e.g., for when a user wants to start a new conversation rather than reply), which keeps it a 4.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• reply_to_tiktok_commentA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only mark readOnlyHint=false and destructiveHint=false, which are broad. The description adds crucial behavioral details: the requirement of at least one of text or image, the special allowance of plain image URLs only on replies, the spam-hiding behavior and suggestion to read back with list_tiktok_comment_replies, and the explicit authorization requirement. These go far beyond the annotations and inform the agent of side effects and failure modes.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core action, then adds necessary constraints (char limit, image types, spam note, auth). While it uses some emphasis (caps) and is a bit dense, every sentence carries value and there is no fluff. The length is justified by the number of nuances the agent needs to know.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 7 parameters, no output schema, and a complex platform behavior, the description covers all critical gap: required fields, optional combinations, the unique imageUrl exception, spam behavior, and auth dependency. An agent reading this can successfully invoke the tool and made aware of verification via list_tiktok_comment_replies. There is no critical missing information.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 71% but leaves imageWidth and imageHeight undocumented. The description clarifies that width/height are for uploaded imageUri, and distinguishes imageUrl (public URL) from imageUri (from upload_tiktok_comment_image). It also states that at least one of text or image is required. This adds meaningful context beyond the schema, though it doesn't fully define the numeric width/height parameters themselves.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource ('Reply to an existing comment on a TikTok post') and adds ownership scope ('the authorized account owns'). It explicitly names twin tools (reply_to_meta_comment, reply_to_youtube_comment) to distinguish from siblings, leaving no ambiguity about what this tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives context on when this tool is appropriate (replying to a comment) and mentions it's the TikTok twin of analogous tools, implying a family of similar actions. It also notes the authorization requirement and points to list_tiktok_comment_replies for verification. However, it doesn't explicitly state when *not* to use this vs. siblings (e.g., vs. comment_on_tiktok_video) — it leaves that to the name and context. Still, the guidance is clear enough for an agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• research_adsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint, openWorldHint, and destructiveHint=false, but the description goes beyond by disclosing that this is an agentic loop taking 30-60 seconds, that it spends credits (a handful vs. a single-call cost), and that it performs several rounds of library pulls plus a written synthesis. This behavioral context, including cost and latency, is critical and not available in the annotations, so the description fully carries its burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose and examples, then provides usage guidance and caveats in a logical flow. Every sentence earns its place—no filler, clear structure, and the critical warning ('WRONG tool for a question that names its own answer') is highlighted. It is appropriately length for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool that is an agentic loop with no output schema, the description explains the behavior (multi-round, synthesis), the time cost, and the credit cost, and routes to faster alternatives for simpler queries. It doesn't explicitly describe the output format beyond 'written synthesis', but that is sufficient for an agent to know what to expect. The context is adequate for deciding when to invoke this tool, and the only minor gap is the absence of a precise return structure, which is acceptable given the open-ended nature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers both parameters (query and brand) with clear descriptions, so the baseline is 3 per the rubric. The description adds an example of a query ('the longest-running protein-pancake ads on Meta') and implies that the query should be open-ended, but it doesn't explain the brand parameter beyond what the schema provides. Since schema coverage is 100%, the description's added semantic value is marginal, though it does reinforce what kinds of queries are appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Open-ended ad research that needs JUDGMENT across platforms' and gives concrete examples ('comparisons', 'what angle is working', 'who else is doing this'), making the tool's specific purpose unmistakable. It also names two sibling tools (pull_competitor_ads and search_meta_ads) and explicitly contrasts them, so an agent can distinguish this from the rest of the tool list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  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 (open-ended questions where the right sources are unknown) and when NOT to use it ('a question that names its own answer'). It names the precise alternatives—pull_competitor_ads for a named brand's live ads, search_meta_ads for one keyword or advertiser on Meta—and notes they are single calls that return quickly, leaving no ambiguity about routing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• save_pinterest_pinA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only say readOnlyHint=false, destructiveHint=false. The description goes further by disclosing that the save endpoint COPIES rather than moves, leaving the original intact, and requires deleting via delete_pinterest_pin to remove the duplicate. Also states the 0-credit cost and Pinterest connection requirement, which are behavioral facts the agent needs to know.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Approximately 150 words, but every sentence is functional: purpose, sibling comparison, copy behavior, user guidance, credits, and connectivity. The structure is front-loaded with the core purpose, then expands into usage and behavioral nuances. Slightly verbose but not wasteful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (3 params, no output schema), the description provides all necessary context: what it does, when to use it, how it behaves (copy vs move), what the agent must do (let user pick board), cost, and prerequisite. Nothing essential is missing for an agent to correctly invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description reinforces that boardId must come from list_pinterest_boards and that the user picks it, but this is already in the schema. It adds no new meaning for pinId or boardSectionId, and the optional boardSectionId is completely undocumented in both schema and description. With 67% schema coverage, the description adds marginal value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb ('save'), resource ('existing Pin'), destination ('another board'), and clearly distinguishes from update_pinterest_pin by calling itself the GENERALLY AVAILABLE option. The purpose is immediately obvious and differentiated from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says to reach for this first over update_pinterest_pin (which is in limited beta), and instructs the user to pick the board via list_pinterest_boards. Also provides cleanup guidance by pointing to delete_pinterest_pin if duplication is unwanted. No ambiguity remains about 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.

• search_meta_adsA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat safety. It adds behavioral details beyond annotations: cost ('Spends a credit or two') and return format ('Returns compact JSON {page_name, body, cta, link, dates, media} per ad'). It doesn't reveal pagination or empty-result behavior, but the annotations cover the core safety profile, making this a solid 4.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences with zero fluff. The core purpose and usage guidance are front-loaded, cost is mentioned concisely, and the return format is succinctly defined. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description provides the return structure explicitly. It covers cost, usage context, and names the alternative tool. It lacks pagination details or limits beyond the 'limit' parameter, but for a 7-parameter tool with full schema coverage and clear annotations, it is complete enough for an agent to call correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds value by clarifying the mutual exclusivity rule: 'a keyword (query) OR one advertiser (companyName / pageId)'. This is not present in the schema and helps an agent choose between parameters correctly, raising the score to 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Structured Meta (Facebook/Instagram) Ad Library pull') and the resource, and explicitly names the sibling tool it is not ('For open-ended research... use research_ads instead'). It clearly distinguishes itself from other search tools like search_google_ads by framing it as a precise pull when you know exactly what to fetch.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage conditions ('use when you know exactly WHAT to fetch') and names the alternative for open-ended research ('use research_ads instead'). It also adds practical cost guidance ('Spends a credit or two'), which is valuable for an agent deciding when to call this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_youtube_watermarkA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes well beyond annotations by disclosing the critical limitation (API cannot read back a watermark) and the honesty about reporting 'accepted' rather than 'confirmed'. Also notes credit cost and connection requirement, adding behavioral context the annotations don't cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence contributes: purpose, timing rationale, constraints, timing options, and the API limitation. Slightly long, but the information is essential and well-ordered.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity, the complete schema coverage, and no output schema, the description addresses all necessary details: how to use it, when to use it, constraints, behavior, and the lack of confirmation. Nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters are fully documented. The description adds value by explaining image constraints (square, 150x150, 10MB), the rendering size implication, and the action default behavior when imageUrl is provided. This enriches agent understanding beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States the precise verb-resource pair (set/remove branding watermark) and explains its channel-wide effect on every video, including future uploads. Clearly distinguishes from thumbnail tools and other YouTube operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context on when to use (before batch uploads vs. after) and explains the default full-video behavior with timingType options. Does not explicitly name alternatives or exclusions, but the usage is well implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• threads_profileA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes far beyond the annotations (readOnlyHint, openWorldHint, destructiveHint) by disclosing critical behaviors: handle matching is EXACT so display names fail, the resolution of bare/'@'/link formats, and a crucial error-handling note (if nothing comes back, do not assume absence – read the note for approval state). It also reiterates read-only and zero cost, consistent with annotations, and clarifies it's not a scraper.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but densely packed with actionable information. It front-loads the core purpose, then moves through usage context, input format caveats, error handling, and prerequisites. Every sentence contributes value, though some phrasing could be tightened (e.g., the dual mention of 'competitor research'). Overall it is structured well and not bloated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a single parameter and no output schema, this description is exceptionally complete: it specifies the accepted input formats, the data returned, the prerequisite connection, the cost, the error-prone scenario and how to interpret the note, and the relationship to a sibling tool. An agent can confidently invoke this tool correctly with no missing guidance.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes the username parameter with examples, but the description adds meaningful semantics: it explicitly states that display names will NOT resolve due to exact matching, and reinforces the accepted formats. This goes beyond a simple restatement of the schema, giving the agent the resolution rules needed to avoid a failed call.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb ('Read') and resource ('public Threads account'), and enumerates the exact data fields returned (name, bio, avatar, verified badge, follower count, lifetime likes/quotes/reposts/views). It also distinguishes itself from the sibling list_threads_profile_posts by naming it explicitly as the companion for reading posts, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: competitor and creator research on Meta's own data, and directs the agent to follow with list_threads_profile_posts to draft a brand's answer. It also states prerequisites ('Needs Threads connected') and cost implications ('0 credits'). However, it does not explicitly mention when not to use this tool, or name direct alternatives for profile-related queries, so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tiktok_account_insightsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and destructiveHint, but the description adds significant behavioral detail beyond that: demographics are withheld below 100 followers for privacy (not because the audience is unmeasurable), daily numbers lag by up to 48 hours, the look-back is capped at 60 days, and specific fields (bio, verified badge, profile link) are deliberately not readable here. It also explains the auth requirement and that it reports which precondition is blocking, which is valuable behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but densely packed with useful information. It front-loads the core purpose, then details preconditions, limitations, and alternatives. The structure is logical and each sentence adds value, though a few explanatory clauses (e.g., 'which is not the same as an audience it could not measure') could be trimmed. Overall it remains clear and well-organized, not repetitive.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity and lack of an output schema, the description is thorough: it enumerates the data returned, explains preconditions and their handling, notes the look-back and lag, identifies excluded fields and provides the alternative, and specifies the required auth and permission check (tiktalk_account_status). Nothing an agent needs to call this tool correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameters (fields, endDate, startDate) with descriptions. The tool description adds some context — the 60-day cap (already in startDate description) and the lag — but does not introduce new meanings for the parameters themselves. Since the schema already does the heavy lifting, the baseline of 3 is appropriate; the description does not significantly enhance parameter understanding beyond what is already in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a precise statement of what the tool does: it returns the connected TikTok account's own analytics, listing specific data types (follower demographics by age, gender, country, city, daily series, lifetime counters). It also explicitly names its twins (instagram_insights and youtube_channel_report), clearly distinguishing it from sibling tools and indicating it is the TikTok counterpart.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage context: it is the TikTok twin of instagram_insights and youtube_channel_report, so it is the tool to use for TikTok analytics. It states preconditions for demographics (business account, 100+ followers) and notes that it reports which precondition is blocking, rather than returning empty data. It also directs users to tiktalk_account for bio/verified badge/profile link, and warns that the look-back is capped at 60 days (shorter than brand-mentions tools), giving clear when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tiktok_account_statusA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes well beyond that: it discloses the two-grant system, the 'third state' where ads are connected but account is not, the scope-binding behavior (scopes are bound at authorize time and never retroactively), and the fact that connecting requires a browser and the reply carries the URL. This is rich behavioral context that helps the agent understand exactly what the tool does and what to expect. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, dense paragraph. It is front-loaded with the core purpose and then explains the two-grant distinction, the third state, scope behavior, and the connection URL. Every sentence carries meaningful information, but it is verbose. The final sentence 'Read-only, free.' is redundant with the annotations, but not harmful. Overall, it is appropriately structured for the complexity but could be trimmed without losing key details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that the tool has no parameters and no output schema, the description carries the full burden of explaining behavior. It covers what is reported (state, business id, scopes, missing scopes), the logic behind possible disconnection (scope binding), the distinction from advertiser grant, and the browser requirement for connecting. Nothing an agent needs to call this tool correctly is missing, including the key caveat that a 'not connected' result is not an error.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema coverage is trivially 100%. The baseline for zero parameters is 4, and since there are no params to describe, the description does not need to add parameter-specific semantics. It does describe the return payload (state, business id, scopes, missing scopes) which is useful context, but that falls under output rather than parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Report whether this brand holds the TikTok ACCOUNT-HOLDER authorization'. It clearly distinguishes this from the ADVERTISER grant, explicitly naming `tiktok_ads` as the other tool. This makes the purpose unmistakable and sets it apart from siblings like tiktok_account or tiktok_creator_info.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains when to use this tool: it covers the ACCOUNT-HOLDER authorization, not the ADVERTISER one, and clarifies that a workspace can be fully connected for ads yet answer 'not connected' here. This is an implicit usage guideline. It does not explicitly list alternatives for every scenario, but the distinction from tiktok_ads is clear, and it notes that browser-based connecting generates a URL — a hint for when this tool is called to aid the connection flow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• x_mentionsA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already cover readOnlyHint, openWorldHint, and destructiveHint, so the description doesn't need to restate those. It adds meaningful behavior: costs credits per mention returned, orders newest first, and requires an X connection. These traits are not derivable from annotations and inform the agent about side effects (billing) and execution context. It could mention pagination or error behavior, but those are less critical for a read operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, each contributing distinct information: purpose, use cases, cost/billing warning, and prerequisite. It is front-loaded with the core function and avoids redundancy. While slightly dense, it remains efficient and every sentence earns its place. Slightly more structure could split use cases from cost advice, but overall it is concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with full schema coverage and annotations, the description provides all needed context: exact purpose, use cases, ordering, cost implications, prerequisite, and a pointer to the follow-up reply tool. Since there is no output schema, the description doesn't need to explain return format. An agent can correctly invoke this tool and make informed decisions about pagination and cost, making it complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all 3 parameters with full descriptions (sinceId, maxResults, paginationToken), so the baseline is 3. The description adds cost semantics directly tied to maxResults, warning that every mention is billed and advising to keep it small. It also reaffirms the default of 10, which the schema states. This extra context about billing and page size adds value beyond the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb 'Read' and resource 'posts mentioning the connected X account', and goes further to specify the content ('who is talking to the brand, in their own words, newest first'). It distinguishes the tool from siblings by describing a unique function (reading mentions) not covered by other X tools like list_x_dms or x_post_metrics. The purpose is unambiguous and specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit use cases: 'find what deserves a reply' and 'mine real objections and customer language for ad copy'. It also gives a follow-up action (reply with post_to_x + replyToId), cost-control advice (keeping maxResults small), and a prerequisite ('Needs X connected'). This gives clear when-to-use guidance and even suggests alternatives for the next step, making it easy for an agent to decide when to invoke this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• x_post_insightsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, destructiveHint), the description adds critical behavioral context: it incurs credit costs per post read, requires the X connector to be connected, supports batches of up to 25 ids, and specifically interprets empty responses as missing data rather than zero performance. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-structured, front-loading the core purpose and then progressively covering alternatives, limits, costs, and data interpretation. Every sentence carries value (differentiation, batching, cost, missing-data handling, requirement), though it is slightly long; still, it avoids fluff and remains efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only analytics tool with no output schema, the description provides complete context: it lists expected metrics (what will be returned), clarifies the difference from public metrics, defines call limits, cost implications, connection requirement, and how to handle missing data. An agent has everything needed to invoke and interpret the result correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters (ids explained as numeric post ids with max 25, granularity as enum with default), so the baseline is 3. The description does not add further parameter-level semantics beyond restating the 25-id limit, which is already in the schema. No added value for parameter meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides 'Advertiser-grade analytics' for the connected account's own X posts, listing specific metrics (impressions, engagements, link clicks, profile visits, video views, video completion quartiles). It distinguishes itself from the sibling x_post_metrics by explicitly noting that public metrics lack clicks and video retention, making the tool's specific value obvious to an agent.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells when to use this tool over x_post_metrics (for clicks and video retention), and provides operational guidance: it warns about credit costs per post read, limits to 25 ids per call, and instructs how to handle missing data ('If X returns no rows, say so — that is missing data, not zero performance'). This fully equips an agent to decide and call correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• answer_google_business_questionA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds significant behavioral context beyond the annotations: it explains the upsert semantics (one answer per account, replacement behavior), that deletion is public and immediate, and that it is confirm-gated. It also states the connection/approval prerequisites. This aligns with annotations (idempotentHint, destructiveHint) without contradiction and provides valuable operational details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise but information-dense, spanning only two sentences. It front-loads the primary action and then packs important caveats (upsert, delete confirmation, prerequisites) without fluff. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description provides all necessary context for an agent to invoke it correctly: the action, the replacement behavior, delete confirmation requirement, and preconditions. The source of questionId is in the schema, so the description doesn't need to repeat it. The tool is fully specified for correct use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers most parameters (text, delete, confirm, questionId). The description adds meaning around these by explaining the upsert behavior (relating text to replacement) and the confirm-gated deletion, which goes beyond what the schema states. With 60% schema coverage, the description partially compensates by clarifying the interaction between text and delete, though it doesn't detail every param's format.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (post or delete an answer) and the specific resource (public question on a Google Business Profile listing). It distinguishes from siblings like post_to_google_business (which posts new content) and reply_to_google_business_review (replies to reviews) by focusing on questions. The purpose is unambiguous and specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool (to answer a question or delete an answer) and provides critical usage constraints: the upsert behavior (answering again replaces), the confirm requirement for delete, and preconditions (Google Business Profile connected and project approved). It does not explicitly name alternative tools or say when NOT to use this, but the context is clear enough from the purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_post_metricsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds significant value by disclosing that missing posts are reported as MISSING (not zero), that no impression counts exist and therefore no engagement rate can be computed, and that it costs 0 credits. These are behavioral details an agent needs to interpret results correctly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and every sentence adds unique information: what it reads, how to address posts, the impression caveat, the MISSING behavior, and the read-only/credits note. It is logically ordered and front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only metrics tool with one parameter and no output schema specified, the description covers all essential usage aspects: what metrics are returned, how to identify posts, edge-case handling for missing URIs, and prerequisites. An agent has everything needed to call it correctly and interpret results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the parameter 'uris' is described in the schema as AT-URIs at most 25. The description adds extra meaning by specifying that these are the `at://…` values returned by post_to_bluesky, not web URLs, and confirms the 25 limit. This goes beyond the schema's basic description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Read') and resource ('live engagement for up to 25 of the connected account’s Bluesky posts') and lists exact metrics (likes, reposts, replies, quotes, bookmarks). It is immediately distinguishable from sibling tools like list_bluesky_posts (which lists posts) and post_to_bluesky (which creates posts).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly explains how to invoke the tool (address posts by AT-URI, not web URL) and sets expectations about what is returned (counts without impressions). It also notes the prerequisite 'Needs Bluesky connected.' It does not explicitly compare to alternative metrics tools, but the domain is clear enough that an agent can infer when this is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• buy_creditsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description fully discloses the financial action (charges saved card), prerequisites (billing-admin rights, saved card), and the multi-step flow. It also mentions the checkout URL for first purchases and that cards are saved afterward, going well beyond the minimal annotation context (readOnlyHint=false) to explain the state-changing behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but efficiently organized: it fronts the core purpose, then walks through the simple and complex flows, and finally handles exclusions and alternatives. Each sentence adds meaningful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description accounts for the main outputs: list format for packs, the quote returning a quote_token, and the checkout URL. It could explicitly state the quote response structure, but the implication is clear enough for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the sequencing and conditions relevant to each parameter (e.g., omitting pack lists packs, confirm:true required for charge, quote_token binds the quote), going beyond the individual schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb (buy) and resource (credit packs), clearly stating the tool's function of topping up credits. It distinguishes itself from siblings like set_auto_reload and billing_status by focusing on one-time purchases and explicitly ruling out subscription management.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance (out of credits), when-not (subscriptions), and names the alternative set_auto_reload for continuous top-ups. It also explains the two-step quote/confirm flow and the no-saved-card path, leaving no ambiguity about the appropriate use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cancel_scheduledA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds the queued-state precondition and the alternative for published posts, which is useful beyond annotations. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three dense sentences with zero waste. The action is front-loaded, followed by source, precondition, and alternative—each sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter tool with no output schema and annotations covering destructive/idempotent behavior, the description provides everything an agent needs: what, when, where to get the id, and what to do if it's too late. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (the 'id' description already says 'the scheduled post id from list_scheduled'). The description reinforces the exact source of the id, adding practical retrieval guidance beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb ('Remove') and resource ('a queued post') with a clear boundary condition ('before it goes out'). It distinguishes itself from list_scheduled and manage_meta_post, making it unambiguous among siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly instructs where to get the id ('Get the id from list_scheduled'), states the valid condition ('while it is still queued'), and names the alternative for published posts ('use manage_meta_post'). This fully routes the agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• comment_on_meta_postA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds critical context: the comment is PUBLIC and posted as the brand, the user must approve the exact wording first, and the tool refuses Instagram media ids by name. It also explains the rationale behind the tactic (reach suppression), giving the agent a deeper understanding of the tool's 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences long but packs in the core action, the tactical rationale, public visibility, a user-approval requirement, the source of postId, the Facebook-only restriction, and even the cost ('Free'). It front-loads the action and avoids any filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no output schema, the description covers all necessary operational context: which posts are eligible, how the comment is posted (publicly as the brand), that user confirmation is needed, where the postId comes from, and why Instagram is not supported. Nothing essential for an agent to invoke it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers all parameters with clear descriptions (100% coverage), so the baseline is 3. The description adds one useful pointer – postId comes from list_meta_posts – but does not extend meaning beyond that for message or attachmentUrl, and no parameter is left ambiguous by schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Leave'), a specific resource ('the brand’s own Facebook Page posts'), and clarifies it is a NEW top-level comment, distinguishing it from replies (reply_to_meta_comment) and post creation (post_to_meta). It also explicitly notes it is for the brand's own posts, eliminating ambiguity about which posts are eligible.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear when-to-use guidance: the 'link in the first comment' tactic, adding a pinned clarification, offer code, or correction. It explicitly excludes Instagram ('FACEBOOK ONLY') and names the correct alternative for Instagram replies (reply_to_meta_comment), so an agent knows exactly when to select this tool versus its siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• convert_onedrive_fileA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavior: conversion happens on Microsoft's servers (no local re-encoding), no data is lost, output is stored at a durable Hermoso URL, and the Microsoft-provided link expires in minutes. This goes beyond annotations and covers essential operational details without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but each sentence serves a purpose: it explains the mechanism, enumerates supported formats, gives examples, states a hard constraint (JPG dimensions), and describes output and permissions. It is front-loaded with the core function, and while detailed, it avoids fluff. Slightly overlong for a 4-5, but very efficient for the complexity it covers.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description does a good job describing what the tool produces (a durable URL) and how to use the result ('pass straight to a render or a post'). It covers prerequisites, output behavior, and a key pitfall (expiring link). It omits explicit response structure (e.g., whether it returns just the URL or an object), but the guidance is sufficient for an agent to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 explaining that JPG conversion requires both width and height because Microsoft refuses the call without them, and it clarifies that fileId comes from list_onedrive_files. This exceeds the schema by providing rationale and origin context, justifying a score above baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb (convert), a clear resource (OneDrive file), and output formats (PDF or JPG). It also distinguishes itself from siblings by highlighting the broad input format support (e.g., PSD, AI, raw camera formats) that other tools in the product cannot open. This makes the tool's purpose unmistakable and separate from read/get/list tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit use cases ('turn a client's deck into images', 'get a usable JPG out of a designer's PSD', 'hand someone a PDF of a spreadsheet') and a critical warning about avoiding the expiring Microsoft link. It also notes the prerequisite of OneDrive being connected. This clearly guides when and why to use the tool, and even hints at the source for the fileId (list_onedrive_files).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_drive_folderA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate mutation (readOnlyHint=false). Description adds valuable behavioral context: return value (folder id + webViewLink) and the distinction between the returned ID and the NAME used by save_to_drive. While it doesn't cover error handling or permissions, it goes beyond annotations without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each adding distinct value: purpose, return value, and usage warnings. No fluff; information is front-loaded and logically ordered. The critical save_to_drive clarification is placed at the end, which is acceptable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with full schema coverage and relevant annotations, the description covers purpose, return value, usage pattern, and potential confusion with sibling tools. Nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema already documents both parameters (100% coverage). Description adds meaning by explaining parentId's role ('parent folder id for a nested folder, default: Drive root') and clarifies the id/name distinction for name usage. This enriches the schema's baseline descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states a specific verb ('Create') and resource ('folder in the user’s Google Drive') with optional nesting under parentId, clearly distinguishing it from siblings like save_to_drive and update_drive_file. The purpose is immediately clear without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: 'Use that ID as update_drive_file’s moveToFolderId or as parentId for a nested folder.' Also warns about save_to_drive's folder being a NAME not an id, and advises passing the NAME there or omitting it. This fully routes the agent to correct alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_meta_catalogA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) by disclosing numerous behavioral traits: it refuses ambiguous or unknown portfolio names by listing real portfolios, never guesses, will not let vertical or owning portfolio be changed later, and Meta silently allows duplicate names — prompting Hermoso to preemptively refuse duplicates and report the existing id. It also explains that the confirmation is read back from Meta (only an id returned) and that the tool is free. These are critical non-obvious behaviors that an agent must know to use the tool correctly, and the description provides them all.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is relatively long but every sentence carries essential information—no filler. It is logically structured: starts with the purpose, then covers portfolio identification (with exact matching rules), then the permanence of vertical/portfolio, then the critical duplicate-name nuance, then response confirmation, and finally cost. The use of 'IMPORTANT' highlights the most critical warning. While it could be tightened, the density is justified for the complexity of the tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 5 parameters, one enum, and nuanced external behavior, the description is remarkably complete. It covers the full workflow, edge cases (ambiguous/unknown names, duplicate names), permanence constraints, the response format (read back from Meta with only an id), and the credit cost. There is no output schema, but the description adequately explains what the confirmation is. Nothing an agent needs to invoke this tool correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema. It clarifies that businessId and businessName are alternative ways to specify the owning portfolio and explains how names are resolved (exactly as printed by list_meta_catalogs, refused if ambiguous). It emphasizes that vertical defaults to commerce and is permanent, and explains the purpose and default of allowDuplicateName. This goes well beyond the schema descriptions, which are terse; the description effectively teaches the agent how to use each parameter correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it creates a NEW product catalog on a Meta business portfolio, with a specific verb and resource. It explicitly positions it as the first step in Advantage+ catalog ads ('build it first, then fill it... then point a campaign at it'), which distinguishes it from sibling tools like list_meta_catalogs, update_meta_catalog, and delete_meta_catalog. The purpose is unambiguous and includes context on how it fits into a workflow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on when to use the tool (create a catalog before filling it with products) and references list_meta_catalogs for obtaining portfolio identifiers, implicitly distinguishing itself from that read-only tool. However, it does not explicitly contrast with update_meta_catalog or delete_meta_catalog, nor does it state 'use this instead of X when...' — though the distinction is obvious given the create/update/delete split. The detailed guidance on naming portfolios and duplicate handling effectively covers the 'when' and 'how' but lacks an explicit 'when not to use' alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_pinterest_boardA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a mutating operation (readOnlyHint false), and the description adds behavioral context about the privacy setting: boards are PUBLIC unless SECRET, and a Pin on a secret board is invisible to everyone. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences: purpose, usage trigger, and parameter guidance. Each sentence carries necessary information without fluff, and the key condition (empty board list) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with three parameters and no output schema, the description covers the purpose, when to use it (with an alternative), and the critical privacy behavior. Nothing essential is missing for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters, so baseline is 3. The description adds extra meaning for the privacy parameter by explaining the implications of SECRET (invisibility) and advising to only use it if the user asks. This exceeds the schema's description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the tool creates a board on the connected Pinterest account, with a specific verb and resource. It also distinguishes from siblings by noting that a Pin cannot exist without a board and referencing list_pinterest_boards as the alternative to check.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly tells when to use this tool: if list_pinterest_boards comes back empty, and not to tell the user you can't pin. It also warns about the SECRET privacy option and only to choose it if the user explicitly asks, providing clear when-not conditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_drive_fileA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint=true, but the description adds critical behavioral nuance: default goes to Trash (recoverable), permanent is irreversible, and confirmation with the user is required. This goes well beyond annotations by explaining the recovery path and the need for explicit user consent, covering the key behavioral aspect of the tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the core action, then details irreversible behavior and usage steps. Every sentence adds value without redundancy. It is efficient and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a delete tool with no output schema, the description is complete: it explains what happens by default, how to make it permanent, which parameters to pass, and the safety caution. It covers all essential information an agent needs to call this tool correctly, even among many similar delete tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 instructing to pass fileId from list_drive_files and emphasizing confirm:true, which clarifies that confirm is effectively required even though the schema's required array only lists fileId. This bridges a gap between schema and actual usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Delete a Drive file.' It specifies the resource and the verb, and distinguishes from siblings like update_drive_file, get_drive_file, and list_drive_files. It also adds nuance about trash vs permanent deletion, making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives practical usage hints: 'Pass fileId (from list_drive_files) + confirm:true' and explains the permanent option. It implicitly signals when to use this tool (when deleting a Drive file), though it doesn't explicitly contrast with alternatives. The context is clear and actionable, but lacks an explicit 'when not to use' statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• edit_reddit_postA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnly=false, destructiveHint=false), the description discloses that the result is read back from Reddit and that an unapplied edit is reported as NOT confirmed, plus the 0-credit cost. It details the three Reddit restrictions ('must not offer them') and the consequences of the alternative (losing score/age/thread). This adds substantial behavioral context the annotations do not cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  While lengthy, every sentence carries critical information. The description front-loads the core purpose, then uses numbered lists for the three prohibitions, explicit remedies, and behavioral expectations. It is well-structured with bolding and formatting that aids scanning. Despite its length, it earns its place with zero filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (Reddit's API constraints) and the lack of an output schema, the description fully equips the agent: it covers context, limitations, remedies, behavioral confirmation, cost, and prerequisites. No critical information is missing for correct invocation and expectation setting.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% — both parameters (postId and text) have descriptive text including accepted formats and replacement semantics. The description adds context like the frozen title and body-only scope, but these are not parameter-specific. Since the schema already explains the parameters thoroughly, the description adds marginal value beyond the schema, matching the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as 'Rewrite the BODY of one of the connected account’s Reddit TEXT posts' and gives concrete use cases (fix a dead link, wrong price, correction). It distinguishes from siblings like delete_reddit_post and post_to_reddit by explicitly stating scope. The purpose is unmistakable and actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance (fixes and corrections) and enumerates three forbidden scenarios where editing is impossible, directing the agent to the only remedy (delete and resubmit) with a clear instruction to say so. It also states the prerequisite 'Needs Reddit connected' and cost. This is exemplary contextual routing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• generate_imageA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  All four annotation hints are false, so the description carries the full disclosure burden and meets it. It discloses that the tool spends credits, that saved-brand hydration can silently swap the engine to the compositing model, that raw:true sends the prompt byte-identical with no rewriting/guidance/negative-prompt, and that delivery and validation are unchanged. This is deep, honest behavioral disclosure far 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Front-loaded with the core purpose and output, and every sentence carries distinct value (engine behavior, multi-brand caution, raw semantics, cost, timing). It is slightly dense and run-on in the engine/multi-brand passages, but contains zero filler, so it earns a high score despite the parsing effort.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 7 parameters, subtle mode interactions, cost implications, and no output schema, the description is remarkably complete. It covers the deliverable (served URL), engine-selection behavior, brand hydration caution, raw mode, cost (credits), durability, and the capabilities catalog for model ids. An agent has everything needed to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds genuine cross-parameter semantics the schema cannot express alone: the interaction between refImages, useBrand, model, and raw (e.g., 'a model you named is only honoured when no references ride — pass raw:true (or useBrand:false)'). It also clarifies that model is 'a catalog id from hermoso_capabilities (omit for the default),' connecting to a sibling capability tool. This is additive meaning, not duplication.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening sentence states a specific verb, resource, and output: 'Render a finished ad IMAGE and return its served URL.' This clearly distinguishes generate_image from video/voice/text siblings (generate_video, generate_voice, generate_text) and names the core deliverable. It also lays out distinct modes (compositing vs raw) that define the tool's scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides rich, actionable usage context: when to pass refImages for product-accurate compositing, the explicit MULTI-BRAND CAUTION instructing to pass the fresh brand's productImages and set useBrand:false, and when to use raw:true to guarantee the named model renders. Lacks only an explicit routing against sibling image tools like render_ad or make_template_ad, which keeps it a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• generate_videoA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  All annotations are false (no readOnly/idempotent/destructive hints), so the description carries the full burden — and it carries it exceptionally. It discloses billing charges ('AUDIO IS NOT FREE... the bed can cost as much as the clip', 'Spends credits'), prompt rewriting by default with raw:true as the byte-identical escape, refusal over truncation ('a longer ask is REFUSED with nothing rendered and nothing charged'), silent resolution downgrades ('rendered at that model's best available tier instead, with nothing in the reply saying so'), and 1–3 min latency. This is far 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence earns its place given the tool's genuine complexity (12 params, billing, raw access, edit mode, routing) — nothing is filler. However, it is a single dense wall of text (~350+ words) with heavy ALL-CAPS emphasis, dashes and parentheticals that hurt scannability. Substantial but poorly structured for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 12-parameter tool with zero annotations and no output schema, the description is essentially complete. It covers the return value (served mp4 URL), the single-clip duration ceiling with refusal behavior, the audio billing trap, credit spend, the raw bypass, edit-mode semantics, and model-routing pitfalls. Nothing an agent needs to call this tool correctly and avoid hidden costs is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema's own per-parameter descriptions are unusually rich (durationSeconds, musicMood, resolution, raw are all deeply explained), so the baseline is 3. The description adds cross-parameter value by connecting the dots: it ties durationSeconds to model choice and the narrower auto-pool, links audio to musicMood and the automatic charge, and explains how refVideo nullifies aspectRatio/durationSeconds — synthesis the schema alone doesn't provide. The description complements rather than repeats the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Opening sentence states a specific verb and resource: 'Render a RAW video clip from your own prompt and return its served mp4 URL.' It further differentiates from render_ad ('use this for raw/experimental clips or precise manual control') and names the sibling it is not (render_ad runs the Studio quality pipeline). An agent can cleanly separate the two tools without inspecting either schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit routing guidance: 'For finished brand ADS prefer render_ad... use this for raw/experimental clips or precise manual control.' It also gives concrete when-to conditions for editing (refVideo), for raw access (raw:true when you want the model itself rather than Hermoso's craft), and for naming a model (when you need the longest/highest-resolution tiers). The description explains not just what but when, with named alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_business_locationA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds substantial behavioral context beyond annotations: it explains the listing is AS THE MERCHANT LAST SET IT, which can differ from Google Maps due to public/Google suggestions, and notes it's read-only with 0 credits and requires a connection. This is valuable and consistent 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: it lists contents, explains the critical merchant-set vs Maps nuance, gives usage guidance, and notes prerequisites. No sentence is redundant; it's informative without being bloated, and key contrasts are front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given it's a read-only tool with one optional parameter and no output schema, the description is complete: it enumerates possible return fields, explains the data source and its relationship to update_business_location, and states the connection requirement. An agent would know exactly what it returns and when to call it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter locationId is fully described in the input schema (coverage 100%), including an example and when it's needed. The description adds no additional parameter semantics beyond the schema, so the baseline 3 per the rubric is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it reads a Google Business Profile listing and enumerates the exact fields returned (name, address, phone, hours, etc.). It uses a specific verb ('Read') and resource, and differentiates itself from update_business_location by noting it reads the merchant-set state, which is what update edits.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: 'Call it before offering to change anything, and to answer “what does our Google listing actually say?”'. Directly references the sibling update_business_location as the tool for edits, and mentions the prerequisite of connecting Google Business Profile. This gives clear context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_jobA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, destructiveHint), the description adds crucial behavioral context: expected render duration (1–3 minutes), the polling loop, and the finality of the 'not_found' status including the cost implication of re-firing. This is operational nuance not covered by annotations and directly informs agent behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: it opens with the core action and return values, then provides timing and termination guidance. Every sentence earns its place, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (single parameter, no output schema), the description covers all necessary information: statuses, progress, URL on completion, polling expectations, and the not_found edge case. An agent can call this tool correctly without additional information.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a description for the id parameter ('the job id, e.g. job_xxx'). The tool description refers to the id but adds no additional semantic detail beyond confirming it targets a render job. Since the schema already captures the parameter meaning, the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Poll a render job by id' and lists what it returns (status, progress, served media URL). This uses a specific verb (poll) and resource (render job), and distinguishes it from other get_* tools that retrieve different resources (e.g., get_brand, get_drive_file).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance: poll repeatedly until done/error without asking the user, and warns that a 'not_found' status is final and must not be re-fired to avoid double-charging. It also sets expectations about call frequency ('several calls is normal') and identifies when polling is no longer appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• hermoso_capabilitiesA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds further behavioral context: it is 'free' (costs no credits) and clarifies that the rendering tools route to server defaults when `model` is omitted. This goes beyond the annotation-derived safety and helps the agent plan resource usage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences pack all essential information without redundancy: what it does, when to call it, and a clarifying non-prerequisite statement. The key purpose is front-loaded, and every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, read-only probe, the description is fully sufficient. It enumerates the exact types of data returned, states that it is free, and clarifies that it is not needed before rendering. Together with the annotations, an agent has everything required to decide whether and when to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema trivially covers 100% and there is nothing to explain. The baseline for 0 parameters is 4, and the description does not need to add parameter documentation; it instead focuses on the output contents, which is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a strong verb-object pair ('Probe what this Hermoso account can do') and enumerates exactly what is returned: model ids, credit costs, aspect ratios, durations, recipe ids, and flags. It distinguishes itself from rendering tools by explicitly stating it is not a prerequisite, so an agent can tell it apart from generate_image, generate_video, and render_ad without opening their schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance ('Call it when you need a specific model id, an exact cost, or a capability you are not sure of') and also states when it is NOT needed ('It is NOT a prerequisite for rendering'), naming the sibling tools that run without it. No ambiguity remains.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_brandsA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat that. It adds valuable behavioral context: it lists current active brand, shared brands, and warns about a common misreading of empty brands. It also notes 'free' (cost trait). This exceeds the baseline but isn't exhaustive about return format or error handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured paragraph that front-loads the core purpose, then usage guidance, then troubleshooting. Every sentence earns its place—no fluff. Capitalization of 'PLUS' and 'SAME' adds emphasis without excess. It is concise despite covering multiple scenarios.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description adequately explains what the tool returns (id+name, active brand, shared brands) and how to use it with use_brand. It includes a troubleshooting tip that addresses a common misinterpretation. For a zero-parameter list tool, this is complete; nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description compensates by indicating what the output contains (id, name, active brand, shared brands), which is helpful even though there is no input schema to document. Since there are no params to explain, this is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it lists every brand on the account with id and name, the currently active brand, and shared team workspaces. It explicitly differentiates from the sibling use_brand by instructing to call this first, and mentions troubleshooting for misinterpreted empty brands. The verb+resource is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit when-to-use guidance: 'Multi-brand accounts: call this, then use_brand to switch' and 'If a brand looks empty... call this first.' This tells the agent exactly when this tool is appropriate versus alternatives, and even explains how shared workspaces are handled. No ambiguity remains.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_creatorsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds behavioral context: it's 'FREE', explains the return fields (name, portrait URL, consent status, pose plates, voice), and notes empty-result behavior. It also reveals cost implications of casting vs. not casting. The description fully overloads the annotation safety profile with practical details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence earns its place: it front-loads the purpose, then packs essential routing and cost information in a logical flow. There's no filler or redundancy; each clause serves a distinct decision an agent must make.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description compensates by detailing the exact fields returned. It also covers edge cases (empty roster), downstream usage across sibling tools, and cost/continuity rationales. For a simple list tool with one optional param, this is comprehensive beyond expectations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter (limit) is already fully documented in the schema with 100% coverage; the description adds nothing extra about it. Since the schema is self-sufficient, the baseline of 3 is appropriate—the description doesn't need to repeat what's structured.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the action (list) and resource (saved creators in the workspace), and defines what a 'creator' is (AI creators, social pulls, consented photos). It clearly distinguishes itself from siblings by naming downstream tools (render_ad, generate_avatar, etc.) and the alternative save_creator. The scope and purpose are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance: 'CALL THIS BEFORE OFFERING TO GENERATE A NEW PERSON' and explains the trade-off (continuity vs. cost). It also names alternatives for the empty case (generate_avatar / save_creator) and instructs not to invent a roster. This is direct, actionable routing advice.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_meta_catalogsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already supply readOnlyHint=true and destructiveHint=false, and the description reinforces them with 'Read-only, 0 credits' rather than contradicting them. It adds rich behavioral context beyond the annotations: the empty-list-is-not-the-merchant interpretation, that unreadable portfolios are reported rather than dropped, and that catalog visibility depends on portfolio admin status. 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The core purpose is front-loaded and the critical interpretation caveats earn their place, but the description carries several sentences of marketing explanation about how Advantage+ catalog ads work ('one campaign that shows each person the products they are most likely to buy...'). This is beyond what an agent needs to call the tool correctly. It is comprehensive but over-specified.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description carries the full burden of describing return values, and it does: id, name, product count, owning portfolio with numeric ID, the portfolios array, the note field, and the unreadable case. It also covers the key failure-mode interpretation (empty list means admin gap, not absent catalog). Nothing an agent needs to invoke and interpret this tool is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has 0 parameters, so per the rubric the baseline is 4; there is nothing additional to document. The description instead clarifies what the response will contain (portfolios array, note, unreadable flag), which is appropriate semantics for a parameterless listing tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb+resource and its exact return shape ('The PRODUCT CATALOGS this Meta login can advertise from — id, name, how many products each holds, and which business portfolio owns it'). It also disambiguates against several siblings by name: it is the source of businessId for create_meta_catalog and is distinct from list_meta_product_sets and list_meta_catalog_products. An agent could pick this tool correctly without opening any schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit workflow guidance: 'START HERE for any "advertise my products" ask, then list_meta_product_sets to pick what to advertise.' It also names the chaining partner (create_meta_catalog) that consumes this tool's businessId output, and explains why this entry point is the right one versus going to Business Manager. The when-to-use is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_meta_partnership_creatorsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description is exceptionally transparent: it discloses read-only behavior and zero credit cost (consistent with annotations), the non-removal of revoked rows, the verbatim status wording from Meta, the enumeration/check asymmetry, and how failed reads are reported. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long, but every sentence serves a purpose, and the key details (two lists, the mistake, status wording) are front-loaded. It could be slightly tightened, but the structure is logical and the verbosity is justified by the complexity of Meta's behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers all essential aspects: the two lists, how to query each, failure semantics, Meta's API limitations, credit cost, and error handling. An agent has everything needed to invoke the tool correctly and interpret results, even without an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Even though the schema already documents all three parameters at 100% coverage, the description adds crucial meaning to each: pageId's optionality, creatorIds' necessity for tag-approval checking, and creatorUsername's scope—plus the numeric-vs-handle distinction and automatic checking. This goes far beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the specific resource — the brand's Partnership Ads creators — and clearly defines the two distinct lists (ad-permission and tag-approval). It differentiates from related tools like manage_meta_partnership_creator, so an agent can immediately know what this tool enumerates without confusion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit usage context, such as when to check specific creators, the difference between the two lists, and the common pitfall of assuming one list implies the other. It does not explicitly name alternative tools but the instructions are clear enough for an agent to decide when to invoke this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_meta_postsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds further behavioral specifics: it is read-only and uses 0 credits, only reads a Page the brand has connected, excludes Stories (Meta's media edge does not return them), and hides unpublished drafts unless requested. No contradiction exists; the description enriches the annotation-provided safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is relatively long but information-dense. It front-loads the core purpose, then justifies importance, then provides usage scenarios, then parameter specifics. Every sentence contributes value; however, it could be slightly tightened without losing meaning. The structure is logical and the most critical information appears early.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the returned fields (id, caption, permalink, publish date, format), the critical role of postId, platform-specific caveats (Stories, drafts), and the credit cost. There is no output schema, so the description compensates by outlining return data and edge cases. It could detail pagination behavior or response format further, but overall it is complete enough 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.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are already documented, giving a baseline of 3. The description adds meaning beyond the schema for 'target' (explaining IG behavior and Stories exclusion) and 'includeUnpublished' (explaining that Facebook hides drafts unless asked). This goes a step beyond the schema, though it does not address 'limit' or 'cursor' specifically, which are well-covered already.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('List') and resource ('connected Facebook Page's or Instagram account's OWN existing posts'), enumerates returned fields (id, caption, permalink, publish date, format), and explicitly positions itself as the tool that provides postId for other Meta tools (meta_post_insights, list_meta_comments, manage_meta_post). This clearly distinguishes it from siblings like list_instagram_media or list_meta_comments without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  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: for 'how did our last few posts do', to find a post the user describes loosely, or before backfill_posts. It also gives specific parameter guidance (pass target:'instagram' for IG, and that Stories are excluded) and contrasts with post_to_meta as the only prior way to obtain a postId. This is clear, actionable, and includes exceptions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_pinterest_boardsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true and openWorldHint=true, but the description adds valuable behavioral context beyond that: it explicitly says 'Read-only, 0 credits' (cost disclosure) and 'Needs Pinterest connected' with a settings path. It also explains the interaction pattern (must let user pick) which is behavioral. No contradiction; the description complements the annotations well.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: it opens with the core function, then the critical workflow note, then cost and prerequisites. Every sentence carries useful information with no redundancy or fluff. It is structured logically from action → workflow → constraints.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with one optional parameter and no output schema, the description covers everything essential: what it returns (fields), when to use it (before posting), prerequisites (connection), and cost (0 credits). It even flags a non-obvious requirement (user must pick). No significant information gap remains.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — the schema already documents the 'privacy' parameter with its enum and meaning. The tool description does not add any additional parameter semantics beyond what the schema provides. Since coverage is high, the baseline of 3 applies; no extra value is required.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'List the boards on the user’s connected Pinterest account' — a specific verb, resource, and scope. It enumerates the output fields (id, name, privacy, pin count), which differentiates it from sibling tools like create_pinterest_board or post_to_pinterest. The purpose is unambiguous and distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance: 'ALWAYS call this before post_to_pinterest and let the USER pick' — it specifies the prerequisite workflow and why (Pinterest requires a board, Hermoso never chooses). It also states the connection requirement (Settings ▸ Connectors ▸ Pinterest) and notes it's read-only with 0 credits. This is exactly the kind of when-to-use and why info an agent needs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• meta_catalog_blast_radiusA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: it is free, read-only, costs 0 credits, and avoids aiming the destructive call at the target to read its refusal. It also explains the rationale for existing, which adds value beyond the structured annotations. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is multi-sentence but every sentence earns its place: purpose, safety, rationale, and linkage to delete_meta_catalog. The critical call-to-action ('CALL THIS BEFORE PROPOSING A DELETE') is front-loaded. No filler; structured effectively.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description explains what the tool returns: number of products, product sets, the exact deletion-cost sentence, and the catalog's exact name needed by delete_meta_catalog. It also covers cost and read-only nature. For a preflight tool, this is fully complete—an agent knows exactly what to expect and how to use the result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage with a description 'numeric catalog id from list_meta_catalogs'. The tool description does not add further semantic detail about the parameter beyond what the schema already provides. The mention of the catalog name is a return value, not parameter semantics. Baseline 3 is appropriate given the high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Read what is INSIDE a product catalog'), the resource (product catalog), and the exact output (count of products, product sets, and the deletion-cost sentence). It clearly differentiates from siblings like delete_meta_catalog and list_meta_catalogs by being a read-only preflight tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly instructs to 'CALL THIS BEFORE PROPOSING A DELETE', explains the permanent nature of deletion (no archive, no undo), and notes that it provides the exact catalog name required by delete_meta_catalog. This gives clear when-to-use and why-to-use guidance, and implicitly when not to use (after deletion is proposed).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_to_xA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true, which are minimal. The description adds extensive behavioral detail: immediate public publication, mandatory user confirmation, length rules (280 vs 25,000 with Premium, never truncates), cost implications (credits per request, 13x for links, 24-hour ceiling), refusal-on-crossing, and the organic-only constraint. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy but front-loads the core purpose and the critical safety warning (show text, get explicit yes) early. Each subsequent sentence addresses a distinct concern (length, cost, organic/ads distinction). While not concise in word count, the complexity of the tool warrants it, and the structure is logical and efficient. A minor trimming of redundancy would make it a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 13 parameters, a nested poll object, and no output schema, the description covers prerequisites (X connected), failure modes (length refusals, batch ceiling, non-member community refusal), and behavioral constraints thoroughly. It does not describe the successful response shape (e.g., returning a post id), which could matter for follow-up promotion, but that is a minor gap given the overall completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with rich per-parameter descriptions (e.g., mediaUrls grid behavior, altText array alignment), so the baseline is 3. The description adds cross-parameter context above this: length limits apply to each thread part, cost per post in a thread, and the 13x link cost. It does not compensate for missing schema descriptions (none are missing) but adds meaningful supplementary guidance, justifying a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb (publish) and resource (user's connected X account), enumerates all modes (single post, media, reply, thread, poll), and distinguishes from non-posting X tools like edit_x_post and delete_x_post, as well as the ad campaign flow (create_x_ads_campaign). It is unambiguous and clearly differentiates from sibling posting tools for other platforms.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly names the alternative for ads: 'X ads are built with create_x_ads_campaign → create_x_ads_line_item → create_x_ads_promoted_tweet' and instructs to 'publish here first and promote that post.' It also clarifies the organic nature and prerequisites (X connected). This gives the agent clear when-to-use vs. when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• read_sheetA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context: the access prerequisite (user must have picked the file), the error behavior (file not found indicates user hasn't picked it), and the return type (2-D array). This goes beyond the annotations and helps the agent handle edge cases correctly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: it starts with the core action, explains access, then the parameter options, error handling, and return format. Every sentence adds value without redundancy. It is front-loaded with the most important information and avoids unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (3 params, no output schema), the description covers all necessary aspects: what it does, how to specify the target, error handling, and return type. It even provides a pointer to list_drive_files for finding the ID. There are no obvious gaps for an agent to invoke this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for all three parameters. The description adds meaning by clarifying that spreadsheetId and sheetUrl are alternatives and where each comes from, reinforcing the schema. It also explains the default range indirectly through the schema. The extra context about the relationship between parameters and the access model goes beyond the schema, so a score above baseline is warranted.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (read cells from a Google Sheet) and the scope (sheets Hermoso can reach, distinguishing from other sheet tools like append_to_sheet or update_sheet). It also explains the access model (created or user-picked) and provides the return format, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives practical usage guidance: how to obtain the spreadsheetId (via create_sheet or list_drive_files) and that you can alternatively pass a URL as sheetUrl. It also advises on error handling (if file not found, ask user to pick it rather than retrying). While it doesn't explicitly contrast with other read tools, it covers the when and how effectively.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• reply_to_reddit_commentA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations. It discloses that the reply publishes PUBLICLY and immediately, requires explicit user approval, and warns about brand reputation and potential subreddit bans. Annotations only indicate readOnlyHint=false and destructiveHint=false, so the description adds critical behavioral context (public visibility, approval requirement, consequences) that the agent must know. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence earns its place. It front-loads the core action, then immediately addresses the most critical safety requirement (approval), then adds brand-risk context, then clarifies parameters, then points to the sibling, and finishes with cost and prerequisites. The structure is logical and efficient, with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is complete for a mutation tool with public impact. It covers what the tool does, prerequisites (Reddit connected), the exact parameter format, how to obtain the correct parentId, the requirement for user approval, and the reputational consequences. There is no output schema, but the description fully equips an agent to call this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes both parameters with 100% coverage. The description adds meaningful clarification for parentId, emphasizing that it must be a FULLNAME (t3_/t1_) and pointing to list_reddit_comments as the source. This reinforces the schema but also provides sourcing guidance that an agent would not get from the schema alone. For text, it advises plain language and avoiding marketing copy, which is behavioral guidance rather than syntax.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: replying to Reddit comments or creating top-level comments. It explicitly distinguishes between replying to a post (t3_) and a comment (t1_), which sets it apart from sibling tools like post_to_reddit or edit_reddit_post. The verb 'Reply' and resource 'Reddit' are specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: it's for replies, requires showing the user exact wording and getting explicit approval, and needs the Reddit account connected. It also points to list_reddit_comments as the source for the correct parentId. It does not explicitly state when NOT to use it (e.g., use post_to_reddit for new posts), but the top-level vs. reply distinction implies this, and the approval requirement is a strong usage guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• save_playbookA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are minimal (readOnlyHint=false, destructiveHint=false, no idempotentHint), so the description carries load. It adds that the playbook lands in the same library the web app lists, runs and manages, and it notes 'Free.' at the end. It doesn't mention overwrite behavior or error cases, but it provides enough behavioral context beyond the empty annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four sentences, front-loaded with the core purpose and destination. The sibling distinctions and the 'Free.' note are concise and each sentence adds value. No redundant phrasing or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 7 params (some nested), no output schema, and sparse annotations, the description covers everything an agent needs: what to save, when to use it, how it differs from alternatives, where it lands, parameter semantics, and cost. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline 3. The description adds meaning beyond the schema: it explains hooks are 'opening hooks worth reusing, verbatim', plays are 'the concrete plays to run ({title, detail}) — the actionable half', and angles are 'persuasion angles'. It also clarifies formats with examples. This makes parameters more actionable without repeating schema text.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Save' and the resource 'PLAYBOOK', then explains what a playbook is and explicitly differentiates it from save_skill and the swipefile. It also names the landing library, so an agent can distinguish it from siblings without opening schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit when-to-use guidance: 'Use it to keep what a competitor_teardown or mine_angles just found, or to bank a creative you want to repeat.' It also names the alternatives (save_skill, swipefile) and describes where the data lands, which effectively covers when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_instagram_shopping_productsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already carry readOnlyHint=true and destructiveHint=false, and the description reinforces 'Read-only, 0 credits.' Beyond that, it discloses several nontrivial behaviors: it returns only a subset of the catalog (not all products), it handles unapproved review_status products by accepting but not showing them and flags them in the reply, and it explicitly states that an empty result does not mean the catalog is empty. These are valuable behavioral disclosures that aid agent decision-making and are not present in 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but every sentence carries weight. It front-loads the core purpose in the first clause, then uses uppercase emphasis for critical caveats (subset warning, review_status flagging). While somewhat verbose, the structure logically flows from purpose to usage to gotchas, and the use of ALL CAPS for key distinctions aids scanning. It is not a model of brevity, but it is well-organized and purposeful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, so the description carries the burden of explaining what the reply contains. It does mention that the reply flags unapproved products, covering a key behavioral aspect. It also covers the main usage patterns, the required catalogId source, and the edge case of empty results. It does not describe the exact output format (e.g., product_id fields), but given the complexity of the Instagram shopping domain and the presence of annotations, the description is sufficiently complete for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds semantic nuance beyond the schema: for `q` it states 'Omit it to list every tag-eligible product, which is a real ask rather than a missing argument,' clarifying the intent of omission. For `catalogId` it reiterates that Meta requires it and it comes from list_instagram_shopping_catalogs. These additions help the agent understand parameter usage beyond the raw schema descriptions, earning a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a precise statement of what the tool does: 'The products in one catalog that can actually be TAGGED on an Instagram post — this is where the product_id for a product tag comes from.' It clearly identifies the resource (products in a catalog), the verb (search/find), and explicitly contrasts with the broader catalog (list_meta_catalog_products) by noting this is a smaller set. This distinguishes it from siblings and leaves no ambiguity about its purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance: it tells the user to omit `q` to see all tag-eligible products and pass a name or SKU to narrow results. It also warns against misinterpreting an empty answer as evidence the catalog is empty, referencing the sibling list_meta_catalog_products and explaining that a product can be in the catalog yet not taggable. This directly routes the agent to the correct tool for tagging use cases and clarifies when not to infer absence.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_pinterest_ads_targetingA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds value beyond annotations: it states 'Read-only, 0 credits, no new permission (it uses ads:read, already granted)' which covers cost and permissions not in annotations. It also discloses behavioral traits: Pinterest accepts wrong IDs silently, the query filter is local, and interest tree traversal. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately long (about 100 words) but every sentence provides substantive value: purpose, usage, tree navigation, query caveat, and safety. It is front-loaded with the main purpose and then details. Slightly verbose but well-structured and not padded; earns a 4 rather than 5 due to some redundancy (e.g., re-emphasizing read-only, already in annotations).

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 5 parameters, an enum, and no output schema, the description covers most critical aspects: parameter usage, tree navigation, query semantics, and safety. However, it omits any guidance on adAccountId (which is likely required for scoping) and does not describe the response structure or pagination. These are gaps, but given the high schema coverage and the detailed narrative, it is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 80%, so the baseline is 3. The description adds significant semantics for targetingType (lists enum values and explains catalog selection) and interestId (tree drill-down behavior). It clarifies query's local filtering. However, it does not explain adAccountId, which has no schema description either, leaving a small gap. Overall, it compensates well for the uncovered parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the specific verb 'search' and the resource 'Pinterest ad targeting options', and explicitly defines its purpose: supplying IDs for an ad group's targetingSpec used by create_pinterest_ads_campaign and create_pinterest_ads_ad_group. It clearly distinguishes itself from those creation tools and explains why accurate IDs are critical. This fully differentiates it from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage context: 'this is where those values come from' and warns against guessing ('guessing one is the worst option available'). It explains when to use targetingType vs. interestId, how to narrow with query, and the tree-walking pattern. It also notes the query is a local filter (not Pinterest's), preventing misuse. This is comprehensive guidance for when and how to use the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_tiktokA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior beyond that: credit spend ('Spends about a credit'), output format (compact JSON with specific fields), ranking by plays, and the notice that there is no ad library. This is genuinely additive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences: the first establishes what it does, the second details the return format, and the third names the alternative and cost. Every sentence earns its place, the content is front-loaded with the core purpose, and there is zero fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with two simple parameters and no output schema, the description covers the essentials: purpose, output structure, ranking, credit cost, and the alternative for open-ended research. Nothing an agent needs to invoke it correctly is missing, and the annotations already handle safety.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% — both query and limit are fully described in the schema. The description does not add any parameter-specific meaning (e.g., no elaboration on query syntax or limit behavior) beyond what the schema provides. Baseline 3 is appropriate since the schema carries the load.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Organic TikTok keyword search' — a specific verb and resource — and immediately clarifies it's organic (not an ad library). It states the use case (mine hooks/trends/remixable creative) and names the sibling tool it is not. This is fully differentiated from other search tools like search_instagram or search_youtube.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says 'Use research_ads for open-ended research', giving a clear alternative and the condition that selects it. The description also implies this is for keyword-driven, top-performing content, which sets expectations for when to invoke this tool versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• send_whatsapp_broadcastA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the annotations. It discloses the queued-job behavior, the lack of a bulk endpoint (paced fan-out), the partial-failure reporting, duplicate removal, refusal of invalid numbers, the US non-delivery issue with error 131049, billing model, opt-in requirements, and the confirm-gating flow. These are all critical behavioral details that annotations (readOnlyHint:false, openWorldHint:true) do not capture. No contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but densely packed with essential information, and critical warnings are emphasized with caps and exclamation marks. It front-loads the primary purpose and then systematically covers constraints, billing, policy, and operational flow. While every sentence adds value, the sheer length may be overwhelming, and some redundancy (e.g., 'ACCEPTED IS NOT DELIVERED' repeated twice) could be trimmed. Still, the structure is logical and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 11 parameters and no output schema, the description covers the entire workflow: how to run a dry run, how to confirm, what happens with duplicates, invalid numbers, per-recipient variables, billing, US restrictions, and how to read results via jobId. It even explains the partial-failure reporting and the 24-hour messaging limit. Nothing an agent needs to operate the tool correctly is left unexplained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds significant meaning to several parameters: it clarifies that `recipients` can be phone numbers or objects with per-recipient components, explains `skipInvalid` behavior ('refused by name unless skipInvalid is true'), describes `confirmCount` as echoing the distinct-recipient count, and emphasizes `dryRun` as a cost-free pre-flight. It also explains the interplay between `jobId` read-mode and sending mode, and why `template` must be approved. This enriches every parameter's semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a precise, specific statement — 'Send ONE approved WhatsApp template to MANY recipients' — naming the verb, the resource, and the scope. It draws a clear line against free-form text and single-recipient uses, and the contrast with send_whatsapp_message is implicit but evident from the 'many recipients' framing. The purpose is unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives strong context on when to use this tool — when broadcasting a template to many people, with a note that free-form text is only allowed in the 24-hour service window. It also advises running `dryRun:true` first and explains the confirm-gating flow. However, it does not explicitly name the alternative tool (send_whatsapp_message) for single sends, leaving that comparison to be inferred. Otherwise, usage boundaries are well defined.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_product_imageA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds substantial context well beyond the annotations: the server downloads and validates, bills one vision check, persists to a durable URL, reads the brand back to confirm, and reports what the brand ACTUALLY holds rather than what was requested. This far exceeds the bare readOnlyHint=false / idempotentHint=true / openWorldHint=true annotations and gives the agent accurate expectations for a mutating, costly operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Long, but dense and justified for the tool's complexity — it covers purpose, failure semantics, confirmation behavior, cost, and cross-tool effects. Core purpose is front-loaded in the first sentence. It reads as verbose rather than bloated, though it could trim the redundant phrasing around 'never what was asked for.'

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, so the description carries the return-value burden — and it does, referencing `savedToBrand` and a summary that reports actual brand state. Combined with side-effect and cost disclosure, an agent has nearly everything needed. Minor gaps: exact response shape and failure-status codes are not specified, but the summary semantics largely compensate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% so baseline is 3, but the description adds real value: it specifies imageUrl is a product shot (excluding lifestyle shots), explains the consequence of the validation (rejection means nothing is locked/saved), and clarifies that brandId switches the active brand. This goes beyond the schema's terse field notes.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb+resource ('Lock an image as the ad's real PRODUCT photo and SAVE it as this brand's default product') and immediately distinguishes itself by explaining the downstream effect on plan_ad / render_ad / generate_image. The agent knows exactly what this does and how it differs from the many adjacent ad/asset tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly enumerates acceptable image sources (prior research results, workspace / list_product_photos URLs, any public photo), names the affected downstream tools, and explains the brandId behavior via the use_brand analogy. It also states rejection conditions (lifestyle/scene shot, off-category, unsafe), telling the agent both when to use it and what will fail.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_youtube_thumbnailA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations, revealing that the change is public and immediate, requires a verified YouTube channel, compresses images over 2MB, mandates Hermoso-hosted images (not just generated ones), and refuses external hosts. Annotations only say readOnlyHint=false, idempotentHint=true, destructiveHint=false; the description adds substantial behavioral context critical for safe invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Though lengthy, every sentence earns its place—covering purpose, constraints, prerequisites, and confirmation requirement. The main action is front-loaded, and the rationale for the tool (thumbnail impact on click-through) is concise and relevant. No filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (prerequisites, hosting constraints, public nature), the description covers all essential operational details. No output schema exists, but the tool's behavior is simple enough (success/failure) that the description is complete. An agent can call this correctly without further info.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so params are documented. The description adds value by clarifying videoId as the ID returned by post_to_youtube and elaborating on imageUrl (what counts as Hermoso-hosted, the need to pass through upload_file first, and that external hosts are refused). This enriches the schema without redundancy.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Set the CUSTOM THUMBNAIL on a video already on the connected channel'. It clearly distinguishes itself from other tools by emphasizing it changes ONLY the thumbnail, leaving video, title, and privacy untouched. This prevents confusion with tools like update_youtube_video.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: it's for videos already on the channel, and implies when to use it (when you want to control the thumbnail instead of YouTube auto-picking a frame). It also gives prerequisites (verified channel) and a usage caveat (obtain user consent). However, it doesn't explicitly name sibling alternatives or state when NOT to use this tool, so it falls short of a perfect 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• store_getA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral context by specifying the exact allowed keys (the allowlist) and reiterating that the operation is read-only and free. This exceeds a baseline but does not detail response formats or error handling, which are minor for a simple read tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is information-dense without fluff. It front-loads the core action, lists stores and allowed keys, and then guides the user to alternatives—all in a logical, scannable structure. Each sentence earns its place, and the parenthetical note is neatly appended.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, read-only tool with a single required parameter, the description is complete. It provides the full allowlist, distinguishes from siblings, and notes the read-only/free nature. Nothing an agent needs to invoke it correctly is missing, and the lack of an output schema is acceptable given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameters (key and limit) with descriptions, but the description adds crucial value by enumerating the exact allowed key values (e.g., heist.memory.v1, adInspo.swipefile.v1) that are not in the schema as an enum. This is essential for correct invocation, going beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('Read one of this workspace’s data stores by key') and the resource it operates on, listing specific store types. It also explicitly differentiates from the typed sibling tools (list_memory, list_skills, get_brand), making it unambiguous which tool to choose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: it names the typed alternatives (list_memory, list_skills, get_brand) as 'friendlier' for certain keys and instructs to 'use store_get for the rest.' It also states the read-only, free nature, leaving no ambiguity about when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tiktok_accountA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a meaningful prerequisite (TikTok connection) that is not in the annotations. It also explicitly repeats 'Read-only' which reinforces but does not contradict annotations. The incremental value is the connection requirement, which is useful for an agent to confirm.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, all substantive. The first sentence states exactly what the tool returns; the second gives concrete use-case examples; the third covers read-only nature and the prerequisite. Every sentence earns its place, and critical info is front-loaded. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-parameter read tool with no output schema, the description is comprehensive. It lists the exact data fields returned, states the precondition (connection), and provides typical query phrasings. An agent has everything needed to decide when to call this tool and what to expect back.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has zero parameters, and schema description coverage is 100% trivially. With no parameters to document, the baseline is 4. The description does not need to add parameter detail because none exist; it correctly focuses on the output fields and usage context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb ('Read') and resource ('the connected TikTok account') and enumerates the exact fields returned (display name, username, bio, verified status, follower/following/likes/video counts). This is a clear, unambiguous purpose that distinguishes it from broader analytics tools like tiktok_account_insights or tiktok_account_status, even without explicitly naming siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit use cases ('how many followers do we have on TikTok', 'how is our TikTok doing', 'confirm whose account is linked before posting') and a prerequisite (TikTok must be connected via Settings ▸ Connectors ▸ TikTok). This gives the agent clear guidance on when to invoke this tool and what needs to be true beforehand.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• update_meta_catalogA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide only basic flags (non-read-only, idempotent, non-destructive). The description adds crucial behavioral detail: Meta always returns {"success":true} even when ignoring a field, so the tool performs a fresh read-back to verify changes and reports unconfirmed values as 'NOT confirmed.' This explains the actual API behavior and the tool's mitigation, going far beyond the annotations. It also notes the zero-cost nature.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Although long, every sentence carries weight. The main purpose is front-loaded, followed by the list of additional settings, the permanent constraints, and the critical note about the 200 response and read-back. The all-caps 'THE 200 IS NOT THE ANSWER' is emphatic and memorable. The structure is efficient given the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 10 parameters, nested objects, and no output schema, the description covers the key aspects: what can be changed, what cannot (vertical, portfolio), how success is verified via read-back, the silent-failure scenario, and the cost. It addresses the biggest risk (false success) and tells the agent exactly what to expect, making it highly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover all 10 parameters, so the baseline is 3. The description adds meaningful context by explaining the purpose of defaultImageUrl and fallbackImageUrl (fallback for product images) and grouping the settings objects (dynamic-ad, destination/flight/store/partner-integration) into travel/local-inventory scenarios. This supplements the generic schema descriptions without redundant repetition.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb ('Change') and a precise resource ('a product catalog's settings'), clearly identifying the operation. It enumerates the settings it can modify (name, image URLs, display settings, travel/local-inventory settings) and explicitly states what cannot be changed (VERTICAL, business portfolio), which cleanly distinguishes it from create, delete, and list siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the primary use case obvious: updating an existing catalog's settings. It warns that vertical and business portfolio are immutable, preventing attempts to change them. It does not explicitly name alternatives like create_meta_catalog or delete_meta_catalog, but the context and sibling list make the intended use clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• update_pinterest_boardA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description significantly exceeds what annotations provide. It discloses that setting SECRET hides all pins without deletion, that it is reversible, that the read-back reports hidden pin counts, and that PROTECTED is refused by name rather than rejected after sending. This adds actionable behavioral context beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence earns its place. The primary action is front-loaded, followed by a clear warning symbol, reversibility note, and an edge-case explanation. The structure flows logically from main purpose to critical caveats, without fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no output schema, this description is exceptionally thorough. It covers prerequisites (Pinterest connected), credit cost (0 credits), allowed values (PUBLIC/SECRET with PROTECTED refused), side effects (hidden pins, reversibility), and even hints at output via read-back. Nothing an agent needs to invoke it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With schema coverage at 75%, the baseline is 3. The description adds value by explaining the intent of name, description, and privacy (rename/rewrite/change privacy). It also clarifies the privacy enum nuance — that only PUBLIC or SECRET are accepted on update and that PROTECTED is always refused — which the schema does not convey. This goes beyond simple repetition of schema fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Rename a board, rewrite its description, or change its privacy') with clear resource and attributes. It distinguishes itself from sibling tools like create_pinterest_board and delete_pinterest_board by focusing on updating an existing board. The title reinforces the purpose without redundancy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool (updating an existing board) and even provides a contextual hint: PROTECTED can only be set at creation, pointing toward create_pinterest_board for that scenario. However, it does not explicitly name alternatives or give a direct when-not-to-use statement, so it falls just short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• update_sheetA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint, idempotentHint, and openWorldHint, but the description adds critical behavioral details beyond those: writing over filled cells is refused first (naming the count), a confirm:true flag is required to proceed, and the result is read back from the sheet so the agent reports actual sheet state. These specifics materially modify expected behavior and are not derivable from annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but highly informative, and each sentence adds value. The purpose is front-loaded, the alternative is named, and edge cases (refusal, confirmation, read-back) are covered. While slightly wordy, it is not bloated or repetitive; the structure flows from purpose to mechanics to safety verification.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 7 parameters, no output schema, and rich annotations, the description covers the critical aspects: what the tool does, when to use it, the confirmation gate, and the read-back guarantee. It does not explicitly explain the difference between sheetUrl and spreadsheetId, but those are conventional and likely self-evident. Overall, an agent has enough to call this correctly without external documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 71%, and the description significantly enriches the main parameters: it gives concrete range examples ('B2:C5', 'Q3 Report!B2'), explains the anchor-cell behavior, clarifies that values must be an array of row arrays, and explains confirm is required only when overwriting. It also details the updates parameter for multiple disjoint ranges. The only parameters left untouched are sheetUrl and spreadsheetId, which are standard identifiers; the description compensates well for the schema gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('CORRECT cells'), the resource ('a Google Sheet'), and the precise operation ('write values to an exact range, overwriting whatever is there'). It explicitly contrasts with append_to_sheet, naming the sibling and the exact limitation it overcomes, so an agent can distinguish this tool without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance: 'This is the fix append_to_sheet cannot make' and explains the failure mode appending would cause. It also specifies the confirmation workflow for overwriting non-empty cells ('show the user that, get a yes, then call again with confirm:true'), leaving no ambiguity about prerequisites or safe invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• update_youtube_channelA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description goes far beyond these, revealing the PUT-merge semantics (reads current settings first to avoid wiping fields), the silent-ignore behavior for some fields (like channel title), the result diffing with `notApplied`, and the instruction not to report unaccepted fields as changed. It also discloses banner constraints and credit cost, adding substantial behavioral context that the annotations do not cover.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but dense and well-structured: it front-loads the primary purpose, then layers critical warnings in uppercase with clear transitions. Every sentence adds value—the merge behavior, the ignored-fields warning, the notApplied handling, banner constraints, and the public/immediate timing. While it is verbose, the emphasis is justified given the tool's complexity and multiple failure modes, so it earns a high but not perfect score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (PUT-merge, silent field rejection, banner dimensions) and no output schema, the description covers all critical aspects an agent needs to call it safely: it explains the merge behavior to avoid accidental data loss, warns about ignored fields and how to interpret the result, specifies banner constraints, and notes the credit cost and connection requirement. Nothing essential for correct invocation is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining practical pitfalls for specific parameters: it warns that `title` is often silently ignored, explains the `keywords` comma-separated format in a way that reinforces the wire format, and specifies banner requirements (type, size, safe area) that are not in the schema. This turns abstract fallback/caveats into actionable guidance, exceeding baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Apply the brand') and resource ('the channel itself'), enumerates the exact fields affected (banner art, description, keywords, country, trailer), and explicitly contrasts itself with sibling tools by noting 'Every other YouTube tool brands the videos; this brands the page they sit on.' This unambiguous scoping makes it instantly distinguishable from update_youtube_video and other YouTube tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly routes usage by contrasting with other YouTube tools ('Every other YouTube tool brands the videos; this brands the page they sit on'), and it adds operational guidance on when to show the user (before making public changes). However, it does not explicitly name alternatives or state exclusions (e.g., 'use this instead of X when Y'), leaving some inference to the agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• upgrade_planA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already indicate non-readonly, non-destructive, but the description adds critical financial behavior: agents never pay directly, returns a Stripe Checkout URL for the human, and 'Nothing is charged until your human pays.' This beyond-annotation transparency is essential to prevent an agent from taking harmful action. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact but information-dense, front-loaded with the main purpose, then the usage pattern, then edge cases. Every sentence adds value: admin-only restriction, listing flow, Stripe payment, downgrade handling, and member message. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description fully covers the three possible return scenarios (new subscriber → Stripe URL, existing paid/downgrade → instructions, member → message), plus permission handling. An agent has all information needed to call correctly without ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both 'plan' and 'period' are well documented, including the default and the 2-months-free bonus. The description reinforces the omit-to-list behavior already present in the schema, adding no new parameter semantics. Baseline 3 is appropriate since schema carries the full weight.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource ('Change this account's SUBSCRIPTION plan'), notes 'admin only', and clearly distinguishes from siblings like billing_status or buy_credits by describing the flow: list plans with no argument, then set a plan. The purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly instructs the two-step call pattern ('Call with no argument to list the plans... call again with `plan` set'), and specifies the fallback for paid/downgrade cases (returns instructions) and for members ('ask an admin' message). This fully clarifies when to use the tool and what to do in each scenario.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_whatsapp_templateA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only mark readOnlyHint=false, openWorldHint=true, idempotentHint=false. The description discloses far more: Meta re-categorises mismatched templates, the reply reports the actual assigned category, submission results in PENDING status, carousel card constraints (same components, body limit), media header requirement, and local refusal by Hermoso. This goes well beyond annotations and gives the agent realistic expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a dense wall of text with many sentences, and while each adds value, it is not concise. It front-loads the core purpose and then cascades into detailed edge cases (carousel, media, category). It could be broken into short bullet-like sections for readability, but given the complexity, a 3 is fair — it is adequate but lacks structural concision.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a creation tool with no output schema, the description covers the post-submission state (PENDING, re-read), the category assignment behavior, media requirements, carousel nuances, and local refusal. It even mentions credit cost (0 credits). The only minor omission is a full response structure, but the description explains the key outcome and next step, making it complete for agent invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3, but the description adds substantial semantics beyond the schema. It explains the category's pricing and policy impact, that en and en_US are distinct templates, the name format, carousel component structure, card body limit, and media handle requirement. This enriches parameter meaning significantly beyond the raw schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear verb-resource pair: 'Submit a new WhatsApp message template for Meta's review.' It further grounds the purpose by stating this is the ONLY way a business can start a WhatsApp conversation outside the 24-hour window, which distinguishes it from sending messages and listing templates. The sibling tools like send_whatsapp_message and list_whatsapp_templates are implicitly separated by this explicit scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use context: it is the only path to initiate conversations, and it warns that submission does not make the template sendable — it returns PENDING and must be re-read with list_whatsapp_templates. It also specifies constraints like media headers requiring an uploaded asset and Hermoso refusing locally, so the agent knows when the tool will fail and how to avoid it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_brandA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint=true, but the description adds crucial behavioral context: the operation is irreversible, affects all shared users, requires a confirmation protocol, and the first call without confirm serves as a dry-run inventory. It explains the rationale for the confirmation fields, going well 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence carries necessary safety information. It is front-loaded with the most critical warning (irreversible) and then flows logically into the confirmation protocol. Though it is a long paragraph, it is structured in a cause-and-effect manner that justifies its length. Could be broken into shorter sections, but it is not bloated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive, high-stakes operation, the description covers the full behavioral contract: what is deleted, irreversibility, impact on shared users, the two-phase confirmation with exact parameters, and the anchor-brand exception. Nothing essential for an agent to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter already has a description. The description adds value by explaining why confirmName and confirmConnectors exist: to prove the correct workspace was targeted, preventing accidental destruction of a live brand. This clarifies the intent and requirement beyond schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: "PERMANENTLY delete a brand workspace and EVERYTHING in it." It enumerates what is included and explicitly distinguishes this from other delete tools by naming the anchor-brand exception. The purpose is unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit two-phase workflow: call without confirm to get an inventory, show the user, get unambiguous yes, then call with confirm:true and necessary verification fields. It also states when NOT to use it (anchor brand) and how that case is handled. This is exemplary usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_pinterest_pinA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes far beyond annotations by detailing the non-destructive first call, the authoritative response source ('read back from Pinterest, never taken from its 2xx'), the impact on ads, and the zero-credit cost. This is comprehensive behavioral disclosure for a destructive action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average (5 sentences) but every sentence serves a distinct purpose: permanence, two-phase flow, promoted-pin risk, and authoritative response. It is structured logically and front-loads the core purpose, though it could be tightened slightly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description explicitly states what the unconfirmed call returns (title, saves, impressions, promoted flag) and how to interpret the verdict. It covers prerequisites, side effects, and the safety mechanism—complete for an agent to execute correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and already explains each parameter, including conditions for confirmName. The description adds the rationale—why confirmName is needed to ensure targeting the correct pin—and explains the flow, providing value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'PERMANENTLY delete a Pin'—a specific verb, resource, and critical qualifier. It also distinguishes itself from other delete tools by emphasizing the permanence and lack of undo, which is unique to this tool among siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides an explicit two-phase workflow: call without confirm to retrieve metadata, then call with confirm and confirmName after user consent. It also states prerequisites ('Needs Pinterest connected') and warns about promoted pins, leaving no ambiguity about when or how to use the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_youtube_videoA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructiveHint:true, but the description goes far beyond by detailing the irreversibility (no trash, no undelete, loss of views/comments/links) and the rationale behind confirmTitle to prevent deleting the wrong video. It also notes the 0-credit cost and channel prerequisite. This adds substantial behavioral context beyond the annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long (~150 words) but every sentence is purposeful: it front-loads the action, then explains irreversibility, the confirmation protocol, the alternative, and prerequisites. The structure is logical and well-paced, though slightly verbose; it could be tightened without losing information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive tool with a multi-step confirmation flow, conditional parameters, and an alternative usage path, the description covers all necessary context: how to call, what to expect, when to use an alternative, and prerequisites. Even without an output schema, an agent has everything needed to invoke this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all three parameters with descriptions (100% coverage). The description adds meaning by explaining the confirmTitle requirement's conditionality (public or any views/comments) and tying videoId to list_youtube_videos. It reinforces the workflow context, slightly elevating value beyond the schema baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'PERMANENTLY delete a video from the connected YouTube channel', which is a specific verb+resource statement that unambiguously defines the operation. It explicitly distinguishes itself from the reversible update_youtube_video tool and other sibling delete tools by emphasizing its irreversible nature.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a detailed two-step confirmation workflow (call without confirm first, get user confirmation, then call with confirm:true and confirmTitle). It explicitly routes users to update_youtube_video for reversible privacy changes, and points to list_youtube_videos as the source for videoId. This is comprehensive and leaves no ambiguity about when to use this tool vs alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• duplicate_scheduledA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description adds crucial behavioral details: 'The copy is INDEPENDENT — editing or cancelling it never touches the original — and it is a genuinely new post rather than a re-send, so it publishes even where the original already did.' This clarifies side effects and independence, which annotations do not convey. No contradiction with annotations exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph that front-loads the core purpose and then adds context. It is not overly verbose given the tool's complexity (18 parameters), and every sentence adds value, from use cases to independence to the retry_scheduled contrast. It could be broken into bullet points for readability, but it is structured logically and remains comprehensible.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (18 parameters, nested objects, many channel-specific fields), the description covers the essential behavior, scheduling options, independence, and the difference from retry_scheduled. It does not need to explain every parameter because the schema already does, and no output schema exists so return values are not required. The description provides enough for an agent to call it correctly without missing key context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 72% (many parameters have descriptions), and the description adds meaningful context beyond those. It explains that all copied fields 'can be overridden in the same call' and clarifies the scheduling distinction between 'at' and 'useQueue:true'. It also mentions the default time ('an hour from now') implicitly via 'at' description in schema, but the description does not list every parameter. It augment the schema without fully compensating for the 28% undocumented parameters, so a 4 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Copy an existing scheduled or already-published post into a NEW queued post.' It clearly states the action, the object, and the result, and distinguishes it from the sibling tool retry_scheduled by noting 'To re-fire only the channels that FAILED, use retry_scheduled instead.' This leaves no ambiguity about what the tool does and when to differentiate it.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly lists use cases ('run a creative again, reuse a post that worked as the starting point for the next one, or re-send something after it went out') and provides a direct alternative: 'To re-fire only the channels that FAILED, use retry_scheduled instead.' It also explains the two scheduling modes (at vs useQueue), giving the agent clear conditions for each. No gaps remain about when to choose this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• edit_videoA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are all false (readOnlyHint, destructiveHint, etc.), so the description carries the full burden. It clearly discloses key behaviors: the edit preserves original motion/timing, it is a paid render, and it returns a served URL. It also explains how the elements parameter affects behavior (restores real identity/product vs. plain restyle). 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense yet every sentence earns its place: purpose is front-loaded, followed by concrete use cases, the recommended clip length, a clear 'NOT for' section naming five alternatives, and a final note on cost and output. The structure guides an agent from selection to invocation without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (video editing, multiple parameters, no output schema), the description covers purpose, usage, exclusions, cost, output URL, and best practices. It doesn't mention error scenarios or hard maximum video length, but the 'Best on 3–10s clips' is a reasonable heuristic. The schema covers source URL provenance. Overall, an agent has everything needed to decide and call the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (all parameters have descriptions), so baseline is 3. The description adds meaningful context for the 'elements' parameter, explaining its purpose (identity/product grounding), the max count (≤4), and when to omit it (plain restyle). It also clarifies the 'instruction' parameter as 'in the user’s own words'. This goes beyond the schema's literal descriptions and aids correct usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('EDIT/transform') and resource ('an existing video clip') and immediately defines the scope: keeps motion/timing, changes subject/setting/style. It provides concrete examples ('change the background to a city', 'restyle it as claymation'). It also distinguishes itself from five named sibling tools, so an agent can reliably tell edit_video apart from post_edit, generate_video, render_ad, dub_video, and recast_motion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states when to use (for style/subject/setting changes) and when NOT to use, listing specific alternatives for each excluded case (mechanical cuts → post_edit, new video → generate_video/render_ad, translation → dub_video, face swap → recast_motion). It also adds a practical recommendation ('Best on 3–10s clips') and flags the paid nature. This leaves no ambiguity about tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fix_beatA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide minimal safety hints (all false), so the description carries the full burden. It discloses that the tool modifies the video track only, keeps audio byte-identical, bills only the replacement seconds (~1/3 of full render), and warns about lip-sync issues under dialogue. This is thorough behavioral disclosure 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a compact paragraph with a clear logical flow: core action, use cases, billing impact, and a critical warning. No fluff; every sentence serves a purpose and the most important constraint (video-only splice) is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is complex (6 params, nested array, specific constraints) and the description covers its purpose, constraints, and billing implications well. It misses the output format (e.g., returns a job ID or new video URL) and error conditions, but the core use cases are fully addressed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, giving baseline 3, but the description adds context: the 1.5-8s window constraint, the meaning of prompt relative to master style, and the importance of speechWindows in avoiding dialogue overlap. This elevates understanding beyond bare parameter names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a precise verb-resource pair: 're-render ONE time window' of an existing video, and further distinguishes itself by specifying VIDEO TRACK ONLY with byte-identical preservation of the rest. It clearly separates from siblings like full re-render or clip_video by emphasizing surgical splicing.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use ('when one beat/shot is broken'), when not to (avoid dialogue windows), and names the alternative (full re-render) with reasoning. Also gives a concrete negative condition and instructs to pass speechWindows to enforce that constraint.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• instagram_profileA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it read-only, non-destructive, and open-world, and the description reinforces this with concrete details: read-only, 0 credits, no new permission, no reconnect. It goes beyond annotations by disclosing the ambiguous error behavior across personal/private/age-gated/nonexistent accounts, and that data comes straight from Meta rather than a scraper — behavior an agent cannot know from schemas.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy but every section earns its place: primary function, cross-tool warning, and error semantics. It front-loads the essential purpose and uses bold for critical constraints. Slightly verbose in the error explanation, but the density of critical usage information justifies the length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description covers all necessary context: accepted input formats, required authentication context (professional account), the relationship to manage_meta_partnership_creator, and the error-to-caller guidance. An agent has everything it needs to invoke this tool correctly and interpret results without additional lookups.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with both parameters already described. The description adds value by enumerating accepted handle formats (bare, @, full link) and the normalization step, plus the condition for omitting pageId. This exceeds the baseline of 3 that schema coverage warrants, though it doesn't elaborate on every edge case for pageId.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a precise action — converting an Instagram @handle into a numeric ID plus profile data — and names the two distinct jobs (ID lookup and brand sizing). It distinguishes itself from the sibling manage_meta_partnership_creator by spelling out that it supplies the numeric IDs that tool requires, making its unique role unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly directs when to call this tool ('CALL IT BEFORE manage_meta_partnership_creator'), explains why (that tool rejects non-Meta IDs with an ambiguous error), and hard-scopes usage to professional accounts. It also warns about the four failure cases returning the same refusal, giving the agent clear guardrails on what not to infer.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_bluesky_postsA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes beyond them by disclosing that Bluesky has no impression/view lexicon, that counts have no denominator, and that reposts are not the brand's own creative. It also notes unknown filters are refused by name, and states the tool is read-only and costs 0 credits. This adds behavioral context well 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but each sentence carries meaningful information. The AT-URI source statement is front-loaded, which is immediately useful. The density of caveats (reposts, no impressions, filter behavior) justifies the length, though a shorter version could have preserved the key decisions. Overall it is well-structured and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description lists the return row fields (text, date, web URL, live counts, repost/reply flag) and explains the no-engagement-rate limitation. It also covers filter semantics, the reading cost, and the dependency of other tools on its AT-URI. Nothing an agent needs to call it correctly appears missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema documents all three parameters (limit, cursor, filter) with descriptions, so schema coverage is 100%. The description adds value by reiterating the filter options and clarifying that an unknown filter is refused by name, and by implying the default limit. It does not reproduce schema details, but adds a small amount of extra semantic guidance.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens by precisely scoping the tool to the brand's OWN recent Bluesky posts, newest first. It explicitly differentiates from sibling tools like bluesky_post_metrics and delete_bluesky_post, and states that it is the source of the at:// AT-URI needed by those tools. This gives an agent a clear, distinct understanding of what this tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It names the dependent sibling tools (bluesky_post_metrics, delete_bluesky_post) and explains the exact use case: obtaining AT-URIs for past work after a post was published in a previous conversation. It also gives guidance on reposts (must not be reported as the brand's own performance) and notes that Bluesky publishes no impression counts, so no engagement rate can be computed. This is explicit when-to-use and when-not-to.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_hooksA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the readOnlyHint annotation by explaining dynamic behavior: verdict suppression below 5 measured posts with reason, no cross-channel comparison, and treatment of never-tried hooks as observation not advice. It also explains why hooks are marked unusable (on-screen-text hooks incompatible with authentic renders). These are valuable behavioral details not conveyed by annotations alone.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single long paragraph but is dense and front-loaded with the core purpose. Each sentence adds meaningful content (what it returns, when to call it, limitations, behavior). It could be broken into more readable bullets, but it is not wastefully verbose relative to the complexity it explains.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only lookup tool with 4 optional parameters and no output schema, the description fully covers what an agent needs: what it returns (menu, settings, traction), how the verdicts are gated, which params affect what, and its place in the ad-planning workflow. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover all 4 parameters, so baseline is 3. The prose adds context: tier changes the 'FINISH of the room' and authentic flag makes on-screen-text hooks 'unusable with the reason.' This clarifies the interaction between parameters and the tool's output, going beyond the schema. Slight deduction for not elaborating the category parameter more explicitly, but it's adequately covered.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a precise purpose: a curated menu of visual scroll-stop hooks and settings, with measured traction, that plan_ad and render_ad accept. It names the consumers and differentiates itself from other tools by being a deliberate selection aid rather than an improvisation tool. It is clear what the tool does and its scope is explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to call it: 'before planning an ad' and 'after publishing,' giving concrete usage timing. It also lists three things it will not do (no recommendation from thin data, no cross-channel comparison, never-tried hooks reported as fact not advice), which effectively tells the agent what not to expect and when to avoid using it. This is excellent guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_instagram_shopping_catalogsA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, and the description aligns with these but adds meaningful context: it clarifies that 'not eligible' is a Commerce Manager approval state Hermoso cannot grant, not a sign of breakage; that 'could not tell' is distinct from 'not eligible'; and that an empty catalog list is not an empty catalog because of the SHOP-vs-PORTFOLIO distinction. It also notes it consumes 0 credits. This adds value beyond the annotation flags.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but front-loaded with the core question statement, then a 'CALL THIS FIRST' directive and a sequence of key distinctions. It uses uppercase for critical terms ('CALL THIS FIRST', 'APPROVED INSTAGRAM SHOP', 'AN EMPTY CATALOG LIST IS NOT AN EMPTY CATALOG') to emphasize importance. It rambles slightly but each sentence carries distinct information — no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with one optional parameter, 100% schema coverage, read-only annotations, and no output schema, the description covers all necessary context: eligibility states, failure modes, the credit cost, the relation to sibling tools, and the manner of the Page-Instagram link. An agent has enough to call it correctly and interpret the reply accurately without additional lookups.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (the only parameter pageId is fully described). The description adds context on the pageId parameter by explaining that the linked Instagram account is what gets tagged, and when to omit it (if only one Page is connected). This adds behavioral nuance beyond the schema's basic field description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific purpose: checking whether an Instagram account can tag products and which catalogs its SHOP can tag from. It clearly distinguishes the subject (SHOP vs portfolio) and names a sibling tool (list_meta_catalogs) for contrast. The 'CALL THIS FIRST' directive and the three reply states further sharpen the purpose beyond the name alone.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says to call this tool first before any product tagging attempt, explains why (tagging fails after upload if no approved shop), and distinguishes the 'could not tell' case from 'not eligible'. It also names an alternative (list_meta_catalogs) and explains when that one is relevant, contrasting SHOP-based access with PORTFOLIO-based access. This is explicit when-to-use guidance with clear exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_tiktok_mentionsA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare read-only and open-world. The description adds substantial behavioral detail beyond annotations: the four conditions causing ambiguous empty results, the 1,000 post cap, null-not-zero semantics for views/reach, 48-hour thumbnail URL expiry, and the authorization requirement. It also distinguishes between TikTok withholding numbers and measurement of nothing—critical for correct interpretation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence carries critical operational detail. It front-loads the purpose and then uses capital-letter warnings to highlight hard constraints. While not concise in word count, it is efficiently structured, with no filler. The use of all-caps for key caveats aids scanning.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description covers interpretation of results (null vs zero, empty ambiguity, cap), prerequisites (business account, authorization), and edge cases (age, recency, thumbnail expiry). It also references companion tools for status checks. An agent has everything needed to call this correctly and avoid misreporting silence.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 57%, so the description must compensate. It adds meaningful context for 'days' (TikTok indexes nothing older than 90 days), 'regions' (filters on the mentioning author's registration country, refuses unpublished codes), and 'fields' (defaults to every field). It doesn't explicitly explain cursor, maxCount, sortField, or sortOrder, but those have schema descriptions or enums. The added context for the mentioned parameters elevates it above the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the verb and resource: 'every public post whose CAPTION @-mentions the connected account's handle.' It also differentiates from sibling tools by naming x_mentions and list_threads_mentions as analogous but TikTok-specific. The scope constraints (public, <90 days, business account) are explicit, leaving no ambiguity about what the tool retrieves.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance: it's the brand-monitoring read missing for TikTok, and it instructs the agent to read the four TikTok enforcement caveats before reporting silence. It names the prerequisite (TikTok business account) and points to tiktok_account_status and tiktok_account_insights for checking. It also mentions the authorization need and refers to tiktok_account_status for verifying permission.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_tiktok_videosA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already include readOnlyHint=true and destructiveHint=false, but the description goes beyond by explaining the unresolved field semantics (id not returned means not on account or deleted, never zero), and crucially discloses that the TikTok API offers no way to edit or delete published posts—critical behavioral context for agents. It also notes 'Read-only, 0 credits' and requirements like 'Needs TikTok connected.' 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but well-structured: it opens with the core purpose, lists the two modes, then explains the unresolved behavior and the edit/delete limitation. The warning about no-edit capability is a bit verbose but earns its place because it prevents futile search for a tool. The use of bullets and bold headings improves scannability, though some trimming could make it leaner without losing value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a list operation with only two optional parameters and no output schema, the description covers all necessary aspects: the data returned, the two invocation patterns, the unresolved field semantics, the account restriction, the read-only nature, and the platform limitation on edits. An agent has everything needed to call this tool correctly and to set user expectations about capabilities.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already has 100% coverage with descriptions for both limit and videoIds. The description adds value by explaining the interaction: limit is ignored when videoIds is given, and videoIds reads specific posts regardless of age. It also clarifies the meaning of unresolved ids. While the baseline is 3 with high schema coverage, the description meaningfully enhances the semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states 'The connected account’s own TikTok posts with per-video stats' and names the exact stats (views, likes, comments, shares, duration, cover image, link). It also distinguishes between the two invocation modes: listing recent posts with no arguments and reading specific posts via videoIds. This clearly separates it from sibling tools like list_tiktok_comments or search tools, leaving no ambiguity about what it does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance on when to use each mode: with no arguments for the most recent posts, with videoIds to answer 'how did that specific video do' without paging. It also states 'Only ever the connected user’s OWN videos,' which prevents misuse. While it doesn't name alternatives like list_tiktok_comments, the two-mode usage is clearly defined, and the warning to not look for a tool to edit/delete posts implicitly steers toward this tool's appropriate use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_youtube_categoriesA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint and destructiveHint annotations, the description adds behavioral context: it is 'Read-only, 0 credits' and 'Needs a connected YouTube channel.' It also reveals the default filtering of unassignable categories and the rationale that such uploads are refused. These enrich the agent's understanding of side effects and prerequisites without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, each carrying essential information: purpose, dependency on post_to_youtube, rationale for regionCode, and default filtering behavior. It is front-loaded with the main action and avoids any fluff, ensuring every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description should convey what the tool returns. It implies a list of categories with id and name by stating that 'the id set AND the names differ by country', and it details the default filtering and prerequisite of a connected channel. While it doesn't explicitly enumerate response fields, it provides sufficient context for an agent to anticipate the result, though a brief note on output structure would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides thorough descriptions for both parameters (ISO 3166-1 alpha-2 code, includeUnassignable meaning). The description adds value by explaining why regionCode cannot be guessed and is required, and by linking the parameter to the broader workflow (discovering a valid categoryId for post_to_youtube). This goes beyond mere schema repetition.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'List the video categories YouTube will accept on an upload in a given country.' It clearly states the tool's function and differentiates it by framing it as the sole source for valid category IDs used by post_to_youtube, distinguishing it from other listing tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly names post_to_youtube as the consumer of categoryId and states that 'this is the only way to discover a valid one', giving an unambiguous when-to-use directive. It also explains why regionCode is required (IDs and names differ by country) and the default filtering of unassignable categories, providing clear contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• make_explainerA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are minimal (all four hints are false), so the description carries the full burden — and it delivers extensively. It discloses the long-running nature ('Takes SEVERAL minutes — one image render per frame'), the concurrency trait ('independent frames are painted concurrently, so it is far faster than the frame count suggests'), the cost model with concrete credit figures per style and density tier, the motion mechanics (hold-still + cut rate + shimmer), the text pipeline that avoids garbling ('text is never model-painted'), and the on-screen text default. No contradiction with annotations: readOnlyHint=false correctly matches a tool that produces a new artifact.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long (~450 words), but for a 13-parameter video-generation tool with subtle defaults, a cost model, and sibling differentiation, nearly every sentence earns its place. Structure is logical: purpose → motion model → text defaults → style → cost → performance → prerequisites → disambiguation. It drops to a 4 rather than 5 because a few passages (e.g., the 'slow move on a still shimmers' physics and the parenthetical on one-detail edits) add flavor more than agent decision value, and the length makes front-loading slightly harder to absorb at a glance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool of this complexity with no output schema and sparse annotations, the description is remarkably complete: it covers outcome, cost, timing, prerequisites, defaults, and disambiguation. The one genuine gap is the return value — for a multi-minute asynchronous operation, the agent is never told what comes back (a job handle? a URL?) or how to retrieve the result. Given sibling tools like get_job imply an async job pattern, this is a meaningful omission that keeps it from a 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Even with 100% schema coverage (baseline 3), the description adds substantial meaning beyond the schema. It explains the music default behavior (which channels get a composed bed unasked, mood-name composition on any channel, dry shipping, and how to look up exact credits), the captions-vs-subtitles-vs-section-headings distinction with timing approximation caveats, the upscale pricing warning and quote-before-acting rule, the cost implications of each frameDensity tier and what makes a stills film read as a film, and per-style visual descriptions. This materially improves the agent's ability to set parameters correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Opens with a specific, unambiguous statement of purpose: 'Turn a TOPIC into a finished narrated explainer video.' It then walks through the full production pipeline (script → pictures → TTS narration → end-card composite), and explicitly differentiates itself from siblings: 'NOT the tool for a short product ad — use render_ad or generate_video for those, and make_template_ad for the deterministic native formats.' An agent can immediately tell what this tool does and how it differs from the closest alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use and when-not-to-use guidance with named alternatives (render_ad, generate_video, make_template_ad). It also gives strong default-handling instructions: leave captions/subtitles off unless the user asks, never enable upscale unasked and quote the credit figure first, 'Ask the user which [style] they want rather than picking silently,' and only drop frame density below default when the user asks for cheaper. Prerequisites are stated ('Needs the writing model and a narration voice engine connected'). This is unusually actionable routing guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_performanceA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces that with 'Read-only'. Beyond that, the description adds significant behavioral context: it never sums metrics across channels, it suppresses verdicts below 5 posts, and it explains how posts without a recorded hook are counted. It also states it returns a `finding` or a `reason`. These details are not in the annotations and are crucial for correct interpretation of results. No contradiction exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average, but every sentence earns its place. It front-loads the primary verb and purpose, then moves to a numbered list of exclusions, a presentation instruction, and a concluding note on read-only and credits. The structure is clear and purposeful; nothing is fluff. The length is justified by the tool's behavioral complexity, so it gets a 4 rather than a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description carefully explains what the output looks like (`finding` or `reason`) and when each appears. It covers aggregation scope, channel-scoping rules, confidence thresholds (5 posts), and data-exclusion semantics. Given the complexity of this analytic tool, the description is nearly exhaustive. An agent would know exactly what to expect and how to present results. No critical context is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (both `axis` and `channel` are described). The description adds contextual meaning beyond the schema: it explains that grouping is by 'hook (default), subject, channel, media format or posting hour' (matching the enum) and clarifies that channel is meaningful because 'every comparison is within one channel'. This rationale is not in the schema and helps the agent understand why restricting by channel matters. It earns a 4 rather than a 3 because it adds interpretative value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Aggregate'), a resource ('this brand's published posts'), and a defined analytical goal ('which hooks and subjects work'), then enumerates the grouping axes. It clearly distinguishes itself from per-platform insight tools like meta_post_insights or x_post_metrics by framing it as a cross-channel aggregate. The purpose is unambiguous and specific, not a tautology.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly lists three behaviors the tool deliberately will NOT do, with reasons, and instructs the agent to 'repeat them rather than paper over them'. It also gives direct presentation guidance ('Present the `finding` verbatim if there is one, and the reason if there is not') and notes the tool is read-only and costs 0 credits. This is strong usage direction, even though it does not name sibling tools, because it tells the agent how to act on the tool's output and what boundaries not to cross.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_to_blueskyA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond annotations. It discloses timed behaviors (Hermoso checks limits before round trip), error conditions (refusal for unconfirmed email), platform-specific rules (Bluesky's 3000-byte cap, video MP4 only), and side effects (media wins over link card). Annotations only cover readOnly/destructive hints; the description adds operational details essential for correct invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but front-loaded with the most critical constraints (character/byte limits, media exclusivity) and then covers ancillary details (captions, link cards, reconnection). Some redundancy (e.g., mentions 'one embed' twice) but each section earns its place. Slightly long, but justified for a complex tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (8 parameters, interaction rules, platform quirks), the description covers all necessary points: return value (public URL), connection method, limits, media rules, error conditions, and the auto card behavior. No obvious gap for an agent to mis-invoke.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with rich descriptions, but the tool description adds extra context: the byte/character limit interplay, the 'one embed' rule clarifying altText and videoAlt conflicts, the linkCard behavior with explicit vs implicit, and the on-fetch limits. It supplements, not just reiterates, the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb ('Publish a post'), the resource ('to Bluesky'), and the connected account context. It distinguishes from sibling posting tools (post_to_x, post_to_tiktok, post_to_meta) by naming Bluesky specifically and detailing platform-specific constraints, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance: it covers text limits, media types, link card behavior, and even when to suppress the card. It also names alternatives implicitly (e.g., other social posting tools) and provides exclusions (e.g., media and link card cannot be combined, video requires confirmed email).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_to_tiktokA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false and idempotentHint=false, but the description goes far beyond that by disclosing that 'post' makes the content live immediately and requires explicit user approval, while 'draft' is safer. It also explains platform constraints like the lack of mixed video/photo posts, the default autoAddMusic=true to avoid silent slideshows, and the connector prerequisite. No contradictions with annotations; the description adds substantial behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, dense paragraph but well-structured: it starts with the core purpose, then details video vs. photo, then destinations, then prerequisites and strategic tips. Every sentence adds value for a tool with 16 parameters and conditional logic, though it could be slightly more scannable with bullet points. It is not overly verbose and front-loads the most critical distinction (post vs. draft).

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity (16 parameters, multiple modes, and platform-specific rules), the description covers the essential points: the two content types, the two destinations with their implications, the consent requirement, the connector prerequisite, the analytics grouping hints, and platform constraints (no mixed posts, photo-title default, autoAddMusic behavior). No output schema exists, but that's acceptable; the description is complete enough for an agent to call this tool correctly and safely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 94%, so the schema already documents parameters well. The description adds strategic meaning beyond the schema, particularly for 'hook' and 'subject', explaining they serve as grouping keys for post_performance analytics and the importance of reusing exact wording. It also clarifies the constraint that videoUrl and imageUrls are mutually exclusive, and explains defaults like coverIndex=0 and photoTitle fallback. This enriches the schema without redundancy.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the verb ('Publish to the user’s connected TikTok account') and resource, distinguishes video vs. photo post formats, and clarifies that a single image is just a one-slide photo post. This clearly separates it from other post_to_* tools (e.g., post_to_meta, post_to_x) and from TikTok-specific utilities like tiktok_creator_info or list_tiktok_videos.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit usage context: when to use 'post' vs 'draft' (and the safety rationale), the prerequisite of a connected TikTok account, the requirement to call tiktok_creator_info first for privacy options and get explicit consent for live posting, and the prohibition on passing both videoUrl and imageUrls. It also notes the default destination and mentions when to use coverIndex. This is comprehensive and leaves little to inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_to_youtubeA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With minimal annotations (readOnlyHint false, openWorldHint true, etc.), the description carries the full burden and excels. It discloses default privacy, the notifySubscribers behavior following privacy, the ad-ready nature of unlisted, the confirmation needed for public publishing, the refusal of scheduled unlisted/public posts, and the region-specific categoryId. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence carries essential information or warnings. Key points are front-loaded (default unlisted) and emphasized with uppercase and bold. For a tool with this many caveats, the length is justified and well-structured; it avoids fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity, full schema coverage, and sparse annotations, the description is complete. It covers prerequisites, defaults, exceptions, parameter interactions, and user confirmations. The lack of an output schema is fine since return value is not specified; the description ensures an agent can call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 substantial meaning beyond the schema by explaining interdependencies: how privacy interacts with publishAt (only private allows scheduling, and it becomes public later), how notifySubscribers defaults follow privacy, and the categoryId default being wrong for most ads. It does not elaborate on hook/subject, but those are analytics fields not central to posting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Publish') and resource ('a finished video to the brand’s connected YouTube channel'), clearly distinguishing it from sibling posting tools like post_to_meta or post_to_tiktok. It also specifies the input type (Hermoso render URL or upload_file URL).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides extensive usage guidance: defaults (unlisted), when to use public vs private, explicit warnings (private cannot be used as ads), scheduling constraints (publishAt only on private), and the prerequisite of a connected YouTube channel. Though it doesn't name alternatives, the domain-specific behavior is unambiguous and includes when-not-to-use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_x_articleA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide minimal behavioral info (readOnlyHint: false, destructiveHint: false), so the description carries the full burden. It discloses crucial behaviors beyond annotations: formatting is never silently dropped, refusal conditions for unsupported elements, the hard limits (10 drafts, 5 publishes per day), counting failed attempts against caps, immediate public publishing, irreversibility, credit costs (three API requests), and connectivity requirements. This is exemplary transparency for a high-stakes mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence contributes critical warnings or operational context, packing high information density without padding. It is reasonably front-loaded, leading with the core distinction and then covering conversion, limits, and pitfalls. While not as brief as the ideal, its length is justified by the tool's complexity and irreversible consequences—so it earns a 4 rather than a 3.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with this complexity (formatting conversion, daily caps, irreversible publishing, costs, connectivity), the description is remarkably complete. It covers what happens to unsupported formatting, how to avoid consuming daily publishes, how to use drafts for review, the impossibility of editing, credit costs, and prerequisites. No output schema exists, but the description explains the outcome (title card in timeline). Nothing needed for correct invocation is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. However, the description adds significant meaning beyond the schema: it explains the 'hook' field's grouping in post_performance and how to reuse wording or pass a hook id from list_hooks; it explains 'allowLossy' defaults and why it should usually stay off; it details the 'headings' enum behavior (blocks vs text) and the fallback purpose; and it clarifies 'publish' as a draft-saving mechanism. This exceeds baseline by adding actionable semantic context that the schema alone does not provide.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool publishes a long-form Article to X, explicitly distinguishing it from a long POST ('a different thing from a long POST'). It names the resource and the conversion process, and implicitly differentiates from sibling post_to_x. The key distinction is front-loaded, making it easy for an agent to select correctly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance, including using publish:false to save drafts for review, avoiding republishing due to daily caps, and warning against iterating on published articles. It also names edit_x_post as refusing edited articles, guiding the agent to use delete and republish as the only remedy. This level of guidance fully covers when and when-not to use the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• send_whatsapp_messageA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description is exceptionally transparent about side effects and limitations: it cannot see the 24-hour window due to missing webhooks, sends optimistically with possible Meta refusal, bills the business, requires explicit user confirmation, checks variable counts against Meta before dispatch, and clarifies that 'accepted' ≠ 'delivered'. Annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) do not contradict any of this; the description adds substantial context beyond them, including the fact that 0 credits are charged.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but dense, with every sentence providing actionable information. It is well-structured: starts with the core purpose and the two-mode distinction, then constraints (confirm, opt-in), then internal checks and error semantics. It is not as concise as a short one-liner, but the complexity of the tool merits this length. No fluff or redundancy; front-loads key distinctions.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity and the absence of an output schema, the description is remarkably complete. It covers what to do, when to use each mode, side effects, required confirmation, policy prerequisites, error handling, and the meaning of the reply (accepted vs. delivered). Everything an agent needs to invoke this correctly is present, including the 0-credit note.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter has a rich description. The description adds meaningful context: it explains the conditional relationship between template and text, the 24-hour window, and the variable-count check against Meta's components. It also clarifies that components must match placeholders and how media headers/carousels are handled. This goes beyond the schema's static descriptions, justifying a score above the baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this sends a WhatsApp message from the brand's registered number to a customer, and immediately distinguishes the two kinds (template vs. text) based on the 24-hour window. It differentiates from the sibling send_whatsapp_broadcast by emphasizing 'a customer' (individual) and 'registered numbers', making the tool's unique role unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly specifies when to use template vs. text: template for starting a conversation outside the 24-hour window, text only inside the window when the customer initiated contact. It also details the confirm requirement, opt-in policy, and the optimistic-send behavior with a failure mode. This gives an agent precise conditional guidance with clear exclusions and alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_competitor_watchA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description goes well beyond this by detailing that empty list stops the watch and clears findings, that setting is free but running spends credits, that the server trims past 5 brands, that runNow triggers an immediate background run, and that country/platform are inherited. This is rich behavioral context with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence carries essential information: purpose, replacement semantics, credit costs, trimming, runNow behavior, inheritance, and a pointer to the related read tool. It is front-loaded with the core purpose and then details, with no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema and two parameters, the description covers all necessary aspects: what it does, when to use, side effects (credit spending, clearing findings), constraints (max 5, domain requirement), and how to read results. Nothing essential is missing for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema already describes both parameters, but the description adds substantial meaning: competitors is the complete list (replacing old), empty array stops the watch, max 5 trimmed, domain is needed for Google and disambiguates Meta; runNow spends credits now and runs immediately. This goes well beyond the schema's field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool sets or stops a standing competitor watch — a weekly job that re-checks brands' ad libraries and reports new findings. It distinguishes this from sibling tools like list_watch_findings (for reading back) and find_competitors (one-time discovery) by emphasizing the recurring, standing nature.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains when to use it (to set or stop the watch) and provides context about the weekly cadence, credit spending, and that it replaces the whole list. It points to list_watch_findings for reading results, but it does not explicitly state when to prefer a different tool (e.g., find_competitors for one-off searches) — the context is clear but exclusions are only implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_post_refillA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses key behaviors beyond annotations: enabled:false removes the recurring job outright, dryRun defaults to planning-only, and spending behavior is gated by max counts/credits. It also explains that at 0 it only reuses Library renders and costs nothing, which is non-obvious. Annotations only state readOnly=false, destructive=false, idempotent=true, so the description adds substantial behavioral context without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core action and uses ALL CAPS for emphasis on critical rules. It is a bit long but every sentence carries information (pause behavior, dryRun, cadence, spending). Slight verbosity from the capitalization style, but not wasteful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 13 parameters and no output schema, the description covers the most critical operational nuances: Pause vs. disable, dryRun preview flow, and cost control. It references the relevant sibling tools for preview and cancellation, and the schema handles per-parameter details. Nothing essential is missing for an agent to call this correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% so each parameter is already described. The description adds global semantics not in the schema: 'PASS ONLY WHAT CHANGES,' the relationship between posting times and postsPerDay, and the spending logic tied to maxImagesPerDay etc. This goes beyond a baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear verb and resource: 'Turn the automatic posting refill on or off and set how it behaves.' It distinguishes itself from siblings like run_post_refill (preview) and cancel_scheduled (cancel queued posts) by explicitly referencing them, making it unambiguous what this tool does versus its alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit when-to-use and alternative guidance: use cancel_scheduled to remove already-queued posts, read a preview from run_post_refill before disabling dryRun, and notes the cadence comes from brand posting times rather than a numeric parameter. It also instructs 'PASS ONLY WHAT CHANGES,' which clarifies partial-update usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_tiktok_post_ad_authorizationA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining side effects. It does this exceptionally: confirms the ON path is confirm-gated and lists real consequences (privacy change to 'Available for Ads', ad review submission, possible third-party ad appearance, acceptance of Advertising Content Terms). It also warns that OFF is refused while an active Spark Ad exists and that the response is a read-back because TikTok returns an empty body. This is rich, accurate behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence conveys a distinct, necessary fact (code source, confirmation gating, side effects, refusal condition, parameter constraint, read-back answer, auth requirement). It is heavily front-loaded with the most critical insight (where the code comes from). It could be tightened slightly but remains efficient for the complexity involved.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With four parameters, no output schema, and a complex domain, the description covers all essential operational knowledge: prerequisites (TikTok account authorization), the exact parameter constraint, the side effects, the return behavior (read-back of status and code), and how it connects to the larger Spark Ads authorization flow. Nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the purpose of the confirm flag (makes the post publicly promotable and accepts terms on the owner's behalf) and by restating the allowed authorizationDays values as an enforcement note. It also clarifies what the enabled flag does in terms of minting the code. This adds value over the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('turn ON or OFF') and the specific resource (TikTok's 'Ad authorization' setting for a post the authorized account owns), and immediately distinguishes it from the sibling tools for getting, extending, and deleting the same setting. It also names the downstream consumer (authorize_tiktok_ads_spark_post), so an agent can place it precisely in the workflow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly explains when to use this tool (to mint a Spark Ads code for the brand's own post) and when not to (for somebody else's post, you still need a human to copy the string). It names the alternative flow and the downstream tool. It also gives preconditions for turning off (pause active Spark Ad campaigns first) and why the confirm gate exists, leaving no ambiguity about the right context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• update_pinterest_pinA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnlyHint:false, idempotentHint:true, destructiveHint:false), the description discloses critical behavior: the endpoint is beta and may be refused regardless of scopes, media can never be changed, and returned values reflect stored state not sent values. It also states cost (0 credits) and connection requirement. This goes far beyond annotation hints and prevents mismatched expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long (over 100 words) but each section is purposeful: purpose, partial-update rule, two critical limits with alternatives, and behavioral note. It is front-loaded with the action and the 'only send' rule, and the limits are clearly numbered. While not concise, the density of essential warnings justifies the length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with complex constraints (beta availability, immutable media, partial updates, connectivity, cost), the description covers all relevant aspects. It explains what can be edited, what cannot, what to do if refused, how the return values behave, and prerequisites. No missing information is apparent given the schema and annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so each parameter already has a description. The description adds the key usage rule 'Only send the fields that should change' (partial update semantics) and lists the editable fields, reinforcing parameter meaning without redundancy. It does not describe each parameter in detail, but given full schema coverage, this is sufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear verb and resource: 'Edit a published Pin' and enumerates the editable fields (title, description, destination link, alt text, or board). It explicitly differentiates from save_pinterest_pin and delete/re-pin alternatives, making its purpose unambiguous relative to siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit usage rules: 'Only send the fields that should change' and details two limits with concrete fallback actions (save_pinterest_pin for re-boarding, delete+re-pin for media changes or wording when beta refusal occurs). It tells the agent exactly when to use this tool and when to use alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• update_youtube_videoA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate mutation (readOnlyHint false) and non-destructive (destructiveHint false), but the description adds crucial behavioral context: the public visibility warning, the requirement for explicit user confirmation, the 'fields you omit are left untouched' semantics, and the prerequisite of a connected YouTube channel. These go beyond annotations and inform safe usage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is somewhat long but every sentence adds value: it lists the edited fields, gives the critical privacy-flip use case, warns about public visibility, states partial-update behavior, and mentions the channel prerequisite. It is front-loaded with the main purpose and avoids fluff, though it could be tightened slightly by merging the privacy warning and confirmation requirement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 5 parameters, one enum, and no output schema, the description covers all essential operational aspects: what it does, the key use case, safety considerations, partial update behavior, and the prerequisite. Nothing critical is missing for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 80% of parameters with descriptions, so baseline is 3. The description adds meaning for privacy (explains unlisted/public/private implications) and clarifies optionality with 'Fields you omit are left untouched.' However, it does not elaborate on the 'tags' parameter, which lacks a schema description, leaving some gap. Astill beneficial boost over the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool edits an existing video's title, description, tags, or privacy, distinguishing it from post_to_youtube (which creates) and delete_youtube_video. It also highlights the specific privacy-flip use case, making the tool's purpose unambiguous and distinct from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly names post_to_youtube as the alternative and states when to use this tool (to flip an unlisted upload to public). It also instructs to confirm with the user before making a video public, and mentions partial updates. This gives clear when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• x_post_metricsA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint/openWorldHint annotations, the description discloses key behavioral traits: that private metrics are served with the user-context connection, that missing data must never be reported as zero engagement, that it costs credits, and that X must be connected. This is valuable context the annotations do not convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence carries actionable information. It front-loads the core purpose and metric list, then priorities, then caveats. Slightly lengthy, but no fluff or repetition—appropriate for the complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description covers what metrics are returned, when data is missing and how to interpret it, credential prerequisites, cost implications, and how to switch to the correct sibling tool. All critical operational details are present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides detailed descriptions for both parameters (id as numeric post id from URL, publishedAt as epoch ms for 30-day window). The description reinforces the purpose of publishedAt ('inside X's 30-day window instead of costing a refused call') and connects it to the tool's behavior, adding clarity beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear statement of what the tool does: 'Read performance of a post on X' and enumerates the exact metrics (impressions, likes, reposts, etc.). It also distinguishes itself from the retired sibling x_post_insights, making its role unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly instructs 'Prefer this over x_post_insights' and notes that x_post_insights' endpoint family is retired. It also specifies when the private advertiser metrics are available (own posts in last 30 days) and cautions about missing data for deleted/protected/suspended posts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• youtube_video_insightsA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true and destructiveHint=false, and the description reinforces with 'Read-only, 0 credits'. It adds beyond annotations: the 0-credit cost and the prerequisite 'Needs a connected YouTube channel'. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy but each sentence carries distinct value: metrics, use cases, comparison, defaults, auth/cost. It front-loads the core purpose and metrics, then layered context. Slightly long but not wasteful; a well-structured block.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a per-video metrics tool with no output schema, the description covers everything an agent needs: the exact metrics returned, use cases, date filtering, default window, cost, and auth prerequisite. Nothing essential is missing for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 adds useful meaning for videoId by explaining it as 'the v= part of the watch URL, or the videoId returned by post_to_youtube', which goes beyond the schema's generic 'the YouTube video id'. Defaults for startDate/endDate are also echoed, but the videoId clarification is the key added value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb+resource: 'Per-VIDEO performance for a video on the connected channel', then enumerates the exact metrics returned (views, watch time, retention, engagement). Explicitly contrasts with youtube_channel ('cannot answer this'), so an agent can distinguish it from siblings without opening schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Gives concrete use cases: 'how did that video do', 'which upload performed best', 'judge an ad before spending more behind it'. Names the alternative (youtube_channel) and states its limitation. Also mentions date-range customization, leaving no ambiguity about when to call this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• backfill_postsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description discloses the dry-run default and confirmation requirement, the cost quoting, the resumability, and the crucial caveat that imported posts are weaker evidence, labelled 'backfilled', with hooks only recovered under specific conditions. It also warns 'Never guess a hook from a caption.' This is rich, honest behavioral disclosure that goes well beyond the structured annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence earns its place. It front-loads the core purpose, then systematically covers supported channels, exclusions with reasons, the dry-run/confirm/resume workflow, and the evidence caveat. No filler or repetition; the length is justified by the tool's complexity. The structure uses punctuation effectively to keep it readable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 5 parameters, no output schema, and nuanced behavior, the description provides everything an agent needs to call it correctly: what it does, which channels work, why others don't, the default dry-run behavior, how to confirm, how to resume with a cursor, and what happens to imported posts regarding evidence. Even the return value is hinted at ('tells you how many posts it found and what reading them will cost'). Nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all five parameters. However, the description adds essential contextual meaning: it explains that limit caps the page size (default 50, max 200), that cursor is for resuming, and that confirm:true is the flag to actually import while omitting it triggers a dry run. It also clarifies accountRef for multiple accounts. This is meaningful added value beyond the schema fields.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear verb-resource pair: 'Import this brand's PAST posts from a channel into the performance record.' It names the exact purpose (feeding 'which hook works' with history) and lists all supported channels, which distinguishes it from posting, insight, and metrics tools in the sibling set. There is no ambiguity about what this tool accomplishes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit workflow guidance: it runs as a DRY RUN by default, requires confirm:true to import, and uses the returned cursor to resume. It also states the intended scenario ('draw on history rather than only on what was published since Hermoso started recording'), and even explains why certain channels are excluded, which prevents inappropriate attempts. This is far above the minimum.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• billing_statusA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only, free'. It adds critical behavioral context beyond annotations: the price field nuance (billing per plan.period, not monthlyUsd), the member-specific visibility limitation (billingScope:'member'), and the instruction to never tell a member there is no card because it cannot be seen. This is exactly the kind of hidden behavior agents need to know.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence earns its place: it leads with the core purpose, then details the specific fields, then the critical usage caveats. The shared-workspace warning and the instruction about not misreporting card status are essential to correct agent behavior. It is structured front-loaded and thorough without fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given zero required parameters and no output schema, the description must fully explain what the tool returns and any caveats. It covers the plan, balance, auto-reload, card, admin rights, and the nuanced member view. It also explains when to use it relative to other tools. Nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the schema carries no parameter documentation. Per the rubric, 0 params gives a baseline of 4. The description does not need to add parameter meaning since there are none, and it correctly focuses on the output and usage context instead.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb and resource: 'Show this account's billing at a glance' and enumerates the specific data returned (plan id/label/price, credit balance, auto-reload, card on file, admin rights). It explicitly distinguishes itself from sibling tools by saying to call it before upgrade_plan / set_auto_reload, so an agent can easily tell it apart.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells the agent when to use it: 'Call it before upgrade_plan / set_auto_reload' and explains that members have read-only billing, so they cannot change billing. It also provides conditional guidance for shared team workspaces, telling the agent exactly what a member sees and how to answer honestly. This is explicit and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_pinterest_boardA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint: true and readOnlyHint: false, but the description goes much further. It reveals the two-step confirmation flow, the behavior of the unconfirmed call (returns board details without deleting), the requirement to echo back confirmName and confirmChildren to prove intent, the irreversibility, the scope of deletion (pins, followers, collaborators), and the permission nuance making secret boards unavailable. It also notes the 0 credit cost and the Pinterest connection requirement. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence carries essential operational or safety information. It front-loads the critical warning and then walks through the flow. While it could be formatted with bullets or sections for readability, the density is justified by the destructive nature and the complexity of the confirm process. It avoids redundancy and stays focused.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a highly destructive tool with a non-trivial workflow, the description covers everything an agent needs: the precise call sequence, the information returned by the unconfirmed call, the significance of each parameter, the pitfall with the alternative, and the prerequisite (Pinterest connected). There is no output schema, but the description details the unconfirmed response. Comprehensive enough for safe and correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema already describes each parameter (100% coverage), the description enriches them significantly. It explains that confirmName and confirmChildren are echoes from the unconfirmed call and exist to ensure the caller has actually inspected the board. It clarifies why confirm is required ('the board and its Pins are gone for good') and how boardId is sourced from list_pinterest_boards. This goes well beyond the schema text.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly what the tool does: 'PERMANENTLY delete a board AND EVERY PIN ON IT.' It uses a strong verb, specifies the resource, and emphasizes the irreversible scope. It distinguishes itself from sibling tools like delete_pinterest_pin and update_pinterest_board by highlighting the permanent deletion of the entire board and the unsuitability of the privacy alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance: call without confirm first, show results, then call with confirm:true and the echoed values. It also explicitly warns against using update_pinterest_board(privacy:'SECRET') as an alternative, explaining why it fails (missing boards:write_secret permission), and states the reversible option lives in Pinterest's own app. This is exactly the kind of when-to-use/when-not-to-use guidance that helps an agent select and invoke correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_reddit_postA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint and readOnlyHint=false, but the description goes far beyond by explaining that Reddit's delete endpoint returns empty success even for unauthorized posts, that the verdict must come from re-reading the post, and that comments persist. This adds substantial behavioral context not present in annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy, but every sentence conveys essential safety or workflow information. It is heavily front-loaded with the permanent deletion warning and the confirm-first instruction. Slightly verbose, but justified given destructive consequences.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers the full destructive operation: two-call flow, confirmName logic, comment persistence, empty-success behavior, credit cost, and connection requirement. No additional information an agent needs is missing, despite the absence of an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema coverage is 100%, the description adds critical semantic value: it explains that confirmName becomes required once the post has comments or a real score, and clarifies the exact title matching requirement. This is essential for correct invocation that the schema alone does not convey.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States the verb (delete) and specific resource (a Reddit post), and is distinct from other delete_* siblings. The description fully clarifies what is being operated on and the permanent nature of the action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides a precise two-step usage protocol: call without confirm first, show the user the post details, get unambiguous consent, then call again with confirm:true and confirmName. Also notes the prerequisite of Reddit being connected, making it explicit 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.

• delete_telegram_messageA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint=true, so the description adds substantial value beyond that: it explains no preview exists because the Bot API cannot read a message back, that the result is Telegram's own success answer rather than a verified read-back, and details two vendor constraints. It also discloses the confirm requirement and the 'permanent' nature. This is rich behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence serves a purpose: safety flow, no-preview rationale, vendor limits, parameter mapping, credits, and connector requirement. It is front-loaded with the core action and safety warning, and while lengthy, it is succinct given the number of critical details an agent needs.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive tool with no output schema, the description covers everything an agent needs: prerequisites, parameter sources, safety confirmation step, vendor limitations, expected return behavior, and credit cost. Nothing critical is left to guesswork, making it complete for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 valuable context beyond the schema: it explains chatId is the same as used in post_to_telegram, messageId is the one returned by post_to_telegram (also the t.me link number), and reinforces that confirm is required true. This bridges the tool to its companion and clarifies provenance of values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('PERMANENTLY delete one message'), the resource ('a Telegram chat'), and the scope ('the bot posted'). It clearly differentiates from sibling deletion tools like delete_x_post and delete_bluesky_post by specifying Telegram and the bot's own messages.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly explains the safety flow (call without confirm first to preview the sentence, then confirm), vendor limits (48-hour window, channel permission), and how to obtain parameters (same chatId as post_to_telegram, messageId returned by it). Also states prerequisites (Telegram connected) and credit cost. This leaves no doubt about when and how to invoke.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_whatsapp_templateA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as destructive, but the description adds critical specifics: deletion is permanent, covers every language, causes refusal of subsequent sends, and the response must be a re-read from Meta rather than the 200. It also notes the credit cost, all valuable beyond the raw flags.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence carries essential information. The most critical warning (permanence and blast radius) is front-loaded, and the confirmation flow is described in a logical order without repetition. It is dense but efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive operation, it covers all necessary context: the permanent deletion, the multi-language scope, the required confirmation flow, the post-deletion behavior, and the verification method. No output schema exists, but the description explains what to expect. Nothing an agent needs to safely call this tool is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already describes all four parameters with 100% coverage. The description adds the rationale for confirmName (proving you aimed at the right template) and the distinction between confirming action vs. confirming target, which is not in the schema. This adds meaningful context, though the schema already covers the basics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the exact verb 'delete' and resource 'WhatsApp message template', and the permanent nature is immediately clear. It distinguishes from other delete tools by the specific resource and the confirmation flow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit step-by-step guidance: call without confirm first to preview, get user approval, then call with confirm true and confirmName. It also warns about the multi-language blast radius and how to handle the response, leaving no ambiguity about when and how to use the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_youtube_report_jobA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the annotations (destructiveHint=true, readOnlyHint=false, idempotentHint=false) by explaining the exact irreversible consequence: deleting the job discards all accumulated daily CSVs, and a replacement starts with only a 30-day backfill. It also clarifies that without confirm nothing is deleted, and describes the read-back behavior. This is exemplary disclosure of side effects and state changes.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, then immediately follows with the critical irreversible warning, and concludes with crisp procedural steps. Every sentence earns its place—there is no fluff or redundancy. The warning about data loss is placed where the agent will not miss it, and the workflow is stated in clear sequence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description fully covers prerequisites (connected channel), the two-phase confirmation workflow, and the irreversible consequences. It tells the agent exactly what to expect when calling without confirm (job read back) and what deletion entails (loss of historical data). For a destructive tool of this complexity, this is thorough and actionable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (both jobId and confirm have descriptions), so the baseline is 3. The description adds value beyond the schema by explaining the confirm parameter's role in the two-step workflow and reinforcing that jobId comes from list_youtube_report_jobs. It doesn't introduce new syntax, but it contextualizes the parameters effectively.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states the specific action ('Stop' a YouTube bulk reporting job) and the precise resource, which immediately distinguishes it from other delete tools (e.g., delete_x_post, delete_playbook) and from YouTube-related siblings like list_youtube_report_jobs or youtube_bulk_report. The verb 'Stop' aligns with the title's 'Delete' and leaves no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides an explicit two-step protocol: call without confirm to retrieve the job details, then call with confirm:true only after user approval. It also states a prerequisite (needs a connected YouTube channel) and implicitly contrasts with list_youtube_report_jobs by telling where jobId comes from. This leaves no doubt about when and how to use the tool versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• diagnose_postsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces with 'Read-only, 0 credits.' It adds valuable behavioral context not in annotations: that it may return 'nothing here needs fixing' as a real answer, that it cannot see organic post conversions, and that the baseline is built from ALL recorded posts. These details meaningfully improve call quality.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Though long, the description is front-loaded with purpose, uses clear section markers (headers, numbered refusals), and every sentence carries unique information. The structure makes it easy to skim for key rules. The length is justified by the complexity of the diagnostic logic. No redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity, the description is thorough: it covers purpose, usage conditions, the four refusal cases, the converting behavior, output instruction ('Print summary verbatim'), and its read-only nature. There is no output schema, so the description compensates by specifying the call to action. An agent has everything needed to decide when to call and what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers each parameter with descriptions, so baseline is 3. The description adds extra meaning: for limit, it states the baseline always uses every post, not just the limited set, preventing a bad month from becoming its own normal; for converting, it clarifies the condition under which converting:false should be passed and that it should be omitted when unknown. This adds value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'tells you what is WRONG with a given post and where the next edit goes.' It distinguishes itself from sibling post_performance by contrasting 'which hook is AHEAD' vs 'what is WRONG'. This is a specific verb+resource with clear differentiation from similarly named tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly explains when to use this tool versus alternatives. It references post_performance for hook comparison, prescribes the sequence 'mine_angles, then list_hooks, then plan_variations' for hook problems, and details the four refusal conditions that tell the agent when NOT to call the tool. It also specifies when the offer rung runs (only with converting:false). This is exemplary.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• disconnect_connectorA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds significant context: it always drops stored credentials, stops tools immediately, does not affect published posts, and explains that whether the provider grant is revoked depends on the provider (with examples like Threads and Microsoft lacking revocation endpoints). It also discloses that reconnection requires a browser. These details exceed the annotation's coverage and provide critical behavior transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Despite its length, every sentence serves a purpose: the main action is front-loaded, followed by critical effects, provider-specific nuances, and instructions. There is no fluff or repetition; the structure is clear and information-dense without being verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers all essential aspects for correct invocation: the irreversible nature, impact on credentials and posts, provider-dependent revocation, the need for a browser to reconnect, the confirm flag, and where to get provider IDs. Given the destructive nature and complexity, it is fully complete for an agent to act correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by stating that 'confirm' must be true and explaining the 'provider' parameter is 'exactly as list_connectors reports it' with examples. This enriches the schema definitions with practical usage context, warranting a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: disconnecting a third-party account from the workspace, with an explicit list of supported providers. It distinguishes itself from sibling tools like list_connectors by being the action of disconnecting, not listing. The verb 'disconnect' and the resource 'third-party account' are specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage instructions: 'Use list_connectors for the exact provider ids' and 'Name the provider to the user, then call with confirm:true.' It also warns that reconnecting requires a browser and that an agent cannot undo this action, making it clear when and how to use the tool. It names the alternative (list_connectors) and provides the condition for use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• fetch_social_dataA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true and openWorldHint=true, and the description is consistent (fetching data is read-only). Beyond the annotations, the description discloses that it returns RAW provider JSON — large and messy — and that it spends credits. These are meaningful behavioral traits that help the agent anticipate side effects and output format without contradicting any annotation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence earns its place: purpose, example, allowlisted platforms, parameter naming conventions, the warning about raw output, and the credit cost. The most important info is front-loaded, and there is no filler or repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's open-ended nature (generic endpoint, no output schema), the description is complete enough for an agent to decide whether to use it and how to invoke it. It lists the platform families, explains the path/params structure, warns about the raw output, and notes credit consumption. It does not attempt to enumerate every endpoint, which would be unrealistic, but it equips the agent with the necessary guardrails.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (both path and params have descriptions). The description adds practical semantic value by explaining that param names vary per endpoint and providing concrete examples (handle for profiles, query for keyword searches, subreddit for Reddit). This goes beyond the generic schema descriptions and helps the agent construct valid params correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific purpose: a generic escape hatch for any ALLOWLISTED long-tail social/web endpoint not covered by the dedicated search_* tools. It provides a concrete example ({path:'/v1/instagram/profile', params:{handle:'nike'}}) and explicitly distinguishes itself from the search_* siblings, so an agent can tell when to reach for it.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance: use it only for long-tail endpoints not covered by the dedicated search_* tools, and explicitly says 'prefer the dedicated search_* tools' and warns that it 'spends credits.' This clearly states when to use it, when not to, and names the alternative category.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_brandA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint: true, but the description adds value by detailing the content returned (products, logos, palette, positioning, learned memory), the hasBrand indicator, and the fact that it costs 0 credits. It also clarifies the tool's role relative to create tools, which is behavioral context not present in 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the primary purpose, then usage guidance, then a caveat. There is zero filler or redundancy. Every sentence earns its place, providing essential information in a compact form.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no parameters and no output schema, the description needs to cover return semantics and usage context—which it does thoroughly. It states the returned elements (products, logos, palette, positioning, memory), the hasBrand flag, the cost (0 credits), and the relationship to create tools. Nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has 0 parameters, and the schema is empty with 100% coverage. Per the rubric, 0 params gives a baseline of 4. The description doesn't discuss parameters (there are none), but it does clarify what the output contains, which is irrelevant to parameter semantics. Since there are no inputs to document, the score aligns with the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states that this tool returns the saved brand profile (products, logos, palette, positioning) and learned memory for the account/workspace. It clearly differentiates from siblings like list_brands (which lists brands) and draft_brand (onboarding) by focusing on the current saved brand and the hasBrand flag. The verb 'get' is implicit via title, but the description makes the resource and purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: call it to check if a brand is on file, with clear branching (if hasBrand true, omit brand; if false, onboard with draft_brand). Also states when not to use it: not required before a render because create tools read the saved brand automatically. This is strong, actionable usage guidance that distinguishes from alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• instagram_collaboratorsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, destructiveHint, openWorldHint), the description adds substantial behavioral detail: the exact meaning of each status, that a post with no collaborators reports none, that it is read-only and costs 0 credits, and that Instagram sends no notifications. This enriches the agent's understanding of what the tool does and its edge cases.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the core purpose. Each sentence adds value: status explanations, the uniqueness of the tool, how to obtain the ID, the no-collaborator edge case, and the cost/read-only note. No fluff or redundancy; it is thorough without being verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 2 parameters (1 required) and no output schema, the description ensures the agent knows what to expect (a list of collaborators with statuses), how to supply the required mediaId, when to use it, and the edge case of no collaborators. It also confirms the tool is read-only and zero-cost, covering all necessary operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds meaningful context for the mediaId parameter by explaining how to obtain it (from post_to_meta's postId or list_instagram_media), and clarifies that it must be one of the brand's own posts. This goes beyond the schema's simple type descriptions, justifying a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear question ('Did the collab invites on an Instagram post get accepted?') and immediately states it reports every collaborator on a brand's own Instagram post with statuses (Accepted/Pending/Declined). It explicitly differentiates from siblings by naming post_to_meta and list_instagram_media as sources for the media ID, and emphasizes it is the only way to get this information.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  States precisely when to use it: 'This is the tool for “did @creator accept yet?”' and declares it is 'the only way to find out' because Instagram sends no notification. It also specifies it applies only to the brand's OWN posts, and offers alternative sources for the media ID, giving clear contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• instagram_insightsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint and destructiveHint annotations, the description discloses crucial behavioral traits: the deprecation of 'impressions' and the refusal of unknown metrics, the threshold under which demographics are not returned (100 followers/engagements), and the meaning of an absent block (never an empty audience). It also states prerequisites and credit cost.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Although lengthy, the description is front-loaded with the core purpose and alternates, then systematically covers caveats. No sentence is wasted; every clause serves a distinct function. The strong typographic emphasis for deprecation and threshold details aids scannability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (7 params, no output schema), the description is remarkably complete: purpose, alternatives, metric details, deprecation warnings, threshold behavior, prerequisites, and read-only nature. An agent has enough to call it correctly without missing critical caveats.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 semantic value by explaining that demographic metrics require a breakdown and that timeframe applies only to demographic metrics, and clarifies the relationship between metrics and breakdown. This goes beyond the schema's terse descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states an explicit verb ('ACCOUNT-level performance') and resource ('Instagram Business account'), enumerates the metrics returned, and explicitly distinguishes from sibling tools ('Use meta_post_insights for one post and meta_page_insights for the Facebook Page'). An agent can immediately understand scope and uniqueness.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides direct guidance on when to use this tool versus alternatives by naming meta_post_insights and meta_page_insights, and clarifies that it covers account-level data. It also explains that demographic metrics are the 'who' read, giving contextual usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_business_locationsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: the read-only nature is confirmed, and it discloses that the operation costs 0 credits, that a Google Business Profile connection is required, and that only shared listings are visible. It also explains the multi-business scenario (agencies) which is a behavioral caveat not inferable from annotations alone.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-organized: it opens with the core function and output, then explains when to call it with a concrete fallback, then safety considerations, then credit cost and connection requirement. Every sentence adds value, and the length is justified by the richness of guidance. It is front-loaded and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description explicitly lists the return fields (id, title, address, website, Maps link). It covers connection prerequisites, credit cost, usage triggers, fallback steps, and the critical safety behavior of letting the user pick. Nothing an agent needs to call this correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline for parameter semantics is 4 (no params to document). The description doesn't need to add parameter info; it already covers the relevant context. No gap exists.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb (list), a precise resource (Google Business Profile listings shared with this brand), and enumerates the returned fields (id, title, address, website, Maps link). It clearly distinguishes from siblings like get_business_location (single) and list_google_business_posts (posts) by emphasizing the filtering scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: call before posting when more than one listing is shared, and let the user pick. It also gives a fallback procedure for no-shared-listings (list_connector_accounts then set_connector_accounts) and explicitly warns against guessing a listing. This is exemplary usage instruction with clear alternatives and exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_linkedin_pagesA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint annotation, the description adds rich behavioral context: it details the return fields (id, name, role), the empty-case interpretation, and the policy that Hermoso never chooses the page for the user. It also notes the 'free' nature and the possibility of missing organization scopes, which is not covered by annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and efficient: the primary purpose is front-loaded, followed by a critical usage directive and empty-case handling, with no redundant sentences. Every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, parameterless read-only list tool, the description is fully complete. It covers the return shape, when to call it, what an empty result means, and how to respond. No output schema exists, but the described return fields suffice.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the description correctly provides no parameter-level detail. Baseline 4 applies since the schema is empty and the description does not need to compensate for undocumented params.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'List', the resource 'LinkedIn COMPANY PAGES', and the specific output (id, name, role). It explicitly differentiates from the sibling post_to_linkedin_page by mandating this call before publishing when multiple pages exist, 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.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit when-to-use instructions ('ALWAYS call this before post_to_linkedin_page when there is more than one Page'), explains the empty-return meaning (no admin role or missing scopes), and advises against guessing IDs. This fully routes the agent to the correct behavior.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_tiktok_commentsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, destructiveHint, openWorldHint), the description discloses critical behaviors: it returns both public and hidden comments by default, explains the nuance that hidden comments may come from owner hiding vs TikTok's moderation filters (which may refuse to unhide), clarifies that parentCommentId marks replies, and notes the include_replies cap of three. It also states it's read-only and free, reinforcing the annotations without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence earns its place. It front-loads the core purpose, then layers the key behaviors (status, replies, auth) in a logical flow. There is no fluff or repetition; the length is justified by the amount of critical operational detail (e.g., the distinction between types of hidden comments) that would otherwise be missed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 8 parameters and no output schema, the description covers all essential aspects: what the tool does, how to filter, how to identify replies, the reply cap, auth prerequisites, and related tools for more detail. An agent would know exactly how to invoke it correctly and what to expect in terms of behavior. The mention of tiktok_account_status closes a potential operational gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 50%, and the description adds meaningful value for key parameters: it explains the status enum's default behavior (ALL) and its implications, the include_replies cap of three, and the videoId identification from URL path. It doesn't explain cursor, maxCount, sortField, sortOrder, but those are conventional for list tools and the schema already has enum definitions for sortField/sortOrder. The description compensates well for the coverage gap on the most nuanced parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Read the comments') and resource ('a TikTok post the AUTHORIZED ACCOUNT OWNS'), and explicitly positions it as TikTok's answer to list_meta_comments and list_youtube_comments. This clearly differentiates it from sibling tools and leaves no ambiguity about what it operates on.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance (only on owner's posts), explains the status filter to get only public comments, and distinguishes list_tiktok_comment_replies for fetching all replies versus the three-reply cap with include_replies. It also explains the separate authorization requirement and points to tiktok_account_status to check. Nothing is left to inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_whatsapp_accountsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes far beyond the readOnlyHint and openWorldHint annotations. It discloses read-only and zero-credit behavior, explains that only brand-shared accounts are reachable, that failed reads are reported rather than dropped (which could cause misinterpretation of missing accounts), and warns about duplicate display names. This is rich behavioral context not in 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Although the description is longer than typical, every sentence earns its place by conveying critical operational details. It is structured to front-load the core purpose, then sequentially covers caveats, configuration, and billing. No fluff or redundancy; each sentence adds unique information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there is no output schema, the description thoroughly explains what the tool returns (IDs, phone numbers, quality rating) and the implications of that data (send limits, needed by other tools). It also covers error behaviors, naming pitfalls, account selection rules, and credit billing. Everything an agent needs to correctly call and interpret this tool is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the description has no need to elaborate on them. The baseline is 4 for tools with no params. The description does not waste space repeating nonexistent parameters and instead focuses on output semantics, which is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the tool lists WhatsApp Business Accounts shared with the brand, including phone numbers, IDs, and quality ratings. It clearly distinguishes itself from other WhatsApp tools by naming them as consumers of these IDs, and it is unambiguous about the resource and verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit 'Start here' guidance, explains when to use it versus alternatives (e.g., WhatsApp Manager for number registration), and details the behavior when no accounts are ticked, including the way to configure via set_connector_accounts. It also covers the case of a single account making wabaId optional, giving clear actionable context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_youtube_video_statsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare read-only and open-world, but the description adds critical behavioral detail: the endpoint is 'intentionally not atomic', missing videos are simply omitted, and the tool names the missing IDs. This goes beyond the annotations and prepares the agent for a short, non-error response, including the explicit instruction to never report missing IDs as zero.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence serves a purpose: stating the function, use case, input source, the lack-of-titles caveat with a workaround, and the non-atomic behavior. Key facts are front-loaded, and there is no superfluous content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a batch tool without an output schema, the description covers everything an agent needs: it states output includes views/likes/comments, explains how to handle missing videos (they are absent, not zero), and notes the absence of titles while providing a join strategy. It also mentions the tool is read-only and free, aligning with annotations. No critical information is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema coverage, the baseline is 3. The description adds valuable context by specifying that videoIds should come from list_youtube_videos and reiterates the max of 50, which slightly exceeds the schema's description by tying the parameter to a specific source, though it does not explain the part parameter further.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns views, likes, and comment counts for up to 50 videos in one call, and explicitly contrasts it with youtube_video_insights to avoid per-video calls. This makes the purpose and scope unambiguous and distinguishes it from similar tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides a concrete use case ('how are my last twenty uploads doing') and tells the agent to source videoIds from list_youtube_videos. It also explains when to use a different approach (when titles are needed, join with list_youtube_videos) and warns against interpreting missing IDs as zero views, giving clear usage boundaries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• make_thumbnailA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the sparse annotations (readOnlyHint:false, destructiveHint:false), the description discloses rich behavioral traits: refusal behavior when no face photo is attached, credit pricing, free headline overlay, identity lock, bakeText's side effect of garbled text, the default typeset overlay, language translation quirks, tweak chaining, and the requirement to check postRenderCheck. This goes far 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but well-structured with clear headers (CONCEPT, THREE GATES, IDENTITY LOCK, PROMPT LANGUAGE) and bold keywords. It front-loads the purpose and then explains necessary behavioral nuances. It is appropriately detailed for a tool with 32 parameters, but a few sections could be tightened (e.g., the prompt language paragraph is dense). Overall, it's efficient relative to the complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity, no output schema, and the need to guide agents through a multi-step production pipeline, the description covers all essential aspects: concept generation, framework selection, the three gates (identity, text, quantity), identity lock, tweaking, language rules, and the required post-render check. It leaves no significant operational gap for an agent to guess.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema coverage, baseline is 3, but the description substantially enriches parameter meaning. It explains the interplay of framework with hermoso_capabilities, clarifies when castGenericPerson should be true (only after explicit user choice), expands on bakeText, tweak, sourceImage, and reference extraction fields with practical usage context, and grounds each parameter in the production workflow. This adds value well beyond the schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a precise verb ('Render') and resource ('YOUTUBE / Shorts / Instagram THUMBNAIL or video cover') and explicitly differentiates itself from generate_image ('INSTEAD of generate_image'). It also conveys the full pipeline nature, making the tool's scope unmistakable even among a huge sibling set.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use this tool ('for any thumbnail, video cover, video preview or MrBeast-style packaging ask') and names the alternative (generate_image). It also gives conditional guidance for related operations (tweak for edits, hermoso_capabilities for framework details) and clarifies the three gate decisions before rendering.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_instagram_product_tagsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description goes far beyond these hints by detailing Meta's add-or-move semantics, the absence of a delete endpoint, the read-back behavior, the distinction between stored and shown tags, and credit costs. It adds critical behavioral context that the agent cannot infer from annotations alone.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately concise given the complexity. It front-loads the core purpose, then logically explains limitations and behavioral nuances. Every sentence adds value—no fluff or redundancy. The structure is clear and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description fully addresses what an agent needs: what the tool does, how to specify tags, the constraints (max 20, fractions), the read-back nature, and the cost in credits. It also covers error-prone edge cases like the inability to remove tags. Nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  While schema description coverage is 100%, the tool description adds essential meaning: x/y are fractions of the image (0.0 to 1.0), max 20 tags on a feed post, and omitting tags performs a read. It also clarifies pageId omission when a single Page is connected. These details are vital for correct invocation and go beyond the schema's basic descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb+resource: it reads or updates product tags on a published Instagram post. It distinguishes itself from sibling tools by focusing specifically on the product-tag edge, and the title reinforces the same scope. An agent can immediately tell this apart from other Instagram operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly frames when to use the tool: to read tags or to add/move them, and it warns that it cannot remove tags and that deleting the post is the only removal path. It also notes that omitted tags means a read, giving clear invocation guidance. The lack of explicit sibling names is acceptable given the niche scope.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_meta_postA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantial behavioral context beyond that: deletion is permanent, Instagram requires a confirm flow, entire carousel albums are deleted as a unit, and the specific permission reconnection issue. It also explains that refusals name the fix. This is far beyond what annotations provide, so a 5 is warranted.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a dense paragraph but well-organized with target-specific clauses and procedural steps. It front-loads the core purpose and then details per-target behaviors. It could be more structured with bullets, but given the complexity (3 targets, confirmation flow, reconnection), it is efficient and every sentence carries necessary information. Slight deduction for being a wall of text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive multi-target tool with 8 parameters and no output schema, the description covers all critical aspects: platform limitations, the confirmation workflow, what the unconfirmed call returns, carousel handling, reconnection prerequisites, and the call-don't-pre-refuse guidance. An agent can safely and correctly invoke this tool based on the description alone, so it is fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  While schema coverage is 100%, the description enriches parameter meanings significantly: confirmName must be the exact caption line from the unconfirmed call, confirmChildren is the count of carousel cards, postId for Instagram is the media id from list_instagram_media. It explains the two-call flow and how confirm parameters relate to each other, which is not in the schema. This goes well beyond the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear purpose: edit or delete a published post, and immediately breaks down behavior per target (Facebook edit/delete, Threads delete only, Instagram delete only with specific constraints). It distinguishes from any related tool by specifying platform-specific capabilities, so an agent knows exactly what this tool does and doesn't do.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: target-specific actions, the two-call sequence for Instagram (call without confirm first, show user details, then call with confirm), when confirm is required (post has likes/comments), and the reconnection requirement for old connections. Also tells the agent to call rather than pre-refuse, which is a clear directive on usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_sheet_tabsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true, but the description goes far beyond: it warns that deleting destroys everything, requires confirmation with confirmCells, explains the last-tab restriction and its workaround, and states that every action is read back before being reported. This is excellent behavioral disclosure with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence earns its place. It front-loads the purpose, then systematically walks through actions, error handling, safety mechanisms, and fallbacks. No fluff, well-organized, and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (three actions, confirmation, destructions, last-tab edge case) and lack of output schema, the description is remarkably complete. It covers all key behaviors, error paths, and alternatives, leaving no obvious gap for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With only 38% schema coverage, the description compensates well by explaining action values, tab identifiers, and confirm/confirmCells semantics in the delete flow. However, it does not explicitly clarify sheetUrl or spreadsheetId, and confirm's role in rename/add is left implicit. The description adds meaning but does not fully cover all eight parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool adds, renames, or deletes a tab in a Google Spreadsheet. It distinguishes itself from siblings like list_sheet_tabs by specifying the three mutation actions, making its purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit patterns for each action ('action:"add" + title', etc.), explains tab identification by title or sheetId, and details the delete confirmation flow. It also names alternatives (clear, or delete_drive_file for the last tab) and notes error handling with the real list, providing comprehensive usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• moderate_youtube_commentA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds crucial behavioral details: spam is a report (not deletion), delete is permanent with no undelete, only delete is confirm-gated (others reversible), and banAuthor auto-rejects future comments. These are not inferable from the schema or annotations and are essential for safe invocation. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph, but it is information-dense and front-loads the purpose. It could be slightly better structured (e.g., bulleted actions), but every sentence earns its place and there is no fluff. A minor readability improvement would make it a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description fully covers prerequisites (connected channel, commentId source), credit cost (0), action nuances, reversibility, confirmation requirement, and platform-specific restrictions. Nothing an agent needs to call this correctly is omitted.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers all 4 parameters at 100%, but the description enriches semantics: it explains what each action does, that confirm is required for delete, that banAuthor only applies to reject, and where commentId comes from. This goes beyond the bare schema and helps the agent construct valid requests.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb ('moderate') and resource ('a comment on the connected channel'), and immediately identifies the exact action set (publish, hold, reject, spam, delete) with explanations. It explicitly distinguishes this tool from its YouTube twin moderate_meta_comment, making it unambiguous which platform it targets. No other sibling does moderation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: it tells the agent to use reject rather than delete when merely hiding a comment, notes that banAuthor is valid only with reject, and instructs to get commentId from list_youtube_comments. It also clarifies that spam is a report not a removal, so the agent can set user expectations correctly. No important usage context is missing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinterest_ads_async_reportA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds significant behavioral context beyond that: the async pending/token mechanism, Pinterest's date windows per granularity/level, the five-minute link validity and one-hour report expiry, and the meaning of EXPIRED status. This is exactly the kind of disclosure an agent needs and is more than what annotations alone provide.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence delivers actionable information: the differentiator, the use cases, the levels, the async flow, the time windows, and the expiry semantics. It is front-loaded with the core purpose and differentiator, then dives into operational details. No fluff or redundancy; it earns its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 12 parameters, no output schema, and a complex async behavior, the description covers the essential operational aspects: when to use, how the async pending cycle works, token handling, time windows per granularity and level, and the meaning of EXPIRED. It also states read-only and 0 credits, aligning with annotations. The combination of description and schema provides an agent with enough to call the tool correctly, including the non-obvious re-submission rule.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 50% of parameters with descriptions, and the description adds crucial semantics for the token parameter (RESUME a pending report) and explains the meaning of the 'since/until' windows in the context of Pinterest's constraints. It also clarifies how the 'level' parameter interacts with targeting twins. Some parameters like adIds, campaignIds are not detailed, but their purpose is self-evident given the ad-report context. The description meaningfully supplements the schema without repeating it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it is the deep Pinterest ad report that reaches further back (914 days) and carries more metrics than the quick report, explicitly naming the sibling pinterest_ads_report. The verb is implicit but unambiguous ('get the deep report') and the resource is well-defined. It also lists the supported levels, making its scope concrete and distinguishable from other tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly tells the agent when to use it ('anything older than three months, and for revenue questions') and contrasts with the alternative that stops at 90 days. It also explains the async workflow (call again with token, never re-submit without it), which is essential for correct usage. The description leaves no ambiguity about the intended context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pinterest_analyticsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint false), the description discloses critical behaviors: 90-day data retention ('refused here with the reason rather than as an opaque error'), video pin metric differences ('pass video:true'), missing-data semantics ('never a measured zero'), and unknown-metric refusal. It also notes availability on Trial access tier. This far exceeds the annotation coverage and prevents common agent pitfalls.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Although long, every sentence earns its place. It front-loads the core function, then covers differentiation, usage guidance, and limitations. The structure is logical and free of redundancy. Each sentence addresses a distinct aspect—scope, comparison to paid, video variant, board absence, error behavior, data-availability nuance, and access tier—making it highly efficient for its information density.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex 10-parameter tool with no output schema, the description covers all essential contextual aspects: scopes, metric types, date-window limits, video behavior, missing-data rules, unknown-metric handling, and trial access. It also explains the difference between organic and paid, ensuring the agent knows when to use this vs. the ads report. No critical information for correct invocation is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 90%, so the baseline is 3. However, the description adds meaningful context beyond the schema: it explains the purpose of scope:'top_pins' (ranks account's own Pins by sort metric), clarifies video:true for scope:'pin' (video pins have a different metric set), and ties limit to top_pins/top_video_pins. These enrich the parameter meanings beyond the property descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly defines the tool's purpose: 'ORGANIC Pinterest performance — impressions, saves, Pin clicks, outbound clicks and their rates' for multiple scopes (account, top pins, top video pins, one pin). It also names the specific metric types and differentiates from paid analytics by referencing pinterest_ads_report, making it impossible to confuse with siblings like pinterest_ads_async_report or pinterest_targeting_analytics.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear when-to-use guidance: 'This is unpaid reach; pinterest_ads_report covers paid.' It also recommends a specific use case: 'Use scope:"top_pins" to answer "what is actually working on our Pinterest"' and explicitly warns against board analytics ('THERE IS NO BOARD ANALYTICS') to prevent misuse. These are direct usage guidelines with alternatives named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• plan_adA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide only minimal info (readOnlyHint:false, destructiveHint:false). The description carries the burden and delivers rich behavioral context: 'Spends credits,' 'Renders nothing,' hook dropping behavior, duration clamping and stitching logic, and the word-budget behavior. This goes far beyond what annotations declare.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but purposefully so—each paragraph adds crucial operational detail. It front-loads the core purpose in the first sentence, then expands on the most complex parameter (durationSeconds) with concrete examples. While not terse, the length is justified for such a multi-faceted tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 9 parameters, 1 required, no output schema, and no annotations, the description fully compensates. It covers the overall flow, chaining, parameter behavior, edge cases (dropping hooks, clamping, stitching), credit cost, and language handling. An agent has everything needed to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds substantial meaning beyond the schema. For durationSeconds, it explains clamping (4–180), stitching (15+15+10 for 40, 13+4 for 17), and the distinction between one-clip vs stitched rendering. For hook, it explains that specific hooks are dropped if undeliverable (e.g., on-screen text on UGC). For brand, it clarifies fallback to workspace memory. This is significant added value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb (turn...into a finished ad CONCEPT), names the exact deliverables (copy variants, image_concept.prompt or video_storyboard, recipe + model ids), and explicitly disambiguates from generate_image/generate_video by stating 'Renders nothing; chain its output into...'. This is highly specific and distinguishes it from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says when to use the tool (planning phase) and how to chain its output (into generate_image/generate_video). It also covers when to omit durationSeconds based on user mention, when to omit brand to use saved brand, and warns against guessing. It names alternatives like draft_brand for onboarding.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_to_linkedinA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare readOnlyHint=false and other simple flags. The description adds critical behavioral context: the post is published immediately and publicly, requires explicit user consent, and explains that the image must be Hermoso-hosted (upload_file converts any user file). It also covers idempotency behavior for retries and duplicate detection, providing transparency 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence earns its place: it front-loads the critical warning about immediate public publishing, then explains image hosting, duplication prevention, and prerequisites without redundancy. It uses clear formatting (capitalized warnings, explicit instructions) and avoids fluff, making it efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 8 parameters with no output schema, the description covers all necessary context: prerequisites (connected account), key behaviors (immediate publishing, public visibility, user confirmation), image constraints, and safe retry mechanisms. Nothing an agent needs to call the tool correctly is missing, and the rich schema descriptions complement the text.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed descriptions for each parameter including hook, text, subject, imageUrl, imageUrls, visibility, allowDuplicate, and idempotencyKey. The description itself adds extra context for imageUrl (must be Hermoso-hosted, upload_file converts) and idempotencyKey (retry safety), but most parameter meaning is already in the schema. Since the schema carries the heavy load and the description enriches a few, a 4 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a precise action: 'Publish a post to the user’s connected LinkedIn profile' with clear scope (text, optional image). It distinguishes from the sibling post_to_linkedin_page by explicitly mentioning that a carousel requires a company page and directing to that alternative, so an agent can immediately tell which tool to use.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use and when-not-to-use guidance: requires a connected LinkedIn account (with Settings path), warns about immediate public publishing and mandates user confirmation. It also names the alternative post_to_linkedin_page for carousel images, giving a clear exclusion. No other tool alternatives are needed since the purpose is specific.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• product_sizzleA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Despite no annotations (all false), the description fully discloses expensive nature (≈1,040 credits at 1080p), that the hero clip is the only paid leg, that dicing/cards are free, and that the music bed is included. It also reveals subtle behaviors like the paid hero always being 15s regardless of 'seconds', and the requirement for a real packshot to get the label right. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Though longer than typical, every sentence earns its place: purpose, mechanics, cost breakdown, prerequisites, and alternatives. The structure is front-loaded with purpose, then details, then cost, then exclusions. No fluff; the length is justified by the complexity and cost sensitivity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description thoroughly covers purpose, usage, costs, and alternatives. The only gap is that it doesn't state what the tool returns (e.g., a job ID, a video URL, or a completion status). Given the presence of sibling tools like get_job and list_jobs, an agent might infer async behavior, but this is not explicit. Everything else needed to call it correctly is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema covers 100% of parameters, the description adds crucial meaning: resolution cost tables, the fact that 'seconds' only affects packing not the paid render, aspect ratio fallback behavior, and the explicit recommendation on refImage. This goes beyond the schema's simple type/format explanations and helps the agent make cost-aware decisions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States the verb 'Render', the resource 'PRODUCT SIZZLE', and precisely describes the output: an 18-30s music-led video made from a single 15s Seedance hero clip, diced into cuts with typeset spec/CTA cards. It clearly differentiates from siblings by naming render_ad, generate_avatar, and make_template_ad as alternatives with distinct use cases.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Gives explicit when-to-use conditions: for talking/UGC use render_ad or generate_avatar, for cheap deterministic format use make_template_ad. Provides essential prerequisites: pass a real packshot as refImage, confirm spend with user before calling. Also clarifies cost implications and resolution trade-offs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• render_adA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations show readOnlyHint=false and destructiveHint=false, but the description goes far beyond that. It discloses that the tool 'Spends credits', takes '1–3 min' and requires polling, explains the act-splitting algorithm (stitched acts vs single pass), mentions silent fallback behavior for unsupported resolutions, and lists refusal conditions for creator casting. It even reveals that the threshold is model-dependent and suggests using dryRun to see the actual split. This level of behavioral detail is exceptional and gives the agent full insight into constraints and 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long (several paragraphs) but every sentence carries critical operational information: model-specific clip caps, silent fallback, refusal conditions, cost implications, and polling instructions. It is front-loaded with the core recommendation and then systematically covers routing, casting, costs, and timing. While it could be tightened, the density of useful information justifies the length; it is not padded with fluff. Structurally it flows well, with clear sections for routing, casting, and behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a complex tool (13 params, a nested `creative` object, no output schema) yet the description covers all critical aspects: the pipeline quality, the routing algorithm (single pass vs stitched acts), the free dryRun option, the casting workflow with refusal conditions, the cost and time expectations, resolution fallback behavior, and polling via get_job. It even addresses edge cases like clamping and model-specific caps. The only omission is the exact return format, but the instruction to 'keep polling get_job' implies the agent will receive a job identifier, which is sufficient for interaction. For a tool of this complexity, it is remarkably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (every parameter has a description), so baseline is 3. But the description adds substantial context beyond the schema: for `resolution` it warns that not all models offer every tier and that the server silently renders at the best available tier; for `creator` it explains the cost benefit, refusal conditions, and that casting skips portrait generation; for `durationSeconds` it clarifies re-timing vs re-authoring and the clamping range. Each parameter gets operational context that an agent needs to call correctly, far exceeding what the schema alone conveys.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear directive: 'RECOMMENDED for finished video ADS: render a plan_ad concept through the SAME quality pipeline as the Hermoso web Studio'. It specifies the resource (ad video), the action (render), and the input (plan_ad's structured output). It differentiates from siblings like plan_ad (which creates the plan) and generate_video (generic video generation) by focusing on the finished-ad pipeline with specific quality attributes. The purpose is unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states explicitly when to use the tool ('RECOMMENDED for finished video ADS') and when to avoid it (e.g., the description of dryRun for testing before spending). It names alternatives: 'list_creators' for casting, 'get_job' for polling, and implicitly contrasts with plan_ad for re-duration. It gives a concrete workflow: pass plan_ad's output, cast a saved creator, use dryRun to check act splits, then poll. No ambiguity remains for an agent deciding whether to call this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• repost_threadA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that this creates a NEW post, which is a side effect not captured by annotations (destructiveHint=false might mislead, but the description clarifies it does create new content). It also transparently reveals that no un-repost endpoint exists, suggests a possible undo via delete_thread with the returned media id, but warns that Meta does not document it and advises verification. This goes beyond annotations and fully covers behavioral nuances.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence provides necessary information: purpose, usage context, side effects, undo limitations, and prerequisites. There is no redundancy; it front-loads the core intent and then covers operational details efficiently. It earns its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool that creates a new post, it covers the action, the input source, the confirmation step, the lack of documented undo, the cost, and the connectivity requirement. It even mentions the returned media id, which helps in chaining with delete_thread. Given there is no output schema, this description provides sufficient context for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, postId, is fully described in the schema ('the Threads post id to repost'). The description adds value by explaining that it accepts any Threads post id and listing the tools that return such ids, enriching the schema's minimal definition. This justifies a score above the baseline of 3 for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (repost), the resource (existing Threads post), and the target (brand’s own profile). It distinguishes itself from creating new posts by comparing to a retweet and explicitly noting it does not copy text. The mention of 'no way to do it previously' adds context that helps the agent differentiate it from other posting tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance on when to use: it works on any Threads post id and names the sibling tools that return such ids (list_threads_posts, list_threads_mentions, search_threads_keyword). It instructs the agent to get user confirmation before executing, which is a clear behavioral directive. It also states the prerequisite (Threads connected) and the cost (0 credits).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• reschedule_postA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the critical partial-update semantics (omitted fields unchanged, empty string clears), the re-validation against create rules, and the restriction to queued posts. Annotations already indicate it's a mutation (readOnlyHint=false) and idempotent (idempotentHint=true), but the description adds essential context like how to clear fields (e.g., linkedinOrganizationId:'') and that re-validation prevents rule violations. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph that efficiently conveys the purpose, partial-update rule, re-validation, id source, and alternatives. It is front-loaded with the main purpose. While long, it packs essential information without fluff; slightly shorter would be ideal but it's well-structured for the complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (49 parameters, multi-channel, nested objects), the description covers all key aspects: what can be edited, the partial-update rule, chain-of-command for published posts, and source of id. Combined with the rich schema, it's complete for correct invocation. The lack of output schema is not an issue since the description doesn't need to explain return values.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  While the schema has per-parameter descriptions (96% coverage), the description adds a global semantic rule that applies to all params: omitted fields are unchanged, empty strings clear values. This is crucial for correct use and not fully captured by individual param descriptions. It also provides a concrete example (linkedinOrganizationId) to illustrate the rule. This meaningfully extends the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Change') and resource ('a scheduled post'), detailing what can be changed (time, caption, media, channels, target board/Page/company Page/listing). It explicitly limits to QUEUED posts and names alternatives for published posts (manage_meta_post / manage_linkedin_post / delete_x_post), distinguishing it from siblings like schedule_post and cancel_scheduled. This is precise and avoids ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  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 (for queued posts) and when not (published posts), naming the alternative tools. It also instructs to get the id from list_scheduled. This gives clear usage context and exclusions, leaving nothing to inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• retry_scheduledA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide only basic hints (readOnlyHint false, destructiveHint false), so the description carries the full burden of behavioral disclosure. It does this richly: explains partial failures, re-queues as a new post that goes out right away, keeps the original's failure record, refuses to double-post, and handles unresolved outcomes with explicit refusal. No contradiction with annotations; it goes far beyond them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is highly front-loaded, opening with the core purpose and then layering details. Each sentence adds crucial operational or safety information, but the overall length is considerable (600+ words). While dense and necessary for this complex tool, it could be tightened slightly without losing value; still, it eams its place overall.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (multi-channel fan-out, partial failures, safety mechanisms), the description covers all essential behaviors: what happens on retry, what gets refused, how to correct fields, the copy behavior, and the timing of re-queueing. It references list_scheduled for identifying retryable channels, and explicitly names the sibling tool for intentional duplicates. No gaps for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Even though schema coverage is 100%, the description adds significant meaning: it identifies which parameters are for correcting failures (boardId, pageId, linkedinOrganizationId, locationId, message, captions), explains that unspecified fields are copied from the original, and gives detailed semantics for allowDuplicate including its bypass of double-post protection. This goes well beyond the schema's own descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Send a post that FAILED again', a specific verb+resource that immediately distinguishes it from scheduling, rescheduling, or duplicating. It elaborates on partial failures and re-firing only failed channels, and explicitly names duplicate_scheduled as the alternative for intentional resends, so an agent can clearly tell it apart from siblings without inspecting schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance: after a failure, after fixing the cause, and for correcting specific fields in the same call. It also states when NOT to use it (for sending the same thing on purpose, use duplicate_scheduled) and warns about allowDuplicate misuse, leaving no ambiguity about the correct scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• subscribe_meta_webhooksA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true), the description discloses critical runtime behavior: Meta may accept a subscription yet record fewer fields than requested, the tool reads the answer back from Meta rather than relying on the 200, and unsupported fields are refused by name with a reason. It also states the credit cost (0). This adds substantial behavioral context not available in annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but densely informative—every sentence earns its place. It front-loads the core purpose (push vs. poll) and then systematically covers each field, followed by the crucial read-back caveat and refusal behavior. While it could be trimmed slightly without loss, the length is justified by the tool's complexity and the number of field-specific nuances.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity, the description is effectively complete: it explains why to use it (push vs. poll), what each subscription type delivers, how to read events, the risk of partial field recording, and unsupported field handling. There is no output schema, but the description implicitly covers the response by stating the answer is read back from Meta. No essential information for correct invocation is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 100% of parameters, but the description goes much further: it explains each enum value in depth ('feed' includes comments/posts/likes/shares, 'leadgen' triggers on form submission), notes that `pageId` can be omitted when only one Page is connected, and clarifies that fields Hermoso doesn't consume will be rejected. This is far beyond what the schema's terse descriptions provide.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb (subscribe) and resource (a Facebook Page), and enumerates the exact event types (feed, mention, leadgen, messages) with a one-line meaning for each. It also contrasts with polling and references the companion read tool (list_meta_webhook_events), making its purpose unmistakable and clearly distinguishable from sibling webhook tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly frames when to use it: to switch from polling to push-based event delivery, highlighting `messages` as 'THE ONLY WAY to be told about one' and the 24-hour reply window. It points to list_meta_webhook_events for reading what arrived, and clarifies that unsupported fields are refused, guiding an agent on what fields are valid and why to choose 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.

• threads_publishing_limitA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, destructiveHint), the description reveals critical behavioral details: it is read-only and costs 0 credits, requires a connected Threads account, and explains that a null value means 'not reported' rather than zero. It also clarifies that 'none left' and 'could not tell' are distinct answers, which is essential for correct interpretation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose and quota details, followed by usage instructions and a key nuance (null vs 0). Every sentence adds value: it explains why to check, what the output means, and a potential pitfall. It is dense but not verbose, and the structure helps an agent quickly extract the key facts.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter read-only tool with no output schema, the description covers everything an agent needs: what quotas exist, their limits, how to interpret returned values (null vs 0), when to call it, and prerequisites (Threads connected). Nothing material is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has no parameters, so schema coverage is trivially 100%. The description adds no parameter details because there are none, but it clarifies the output structure (used, total, remaining per quota type) which is relevant to interpreting the result. Since the baseline for 0 params is 4, this is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states what the tool does: it reports the brand's Threads quota remaining, enumerating the four quota types (posts, replies, deletions, location searches) with their limits. It clearly distinguishes this from posting or other Threads tools, making it unmistakable what the tool returns.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance: check before any bulk operation and when Threads starts refusing requests. It explains why this is important (quota refusal is otherwise indistinguishable from connection/permission issues) and even advises that reconnecting won't fix it. This is actionable, concrete guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• update_business_locationA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that changes are immediately public on Google Search and Maps with no draft, preview, or undo—details beyond the annotations. It also notes that output-only and immutable fields are refused by name, and that name/address changes carry suspension risk. This is a comprehensive behavioral disclosure that exceeds the annotation hints (destructiveHint, readOnlyHint). No contradiction found.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but densely informative. It front-loads the purpose, then immediately flags the irreversible public effect, then walks through the required two-step confirm process, and covers edge cases. Every sentence adds critical information—no filler. The structure leads the reader from what to how to cautions in a logical order.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (5 params, nested objects, no output schema), the description is complete: it states the prerequisite (Google Business Profile connected), explains the before-and-after retrieval behavior, covers the confirm/dryRun flows, and warns about name/address changes. An agent has all necessary information to invoke this tool correctly and safely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema coverage is 100%, the description adds essential operational meaning: it specifies that `fields` should contain only the changes, keyed by Google's own field names, and lists the valid keys. It also clarifies the confirmName requirement and the role of dryRun. This enriches the schema definitions with practical usage constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear verb ('Change') and resource ('Google Business Profile listing'), enumerating the specific fields that can be modified (hours, phone, website, etc.). This distinguishes it from sibling tools like list_business_locations or get_business_location, which are read-only, and post_to_google_business, which creates new posts. The purpose is unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit procedural guidance: call without confirm first to validate and retrieve current values, then call again with confirm:true after approval. It also explains the dryRun option for validation without writing, and the confirmName requirement for name/address changes, which is a critical prerequisite. This goes beyond mere context and gives a clear when-to-use/how-to-use workflow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• update_docA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint=true, but the description adds essential context beyond that: it explicitly warns that rewrite is destructive, explains the confirm flow, and reveals the failure reporting behavior (zero matches reported as failure, never silent success). It also justifies the index-free design, which helps agents understand constraints. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but each sentence carries meaningful operational detail. It front-loads the core purpose and then systematically explains both modes and their warnings. While not maximally terse, the density of useful information justifies the length; a minor deduction for being more verbose than strictly necessary.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With six parameters, two operation modes, and a destructive rewrite path, the description covers all essential usage guidance: prerequisites (read_doc first), confirmation workflow, error behavior, and the rationale behind index-free edits. Since there is no output schema, the description appropriately focuses on invocation and side effects, making it complete for an agent to call correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 83%, but the description substantially enhances parameter meaning: it explains the two distinct call shapes (replacements array vs rewrite string), clarifies that rewrite:"" empties the document, gives the role of confirm and confirmCells, and notes matchCase:false ignores case. This goes well beyond the bare schema and aids correct invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'EDIT a Google Doc' and explicitly characterizes it as 'the correction append_to_doc cannot make', naming the sibling it differs from. It further distinguishes two concrete modes (replacements and rewrite), so an agent can immediately grasp the verb, resource, and scope without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit step-by-step usage: for replacements it instructs to call read_doc first and match text exactly, including matchCase:false semantics; for rewrite it dictates the two-phase confirm flow (call without confirm to get character count, then confirm:true + confirmCells). It also names the alternative append_to_doc and clarifies when each mode applies.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• upload_fileA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide only basic hints (non-readonly, non-idempotent, non-destructive). The description goes far beyond: error semantics (two sources = error, never silent preference), server-side fetch behavior with private-address refusal and per-hop redirect re-checks, size limits, the fact that bytes never cross the connection for url, and the raw-bytes HTTP route alternative. This fully discloses operational traits an agent needs.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-ordered: purpose and the core 'bring-your-own-creative' concept are front-loaded, then source options with constraints, then tool-specific re-hosting guidance, then return format. Every sentence earns its place, though the raw HTTP route detail (~40 words) is aimed at a developer calling the API directly rather than an AI agent, which trims efficiency slightly. It would benefit from tighter formatting, but there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 4-parameter tool with no output schema and tricky multi-surface behavior, the description is complete: it specifies the return shape ({url, kind, bytes}), all size constraints, per-surface availability, the one-source rule, and the full list of accepting tools. Nothing an agent needs to invoke it correctly is missing, and the no-required-params ambiguity is resolved by the explicit 'exactly ONE source' instruction.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema coverage is 100%, the description adds substantial meaning the schema does not convey: it explains that url always works because Hermoso fetches server-side (so no connection limit), that path is refused on the hosted connector, and that dataUri has a practical 15MB ceiling because bytes travel over the connection. It also clarifies the mutual exclusion of the three source params, which the schema does not state — crucial given no param is marked required.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('persist'), a resource (arbitrary user file), a concrete output (durable public URL), and a size ceiling (150MB). It also sharply differentiates itself from siblings by naming the 'bring-your-own-creative path' for files unrelated to Hermoso renders, and it enumerates every tool that accepts the returned URL. An agent cannot confuse this with the many publish/schedule siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Extremely explicit guidance: when to use it (user-owned creatives, not Hermoso renders), the exact one-source rule with 'passing two is an error', per-parameter selection criteria (url always works incl. hosted connector, path only on stdio/CLI, dataUri under 15MB), and which downstream tools take external URLs directly vs which require re-hosting through this tool. The 'when in doubt, use this' directive removes any ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• x_post_insights_historicalA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations cover safety (readOnly, openWorld, non-destructive), but the description adds crucial operational details: 'COSTS CREDITS PER POST READ', 'Needs X connected', 'Takes up to 25 post ids at once', 'window actually queried is reported back'. It also explains that older posts return nothing rather than zero performance, which is a significant behavioral nuance.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence contributes information: parity with sibling, use cases, limits, defaults, cost warning, and connectivity requirement. The description is front-loaded with the main purpose and uses capitalization for critical warnings, making it efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with four parameters, full schema coverage, and no output schema, the description covers what metrics are returned, limits, default behavior, costs, prerequisites, and the distinction from the sibling. Nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema coverage is 100%, the description adds value beyond the schema by clarifying the ids limit ('up to 25 post ids'), the default date window ('defaults to the last 28 days'), and the reporting of the actual queried window. It does not explicitly explain each parameter individually, but the added context is meaningful.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as advertiser-grade X analytics with a specific list of metrics, and explicitly states it covers 'any date range' distinguishing it from x_post_insights. The phrase 'This is the one to use for...' further clarifies its specific role.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit usage cases ('how did last week’s post do', 'compare these three posts over the month') and contrasts with the sibling tool: 'x_post_insights physically cannot see past yesterday'. It also specifies the alternative, providing clear when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• youtube_bulk_reportA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare readOnlyHint, openWorldHint, and destructiveHint. The description goes far beyond, disclosing the scheduled vs on-demand nature, the 48-hour delay, 30-day backfill, 60-day expiration, and the interpretation of zero rows as missing data rather than zero impressions. This is rich behavioral context that annotations cannot convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy but each sentence delivers essential information. The unique value proposition is front-loaded, followed by the critical scheduling caveat, report list, and data interpretation notes. While dense, it avoids redundancy and earns its length given the tool's complexity; a minor deduction for being unstructured all-caps emphasis that could be tightened.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema and a complex asynchronous behavior, the description fully covers invocation semantics, data availability, common misunderstandings (zero rows, history limits), and differentiation from a sibling. An agent can confidently call this tool and interpret results correctly based solely on the description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover all 5 parameters, but the description adds crucial semantics: the meaning of the 'schedule' boolean (whether to create the job), the behavior for unknown report names (refused with a list), and the data availability implications of days/since/until. It also explains the 'basic' report and the uncapped traffic_source_detail, which are not obvious from the schema alone.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('bulk report') and resource ('YouTube'), enumerates the report types, and explicitly contrasts it with youtube_channel_report as a different API. It also highlights its unique value proposition for thumbnail metrics, making it immediately distinguishable from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly explains when to use this tool vs the alternative (youtube_channel_report), the scheduling mechanism, and the critical caveat that results are not returned on first call. It tells the agent exactly what to expect and what to communicate to the user, leaving no guesswork about invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_meta_catalogA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the destructiveHint annotation, it discloses irreversible deletion, no archive/undo/transfer, the cascade to product sets and ad sets, the read-back result semantics (never Meta's acknowledgement), and the credit cost. This provides deep behavioral context with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy but every sentence earns its place—topics flow from permanence to consequences to confirmation requirements to the prerequisite call to result interpretation and cost. The purpose is front-loaded, and the structure is logical and dense without fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  It covers the entire operational workflow: prerequisite blast radius call, confirmation semantics for non-empty vs. empty catalogs, the live product set block behavior, read-back result interpretation, and cost. No essential information is missing for an agent to call this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema coverage is 100%, the description adds crucial rationale: confirmName proves inspection, confirmChildren when asked, and the live product set override risk. It explains why each safety parameter exists, going well beyond the schema's mechanical descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource — 'PERMANENTLY delete a product catalog' — and immediately distinguishes its destructive, irreversible nature from any other catalog-related tool. It names meta_catalog_blast_radius as a prerequisite, clearly separating the delete action from the inspection tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs to call meta_catalog_blast_radius first and details when confirmName is required (any catalog that holds anything) vs. an empty catalog's one-call delete. It also warns about allowDeleteWithLiveProductSet and not to set it without disclosure, giving clear when-to and when-not-to guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• edit_x_postA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, but the description far exceeds these by detailing behavioral nuances: text replacement, new post ID, edit window, edit limits, Premium requirement, error handling (reports X's refusal), and billing behavior. No contradictions with annotations; adds substantial context beyond structured metadata.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Though lengthy, the description is dense with actionable information, structured with an opening action, numbered key points, and clarifying notes. Every sentence adds value, and critical constraints are front-loaded. It is appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers all operational aspects: prerequisites, X-specific edit model, error handling, billing, and the need to return the new URL. It preempts common mistakes and explains edge cases (articles, edit limits). No output schema exists, but the description sufficiently explains expected outcomes and behaviors.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with clear descriptions for text and postId, but the description enhances both: text is clarified as the complete replacement (matching the edit model), and postId is enriched with 'Pass whichever id the user has' and explanation of the edit chain resolution. This goes beyond the schema's basic definitions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource ('EDIT the text of one of the connected account’s own posts on X'), making the tool's purpose unmistakable. It distinguishes itself naturally from siblings like delete_x_post and post_to_x by focusing on editing existing posts and elaborating on the unique constraints of X's edit model.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use the tool (to edit own posts) and provides critical usage rules: whole-text replacement, new post ID creation, one-hour window, limited edits, and ineligibility of articles. It also explains when the tool will attempt versus report refusal, and the need for Premium and X connection, giving clear conditions for invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• enable_toolsA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already include idempotentHint=true, destructiveHint=false, and readOnlyHint=false, but the description adds valuable behavioral context: how the tool behaves on different host types (stdio/CLI re-read vs. chat fixed roster), that it explicitly reports the limitation rather than false success, and that it never turns anything off and is free/instant. It also explains why ads/analytics are excluded by default (size), which is beyond what annotations could convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy but remarkably dense—every sentence contributes critical information. It front-loads the core purpose, then covers caveats, triggers, and technical details in a logical order. No filler or redundancy; the length is justified by the tool's meta-nature and the need to explain both host behavior and usage triggers.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given this is a tool-enabling tool with only one parameter, the description is exceptionally complete. It explains the full context: why certain groups are excluded by default (size), when to invoke it, how it differs from connect-time configuration, and what to expect in response. An agent has everything needed to correctly decide when and how to call it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% (the only param `groups` has a description), but the description adds far more: it lists all valid group names, gives usage examples with `['ads']` and `['analytics']`, clarifies that unknown names are refused by name, and explains the default exclusions. This goes well beyond schema to fully define the parameter's meaning and accepted values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Switch on a group of tools that is not in this session's roster.' This is a specific verb and resource, and it distinguishes this meta-tool from the many sibling tools that perform content operations. The detailed explanation of how it differs from a connect-time configuration (e.g., `?tools=all`) further clarifies its unique role.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance with concrete examples: 'CALL THIS THE MOMENT YOU NEED ONE' and specific triggers like 'If the user asks to build...an ad campaign, call enable_tools({groups:['ads']}) first.' It also explains when not to rely on it (hosts that don't re-read the tool list) and points to the reliable alternative (`?tools=all`). This is model guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• generate_voiceA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only provide flags (readOnlyHint=false, etc.), which are neutral. The description goes far beyond by disclosing: cost implications ('Paid (a couple of credits by length; ≤900 characters)'), refusal behavior ('a name that engine does not have is REFUSED for free with its real list'), and the fact that some engines generate their own voice and ignore presets, with the reply indicating which voice actually spoke. This adds rich behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Though the description is long, every sentence carries actionable information. It leads with the core purpose and output, then defines scope exclusions, then details parameters, then covers edge cases and cost. There is no fluff, and the structure flows naturally from what to when to how. The density is appropriate for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description must convey the return value, which it does ('return the served MP3 URL'). It covers parameter semantics, defaults, refusals, cost, and character limits. It also references a sibling tool (hermoso_capabilities) for authoritative voice lists. An agent has everything needed to call this tool correctly in all scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, meaning all parameters are described in the schema. The description adds substantial meaning: engine defaults and valid values (seed-audio default, plus others), the relationship between engine and voice presets (preset must belong to engine), and directs the agent to hermoso_capabilities for the full voice list. It also clarifies the character limit and cost model. This goes well beyond the schema's basic field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear, specific purpose: 'RAW text-to-speech from the voice-model catalog: speak a script in a chosen voice and return the served MP3 URL.' It defines the resource (voice-model catalog), the action (speak a script), and the output (MP3 URL). It also explicitly distinguishes itself from sibling tools (render_ad, generate_video, change_voice) by stating what it is NOT for, leaving no ambiguity about its role.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage guidance is explicit: 'For a standalone voiceover / narration clip — NOT for adding audio to a video (render_ad and generate_video voice their own spots; change_voice re-voices a finished clip).' It also describes the engine choices with a default, mentions voice preset behavior, handles edge cases (engines that ignore presets and generate their own voice), and notes the character limit. This gives an agent clear conditions for when to use this tool versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• linkedin_page_analyticsA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, destructiveHint, openWorldHint), the description discloses critical behavioral traits: data lag ('follower figures run about 2 days behind'), data retention ('LinkedIn keeps 12 months'), omission behavior ('OMITS posts with no recorded activity rather than returning zeros'), access refusal ('a Page the account merely administers is refused'), and credit cost ('0 credits'). These are not captured in annotations and are essential for correct interpretation of results. The description also instructs on handling missing data ('report an absent post or an unavailable section as MISSING data, never as zero').

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence carries unique value. It front-loads the purpose and metric list, then the contrast with the paid-report sibling, then parameter semantics, then behavioral caveats. None of the information is redundant with the schema or annotations. Despite its length, it is efficiently structured and no sentence is wasted.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with this complexity (multiple metrics, two operational modes, access constraints, data-quality quirks), the description covers everything an agent needs to call it correctly: what metrics are returned, how to switch to per-post mode, access requirements, data freshness, retention limits, missing-data handling, credit cost, and scopes. There is no output schema, but the description enumerates all returned metrics and even instructs how to report missing entries, leaving no critical gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema covers all parameters (100% coverage), the description adds essential semantic depth: it explains the default for startDate ('28 days ago') and endDate ('today'), the source for organizationId ('from list_linkedin_pages'), and crucially the interaction between postUrns and date range ('LinkedIn forbids a date range together with named posts, so that switches to lifetime-per-post'). This clarifies how parameters influence each other and what values are expected, going well beyond the schema's basic descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear verb and resource: 'ORGANIC performance for one of the brand’s LinkedIn COMPANY PAGES,' then enumerates the specific metrics (followers, views, post engagement). It explicitly contrasts itself with linkedin_ads_report, stating 'It is NOT linkedin_ads_report — that covers PAID campaigns,' which immediately distinguishes it from the sibling tool. The purpose is unambiguous and the scope is precisely defined.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage guidance: it states when to use this tool (for organic Page performance) and when not (for paid campaigns, deferring to linkedin_ads_report). It also explains the prerequisite ('Needs LinkedIn connected with the organization scopes'), access restriction ('Only Pages the user ticked in Manage accounts are readable'), and the behavioral switch when postUrns are provided. It names the alternative explicitly, so an agent knows exactly which tool to choose in different scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• moderate_tiktok_commentA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds substantial nuance: DELETE is permanent and confirm-gated, HIDE is reversible, UNHIDE is not guaranteed because TikTok's own filters may keep it hidden, and the reply reads back real status rather than trusting a 200. This far exceeds what annotations provide and does not contradict them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence earns its place. It front-loads the two critical TikTok enforcement rules in caps, then covers prerequisites and parameter behavior. The structure is easy to scan, with clear sectioning via numbered rules, and there is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with five distinct actions, multiple conditions, and edge cases (delete vs hide, unhide uncertainty, videoId requirements, authorization), the description covers all essential operational aspects. The absence of an output schema is mitigated by the statement that the reply reads back the comment's real status. Nothing an agent needs to invoke this tool correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 75% (commentId, confirm, videoId have descriptions; action only has an enum). The description enriches all parameters: it explains the action enum values' semantics, confirms that confirm is required for DELETE, specifies that videoId is required for HIDE/UNHIDE and helps verify changes, and identifies commentId as coming from list_tiktok_comments. It adds meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a precise verb-resource pair: 'Moderate one comment on a TikTok post the authorized account owns' and enumerates all five actions (LIKE, UNLIKE, HIDE, UNHIDE, DELETE). It clearly distinguishes itself from other moderation tools by scoping to TikTok and to a single comment, leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit decision rules: 'YOU CAN ONLY DELETE A COMMENT THIS ACCOUNT WROTE — anyone else's can be hidden but never deleted, so HIDE is the tool for an unwanted comment from a stranger.' It also states when videoId is required and when it is optional, and mentions the authorization prerequisite via tiktok_account_status. These are concrete, actionable usage conditions that route the agent correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_to_linkedin_pageA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the sparse annotations (readOnlyHint false, openWorldHint true, idempotentHint false, destructiveHint false), the description discloses crucial behavioral traits: it 'PUBLISHES immediately and PUBLICLY' and mandates user confirmation before calling; it explains that media must be Hermoso-hosted and uploaded to LinkedIn; it details the irreversibility of media attachments (image/video/captions/thumbnail cannot be swapped after publishing) while noting copy can be edited via manage_linkedin_post; and it explains link-preview behavior (LinkedIn never scrapes). These are exactly the kind of behavioral caveats an agent needs and the annotations do not provide. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but dense, with every sentence earning its place. It front-loads the core purpose and the most critical decision rules (link vs. text, sibling distinction, public nature) before diving into content-type specifics. The structure leads with the action, then the key caveats, then parameter-level detail, and ends with an alert about immutability. No redundant or filler text; it is appropriately verbose for a tool with 18 parameters.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 18 parameters and no output schema, the description covers all critical usage dimensions: media constraints (hosting, mutual exclusion), link-preview requirements, organization selection, idempotency/safe retries, captions and thumbnails, alt text, visibility defaults, duplicate handling, and the distinction from the sibling. It even hints at response behavior (e.g., 'the reply confirms it was UPLOADED and never that it is visible yet' for captions, and idempotent retries return the original post id). Nothing essential is missing for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema description coverage is 100%, the description adds substantial semantics beyond each parameter's own text. It explains cross-parameter relationships (linkUrl is mutually exclusive with image/video/carousel; captionsSrt requires videoUrl; videoThumbnailUrl is distinct from linkThumbnailUrl), prescribes how to source parameter values (linkTitle/linkDescription/linkThumbnailUrl must be read from the page; organizationId comes from list_linkedin_pages; media must be Hermoso-hosted via upload_file), and clarifies the meaning of array ordering for carousels. This goes well beyond what the schema descriptions alone provide, giving the agent actionable guidance on how to fill each field correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Publish a post to one of the user’s LinkedIn COMPANY PAGES' and enumerates concrete content types (text, image, video, carousel, link post). It explicitly contrasts with the sibling post_to_linkedin ('which publishes to the person’s own profile'), naming the alternative and the selection condition. No ambiguity remains about what this tool does or how it differs from its sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance: 'USE linkUrl WHENEVER THE POINT OF THE POST IS A LINK' with the rationale (LinkedIn disables URL scraping), and it warns against using this tool for personal-profile carousels ('ORGANIC CAROUSELS ARE COMPANY-PAGE ONLY — a personal profile cannot publish one and is refused by name'). It also instructs the agent to pick the correct sibling 'and never substitute.' These are clear decision criteria with no reliance on inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_to_pinterestA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only provide hints (readOnly=false, idempotent=false, destructive=false, openWorld=true), but the description adds critical behavioral context: it PUBLISHES to a public profile, requires confirmation, takes 1-2 minutes for video, and details idempotencyKey behavior for safe retries. This adds substantial value beyond the structured hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Though lengthy, the description is densely informative with zero filler. Each sentence serves a purpose—covering core functionality, prerequisites, carousel specifics, behavioral warnings, and retry logic. The critical scope ('Create a Pin') is front-loaded, and the structure flows logically from what to do to how to do it safely.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (15 params, carousel/multi-slide handling, idempotency), the description covers all necessary aspects for correct invocation: prerequisites, parameter semantics, edge cases, and retry strategies. It does not have an output schema, but the description provides enough context for an agent to act correctly, including asking for required info and confirming before destructive-ish actions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, but the description enriches every parameter with use-case rationale: explains why link is important, how boardId selection works, how carousel imageUrls order matters, and the grouping semantics of hook/subject. It clearly explains edge cases like altText behavior on carousels, which the schema alone does not convey.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Create a Pin on one of the user’s Pinterest boards' and specifies the media types (image, video, carousel). It clearly differentiates from sibling tools by naming the platform and action, and is immediately distinguishable even from other post_to_* tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description includes explicit usage guidance: calls out that boardId is required and instructs to call list_pinterest_boards first, advises confirming the board/title/link before publishing, notes that Pinterest must be connected, and explains behavior for video ingestion and idempotent retries. This goes beyond mere context to actionable when-to-use steps.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_to_telegramA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only indicate a non-read-only, non-idempotent write operation. The description goes far beyond: it discloses that Hermoso uploads bytes rather than handing links, explains the differing size limits (10MB photo vs 50MB video vs link limits), states the bot must be present in the chat, describes refusal behavior, and explains the return value (message id, t.me link or null for private groups). It also discloses credit cost and connection steps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but perfectly structured with bolded section headings (WHICH CHAT, TEXT, MEDIA, THE BOT MUST BE IN THE CHAT) and front-loads the most critical rule (chatId required). Every sentence adds value – no fluff. The use of CAPS and clear logical flow makes it dense yet navigable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 7 parameters and no output schema, the description covers everything an agent needs: parameter semantics, error conditions, permission requirements, return structure, and even setup instructions. It anticipates edge cases (private group null url, caption not being a message). Nothing is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema coverage is 100%, the description enriches every parameter: chatId's format and default-absence, text length drop with media, media upload method, album mixing, silent's non-visibility nature, and disablePreview's default. This goes well beyond the schema's brief strings.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Publish to a Telegram channel, group or chat as the brand's own bot' – a specific verb, resource, and actor. It distinguishes itself from siblings like list_telegram_chats (which reports chats) and delete_telegram_message (which removes). The purpose is unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states that chatId is 'ALWAYS REQUIRED and is NEVER GUESSED', and directs the agent to 'ask the user, or use list_telegram_chats' as an alternative. It also clarifies that list_telegram_chats is 'NOT a roster', so a chat missing from it can still be posted to. This is explicit when-to-use vs. when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_instagram_hashtagA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare safe/read-only/open-world hints, but the description adds critical behavioral context: uses brand Meta credentials (not scraper), only public non-promoted posts, no chronological order, results bounded by data size not post count, and per-account budget of 30 unique hashtags per rolling 7 days. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Long but every sentence earns its place; no fluff. Purpose is front-loaded, edges separated, caveats (short result vs small tag) and budget explained in tight, scannable blocks. The use of caps for key warnings aids comprehension without losing brevity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (Instagram quirks, budget, edge behavior), the description covers everything an agent needs to call it correctly and interpret results: return fields, edge semantics, data-size pagination caveat, budget limits, and the 'recent' empty result trap. No output schema needed since returned fields are stated.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Even though schema describes parameters 100%, the description enriches each: tag format examples and exact-match rule, edge semantics and when to switch, limit explanation about carousel-heavy pages returning fewer rows, and pageId's role in budget attribution. Goes well beyond schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool reads public Instagram hashtag posts including caption, media, permalink, and counts, distinguishing it from generic search tools. It explicitly frames the use case (category/competitor listening) and differentiates itself from siblings by focusing on hashtags and Meta credentials.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use scenarios (e.g., market listening, feeding captions into mine_angles) and when-not (avoid misinterpreting empty results). Clearly explains the edge:'recent' vs edge:'top' decision rule and the 'recent' 24-hour limit, plus budget considerations — all actionable guidance beyond the schema.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• threads_insightsA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context beyond that: the unknown-metric refusal behavior, the metric set differences, the lifetime-metric window behavior, the demographics floor of 100 followers, and the clarification that an absent demographics block means under Meta's floor rather than empty audience. This is rich, useful transparency that helps the agent anticipate tool responses.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence is necessary and dense with useful information. It front-loads the primary purpose, then adds edge-case behaviors and constraints. There is no fluff – each clause adds value, making it efficient given the complexity it covers.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only analytics tool with no output schema, the description is remarkably complete. It covers scope logic, metric differences, window behavior, error handling (refusing unknown metrics), demographic floor, and the meaning of absent blocks. Nothing an agent needs to invoke it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  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, but the tool description adds significant cross-parameter meaning: how postId determines scope, that since/until only apply to account scope, that breakdown is required by follower_demographics and must be exactly one, and that metrics lists differ between scopes. This goes well beyond the schema's individual descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states exactly what the tool does: 'Performance for ONE Threads post ... or for the whole ACCOUNT when it is omitted.' It lists concrete metrics (views, likes, replies, reposts, quotes, shares, clicks, followers_count, follower_demographics) and explicitly distinguishes the two scopes, clearly differentiating it from siblings like instagram_insights or meta_post_insights.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance on when to omit postId (account-level), notes that metric sets differ by scope, explains that since/until narrow only the account window, and warns that followers_count and follower_demographics are lifetime metrics that ignore the window. It also clarifies that an unknown metric is refused by name, preventing misuse. While it doesn't name alternative tools, it fully specifies its own usage conditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• youtube_channel_reportA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true. The description goes beyond annotations by explaining that demographics returns only viewerPercentage and nothing else, warning against converting to absolute viewers. It also clarifies that capped reports are top N, and that zero rows means missing data, not zero views. No contradictions with annotations; the description adds substantial behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-structured: it starts with the core purpose, then lists reports with parenthetical explanations, and ends with critical caveats. Every sentence carries information that aids correct usage. It is long but appropriately so given the complexity of 17 different reports. Front-loaded with the key differentiator and the most useful report. No fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity (17 reports, 6 parameters, no output schema), the description is remarkably complete. It covers report selection, parameter interactions (parent, videoIds), behavior on unknown reports, and important data interpretation caveats. The absence of an output schema is compensated by telling the agent what to expect in terms of data shape (e.g., demographics returns viewerPercentage only) and limits. An agent can call this tool correctly without needing further clarification.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. However, the description adds extensive meaning beyond the schema: it explains the practical purpose of the report enum (e.g., trafficSourceDetail requires parent), defines 'parent' as required by *Detail reports with examples, clarifies that audienceRetention requires exactly ONE video, and notes the caps per report. The description enriches the parameters with context that the schema alone does not provide.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies what the tool does: it provides YouTube analytics broken down by dimension, explicitly contrasting it with youtube_channel (totals) and youtube_video_insights (one video, flat). It lists all reports and their meanings. This is a specific verb+resource with full clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  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 versus alternatives: 'the questions youtube_channel (totals) and youtube_video_insights (one video, flat) cannot answer.' It also gives practical guidance on choosing reports (e.g., trafficSource is the most useful for judging thumbnail/title), how to scope with videoIds, and warns about unknown report names being refused with a list. It provides clarity on when to omit videoIds (whole channel) and the requirement for audienceRetention to use exactly one video.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.