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

No annotations were provided, so the description carries the full burden. It discloses key behavioral traits: owner-only access with 403 for non-owners, requirement for 'pending' status, and the return of updated draft with per-platform publish results. This is comprehensive for a mutating tool.

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

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

The description is concise yet information-dense, with every sentence contributing: main action, permission, usage context, state requirement, return value, and alternative. It is well-structured 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.

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

The tool is moderately complex (approve + publish, owner-only), and the description covers all critical aspects: what, when, prerequisites, permissions, return value, and alternative. No output schema exists, but the description adequately explains what to expect from the response.

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

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

Schema coverage is 100% for the single draftId parameter. The description adds value by stating the prerequisite that the draft must be in 'pending' status and how to find the ID ('Find it via list_drafts or get_draft'), which supplements the schema's minimal description.

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

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

The description clearly states the specific action: 'Approve a pending draft AND publish it immediately to its target platforms.' It distinguishes itself from sibling tools by explicitly naming approve_and_schedule for scheduled publishing, making the purpose unambiguous.

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

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

Provides explicit usage guidance including example user phrases ('publish this now', 'send it out'), a precondition (draft must be in 'pending' status), and an alternative ('For scheduled publishing instead, use approve_and_schedule'). This clearly informs 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.

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

With no annotations provided, the description carries full behavioral disclosure. It reveals owner-only restriction, cron-based execution ('checks every minute'), catch-up behavior if the server was down, timezone selection logic, and the pending-status requirement. It does not cover error handling or mutation of draft state beyond scheduling, but the disclosed details are substantial.

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

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

The description is well-structured and front-loaded with the main purpose. Each sentence adds value: usage examples, alternative tool, cron behavior, timezone rule, and status prerequisite are all relevant and succinctly stated.

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

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

The description covers the essential contexts for scheduling: when to use, conditions, execution mechanics, and a key alternative. It stops short of describing error states or the return format, but given the absence of an output schema and the complexity of the action, it remains largely complete.

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

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

Although the input schema already provides 100% parameter coverage, the description adds meaningful context beyond the schema: the timezone precedence rule ('use user's stated timezone if they give one, otherwise workspace timezone') and a precondition for the draft's status. This enriches the parameter semantics.

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

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

The description clearly states the tool approves a pending draft and schedules it for future publication, using a specific verb and target. It also explicitly distinguishes from the sibling tool approve_and_publish_now, ensuring no ambiguity.

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

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

The description provides explicit usage guidance: 'Use this when the user wants to queue a post' with concrete examples, and excludes immediate publishing with a direct pointer to the alternative tool. It also states the precondition that the draft must be in 'pending' status.

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

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

With no annotations, the description carries the full responsibility for behavioral disclosure. It discloses the main side effect: 'This opens the user's browser to the consent screen.' It also provides context about automatic triggering from other tools. However, it does not mention what happens after successful authentication (e.g., session token, return value), which is a minor gap for a tool with no 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.

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

The description is exactly three sentences, each with a distinct purpose: action, trigger, and exclusions. It is front-loaded with the core behavior in the first sentence, and every sentence adds value without redundancy. There is no fluff or repetition of schema information.

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

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

For a zero-parameter tool with no output schema, the description covers the essential aspects: what it does, when to use it, and a key side effect. The only missing piece is confirmation of what the tool returns after completion, but given the simplicity and the clear triggers, the description is sufficiently complete. It even explains why it is often unnecessary, which is valuable contextual guidance.

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

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

The tool has zero parameters, and the schema confirms this with an empty properties object. The description correctly does not attempt to explain parameters. With no parameters, there is nothing for the description to add, and the baseline score of 4 is appropriate.

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

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

The description clearly states the action: 'Explicitly start the Vibe Marketing sign-in flow.' The verb 'start' and the specific resource 'sign-in flow' make the purpose unambiguous. It also distinguishes this tool from content-focused siblings like get_draft or create_draft by noting that other tools auto-trigger this flow, so it is a unique utility tool.

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

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

Explicit usage guidance is provided: 'Use this when the user says something like "connect to vibe marketing" or after `disconnect`.' It also gives an exclusion: 'Most other tools will trigger this automatically if not already connected, so you usually don't need to call it directly.' This clearly states when to use and when not to, fulfilling the dimension fully.

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

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

With no annotations, the description carries full burden. It discloses that the draft lands in 'pending' status, does not auto-publish, requires publicly accessible media URLs, and notes that uploading from chat is not supported. It also mentions the Review queue, giving useful side-effect context.

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

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

The description is well-structured: a clear opening statement, then flow of how the draft is created and what happens after. Each sentence contributes meaningful information without redundancy.

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

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

While the description is comprehensive about creation behavior and post-creation workflow, it does not explicitly state the return value/shape of the created draft. In the absence of an output schema, this would be helpful for agents to handle the response.

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

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

The description adds critical context beyond the schema: it lists required parameters, explains contentType semantics, and constrains mediaItems to publicly accessible URLs. The 'uploading not supported' nuance is not present in the schema and is essential for correct invocation.

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

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

The description starts with 'Create a new draft post in the user's Vibe Marketing workspace,' clearly stating the verb and resource. It also distinguishes this tool from siblings by noting that the draft does NOT publish automatically, contrasting with publish/approve tools.

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

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

It explicitly says 'Use this whenever the user wants to draft a social post.' It also references approve_and_publish_now / approve_and_schedule as the next steps, providing alternative tools and clarifying when this tool is appropriate.

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

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

With no annotations, the description carries full burden and excels. It discloses that tokens are forgotten locally, the user will be re-prompted on the next API call, and that the grant is NOT revoked server-side. This is critical behavioral 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.

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

Four short, information-dense sentences. Every sentence adds value: what it does, consequence, non-revocation clarification with alternative, and usage trigger. No unnecessary fluff.

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

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

For a zero-parameter tool with no output schema, this description is complete. It covers the action, local scope, consequence, limitation, and usage context, making it fully sufficient for an agent to select and invoke correctly.

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

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

The tool has no parameters and schema coverage is 100% (empty schema). The description adds no parameter-specific details, but none are needed. Per rubric, 0 params baselines at 4, and the description doesn't need to compensate.

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

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

The description uses a specific verb ('Forget') and resource ('locally stored Vibe Marketing tokens'), clearly distinguishing it from siblings like connect and whoami. It also explicitly states what it does not do (revoke server-side), adding further clarity.

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

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

Explicitly states when to use the tool ('when the user says log out, disconnect, or forget my credentials') and provides an alternative for full revocation (Settings → Connected Apps). 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.

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

With no annotations provided, the description carries the full burden and does so well. It discloses the timezone handling, sorts results by effective time (scheduledFor if scheduled, publishedAt if published, submittedAt otherwise), and explicitly states it returns an empty array when no drafts exist (never 404). These details go beyond the schema and provide crucial operational context.

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

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

The description is three sentences, front-loaded with the primary purpose, followed by usage examples, then return behavior. Every sentence contributes meaningful information without redundancy or fluff, making it an exemplar of conciseness and structure.

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

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

Despite having no output schema, the description tells the agent exactly what to expect: a full Draft[] sorted by effective time, empty array if no drafts, and the timezone context. With only three parameters, this covers all necessary operational details for successful invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that 'day' is interpreted in the workspace's timezone and by referencing that filters have the same semantics as list_drafts, which helps calibrate expectations. This goes beyond merely restating the schema.

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

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

The description uses the specific verb 'Fetch' and clearly identifies the resource as 'all drafts for a single calendar day' with timezone scope. It distinguishes the tool from siblings like get_calendar_week (single day vs. week) and list_drafts (day-specific vs. general listing).

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

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

The description provides explicit usage examples: 'what's going out tomorrow', 'show me Friday's posts', and 'inspect a specific date in the calendar.' It also notes that optional filters mirror list_drafts. However, it does not explicitly state when not to use it or point to get_calendar_week for multi-day queries, so it misses the 'when-not/alternatives' criterion for a 5.

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

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

With no annotations, the description carries the transparency burden. It discloses the return shape, the exact 7-day array length, the sampling behavior (NOT the full list), and the server-side 400 error for non-Monday weekStart. It could add more about authentication or rate limits, but for a read operation, these are the most critical behavioral details.

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

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

The description is four sentences, front-loading the core purpose and then delivering return format, constraints, and alternatives in a logical order. No wasted words; every sentence adds value.

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

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

Given there is no output schema, the description appropriately details the return shape and key constraints. It explains the 7-day guarantee and the sample-of-drafts behavior. However, it does not explain how status/platform parameters affect the aggregate, which leaves a gap in the overall context for such a complex tool.

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

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

Schema description coverage is only 33% (only weekStart has a description). The description adds the Monday constraint for weekStart, but entirely omits the semantics of the 'status' and 'platform' array parameters. The agent is left to guess whether these are filters, inclusion lists, or something else. Given the low schema coverage, the description should have compensated but did not.

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

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

The description clearly states the tool fetches a weekly calendar aggregate, distinguishing it from get_calendar_day by explicitly noting the latter is for drilling into a specific day. The return format is specified, so the agent knows 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.

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

Provides explicit usage guidance: 'Use this for "what's my week look like" type queries' and directs to get_calendar_day for day-level detail. This clearly differentiates when to use this tool versus the sibling.

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

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

With no annotations, the description carries the full burden of disclosure. It explains the full returned state (publish results if published, rejection info if rejected), the 404 scenario for workspace mismatch or soft-deletion, and the caveat that deleted drafts can be fetched via list. This is rich behavioral context beyond a simple 'get' statement.

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

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

The description is concise, front-loaded with the core action, and then adds useful details in a logical order (return contents, usage guidance, error behavior). Every sentence contributes value, with no redundancy or filler.

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

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

For a simple single-parameter tool with no output schema, the description covers the primary function, return value composition, error conditions, and the edge case of deleted drafts. It fully equips an agent to invoke the tool correctly and interpret the response.

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

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

The schema already documents the sole parameter draftId as 'The draft id (UUID).' with 100% coverage. The description does not add new parameter semantics beyond the schema, which is acceptable per the baseline when schema coverage is high. No additional parameter-level detail is needed.

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

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

The description clearly states the action: 'Fetch a single draft by id.' It also enumerates the returned content (mediaItems, platformOverrides, publish results, rejection info), which distinguishes it from sibling tools like list_drafts (listing) and get_draft_audit (audit). The verb-resource pairing 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.

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

The description explicitly says 'Use this when the user references a specific draft and you need its full state.' It also mentions the 404 condition and provides guidance for fetching deleted drafts via list_drafts with status:['deleted']. This gives clear when-to-use context and implicitly distinguishes from listing tools.

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

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

With no annotations provided, the description carries full burden. It discloses that the tool returns an ordered list of audit events with timestamps and actor names, and notes the types of events (submit, approve/reject/schedule/publish). It does not mention permissions, error conditions, or whether it is strictly read-only, but the read-only fetch nature is strongly implied.

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

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

Three sentences pack the core function, usage cues, and return value without waste. The description is front-loaded with the primary action and resource, making it easy to scan.

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

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

The tool is simple with one parameter and no output schema, but the description explains the return format and enumerates the event types. Combined with sibling context, it is fully adequate for an agent to select and invoke the tool correctly.

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

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

The schema covers 100% of the single parameter (draftId) with a clear description. The tool description itself does not add further parameter-level detail, but the schema is sufficient, so the baseline of 3 applies.

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

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

The description clearly states the tool fetches the audit trail for a single draft, with a specific verb and resource. It distinguishes itself from siblings like get_draft and list_drafts by focusing on audit events rather than content or listing.

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

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

The description provides explicit when-to-use guidance with real user queries ('what happened to this draft', 'who approved this') and debugging scenarios. It does not explicitly mention when-not-to-use or name alternative tools, but the context is clear enough to guide selection.

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

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

No annotations are present, so the description carries the full burden. It thoroughly discloses key behavioral traits: soft-deleted rows are hidden by default, pagination via cursor and nextCursor, total count before pagination, and role-based visibility (employees see own drafts, owners/reviewers see all). This is extensive and valuable.

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

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

While the description is fairly long, every sentence provides necessary information: scope, example triggers, return shape with pagination details, hidden deleted status, and access control. There is no fluff or repetition, and it is logically structured 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.

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 fully explains the return structure ({ drafts, nextCursor, total }) and pagination behavior. It also covers optional filters, default limit, deleted row handling, and role-based visibility, making it complete for a list tool with 7 optional parameters.

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

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

The input schema has 100% parameter description coverage, so the baseline is 3. However, the tool description adds meaning beyond the schema by stating 'All filters are optional and AND together' and clarifying that status='deleted' is hidden by default, which is not in the schema. It also explains cursor usage for pagination, reinforcing the schema's description.

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

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

The description clearly states 'List drafts in the user's workspace' with a specific verb and resource, and gives concrete example user queries. It distinguishes from sibling tools like get_draft by focusing on listing multiple drafts with filtering and pagination.

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

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

It explicitly says 'Use this whenever the user asks...' with several concrete trigger phrases, providing strong usage guidance. It does not explicitly mention alternatives or when not to use it, but the context and scope make those clear.

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

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

With no annotations, the description carries the full burden. It discloses the return type (Notification[]), sorting (newest first), row cap (200), per-user scoping, and the semantics of unsurfacedOnly. This is highly transparent for a read-only list operation.

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

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

The description is concise and well-structured: it front-loads the purpose, then details behavior and parameter usage. Every sentence adds value with no redundancy.

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

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

Given the tool's simplicity (one optional parameter, no output schema, no nested objects), the description fully covers what the tool does, what it returns, and how to filter results. No significant gaps remain.

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

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

The schema already describes the only parameter, but the description adds meaningful context by equating unsurfacedOnly to the 'unread bell badge' and clarifying its default behavior. This enriches the parameter's meaning beyond the schema.

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

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

The description clearly states the tool lists the current user's notifications, scoped to the workspace, with explicit examples of intended queries. It is specific and distinct from all sibling tools, which focus on drafts, calendar, and other resources.

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

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

The description explicitly says when to use the tool with example queries like 'do I have any notifications' and 'what got rejected recently', and provides guidance on the unsurfacedOnly flag for unread notifications. No alternative tools exist for notifications, so exclusion guidance is unnecessary.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses what the tool returns (base URL and version) and explicitly states 'No auth required,' which are valuable behavioral traits beyond the simple 'ping' name.

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

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

Two concise sentences, front-loaded with purpose, then return value, auth hint, and usage scenario. Every sentence earns its place; no redundancy or filler.

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

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

For a simple health-check tool with no params and no output schema, the description fully covers purpose, return value, auth, and usage context. Nothing meaningful is missing.

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

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

The tool has zero parameters and schema coverage is 100%. Per rubric, a 0-parameter tool scores a baseline 4, and the description adds no unnecessary parameter details.

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

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

The description clearly states the tool verifies server reachability, which is a specific verb-resource combination. It distinguishes itself from siblings by focusing on connectivity health, unlike the content-related tools (get_draft, approve_and_publish_now, etc.).

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

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

Explicitly tells the agent when to use it ('if you suspect connectivity issues before assuming a deeper failure'), providing clear context. It does not mention alternatives, but for a ping/health check, the usage guidance is sufficiently targeted.

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

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

With no annotations, the description carries full burden and delivers: it notes the owner-only restriction, that rejection is undoable via the web UI undo journal for ~10 seconds, that the reason/comment surface in the employee's view, and that the draft must be pending. These are concrete behavioral details that help an agent understand 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.

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

The description is compact and front-loaded: it starts with the primary action and outcome, then gives usage triggers, parameter guidance, and behavioral caveats in a logical order. Every sentence adds value; no fluff or repetition.

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

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

Given the tool's moderate complexity (3 params, no annotations, no output schema), the description covers all essential aspects: purpose, when to use, parameter semantics, status precondition, permission (owner-only), and undo behavior. It is thorough enough for an agent to invoke the tool correctly without additional context.

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

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

Although schema coverage is 100%, the description adds meaning beyond the schema: it explains that the reason and comment both surface in the employee's view, and that if none of the five reason categories fit, one should set reason to null and use the comment. This clarifies parameter usage in a way the raw schema does not.

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

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

The description clearly states the tool's action: 'Reject a pending draft so the submitter knows it won't publish.' It uses a specific verb ('reject') and resource ('draft'), and distinguishes itself from sibling approve tools by focusing on rejection. The phrase 'so the submitter knows it won't publish' adds outcome clarity.

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

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

The description provides explicit usage triggers: 'Use when the user says "reject this", "this one's no good", or describes a problem with a draft.' It also clarifies when to use the optional reason categories versus null/comment, and states the draft must be in 'pending' status. This is strong guidance beyond generic 'when to use'.

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

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

With no annotations provided, the description carries the full burden of disclosure. It reveals a significant side effect—triggering the consent flow if not connected—and outlines the return content. This is valuable transparency for a tool that might otherwise seem purely informational.

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

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

The description is two sentences, both directly informative. The first sentence states the core function and its notable trigger behavior; the second offers concrete example user queries. No filler or redundant phrasing, with the most critical information front-loaded.

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

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

For a simple tool with no parameters and no output schema, the description covers the essential points: what it returns, the side-effect of consent flow, and when to use it. It omits the exact response format, but the listed fields give enough context for an agent to interpret the result. Sibling tools like connect/disconnect further contextualize its role.

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

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

The tool has zero parameters, and the description correctly avoids explaining any inputs. It instead details the output fields (workspace, scopes, timestamps), which adds value beyond the trivial empty schema. The baseline for 0-parameter tools is 4, and the description meets that.

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

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

The description uses a specific verb ('Return') and names a clear resource ('info about the active Vibe Marketing connection'), enumerating exactly what data is included. This unambiguously distinguishes it from sibling tools like ping or connect, making the tool's purpose obvious.

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

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

The description explicitly lists the user-phrased triggers ('am I connected' or 'which workspace am I using') for when to use the tool. While it doesn't name alternative tools or state when not to use it, the provided use cases give clear contextual guidance.

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