SendIt

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

The annotations indicate readOnlyHint=false and openWorldHint=true, implying potential side effects or external effects, but the description does not clarify what these side effects might be. It also does not mention return format, required permissions, or any behavioral details beyond the basic analysis action, so the agent is left uninformed about the tool's non-read-only nature.

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

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

The description is a single, well-structured sentence that front-loads the action and lists the analysis areas concisely. Every word is useful and there is no unnecessary detail.

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

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

The tool has no output schema, and the description does not describe what the analysis returns or what side effects occur. Since annotations suggest a non-read-only and open-world nature, the description should explain what changes or outputs result from the analysis, but it only lists topics without clarifying the outcome or execution context.

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

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

The schema has only 50% description coverage, with projectId left undocumented. The description does not mention either parameter (projectId or team_id) and provides no guidance on how to specify the project for analysis, offering no added meaning beyond the bare schema.

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

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

The description clearly states that the tool analyzes a project and specifies the dimensions covered (audience, positioning, differentiators, content pillars, risks). However, it does not differentiate from the sibling tool 'get_project_analysis', which likely has a similar purpose, so it misses the opportunity to distinguish itself.

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

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

No guidance is provided on when to use this tool versus alternatives. The description only implies generic usage for project analysis, with no mention of prerequisites, exclusions, or related tools such as 'get_project_analysis' or 'generate_project_strategy'.

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

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

Annotations indicate this is a write operation (readOnlyHint=false) and not idempotent, but the description adds the key behavioral consequence: 'Once approved, it will be published at the scheduled time.' This goes beyond the structured annotations by clarifying the downstream effect, though it does not discuss reversibility or permission requirements.

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

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

The description is two sentences, front-loaded with the primary action and followed by a concise consequence. Every word earns its place, with no redundant or vague 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?

Given the simple input schema, strong annotations, and no output schema, the description provides sufficient context: it names the resource, the condition ('pending approval'), and the post-approval behavior. It does not mention return values, but for an action-oriented tool this is not a critical gap.

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

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

Schema description coverage is 100%, with clear descriptions for postId, comment, and team_id. The tool description itself adds no parameter details, but because the schema already thoroughly documents each parameter, 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.

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 scheduled post that is pending approval,' identifying both the verb and resource. It also explains the outcome ('published at the scheduled time'), but it does not explicitly differentiate from the sibling tool reject_post, so it stops short of a 5.

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

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

The description implies the usage context: it is for approving pending scheduled posts. However, it does not provide explicit guidance on when to use this tool versus alternatives such as reject_post or list_pending_approvals, nor does it mention exclusions or prerequisites.

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

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

Annotations already establish this is a mutating operation (readOnlyHint=false) but not destructive (destructiveHint=false). The description adds context that approval can be bulk or per-item and supports rejection with feedback. It also signals the next step in the workflow, giving 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.

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

The description is two sentences with no filler. The first sentence states the core functionality; the second provides a critical next-step pointer. Every word earns its place.

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

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

For a tool that alters approval state, the description covers the main actions and next step. It lacks information about the return value or how to inspect pending items, but given the absence of an output schema and the straightforward nature, it's sufficiently complete. It could mention that planId approves all pending, but that's implied.

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?

All four parameters are fully described in the schema (100% coverage), so the description doesn't need to repeat them. It does clarify the two usage modes (bulk via planId vs individual via itemId and feedback), which adds semantic meaning to how the parameters should be used together.

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 all pending items in an autopilot plan or approves/rejects individual items, using specific verbs (approve/reject) and a clear resource (autopilot plan). It distinguishes from siblings by focusing on plan-level approval and mentioning the follow-up execute 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?

The description explicitly directs the user to use autopilot_execute_plan after approval, providing clear sequential guidance. It implies this tool is for the approval phase, but doesn't explicitly contrast with alternatives like approve_post or list_pending_approvals, though its scope is evident.

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

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

The description adds meaningful behavioral context beyond the annotations: posts are spaced out over time and go through the standard publishing pipeline. This explains the side effects implied by openWorldHint and readOnlyHint=false, though it does not detail error cases or confirmation behavior.

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

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

The description is two sentences, front-loads the core action, and includes only relevant detail about spacing and the pipeline. Every sentence earns its place with no redundant content.

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

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

For a simple one-parameter tool with informative annotations, the description covers the essential behavior and pipeline context. It does not explain return values or edge cases like an empty plan, but no output schema exists to set a higher expectation.

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 already provides full coverage (100%) for the single parameter planId, and the description adds no additional meaning beyond confirming it refers to the autopilot plan. This meets the baseline for high schema coverage.

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

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

The description clearly states the action (schedule) and the resource (all approved posts in an autopilot plan), distinguishing it from sibling tools like autopilot_generate_plan or autopilot_approve_plan. The second sentence clarifies the scheduling behavior.

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 phrase 'approved posts' provides clear context that the plan must be approved before execution, implying a sequential relationship with autopilot_approve_plan. However, it does not explicitly mention when not to use this tool or name alternatives like bulk_schedule.

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

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

Annotations already indicate this is a mutating, open-world operation. The description adds behavioral context beyond annotations by detailing the 5-agent chain and that the output is for review, not execution. This explains the internal process and intent without contradicting the annotations. No annotation contradiction.

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

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

The description is three sentences, front-loaded with the core action, then adds the agent chain and output purpose. Every sentence earns its place with no redundancy or 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?

With no output schema, the description explicitly states what is returned ('a plan with individual post items for review'), which is essential. It also provides enough process context (agent chain) for an agent to set expectations. It could be more complete by noting that the plan is not yet approved or scheduled, but 'for review' implies this and sibling tools cover approval.

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% for both parameters (goalId and weekNumber), so the schema already documents their meaning. The description adds minimal parameter context—'weekly' aligns with weekNumber but does not clarify defaults or auto-increment behavior 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.

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

The description uses a specific verb and resource: 'Generate a weekly content plan for an autopilot goal.' It clearly indicates the scope (weekly, autopilot goal) and distinguishes from sibling tools like autopilot_execute_plan and autopilot_approve_plan by stating it returns a plan for review. The agent chain further clarifies the purpose.

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

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

The description gives clear context: this is for generating a weekly plan for an autopilot goal, implying use before approve/execute steps. However, it does not explicitly mention alternatives or when not to use it (e.g., for manual content generation, use generate_content instead). This misses the 'explicit alternatives' bar 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the exact kinds of progress metrics returned (weeks planned, posts approved, scheduled, published), which is useful behavioral context beyond the safety flags.

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

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

The description is a single, front-loaded sentence that immediately states the action and object, followed by the metric list. No wasted words.

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

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

For a simple read-only getter with one parameter, the description adequately covers the tool's purpose and returns. It lists the specific progress metrics, and given the absence of an output schema, this is sufficient contextual information.

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% coverage for its single parameter goalId, with a straightforward description. The tool description does not add additional semantic detail about the parameter, 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.

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

The description uses a specific verb and resource ('get progress metrics for an autopilot goal') and enumerates the metric types (weeks planned, posts approved, scheduled, published). This clearly distinguishes it from sibling tools like autopilot_list_goals or autopilot_execute_plan.

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

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

The description provides clear context: use this tool when you need progress metrics for an autopilot goal. It does not explicitly name alternatives or exclusions, but the purpose is specific enough to infer when to apply it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description carries little additional burden. It adds the scope 'current user' but does not disclose return format, pagination, or ordering. This is not a contradiction, and the annotations cover safety.

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

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

The description is a single, focused sentence: 'List all autopilot goals for the current user.' Every word adds value and there is no redundancy or 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?

Given the tool has zero parameters, no output schema, and annotations confirming read-only behavior, the description fully captures the action and scope. There is nothing further needed for an agent to use this 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 input schema has zero parameters, so the baseline per rubric is 4. The description correctly notes it lists all goals without requiring parameters, but it doesn't need to add further 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 verb 'List', the resource 'autopilot goals', and the scope 'for the current user'. This unambiguously differentiates it from sibling tools that set, execute, or generate plans.

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

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

The description implies the use case (retrieving all goals for the current user) but provides no explicit comparison to alternatives or when-not-to-use guidance. For a simple read-only list tool, the context is clear, so implied usage is acceptable.

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

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

Annotations indicate this is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds valuable behavioral context by explaining the side effects: the autopilot will use AI agents to plan and schedule content, which goes beyond the annotation safety profile. It also gives concrete examples of acceptable goals.

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: a clear first sentence states the purpose, a second explains behavior, and a third provides examples. No redundant or filler content.

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

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

Given the tool has 4 parameters (two required), nested objects, and no output schema, the description covers the core purpose and workflow. It does not mention whether approval or planning are separate steps, but the sibling tools (autopilot_generate_plan, autopilot_approve_plan) imply a larger workflow. The description is sufficient for an agent to decide when to use this tool.

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

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

The input schema covers 100% of parameters with descriptions, so the schema largely carries the burden. The description adds example goals and names platforms in the example, which slightly enriches the goalText and platforms semantics, but it does not provide additional detail for durationWeeks or targetMetrics 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's function: 'Set a social media goal for the AI autopilot to work toward.' It uses a specific verb and resource, and distinguishes it from related tools like autopilot_list_goals or create_goal by focusing on the autopilot context.

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

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

The description provides clear context by explaining how the autopilot will work toward the goal ('use AI agents to plan content, generate posts, and schedule them'). It gives example goals that illustrate appropriate use, but does not explicitly mention when not to use it or compare with alternative tools like autopilot_generate_plan.

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

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

Adds valuable behavioral context beyond annotations: the validation-first workflow (validate_only:true then false), safety default (validate_only defaults true), and skip_errors semantics. No contradiction with annotations.

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

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

Well-structured with clear sections (USE THIS WHEN, CSV FORMAT, OPTIONAL COLUMNS, PROCESS). Each section adds necessary information without redundancy; concise and scannable.

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?

Complete for a complex bulk operation: includes use cases, input format expectations, validation steps, and parameter semantics. No output schema is present, but the description does not need to explain returns given the operational focus.

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

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

Schema coverage is 100%, and the description enhances this by detailing the exact CSV required columns (platform, scheduled_time, text) and optional columns (media_url, first_comment, hashtags). It also clarifies the meaning of validate_only and skip_errors within the workflow.

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 'Schedule multiple posts at once from CSV content' with a specific verb, resource, and scope. The 'USE THIS WHEN' section further clarifies intended use cases, distinguishing it from single-post scheduling 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?

Explicit 'USE THIS WHEN' section lists concrete scenarios (spreadsheet/list, content calendar, migrating content). The PROCESS section provides step-by-step guidance on validating before executing, offering clear operational recommendations.

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

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

Annotations already provide readOnly/destructive hints; the description adds the list of action categories but does not disclose partial-failure behavior, recurrence scope implications, or side effects beyond the action list. It does not contradict annotations.

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

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

The description is a single, front-loaded sentence that efficiently communicates the core purpose without filler or redundancy.

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

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

Despite having 10 parameters and no output schema, the description stays minimal. It doesn't address important contextual aspects like the 200-item cap, potential partial failures, or behavior of actions that require additional fields (e.g., assign). The rich schema compensates somewhat, but the description could provide more high-level 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?

Schema coverage is high (90%), so parameters are well-documented. The description adds no syntax or constraint details beyond what the schema provides, only mapping the action list. It meets the baseline without adding parameter-specific value.

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

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

The description clearly states the tool performs a single bulk action across many calendar events, enumerating specific action types (shifts, reschedules, queue moves, cancellations, assignments). This distinguishes it from single-event update_calendar_event and bulk_schedule.

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 phrase 'many calendar events at once' implies the use case for bulk operations, contrasting with single-event tools. However, it does not explicitly mention when not to use it or point to alternatives like update_calendar_event for individual updates.

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

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

The description adds a meaningful behavioral detail beyond the destructive annotation: it specifically stops 'future pending occurrences' from publishing, implying past occurrences remain unchanged. It does not clarify reversibility or effects on the series record itself, but 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.

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

The description is a single concise sentence that front-loads the action and result. No redundant words or unnecessary details.

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

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

With full parameter documentation and annotations indicating destructive behavior, the description is adequate for tool selection and invocation. It could be improved by noting that past published posts are unaffected, but the current description is sufficient for a simple cancellation action.

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 already defines all parameters with descriptions (100% coverage), so the description does not need to explain them. The description adds no parameter-specific semantics beyond the schema.

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

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

The description uses a specific verb ('Cancel') and identifies the resource ('recurring series') along with the precise effect ('stop future pending occurrences from publishing'). This clearly distinguishes it from sibling tools like update_recurring_series and delete_scheduled_post.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or alternative tools such as updating the series or deleting individual occurrences.

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

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

The annotations already declare the tool read-only, idempotent, and non-destructive. The description adds the specific status values returned and the presence of a result URL upon completion, which provides useful behavioral context beyond the annotations. It does not detail error handling or polling behavior, but the core safety and result traits are covered.

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

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

The description is two sentences long, front-loaded with the action and followed by return details. Every word earns its place, with no unnecessary elaboration 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?

For a simple one-parameter read-only tool with no output schema, the description adequately explains the return values (status categories and result URL). It does not mention error cases or how to interpret a 'failed' status, but given the tool's simplicity and the annotations, it is sufficiently complete for an agent to use it correctly.

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

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

The input schema has 100% coverage for the single parameter, including a description ('The AI media job ID to check'). The tool description adds no new information about the parameter beyond what the schema provides, so it meets the baseline for high schema coverage.

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

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

The description clearly states the tool checks the status of an AI media generation job and lists the possible statuses (pending, processing, completed, failed), making its purpose specific and distinct from sibling tools like generate_ai_media. The verb 'check' plus the resource 'status of an AI media generation job' is precise and not tautological.

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

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

The description implies the tool is used to query the status of an AI media generation job, but it does not explicitly state when to use it (e.g., after generate_ai_media) or provide exclusions or alternatives. There is no mention of how to obtain a job_id or when not to use it, so 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.

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

The description adds requirement context (account connection, whitelisting) beyond the annotations, but it does not disclose side effects or the broader implications of marking a goal complete/incomplete. It does not contradict the destructiveHint annotation, but the added behavioral detail is minimal.

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

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

The description is concise and well-structured, with a clear action statement followed by a bulleted requirements list. Every sentence carries necessary information, and there is no fluff or redundancy.

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

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

For a simple two-parameter mutation tool with robust annotations and schema, the description covers the essential usage prerequisites. It omits details about return values or side effects, but these are not critical given the available schema and annotations.

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

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

Schema coverage is 100%, and the schema descriptions for goalId and completed are clear. The description adds no additional meaning beyond the action itself, 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.

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

The description clearly states the tool's function with a specific verb ('Mark') and resource ('Product Hunt goal'), explicitly covering both complete and incomplete states. This differentiates it from sibling tools like create_goal, which focus on goal creation.

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 prerequisites (connected account, app whitelisting) that are useful for usage, but it does not explicitly indicate when to use this tool versus alternatives like autopilot_set_goal or create_goal. The usage context is implied but not differentiated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description confirms the tool is a read-only schema retrieval and mentions credential types (API key or token), but it does not add further behavioral context such as prerequisites, rate limits, or side effects. With annotations doing the heavy lifting, this is adequate but not enriched.

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

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

The description is a single, 12-word sentence that front-loads the action ('Get') and resource. Every word is informative, with no filler or redundant phrasing.

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 very simple: no parameters, no output schema, and strong annotations. The description adequately communicates the purpose and the nature of the returned value (a schema). It could optionally clarify the exact format of the schema, but for a straightforward retrieval tool with safe annotations, this is sufficiently complete.

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

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

The tool has zero parameters, so schema description coverage is trivially 100%. According to the rubric, 0 params earns a baseline of 4. The description's mention of 'API key or token credentials' hints at the schema content, but since there are no parameters, no additional parameter semantics are 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 tool's function: 'Get the credential setup schema to connect Bluesky using API key or token credentials.' It uses the specific verb 'Get', names the exact resource (credential setup schema), and identifies the target platform (Bluesky), distinguishing it from other connect_* sibling tools that target different platforms or perform actual connections.

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

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

The description implies this tool is used before connecting Bluesky (since it retrieves the credential schema), but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions. The context is clear but the guidance is 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.

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

The description credibly discloses side effects for OAuth2, API key, and webhook connectors: returning an authorization URL, storing the key, and registering the webhook URL. However, the bot_token auth strategy is entirely omitted, leaving a gap in behavioral coverage.

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 with the core purpose. The subsequent lines efficiently enumerate auth-type behaviors without redundancy. Every sentence contributes 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?

The tool is a generic connector connection tool, but the description fails to mention the bot_token auth strategy included in the schema. It also does not describe return values for API key or webhook flows, nor does it provide context on idempotency or prerequisites, leaving important operational details unclear.

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

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

Schema coverage is 100%, so the schema already describes apiKey, botToken, and webhookUrl. The description adds minimal parameter-related meaning by associating auth types with behavior, but it omits the botToken parameter entirely and does not clarify which parameters are mutually exclusive.

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 initiates an authentication flow for a connector, with specific behavior per auth type. It distinguishes itself from the many connect_* siblings by being generic and connector-driven, rather than platform-specific.

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

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

No guidance is given on when to use this generic connector tool versus the numerous platform-specific connect_* siblings (e.g., connect_slack, connect_telegram). It does not mention prerequisites, exclusions, or alternative tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context that it returns a credential setup schema and supports API key or token credentials. However, it does not disclose any further behavioral details such as what the schema structure looks like or any prerequisites, so the added value beyond annotations is limited.

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

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

The description is a single, well-structured sentence that front-loads the core action ('Get the credential setup schema') and includes only relevant details (platform and credential types). Every word earns its place, with 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?

For a tool with zero parameters and no output schema, the description fully captures the tool's purpose and scope. It clearly distinguishes that this is a schema retrieval action, not the actual connection process, and specifies the credential types. No further information is necessary 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.

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

The input schema is empty (0 parameters), so schema coverage is trivially 100%. The description adds meaningful context by explaining that the tool returns a schema for setting up credentials using API key or token, which clarifies the tool's purpose despite having no parameters. This aligns with the baseline of 4 for zero-parameter tools.

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

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

The description clearly states the tool's function: 'Get the credential setup schema to connect DEV.to'. It uses a specific verb ('Get') and resource ('credential setup schema'), and distinguishes itself from sibling connect_* tools by naming the specific platform (DEV.to) and the credential types (API key or token).

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

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

The description provides clear context: this tool is for retrieving the credential schema needed to connect DEV.to. While it doesn't explicitly exclude alternative tools, the platform-specific naming (DEV.to) among many connect_* siblings makes the intended usage unambiguous. No exclusions or when-not guidance are given, 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.

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

Annotations already declare non-destructive, idempotent, open-world, and read-only behavior. The description adds that it retrieves a 'webhook setup schema', but does not disclose potential side effects, prerequisites, or what the schema contains. It adds minimal behavioral nuance beyond annotations.

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

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

The description is a single concise sentence that front-loads the action ('Get') and object ('webhook setup schema'). Every word contributes to clarity with no filler.

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

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

Given the simple nature (no parameters, no output schema) and rich annotations, the description sufficiently explains the tool's purpose. It could possibly mention that this is a preparatory step and not an actual connection, but the wording already implies that by saying 'to connect Discord'.

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

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

The tool has zero parameters, so the baseline is 4. The description adds meaning by framing the return as a schema for webhook setup, which helps the agent anticipate the response even though no parameters exist.

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 ('Get') and resource ('webhook setup schema') clearly tied to Discord, distinguishing it from sibling connect_* tools for other platforms. It precisely communicates the tool's function without 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 phrase 'to connect Discord' implies the tool is used as a preparatory step for integrating Discord, and the sibling context suggests it is specific to Discord among similar tools. However, it lacks explicit exclusions or alternative tool mentions.

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

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

Annotations already communicate readOnlyHint=true and idempotentHint=true, and the description is consistent with these. It adds the behavioral context that it returns a URL for connecting a Dribbble account, but does not disclose additional details such as whether user interaction is required or whether it initiates a background flow. Given the strong annotation coverage, the description adds acceptable but not extensive value.

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

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

The description is a single, front-loaded sentence that conveys the essential information without any filler. Every word earns its place, 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.

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

Given the tool's simplicity—no parameters, no output schema, and low complexity—the description is complete. It tells the agent exactly what the tool returns (OAuth URL) and for what purpose (connecting Dribbble). Nothing essential is missing.

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

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

The input schema has zero parameters, so there is nothing to explain. The description adds semantic context by indicating the output type (OAuth URL) and purpose, which is more than the empty schema provides. A score of 4 reflects the baseline for a no-parameter tool with clear 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 tool's purpose: to 'Get the OAuth URL to connect your Dribbble account.' The verb 'Get' is specific and the resource (OAuth URL) and context (connecting Dribbble) are explicit. It also implicitly distinguishes itself from sibling connect_* tools by naming the platform.

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

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

The description implies usage: when the user wants to connect their Dribbble account, this tool returns the OAuth URL. However, it does not explicitly state when to use this over other connect_* alternatives, nor does it mention any exclusions or prerequisites. The purpose is clear but guidance on when/why it should be chosen is minimal.

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

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

Annotations already declare the tool as readOnly, idempotent, and non-destructive. The description adds the OAuth URL context but does not disclose additional behaviors such as URL expiration, required redirect handling, or any side effects. It does not contradict annotations.

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

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

The description is a single concise sentence that front-loads the action ('Get the OAuth URL') and states the purpose. Every word serves a function, with no unnecessary detail.

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

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

For a zero-parameter tool with no output schema, the description adequately conveys the tool's purpose and expected return (a URL). Given the simple complexity, the description is complete and leaves no ambiguous gaps for an agent to misinterpret.

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

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

The tool has zero parameters, so the description adds no parameter semantics, but the baseline for 0 params is 4. The schema already covers all (vacuous) parameters, and the description's mention of 'your Facebook account' implies no extra inputs are 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 tool's function with a specific verb and resource: 'Get the OAuth URL to connect your Facebook account.' This distinguishes it from sibling connect_* tools for other platforms by explicitly naming Facebook.

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

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

The description implies use for Facebook connection but provides no explicit guidance on when to use vs. alternatives like connect_platform or connect_connector. The purpose is clear from the name, but no when-not-to-use or alternative tools are mentioned, leaving the agent to infer.

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

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

Annotations already declare the operation is read-only, idempotent, and non-destructive. The description adds that it returns an OAuth URL, which is consistent. No contradictory or additional behavioral context needed for a simple URL-fetching 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?

A single, front-loaded sentence communicates exactly what the tool does with no wasted words. Ideal conciseness.

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

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

For a parameterless tool with strong annotations and no output schema, the description fully covers what the tool does and what it returns. No missing context.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. Per rubric, 0 params earns a baseline 4; the description adds nothing needed about parameters since there are none.

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 ('Get') and clear resource ('OAuth URL to connect your Google My Business account'), fully distinguishing it from sibling connect_* 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.

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

The description clearly states the tool connects Google My Business, and given the many sibling platform-specific connect tools, usage context is clear. It doesn't explicitly exclude other tools, but the platform-specific naming makes alternatives 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?

Annotations already mark it as read-only, open-world, idempotent, and non-destructive. The description adds context by specifying the return type (credential setup schema) and accepted credential types (API key/token), going beyond the structured 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.

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

A single, clear sentence that immediately states the purpose and the credential types. No filler, no redundancy, and the key information is 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 zero-parameter, read-only schema retrieval tool, the description is sufficient. It explains the core purpose and output type, though it does not detail the schema's structure; this is acceptable given the tool's simplicity and lack of an output schema.

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

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

The tool has zero parameters and the schema is an empty object, so there is nothing to document. The description mentions credential types, which provides useful context even though no parameters exist.

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 returns the credential setup schema for Hashnode, using specific verbs and resource naming. It distinguishes itself from sibling connect_* tools by clarifying it retrieves a schema rather than performing a connection.

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

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

The description implies this tool is used to get credential schema for connecting Hashnode, but provides no explicit when-to-use or alternatives guidance. It does not mention related tools like get_platform_settings_schema or actual connect actions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds that the tool returns a URL (OAuth URL), which is useful context beyond annotations. However, it does not disclose details like whether user interaction is required after obtaining the URL or how the result should be handled.

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

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

The description is a single sentence of 9 words with no redundant information. It is front-loaded with the action ('Get the OAuth URL') and immediately clarifies the purpose ('to connect your Instagram account'). Every word earns its place.

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

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

For a simple tool with no parameters, no output schema, and minimal annotations, the description adequately explains the return value (an OAuth URL) and the intended action. It does not explain what to do with the URL, but for a connector tool this is likely self-evident. The description is complete enough for an agent to select and invoke it correctly.

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

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

With zero parameters, the input schema is fully covered (100%). The baseline for 0 params is 4, and the description's mention of 'your Instagram account' adds no parameter-specific meaning but is not needed. No further explanation is required.

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

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

The description clearly states the tool's function: 'Get the OAuth URL to connect your Instagram account.' It uses a specific verb ('Get') and resource ('OAuth URL') and explicitly mentions 'Instagram account,' distinguishing it from other connect_* 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.

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

The context is clear: this tool is used to obtain an OAuth URL for connecting Instagram. Sibling tools like connect_facebook or connect_twitter exist, but the description implies the use case without explicitly listing exclusions or alternatives. This meets the 'clear context, no exclusions' bar.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with these. It adds modest context by mentioning API key/token credentials, but does not disclose further behavioral traits such as whether the schema is static or dynamic, or any rate limits. With annotations covering safety, 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.

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

The description is a single, front-loaded sentence with no redundant information. Every word contributes to understanding the tool's 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?

This is a simple, parameterless read-only tool with no output schema. The description fully explains what it does and what it returns (a credential setup schema). Combined with strong annotations, no further context is needed.

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

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

The tool has zero parameters, so the baseline is 4. The description adds value by specifying that the credential setup schema involves API key or token credentials, which gives semantic meaning beyond the empty 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 verb 'Get' and the resource 'credential setup schema' for Lemmy, specifying it uses API key or token credentials. This distinguishes it from other connect_* tools by naming the specific platform and the type of output.

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

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

The description implies this tool is used to fetch the credential schema when connecting Lemmy, but it does not explicitly state when to use it over alternatives like connect_platform or get_platform_settings_schema. No exclusions or alternative tools are mentioned.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the OAuth context and account connection purpose, but does not disclose additional behaviors such as URL expiration, redirect requirements, or any side effects.

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

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

The description is a single concise sentence that is front-loaded with the action and resource, containing no unnecessary words 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?

For a simple tool with no parameters and no output schema, the description provides sufficient information to understand its purpose. However, it does not explicitly differentiate between personal account and page, relying on the sibling tool name for distinction.

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

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

The input schema has zero parameters, so schema description coverage is trivially 100%. Baseline for zero parameters is 4, and the description does not need to elaborate on parameters.

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 'get' and identifies the resource as 'the OAuth URL to connect your LinkedIn account,' clearly stating what the tool does. It distinguishes from the sibling connect_linkedin-page by explicitly referring to 'your LinkedIn account' (personal) rather than a page.

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

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

The description implies usage for connecting a LinkedIn account, but does not explicitly state when to use this tool versus alternatives like connect_linkedin-page. No exclusions or alternative guidance is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral context (e.g., prerequisites, URL expiration, or what to do with the URL) 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.

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

A single, front-loaded sentence with no waste. It clearly conveys the tool's purpose and target resource.

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

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

For a zero-parameter tool with clear annotations, the description is largely complete. It could briefly mention the next step in the OAuth flow (e.g., that the returned URL must be visited by the user), but the core functionality is clear.

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

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

There are no parameters, so the baseline of 4 applies; there is nothing for the description to add 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?

Description states a specific verb ('Get') and resource ('OAuth URL to connect your LinkedIn Page account'), clearly distinguishing it from the sibling connect_linkedin which likely targets personal profiles.

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 phrase 'connect your LinkedIn Page account' implies the use case, but there is no explicit guidance on alternatives or when not to use this tool compared to the other connect_* siblings.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds a minor behavioral detail (it returns an OAuth URL as part of the connection flow), but does not go into further depth such as whether the URL expires or requires user interaction. With annotations present, 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.

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

The description is a single, focused sentence that immediately states the tool's purpose. It contains no extraneous words or repetition, making it highly effective for quick comprehension.

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

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

For a tool with no parameters and simple output (an OAuth URL), the description fully answers what the tool does and what the agent can expect. The annotations provide sufficient safety and side-effect context, so the description does not need to elaborate further. It is complete for its complexity level.

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

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

The tool has zero parameters, so the baseline is 4, and schema coverage is 100% (vacuously). The description does not need to explain any parameters since none exist, and no additional semantic guidance is required.

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

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

The description clearly states a specific verb ('Get') and resource ('OAuth URL') for a specific target ('your Mastodon account'), which distinguishes it from sibling connect tools for other platforms. It goes beyond the title by specifying the exact output, making the tool's function 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 context is clear: this tool is used when a user wants to connect their Mastodon account, as evidenced by the name and description. It does not explicitly mention alternatives or exclusions, but the sibling list of platform-specific connect tools makes the intended usage obvious, so clear context with no exclusions merits a 4.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond annotations by specifying that the tool returns 'custom connection setup instructions' (indicating a read-only instructional output) and warns that the connector is unofficial and may change without notice. This is useful 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.

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

The description is two short sentences: the first delivers the core functionality, the second adds a necessary caveat. There is no filler or redundancy, making it appropriately concise and well-structured.

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

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

Given the tool's simplicity (0 params, no output schema), the description provides adequate information about what it does and the unstable nature of the connector. It could be more complete by explicitly stating that it does not perform the connection itself, but 'instructions' implies this. Overall, it is sufficiently complete for an agent to understand the tool's 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, so schema coverage is 100% trivially. The description doesn't need to explain parameters, and none are present to elaborate on. Baseline for 0 params is 4, and no additional parameter semantics are 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 'Get the custom connection setup instructions for Nostr' uses a specific verb (Get) and resource (connection setup instructions for Nostr), clearly distinguishing it from sibling connect_* tools by naming the target platform. It fully communicates what the tool does.

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

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

No explicit guidance is given about when to use this tool versus alternatives. While it implies Nostr-specific usage, it does not mention when not to use it, nor does it reference sibling tools or prerequisites. The only additional context is the unofficial/change warning, which is more of a caution than a usage guideline.

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

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

Annotations already declare the tool as readOnly and idempotent, so the safety profile is covered. The description adds that the tool returns an OAuth URL, which is useful behavioral context. However, it doesn't elaborate on what the URL is for, how it should be used, or any nuances (e.g., expiration, redirect behavior), so it adds limited value beyond the annotations.

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

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

The description is a single, well-structured sentence that front-loads the action ('Get the OAuth URL') and specifies the target ('Pinterest account'). Every word earns its place, with no redundancy or irrelevant detail.

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

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

For a simple tool with no parameters, no output schema, and strong annotations, the description is largely complete. It fully states the tool's purpose and return type (OAuth URL). The only minor gap is that it doesn't mention any follow-up steps (e.g., user must open the URL to complete the connection), but this is not essential for tool invocation. Overall, it's sufficient for an agent to select and call the tool correctly.

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

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

The tool has zero parameters, so there is no parameter semantics to explain. The description doesn't need to add parameter information, and the baseline of 4 for zero-parameter tools is appropriate. The schema coverage is vacuously 100%.

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

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

The description clearly states a specific action (get the OAuth URL) and a specific resource (Pinterest account), making it immediately clear what the tool does. It distinguishes from sibling connect_* tools by naming Pinterest explicitly, so there's no ambiguity about which platform it targets.

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

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

The description implies the tool should be used when the user wants to connect a Pinterest account, providing clear context. However, it offers no explicit guidance on alternatives (e.g., other connect_* tools, checking existing connections via list_connected_accounts) or when not to use it, leaving the agent to infer from the name and context.

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

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

The description adds behavioral context beyond annotations by explaining that the output depends on the platform's auth method. This aligns with the readOnlyHint (it returns setup info rather than performing the connection) and clarifies the tool's side-effect-free nature.

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

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

The description is two sentences, front-loaded with the action, and wastes no words. It delivers purpose and output context efficiently.

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

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

The description covers the essential purpose, parameter, and output variability, and an output schema supplies return details. However, it omits guidance on choosing between this and the many dedicated connect_* tools, leaving some ambiguity in a crowded tool landscape.

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

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

Schema coverage is 100%, so the platform enum is already documented. The description adds meaning by indicating that the parameter value affects the output contract (OAuth URL vs webhook vs credentials), which helps the agent anticipate behavior.

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 connects a platform by ID and specifies the three possible return types (OAuth URL, webhook setup details, or credential form contract). This distinguishes it from sibling connect_* tools by emphasizing dynamic selection based on platform ID.

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

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

The description implies a generic dynamic connector ('dynamically by platform ID') but does not explicitly state when to use it over dedicated connect_* tools. No exclusions or alternatives are provided, so the agent must infer from the sibling list.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the output type (OAuth URL), which is useful but does not elaborate on other behavioral aspects like OAuth flow or prerequisites. It is 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.

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

The description is a single, well-front-loaded sentence with no redundant information. It efficiently communicates the core purpose without verbosity.

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

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

For a simple, zero-parameter tool with clear annotations and no output schema, the description adequately explains the action. It could potentially mention what to do with the returned URL, but that is beyond the minimal required context.

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

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

The tool has zero parameters, and the schema coverage is 100% (vacuously). The description does not need to explain parameters; the baseline for 0 params is 4.

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

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

The description states a specific verb ('Get') and resource ('OAuth URL to connect your Product Hunt account'), clearly distinguishing it from sibling connect tools for other platforms. It precisely identifies the tool's function.

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

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

The description clearly indicates when to use this tool (to connect a Product Hunt account) and implies it is not for other platforms by naming Product Hunt specifically. It lacks explicit alternatives or exclusions, but the context is unambiguous given the tool name and sibling list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond being a simple get operation, which is acceptable but does not enrich the annotations further.

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

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

The description is a single sentence that is front-loaded with the key action and resource. It contains no extraneous information and is appropriately sized for the tool's simplicity.

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 (0 params, no output schema, comprehensive annotations), the description sufficiently explains what the tool returns. It could optionally mention next steps for using the schema, but this is not necessary for a basic getter.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and with 100% schema coverage (empty schema), nothing is missing.

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 gets the webhook setup schema for connecting Slack, using a specific verb ('get') and resource ('webhook setup schema'). It distinguishes from siblings by naming Slack specifically, which differentiates it from other connect_* tools.

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

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

The description implies usage when a user needs to connect Slack and requires the webhook setup schema. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or mention alternative tools like connect_platform or get_platform_settings_schema.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds little behavioral context beyond the credential types, similar to baseline examples.

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

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

A single, front-loaded sentence with no filler. Every word contributes meaning, and it is appropriately sized for a zero-parameter getter.

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 no parameters or output schema. The description stating it returns a 'credential setup schema' is adequate, though it does not describe what to do with the schema or provide further 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 input schema has zero parameters, and schema description coverage is 100%, so the baseline is 4. The description's mention of API key or token credentials adds context about accepted credential types, though not tied to specific parameters.

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

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

The description clearly states a specific action ('Get the credential setup schema') and resource ('Telegram'), with additional scope via 'using API key or token credentials'. This distinguishes it from sibling connect_* tools by platform and purpose.

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

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

The description implies when to use this tool: when you need the credential setup schema for Telegram. It does not explicitly mention alternatives or when-not to use, but the context is clear given the sibling set.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds that this returns an OAuth URL, which is useful context, but it does not elaborate on side effects or requirements beyond what annotations imply. It is consistent with annotations, so no contradiction.

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

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

The description is a single, front-loaded sentence with no redundancy. It delivers the essential information instantly, which is ideal for such a simple tool.

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

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

For a tool with no parameters and no output schema, the description is complete. It explicitly mentions the return value (OAuth URL) and the tool's purpose. Combined with rich annotations, the agent has sufficient context to select and invoke this 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 tool has zero parameters, so the schema provides full coverage (100%). The baseline for 0 params is 4, and the description does not need to add parameter details. It briefly indicates the output (OAuth URL), but since no params exist, there is nothing to compensate for.

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

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

The description clearly states the tool's function: obtaining the OAuth URL for a Threads account. The verb 'Get' is specific, and 'OAuth URL to connect your Threads account' precisely identifies the resource and distinguishes it from sibling 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.

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

No guidance is provided on when to use this tool versus alternatives. While the name implies it's for Threads specifically, the description does not mention any prerequisites, the OAuth flow context, or exclusions relative to other 'connect_' tools. The agent is left to infer usage from the name alone.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds no behavioral details about the OAuth flow, such as URL expiry or user approval, beyond what annotations indicate.

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

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

The description is a single, concise sentence with no unnecessary words, front-loading the action.

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

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

For a no-param, no-output-schema tool, the description covers the basic purpose but omits important contextual information like how the returned URL should be used, whether it requires user authorization, and any setup prerequisites. This leaves some gaps for an agent.

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

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

With zero parameters, the schema fully covers input requirements. The description appropriately doesn't mention parameters, so baseline 4 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 explicitly states 'Get the OAuth URL to connect your TikTok account,' providing a specific verb and resource. It clearly distinguishes from sibling connect_* tools by naming TikTok.

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

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

The description implies usage for TikTok but lacks explicit guidance on when to use this tool versus alternatives, prerequisites, or the expected OAuth flow. It does not mention that the URL requires user interaction or that other connect_* tools are used for other platforms.

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

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

Annotations already indicate a safe, read-only, idempotent operation. The description adds important non-obvious context: this is an unofficial connector that may change without notice. This warning goes beyond the structured annotations and helps set expectations.

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

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

The description is two sentences long and front-loaded: the first sentence states the action and resource, the second adds a necessary caveat. Every word earns its place; no padding or redundancy.

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

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

For a zero-parameter tool with rich annotations and no output schema, the description is complete. It explains what the tool returns (the schema), the connection target (Whop), accepted credential styles, and warns about instability. Nothing essential is missing.

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

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

The input schema has zero parameters, and schema coverage is 100%, so the baseline is 4. The description adds useful context by mentioning the credential types (API key or token) that would be used with the returned schema, which is helpful even though no params are defined.

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 ('Get') and clearly identifies the resource ('credential setup schema') and target platform (Whop). It differentiates itself from the many sibling connect_* tools by specifying that it returns a schema rather than performing the actual connection.

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 makes clear the tool is for obtaining the credential schema needed to connect Whop using API key or token credentials. It doesn't explicitly spell out when not to use it, but the platform-specific context is clear and no alternatives are necessary.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that it returns an OAuth URL, which is consistent but not deeply beyond annotations. It doesn't disclose additional behaviors like URL expiration or browser redirect steps, but with annotations covering the safety profile, a mid-score 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.

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

One sentence, front-loaded with the action, no unnecessary words. Every word earns its place. Perfectly concise.

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 (no parameters, no output schema), the description is largely complete: it states the output (OAuth URL) and the purpose. Minor context missing about post-authorization flow, but not essential for such a straightforward tool. Slight deduction for not mentioning that the URL is for user-facing authentication, but still adequate.

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

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

The tool has zero parameters, so the description need not add parameter meaning. Baseline is 4 as per rubric for 0 params; the description focuses on the action and result, which is sufficient.

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

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

The description uses a specific verb ('Get') and resource ('OAuth URL to connect your X account'), clearly distinguishing this from sibling connect_* tools for other platforms. It fully states what the tool does 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.

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

The description implies usage for connecting an X account, but does not explicitly state when to use this versus the many sibling connect_* tools or any exclusions. The platform is named, so context is clear, but no explicit guidance or alternatives are mentioned.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the purpose of returning an OAuth URL but does not disclose additional behavioral traits such as token expiry or that the URL is for user interaction. This is acceptable given the annotation coverage, but no extra context is provided.

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

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

The description is a single concise sentence that is immediately informative. It front-loads the primary action ('Get the OAuth URL') and includes the necessary context ('connect your YouTube account') with no redundant information.

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

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

For a simple tool with no parameters, no output schema, and strong annotations, the description sufficiently conveys the return value (OAuth URL) and purpose. It could mention next steps (e.g., 'use the URL in an authorization flow'), but this is not critical. Slight room for improvement prevents a 5.

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 is empty with zero parameters, so there are no parameters to describe. The description confirms the tool takes no input. Baseline for 0 params is 4, and no further semantic explanation 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 tool's function: 'Get the OAuth URL to connect your YouTube account.' It uses a specific verb ('get'), identifies the resource ('OAuth URL'), and specifies the target ('YouTube account'). This distinguishes it from sibling connect_* tools by naming YouTube explicitly.

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

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

The description provides no guidance on when to use this tool versus alternatives such as connect_platform or other connect_* tools. It does not mention prerequisites, context, or exclusions. There is no explicit 'when to use' or 'when not to use' information.

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

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

Annotations already indicate this is a write, open-world, destructive operation. The description adds the supported platform list but does not disclose additional behavioral traits such as real-money spend, irreversibility, authentication requirements, or post-creation implications. Some context is added, but deeper behavioral disclosure is missing.

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 front-loaded with the core purpose. The second sentence listing supported platforms is useful, but the final sentence about the AI Campaign Builder agent is tangential and does not directly aid tool invocation, keeping it from a perfect score.

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 complex tool with 8 parameters, nested targeting, and no output schema, the description gives platform breadth but omits return values, platform-specific targeting nuances, and prerequisites like authentication or account connection. It is adequate but leaves gaps for an agent to fully understand the operation's outcome.

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

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

Schema coverage is 100% with all parameters described. The description does not add any parameter-specific meaning 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.

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

The description clearly states the tool creates a new advertising campaign, with a specific verb and resource. It lists supported platforms, which distinguishes it from ad creative tools and other connect tools. This is a clear and unambiguous purpose.

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

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

The description provides clear context for when to use the tool by enumerating supported platforms (Meta, Google, LinkedIn, TikTok, Pinterest, etc.), implying it is the correct tool for creating campaigns on any connected ad platform. It does not explicitly mention alternatives or exclusions, but the platform scope is 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?

The description does not disclose any behavioral traits beyond what annotations already indicate (e.g., destructiveHint=true). It fails to explain side effects, permissions, or what happens when an ad creative is created.

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 front-loaded with purpose. The second sentence about the Creative Asset agent is somewhat tangential but not overly verbose.

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

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

For a tool with 9 parameters and no output schema, this description is inadequate. It does not explain return values, how creative types map to required fields, or how the creative integrates with the campaign.

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 only repeats creativeType enum values without adding extra meaning to the parameters.

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

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

The description clearly states the tool creates an ad creative and lists supported types (image, video, carousel, text). It is distinct from sibling tools like create_ad_campaign by resource, though it does not explicitly contrast them.

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?

There is no guidance on when to use this tool versus alternatives. The mention of the Creative Asset agent is a general suggestion for help, not a conditional usage instruction.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds no behavioral detail beyond the action itself, such as side effects, permissions, or overwrite behavior. It does not contradict the annotations, so a baseline score of 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.

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

The description is well-structured with a clear opening sentence followed by a bulleted list of configurable fields. It is somewhat long due to 11 fields, but each bullet is concise and earns its place. The front-loading of purpose is effective.

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

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

Given the tool's complexity (11 parameters) and full schema coverage, the description covers all parameters and the overall purpose. It lacks details about the response format or side effects, but since there is no output schema, this is a minor gap. The description is otherwise comprehensive for invoking the tool correctly.

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

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

Schema description coverage is 100%, and the description lists all fields with brief clarifications (e.g., 'approvedHashtags: Preferred hashtags to prioritize'). While this adds slight detail over the schema, it largely repeats what the schema already provides, yielding a baseline score of 3.

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

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

The description clearly states the tool's action ('Create a brand voice profile') and its purpose ('to guide AI content generation'). It distinguishes itself from sibling tools like list_brand_voices and set_default_brand_voice by focusing on the creation action.

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

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

The description provides context that this tool is for creating a brand voice profile to guide AI content generation, implying when it would be used. However, it does not explicitly mention alternatives, prerequisites, or when not to use it, unlike a fully guided description.

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

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

Adds requirements and error handling details beyond the annotations: account connection prerequisite, app whitelisting for write access, and error instructions. Annotations already indicate destructive/write nature, and the description reinforces this without contradicting.

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 with a clear title, a requirements list, and a note about error behavior. Each line conveys essential information without 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?

Given the tool's simplicity, the description covers prerequisites, an error path, and the title limit. It does not describe the success return value, but this is less critical for a create operation and annotations already signal write behavior.

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 contains descriptions for all parameters (title with max 280, dueAt with ISO format), and the description only reiterates the title length limit. Since schema coverage is 100%, the description adds minimal extra value for parameters.

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

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

The description states 'Create a new maker goal on Product Hunt' with a specific verb (create), resource (maker goal), and platform. It clearly distinguishes from siblings like complete_goal and list_goals by specifying creation of goals.

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?

Lists prerequisites: must have Product Hunt account connected, write access requires app whitelisting, and mentions error behavior if write access is unavailable. This gives clear context on when the tool can be used, though it does not explicitly contrast with alternative goal-creating tools.

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

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

Annotations indicate this is a write (readOnly=false), non-idempotent, and world-affecting (openWorldHint=true), but the description adds no behavioral context beyond that. It doesn't disclose potential side effects such as evergreen auto-republishing or whether duplicates are created, which are relevant given idempotentHint=false.

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

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

Two sentences, zero waste. The first sentence captures the core action and types, the second clarifies the alias relationship. It is perfectly 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?

With 9 parameters, no output schema, and global side effects indicated by annotations, the description is too brief. It doesn't mention return values, side effects, or behavior when optional fields like evergreenEnabled are set. The description is minimally viable but leaves significant gaps.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description doesn't add any param-specific meaning; it merely restates the type enum in prose. Baseline 3 is appropriate.

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

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

Description clearly states the verb 'Save' and the resource 'content to your library', and lists the content types (draft, template, evergreen) which map to the schema enum. It also notes it's an alias for save_to_library, distinguishing it from that sibling.

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 phrase 'for reuse' implies when to use the tool, but it doesn't provide explicit guidance on when to prefer this over sibling tools like save_project_content_to_library or update_library_item. The alias note is helpful but not a full usage guideline.

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

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

The description adds no behavioral context beyond the annotations—it doesn't mention idempotency, permissions, side effects, or error cases. Since readOnlyHint=false already signals a write operation, the description provides no additional transparency about what happens when the project is created.

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

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

The description is a single, focused sentence with no filler. It communicates the core purpose efficiently, though this brevity comes at the cost of behavioral and parameter detail.

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

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

With six parameters, no output schema, and sparse annotations, the description is far too minimal to inform correct usage. It omits parameter semantics, return behavior, and any context about how 'sources' or 'team_id' should be used.

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 only 17% (only team_id has a schema description), and the tool description doesn't explain any of the six parameters, including required 'name' or the 'sources', 'tags', 'category', and 'description' fields. The agent must guess parameter semantics from names alone.

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

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

The description uses a specific verb ('Create') and identifies the resource ('Projects workspace'), with a qualifier ('for a product, app, or codebase') that distinguishes it from sibling tools like create_workflow or create_goal. It clearly states what the tool does.

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

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

The description implies a use case (creating a workspace for product/app/codebase) but provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions or prerequisites. It gives some context but not enough to fully direct an agent.

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

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

Annotations already declare readOnly=false and destructive=false; the description adds that reports are generated and delivered automatically, which is useful context about side effects. However, it does not disclose other behavioral traits such as validation behavior, prerequisites, or failure scenarios.

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

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

The description is a single well-structured sentence that immediately states the purpose. Every word contributes meaning, 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?

Given the tool's 6 parameters, 3 enums, and no output schema, the description is minimally adequate. It does not explain what the tool returns (e.g., an ID for the created schedule) or what happens after creation, but the schema covers parameter semantics sufficiently.

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

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

Schema descriptions provide 100% coverage of all six parameters, so the description does not need to add parameter-level detail. It provides only general context about recurrence and delivery, which goes beyond the schema but does not materially enhance parameter understanding.

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

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

The description clearly states the tool creates a recurring analytics report with automatic delivery, using a specific verb (create) and resource (scheduled report). It emphasizes 'recurring' and 'delivered automatically', which distinguishes it from one-time report tools like run_analytics_report.

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

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

The description implies when to use this tool (when a recurring, automated report is needed) but does not explicitly contrast with alternatives or state exclusions. It lacks guidance on choosing between this and run_analytics_report or scheduling workflows.

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 all annotations false, the description carries the full burden. It discloses key behavioral traits: creates a browser link, user must open it to upload, supports up to 20 files, expires in 15 minutes, and the file is local. This goes well beyond the minimal annotation info and sets clear expectations.

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 with a clear opening, a numbered workflow, and key constraints (file limit, expiration). Every line adds value; the workflow steps are necessary and concise, making it easy to follow without 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?

Despite having only one optional parameter and an output schema, the description is self-sufficient: it covers the tool's purpose, exact usage scenario, step-by-step workflow, and operational limits. There's no missing information an agent would need to invoke it correctly.

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

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

The input schema has 100% coverage for the single optional parameter mediaType, including an enum and description. The description doesn't add new parameter-level semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Create a browser upload link for media files.' It clearly distinguishes itself from siblings like upload_media and get_upload_session by focusing on generating a user-facing upload URL, and it explicitly mentions the context of chat-shared images/videos.

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 when-to-use guidance: 'ALWAYS use this when the user shares an image or video in chat.' It also explains why (local file cannot be passed directly to publish_content), and maps out a full workflow including next steps (get_upload_session, publish_content/schedule_content), effectively differentiating from alternatives.

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

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

Annotations already flag readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the description doesn't need to restate those. It adds behavioral context by listing trigger/step types, but doesn't go into consequences like validation, idempotency, or error conditions. This is adequate given the 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.

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

The description is well-structured with bullet points for trigger and step types, making it easy to scan. It is somewhat long but appropriate for a complex tool with many enum options. Every sentence adds information about workflow composition.

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 high-level structure but lacks operational details for constructing step configs (e.g., required fields for http_request, condition, transform) and triggerConfig formats (e.g., cron syntax, event names). Since config is a free-form object in the schema, the description should carry more of the burden, but it only provides type names. This leaves gaps for correct invocation.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the enum options for triggerType and step types (e.g., 'manual - Run on demand', 'schedule - Cron-based schedule'), going beyond the raw schema. It doesn't explain triggerConfig or step config structures in depth, but the high-level mapping helps.

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

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

The description clearly states 'Create a new automation workflow' and explains that workflows consist of a trigger and steps. This differentiates it from sibling tools like update_workflow, delete_workflow, and trigger_workflow.

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

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

The description provides explicit context on when to use the tool by enumerating trigger types and step types, which covers the main usage scenarios. However, it doesn't explicitly mention when NOT to use this tool or compare it with alternatives beyond the obvious create/update/delete distinction.

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

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

The description mentions 'AI-powered' and the return object, but the annotations indicate readOnlyHint=false, implying possible side effects. The description does not disclose whether the critique is stored, triggers other actions, or calls external APIs, creating ambiguity about the tool's state-modifying behavior.

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

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

Two focused sentences convey the purpose, method, and return value with no redundancy. The information is front-loaded and every word contributes meaning.

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

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

With no output schema, the description covers the primary return values (score, breakdown, tips) but leaves gaps: it does not explain how platform context or mediaUrl influence the critique, nor does it mention potential side effects or errors. It is adequate but not comprehensive for an agent deciding to invoke it.

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

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

The input schema covers all three parameters with descriptions, so the baseline is 3. The description adds context by mentioning the return score range and breakdown, but it does not explain how 'platforms' or 'mediaUrl' affect the scoring beyond what the schema already states.

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 ('Score and critique') with a clear resource ('post content'), and it mentions the unique value of 'AI-powered suggestions'. It distinguishes itself from siblings like score_content by focusing on critique and improvement, though it does not name them explicitly.

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

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

No guidance is provided on when to use this tool versus alternatives such as validate_content, approve_post, or edit_post. It does not state whether it is for pre-publish feedback or how it differs from approval/rejection workflows, leaving the agent without contextual decision support.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write operation. However, the description adds no additional behavioral context—it does not mention permanence, required permissions, side effects, or what happens on failure. It adds no value beyond the annotations.

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

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

The description is a single, clear sentence with no extraneous words. It is appropriately sized for a simple delete operation and gets straight to the point.

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

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

Given the low complexity, good schema coverage, and presence of annotations, the description is minimally viable. It tells the agent what the tool does, but it omits any extra context like irreversibility or team-scope behavior. It is functional but not rich enough for a higher score.

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%: both 'id' and 'team_id' have clear descriptions. The tool description adds no parameter-specific information, so it does not compensate beyond the schema. Per rubric, baseline is 3 for high schema coverage.

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

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

The description clearly states the action ('Delete') and the specific resource ('content library item'), which distinguishes it from sibling tools like delete_post or delete_workflow. It is not a tautology; it expands the tool name into a meaningful full sentence.

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

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

The description gives no guidance on when to use this tool versus alternatives, such as delete_post or update_library_item. It does not mention contexts like team scope, prerequisites, or exclusions, leaving the agent without directional cues.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds useful behavioral context beyond that: it clarifies accepted identifier formats (database ID, platform post ID, or URL) and lists supported platforms. It doesn't contradict annotations, but it doesn't detail side effects like whether deletion is reversible or affects analytics.

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 short and to the point: the first sentence states the purpose, and the second paragraph explains the accepted identifiers. No unnecessary details or fluff, and it's front-loaded with the most important info.

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

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

Given the tool's complexity (10 platforms, destructive action, 3 parameters) and the presence of an output schema, the description covers the essential elements: what it deletes, where, and how to specify the target. The team_id parameter is not mentioned in the prose, but the schema covers it, so this is adequate. A slightly higher score is prevented by not explicitly warning about the permanence of the deletion, though annotations do flag destructiveness.

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

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

Schema coverage is 100% with detailed descriptions, so the baseline is 3. The description adds extra meaning by explaining that the postId can be a database ID returned from SendIt, a platform post ID, or a URL, which enriches the schema's brief 'Post identifier' description. This goes beyond what the schema alone provides.

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

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

The description clearly states the action ('Delete a published post') and the resource ('from a platform'), with a specific scope that distinguishes it from sibling tools like delete_scheduled_post or delete_library_item. The supported platform list further clarifies its breadth.

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

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

The description gives clear context: it's for deleting already-published posts, and mentions the database ID from SendIt, which implies this is not for scheduled posts. However, it doesn't explicitly say 'use delete_scheduled_post for scheduled items' or mention any exclusions, so it lacks explicit alternative guidance.

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

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

Annotations already disclose destructiveHint=true and idempotentHint=true, so the description does not need to restate those. It adds the timing constraint ('before it's published') as useful context. However, it does not explain what happens after deletion (e.g., irreversibility, impact on related workflows), which is acceptable given the annotations but not comprehensive.

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

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

The description is a single, focused sentence that is front-loaded with the action and resource. Every word adds 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 tool with two parameters (one required), a clear output schema, and descriptive annotations, the description is sufficient. The timing constraint adds useful context, and the schema covers parameter details. It could be slightly more explicit about the state of the post after cancellation, but the overall picture is complete.

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

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

The schema provides 100% coverage with descriptive text for both parameters (team_id and scheduleId), so the description adds no extra meaning beyond what's already structured. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('cancel') and a specific resource ('scheduled post') with a clear timing qualifier ('before it's published'). This distinguishes it from sibling tools like delete_post (targets published posts) and edit_scheduled_post (modifies rather than cancels).

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

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

The description implies the tool is for scheduled posts that have not been published yet, providing clear context for when to use it. However, it does not explicitly name alternatives (e.g., edit_scheduled_post for changes, delete_post for published posts) or state when not to use it, so it falls short of the highest standard.

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

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

Annotations already declare destructiveHint=true, and the description adds 'permanently' which reinforces irreversibility. However, it does not elaborate on side effects such as whether associated runs or related data are also deleted, which would be valuable for a destructive operation. No contradiction with annotations.

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

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

The description is a single, front-loaded sentence that conveys the essential action. It contains no filler or redundant information, earning its place efficiently.

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 (1 parameter, no output schema) and the presence of destructiveHint annotation, the description is minimally adequate. It might benefit from noting that deletion is permanent and cannot be undone, but 'permanently' already covers this. No major gaps for the level of complexity.

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

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

The input schema has 100% coverage for the single parameter 'workflowId' with a description. The tool description does not add any extra semantics beyond the schema, 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 action ('Delete') and the resource ('a workflow') with the qualifier 'permanently' to emphasize irreversibility. It distinguishes this from sibling tools like create_workflow, update_workflow, and list_workflows.

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

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

No guidance is provided on when to use this tool or when to avoid it. It does not mention alternatives, prerequisites, or consequences beyond 'permanently', which is a factual attribute rather than usage context.

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

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

Annotations already mark destructiveHint=true, but the description adds the specific consequence that credentials are revoked, which is context beyond the annotation. It clearly states both disconnecting and revoking credentials as the behavioral outcome.

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

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

The description is a single, front-loaded sentence with zero wasted words. It efficiently communicates the core action and its additional credential-revocation nuance.

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 destructive tool with annotations and full schema coverage, the description is largely complete. It could clarify the behavior when credentialId is omitted (e.g., whether all credentials are revoked), but the core behavior is sufficiently clear for an action-oriented 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 100%, with both connectorId and credentialId clearly described. The description does not add meaning beyond the schema, so the baseline of 3 applies appropriately.

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 ('disconnect') and resource ('connector') and adds 'revoke credentials' to clarify the full scope. It clearly distinguishes from sibling tools like connect_connector and execute_connector_operation.

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

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

The description implies when to use this tool (to disconnect a connector), but does not explicitly mention alternatives or when-not-to-use. Given the siblings include connect_connector and various list tools, some explicit guidance on selection would improve this dimension.

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

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

Annotations already indicate non-read-only, non-idempotent behavior, and the description adds that it returns a draft with tone and safety flags. No additional side effects, persistence, or safety details are disclosed, but the description does not contradict annotations.

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

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

The description is two sentences, front-loaded with the core action and followed by the output summary. Both sentences add necessary information 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?

The description covers the tool's purpose and return value, and the schema fully documents parameters. It omits details about safety flags or persistence, but for a simple draft-generation tool, the information is adequate.

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

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

The input schema provides descriptions for all three parameters (mention_id, tone, max_length), so the description adds no additional parameter meaning. Since schema coverage is 100%, 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 generates an AI-powered reply draft for a social mention, distinguishing it from sibling tools that actually post replies (reply_to_comment, reply_to_conversation). It also specifies the return value (draft with tone and safety flags).

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

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

The description implies appropriate use by mentioning 'social mention' and 'draft', and the tool's name reinforces this. However, it does not explicitly exclude when to use alternatives like reply_to_comment or provide comparison guidance.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, and idempotentHint=false, indicating a mutating operation with potential side effects. The description adds one behavioral trait: if no time is supplied, the post is automatically shifted forward. However, it does not explain what 'shifted forward' means (e.g., to next available slot), what fields are copied, or whether the new post requires re-approval. This adds some context but is not comprehensive given openWorldHint=true.

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

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

Two sentences, front-loaded with the main purpose, followed by a concise edge-case note. Every word earns its place; there is 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?

Given five parameters, zero required, no output schema, and openWorldHint=true, the description is minimal. It covers the core duplication action and the auto-shift behavior, but leaves gaps: how far forward it shifts, whether all post attributes are duplicated, whether a new post ID is generated, and side effects like approval flows. The annotations cover safety (mutation, non-idempotent), so the description does not need to repeat that, but it could provide more operational 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?

Schema coverage is 100%, with each parameter having a description. The description adds meaningful semantics for scheduledAt by explaining the behavior when it is omitted (auto-shift forward), which is not in the schema. It does not describe the alias relationships (id, scheduleId) but those are already covered by the schema. The description thus adds value beyond the structured fields.

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

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

The description opens with a specific action: 'Create a new scheduled post by duplicating an existing scheduled post.' This clearly identifies the resource (scheduled post) and the operation (duplicate), distinguishing it from siblings like edit_scheduled_post or retry_scheduled_post. 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.

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

The description implies the use case—duplicating an existing scheduled post—but does not explicitly state when to use this tool versus alternatives (e.g., edit_scheduled_post, retry_scheduled_post, schedule_content). The note about auto-shifting when no time is supplied gives some scheduling context, but no exclusions or alternative references are provided. Usage is thus implied rather than explicitly directed.

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

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

Annotations already declare the tool as non-read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations: it limits edits to text/caption (and YouTube-specific fields), lists platform constraints, and requires the published post ID from original publish via SendIt. No contradiction with annotations.

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

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

The description is concise and well-structured: a clear definition, a compact supported/not-supported list, and a critical prerequisite. 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.

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

For a tool with six heterogeneous parameters and no output schema, the description adequately covers selection context (supported platforms, published posts, post ID requirement) and points to schema details for parameter specifics. It does not explain success/failure responses, but that is not essential given annotations and the simple nature of the edit operation.

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

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

Schema coverage is 100%, with clear descriptions for all six parameters. The description adds minimal parameter semantics beyond the schema, except for the platform support list that clarifies which fields apply to which platforms (e.g., 'YouTube (title/description/tags)'). This is helpful but not essential given the schema already includes 'YouTube only' notes.

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

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

The description clearly states the tool's purpose: 'Edit a published post on a supported platform' and explicitly lists supported and unsupported platforms, distinguishing it from related tools like edit_scheduled_post. It clarifies that it updates text/caption, with platform-specific fields like YouTube title/description/tags.

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 strong usage context by specifying it applies to published posts, requires the published post ID from original publish, and lists supported vs. unsupported platforms. It does not explicitly mention alternatives (e.g., 'use edit_scheduled_post for scheduled posts'), but the 'NOT SUPPORTED' list and requirement for a published post ID give clear when-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?

The description adds behavioral context by listing the types of updates supported, including the non-obvious 'approval-scope' and 'publish-now' behaviors that modify scheduling and publishing flow. Annotations already mark readOnly=false and destructive=false, and the description does not contradict them; it supplements them with these update capabilities.

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

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

The description is a single, front-loaded sentence that states the primary action first, then compactly lists supported update types without waste.

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

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

Given the tool's complexity (15 params, no output schema), the description does not explain parameter relationships or side effects, but the rich schema descriptions and annotations fill most gaps. It misses some nuance like whether partial updates are allowed, but overall it's sufficient.

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

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

The input schema already provides 100% description coverage for all 15 parameters, so the baseline is 3. The description groups parameters into update categories (text, media, etc.) without adding detailed syntax or relationships, so it does not elevate the score.

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

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

The description opens with 'Edit a pending scheduled post' – a specific verb ('edit'), resource ('scheduled post'), and state ('pending'). It enumerates the supported update categories (text, media, platform, timing, approval-scope, publish-now), distinguishing it from sibling tools like edit_post or delete_scheduled_post.

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

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

The phrase 'pending scheduled post' clearly scopes the tool to only pre-publication states, implying it should not be used for published posts or for scheduling new posts. However, it does not explicitly name alternatives or state when not to use it, so it gets 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.

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

Annotations already indicate this is a mutating operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that it creates a support ticket from the conversation context, providing a useful behavioral detail. However, it does not go deeper into prerequisites or side effects beyond that.

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

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

Two concise sentences with no fluff. The first states the core action, and the second specifies the behavioral outcome, making it highly efficient and well-structured.

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

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

For a simple escalation action, the description is sufficient: it names the platforms, the input conversation, and the ticket creation. It does not mention preconditions like connector connectivity or return values, but the schema and annotations cover the essential details, making it reasonably complete.

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

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

Schema descriptions cover 3 of 4 parameters (note, conversationId, targetConnector), and the description clarifies that the escalation uses conversation context. The priority parameter lacks a description but is self-explanatory via its enum. 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.

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

The description uses a specific verb ('escalate') with a clear resource ('social conversation') and destination ('connected support platform'), and explicitly states the ticket-creation outcome. This distinguishes it from siblings like reply_to_conversation or list_conversations.

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

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

The description clearly implies the use case: when a social conversation needs to be escalated to an external support platform. It does not explicitly name alternatives or exclude other tools, but the context is clear enough given the sibling list.

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

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

Annotations already indicate readOnlyHint=false and openWorldHint=true. The description adds that operations 'include read/write actions specific to each connector,' providing extra context about the tool's behavior beyond the annotations. It does not contradict annotations and gives useful information about the scope of operations, though it remains somewhat general given the open-world nature.

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

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

The description is two sentences with no filler. The first sentence states the core purpose, and the second provides a critical usage pointer. Every word earns its place, and the structure is front-loaded and scannable.

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 generic, open-world nature, the description succinctly covers the key usage pattern (discover via get_connector_capabilities, then execute). The schema covers parameter semantics, and no output schema exists, so return values need not be explained. It is complete enough for selecting and invoking this dynamic tool, though it could mention error-handling or validation behavior.

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% description coverage: connectorId, operation, data, and idempotencyKey are all described, including example operation names. The description adds no further parameter-specific details, but the schema already carries the full semantic load, so 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.

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

The description clearly states the tool's function: 'Execute a specific operation on a connected connector.' This identifies the verb (execute), the resource (operation on a connector), and distinguishes it from sibling tools like get_connector_capabilities (discovery) and connect_connector (connecting). The second sentence clarifies that operations are connector-specific, further aiding selection.

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 directs users to get_connector_capabilities to discover available operations, providing a clear prerequisite and alternative. It implies that this tool is for executing operations once capabilities are known, but does not explicitly state when not to use it or mention other alternatives. This is clear context with a named alternative, but lacks an explicit exclusion.

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