Prowlo — Reddit & X for AI agents

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical behavior: alerts fire only on newly-ingested records, are rejected if query.any lacks mention terms, batch notifications, and are not metered. It also surfaces the free-account requirement and signup link behavior. No contradiction with annotations.

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

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

The description is compact and front-loaded with 'Create an Alert.' Each sentence adds meaningful behavior or constraints; there is no filler or redundancy.

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

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

For a 5-parameter nested-object tool with no output schema, the description covers behavior, constraints, firing modes, delivery, metering, and account prerequisite. It does not describe the return value, but the absence of an output schema and rich schema descriptions partially mitigate that 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 covers 100% of parameters with descriptions, so baseline is 3. The description adds key semantics not in schema: the requirement that query.any contain at least one mention term and the distinction between per-match and threshold firing. This lifts it to 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?

Description opens with 'Create an Alert' – a clear verb+object. It then states the firing condition ('fires when newly-ingested records match `query`'), distinguishing from sibling alert_update/delete/list operations. The purpose is specific and unambiguous.

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

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

The description gives actionable usage constraints: requires at least one mention term in query.any, per-match vs threshold firing, and delivery targets. It also notes account prerequisite. It does not explicitly contrast with sibling tools (e.g., alert_update), though the create action is self-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?

Adds non-metered status and account requirement beyond what annotations provide. However, the ambiguous 'call it to get a signup link' could mislead, and no mention of effects on related resources or recovery options.

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?

Very brief and front-loaded, but the parenthetical is awkward and the fragment 'Not metered.' could be smoother. Still, 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 delete tool, annotations and schema cover the essentials. The description adds cost and prerequisite context, but the ambiguous signup link instruction leaves a gap, and no return behavior is described.

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 a useful parameter description ('Alert id to delete (from alert_list)'). The tool description itself adds no additional parameter semantics, so baseline 3 is appropriate.

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

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

Clearly states 'Delete an Alert by id' with a specific verb and resource. This distinguishes it from siblings like alert_create and alert_update.

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 prerequisite context (requires a Prowlo account) and cost info (Not metered), but no guidance on when to use this vs alternatives. The confusing 'call it to get a signup link' phrase does not clarify usage.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable context: 'Not metered' (billing behavior) and the auth prerequisite ('requires a free Prowlo account'). It also clarifies what data is returned, going 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 one concise sentence plus a parenthetical, front-loaded with the main purpose. Every phrase (scope, non-metered, auth) 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 simple read tool with two well-documented parameters and readOnly/idempotent annotations, the description covers purpose, scope, auth, and metering. The lack of output schema is compensated by the mention of return content ('what was matched and where it was sent').

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 id and limit fully documented in the input schema. The description adds no parameter-specific detail 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's action: 'List recent deliveries (fires) for one Alert'. It specifies the resource (deliveries) and result ('what was matched and where it was sent'), distinguishing it from siblings like alert_list (which lists alerts, not deliveries).

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 defines the scope ('for one Alert') and notes 'Not metered' and 'requires a free Prowlo account', giving context on when to use it. It doesn't explicitly name alternatives, but the tool's unique purpose among siblings makes the usage 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?

Annotations already indicate readOnlyHint and idempotentHint. The description adds meaningful behavioral details: not metered, includes last-delivered time and total deliveries, and the signup-link behavior for missing accounts. No contradiction with annotations.

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

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

Two compact sentences, front-loaded with the primary action. The parentheticals add necessary context (definition, metering, account requirement) without unnecessary verbosity.

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

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

For a no-parameter list tool with no output schema, the description covers the essential return fields (last-delivered time, total deliveries), the account prerequisite, and metering. It lacks explicit pagination details but is adequate for a simple listing 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?

The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to explain parameters and does not add anything 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 'List your organization’s Alerts' with a specific verb and resource, and explains what alerts are (persistent rules firing to Slack/webhooks). However, it does not distinguish this tool from the sibling 'get_alerts', which could be a similar listing 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?

Provides useful context: 'Not metered' and requires a free Prowlo account, with an unusual call-to-get-signup-link behavior. This gives clear context for when to use the tool, but it does not explicitly mention alternatives or exclusions relative to sibling tools like get_alerts.

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

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

Beyond annotations, the description discloses partial-update behavior, the query.any validation requirement, the fact that it is not metered, and an account requirement with a signup link call. This adds meaningful behavioral context; annotations already cover read-only/destructive hints, so this is well above baseline.

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

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

Four short, information-dense sentences with front-loaded purpose. No filler; each clause adds a distinct detail (purpose, partial update, query constraint, metering/account). This is exemplary 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?

The tool has moderate complexity (nested query/destination/threshold objects) and no output schema. The description covers the key usage constraints and prerequisites, but does not state what the tool returns (e.g., updated alert object), which would be expected given no output schema. So it's nearly complete but leaves that 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 coverage is 100%, so baseline is 3. The description adds value by explaining partial update semantics (only provided fields change) and the query.any constraint, which is not evident from the query schema alone. However, most parameter meanings are already in the schema, so a 4 is appropriate.

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

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

The description uses the specific verb 'Update' with resource 'Alert' and enumerates updatable fields (name, query, destination, threshold, status), clearly distinguishing it from alert_create, alert_delete, and alert_list. It leaves no ambiguity about what the tool does.

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

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

It gives clear usage context: partial update semantics ('Only provided fields change'), a critical constraint on query (must include query.any), and metering/account prerequisites. It does not explicitly name alternative tools, but the sibling list makes the update-vs-create distinction clear. This is more than minimum viable but not as explicit as naming 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 declare readOnlyHint and idempotentHint, but the description goes further by disclosing the integration state semantics: Slack delivery requires connection, and webhook IDs must reference listed values. It also mentions the signup-link behavior for non-account holders, adding behavioral context beyond the static 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: three sentences, each with a distinct purpose. The first sentence front-loads the primary function, the second gives actionable integration guidance, and the third covers support usage and free-account signup. No word is wasted, and the structure is logically ordered.

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?

Although there is no output schema, the description enumerates the returned fields and their practical relevance, making the tool's behavior fully understandable. It also connects the tool to sibling tools (alerts) and external use cases (support), covering all necessary context for a zero-parameter 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 input schema has zero parameters, so the baseline is 4. The description compensates by thoroughly documenting what fields the response contains (org ID, name, user ID, email, role, plan, status, integrations) and how to use those fields (e.g., checking integrations before alert configuration, quoting organizationId for support). This adds meaningful semantic value even without 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 'Get your Prowlo account details' and enumerates specific fields (organization ID, user ID, email, role, plan, account status, integration state). This is a specific verb+resource construction that effectively distinguishes the tool from all sibling tools, which target alerts, records, social data, etc.

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

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

The description provides explicit when-to-use guidance: check `integrations` before setting an Alert destination, and quote `organizationId` when contacting support. It also implicitly explains how to interpret the returned integration fields in relation to alert tools (slack/webhook dependencies), making the usage context highly actionable.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral details: 'NOT metered' (no cost), alerts are 'merged and time-sorted', and it requires a free Prowlo account. These go beyond the annotations and help the agent understand side effects and prerequisites.

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

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

The description is extremely concise: two sentences. It front-loads the core action and resource, then provides critical qualifiers ('NOT metered', account requirement) in a parenthetical. Every sentence earns its place, 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?

The tool is simple (one parameter, no output schema) and the description adequately covers its behavior: what alerts are, their types, ordering, and access requirements. It could mention the return format (fields of each alert), but for this complexity level, the description is sufficiently complete.

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

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

Schema coverage is 100% and the 'limit' parameter is fully described in the schema (1-50, default 20). The description does not add any additional meaning about the parameter, so the schema carries the full burden. This aligns with the baseline of 3.

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

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

The description uses a specific verb ('Read') and resource ('recent operational alerts'), and explicitly defines what these alerts are: 'errored crawl runs (critical) and failed webhook deliveries (warning), merged and time-sorted.' This clearly distinguishes it from sibling tools like alert_list, which likely handle user-configured alerts.

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: it reads operational alerts derived from real failures. It also notes 'NOT metered' and mentions the account requirement with a signup link, which helps the agent decide when to call it. However, it does not explicitly state when not to use it or name alternative tools, so it lacks explicit exclusions.

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

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

Annotations already declare read-only and idempotent, but the description adds valuable behavioral details: non-metered status, the account requirement, and the fact that calling it can yield a signup link. It also outlines the exact response composition (summary fields, per-run fields, pagination), going beyond the structured annotations.

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

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 then efficiently lists response contents and operational notes. Every clause delivers functional or contextual value with no redundancy.

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

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

With no output schema, the description compensates by explicitly listing the fields in the summary and per-run data, as well as pagination and error handling. It also addresses operational concerns (metering, authentication) that an agent needs to know. This is complete for a read tool with this 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 already provides 100% coverage with detailed descriptions for both 'limit' and 'cursor', including constraints. The description's mention of a 'paginated list' aligns with cursor pagination but adds no extra parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description clearly states the verb ('Read') and the resource ('crawl-run activity'), and enumerates what is returned (summary + paginated list). This distinguishes it from any sibling tools and leaves no ambiguity about 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 provides clear context by noting the tool is 'NOT metered' and requires a free account, which are relevant selection and cost factors. However, it does not explicitly mention alternative tools or conditions when not to use it, so it falls short of a 5.

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

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

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses important behavioral traits: it is 'free, rate-limited only' and 'requires a free Prowlo account', plus states that calling it can produce a signup link. This adds useful context about cost, limits, and authentication that the annotations alone do not convey.

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

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

The description is two sentences and front-loaded with the core purpose. It lists several output fields without being wasteful, though the parenthetical about requiring an account is slightly tangential. Every sentence contributes but the density of the first sentence makes it a 4 rather than a 5.

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 is quite complete: it enumerates the summary contents, states its non-live nature, rate limits, and usage order, and notes the account requirement. It lacks a formal return schema definition but that is not necessary when the description covers the key output areas.

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 (no parameters), so the baseline is 4. The description compensates by explaining what the tool returns (summary fields) and how to use it, which is sufficient given there are no parameter semantics to clarify.

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

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

The description opens with a specific verb+resource: 'High-level summary of your Dataset' and enumerates the exact contents (record count, last ingest time, watchers/sources, busiest channels, live-read usage/reset time). It also distinguishes itself from live Reddit calls by explicitly stating 'NOT a live Reddit call', which sets it apart from sibling tools like social_get_post or search_dataset.

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

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

It gives an explicit usage directive: 'Use this first to understand the size and shape of your archive before querying it.' It also communicates a clear when-not-to-use signal with 'NOT a live Reddit call', implying that other tools should be used for live data. However, it does not name specific alternative sibling tools, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to re-state safety. It adds behavioral context about the account requirement and signup link, which goes beyond annotations. However, it doesn't detail what happens if the user already has an account or the exact response shape.

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 verb and resource. The second sentence adds usage context and auth note without fluff. Every sentence earns its place.

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

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

Given zero parameters, read-only annotations, and no output schema, the description is complete. It lists the profile fields that will be returned, explains the use case, and covers the auth requirement. No critical information is missing for an agent to invoke it correctly.

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

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

There are zero parameters and schema coverage is 100%, so the description doesn't need to explain any parameters. A score of 4 is appropriate as the baseline for tool with no 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's function: getting the organization's product profile. It lists the specific contents (name, description, audience, value propositions, tone, reply guidelines), making it distinct from sibling tools like get_account or get_usage.

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

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

Provides a clear usage context: 'Useful context for crafting relevant replies.' This implies when to use it, but doesn't explicitly mention alternatives or when not to use it. The note about requiring a free account and calling to get a signup link adds a prerequisite, but no direct comparison to other 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 and idempotentHint, and the description adds useful behavior context: it is free, rate-limited, requires an account, and returns full record details. This goes beyond the annotations without contradiction.

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

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

The description is a single focused sentence with a parenthetical about account requirements. It is front-loaded with the core action and includes 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 single-record fetch with one parameter, good annotations, and no output schema, the description covers the essential context: what data is returned, the non-live nature, and the account prerequisite. This is complete for the tool's complexity.

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

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

The input schema has 100% coverage for the single 'id' parameter, including a description of where the id comes from. The tool description adds no additional parameter information, 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 fetches one Dataset record by id, with specifics on what is returned (full body + intent/embedding signals + tags). This distinguishes it from sibling tools like list_records and search_dataset.

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 is not a live Reddit call and mentions a required account, implying when to use it over live data tools. However, it does not explicitly name alternatives, leaving some room for interpretation.

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 and idempotentHint, so the bar is lower. The description adds valuable behavioral context: successful live-reads are 'charged on success', internal-data reads are 'NOT metered — only rate-limited', and the account requirement (including that calling this tool provides a signup link). These details go beyond the annotations and help the agent understand side effects and prerequisites.

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

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

The description is front-loaded with the main purpose and is concise, using three sentences. The listing of specific tools in parentheses is a bit long but serves to disambiguate metered vs. unmetered operations. Every sentence contributes useful information, 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?

Given the tool has no parameters, no output schema, and rich annotations, the description provides everything needed: what it returns, which actions are metered, the account requirement, and a hint that calling it yields a signup link. It is fully self-contained for an agent to decide when and how 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 tool has zero parameters, so the schema provides complete coverage. The description does not need to explain parameter syntax, and the baseline for 0 params is 4. It indirectly explains what the tool returns (passthrough count, cap, reset time), which is parameter-adjacent but not truly parameter semantics. No deductions are warranted.

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 'Get your daily live-read usage' and specifies the exact resources returned ('today's passthrough count, your daily cap, and reset time'), which clearly identifies the tool's function. It also distinguishes itself from sibling tools by focusing specifically on usage metering and account details, not on data retrieval or alert management.

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 on when to use this tool: to check daily live-read usage, and it clarifies which operations count toward the cap versus which are unmetered. It also states the prerequisite of a free Prowlo account. However, it does not explicitly name alternative tools or state 'use this instead of X', though the distinction between live-read and internal-data reads implies appropriate selection.

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

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

The description discloses critical behaviors beyond the readOnlyHint annotation: it strips AI tells, compresses content, is 'intentionally imperfect + non-deterministic — do NOT fix it or retry,' and notes daily caps and free availability. It also states what it returns (rewrite, AI tells, quota). This is far richer than the sparse annotation.

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

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

The description is long but every sentence carries actionable value, from the core verb to input rules, output details, and non-determinism warning. It is front-loaded with the purpose and then organized into clear sections (best-use, input rules, what it returns). 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 no output schema, the description fully explains return values, including the rewrite, AI tells found, and remaining quota. It also covers usage context (post-draft), constraints (plain text, one comment, ≤2000 chars), and behavioral caveats (imperfect, daily-capped). Nothing important 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?

With schema coverage at 100%, the baseline is 3, but the description adds substantial parameter-level guidance: 'put every fact/number/name you want kept IN the text — it never invents any,' 'keep it to ONE or TWO points,' 'plain text only,' and 'shorter is better ≤2000 chars.' It also explains the character parameter as 'Pick `character` for the voice.'

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

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

The description opens with a specific verb and resource: 'Rewrite YOUR drafted comment so it reads like a real person typed it.' It clearly differentiates from sibling tools by focusing on transforming an existing comment draft rather than CRUD or search operations. The scope ('one comment per call') and output purpose are explicitly stated.

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

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

It explicitly instructs when to use: 'Best AFTER you draft a reply — write the real substance, then humanize it.' It also provides detailed INPUT RULES, including 'one comment per call, do NOT include the post you are replying to,' and tells users to pick a character for voice. This leaves no ambiguity about how to invoke it effectively.

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

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

Beyond annotations (readOnlyHint false, destructiveHint false), the description discloses several key behaviors: whole-word matching, language tagging defaults, changes taking effect on the next processing cycle, and non-retroactive updates to existing scores/matches. These go well beyond what annotations convey and set correct expectations for a mutation tool.

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

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

The description is long but well-structured and front-loaded with critical information (deprecation, purpose, key distinctions). Every sentence adds value, covering matching, language modes, prerequisites, timing, and retroactivity. It could be tightened but doesn't contain 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?

The description is highly complete: it covers the deprecation, prerequisites (Watchers, account), behavior, parameter usage, and limitations (no retroactive updates). It does not state the return value, but given the absence of an output schema and the tool's create nature, the description still provides sufficient contextual completeness for correct use.

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

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

Although the schema already documents all parameters at 100% coverage, the description adds practical meaning: clarifies the single vs. multiple term usage ('keyword' vs 'keywords'), explains the 'description' field's role in verifying matches, and gives a concrete languageMode example with the Swedish word 'syften'. This elevates the baseline from 3 due to added context.

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

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

The description clearly states the tool creates TAGGING RULES (org-wide labels for posts already ingested by Watchers), and explicitly distinguishes itself from keyword_monitor_create by noting it does NOT search Reddit. It also flags the deprecation and rename to tag_rule_create, providing strong differentiation from sibling tools.

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

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

The description provides explicit usage guidance: use keyword_monitor_create instead when searching Reddit, create Watchers first if none exist, and pass languageMode 'non-other' for terms with foreign-language meanings. It also mentions the deprecation and rename, giving clear direction to use tag_rule_create moving forward.

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

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

Goes well beyond annotations by disclosing that the action cannot be undone (reinforcing destructiveHint), changes take effect on the next scheduled processing cycle, existing scores/matches are not retroactively updated, and a free Prowlo account is required. This provides essential behavioral context beyond the structured metadata.

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

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

The description is moderately long but every sentence serves a purpose: deprecation notice, functional scope, alternative tool reference, irreversibility, scheduling, side effects, and auth requirement. It is front-loaded with the most critical info and contains no filler.

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

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

Given the confusion risk with watcher_delete and the deprecation, the description covers all necessary operational aspects: what it acts on, what it does, when it takes effect, what is not updated, account requirement, and the replacement tool. No output schema is needed for a delete operation, and the description is sufficient for correct use.

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

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

The schema already fully describes the single 'id' parameter with 100% coverage, including its provenance from tag_rule_list. The description adds context about what the rule is but does not enrich parameter semantics 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 clearly states 'Remove a TAGGING RULE' and disambiguates from Keyword Monitor entries by referencing watcher_delete. It also provides the rename target tag_rule_delete, making the tool's purpose and relationship to siblings 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?

Explicitly says when to use this tool (to stop a tagging rule from tagging posts) and when not to (Keyword Monitor entries, which are watchers), naming the alternative tool watcher_delete. Also notes the deprecation and rename, providing clear guidance on tool selection.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description adds substantial behavior: deprecation status and removal date, that it returns term/status/match statistics, that changes apply on the next scheduled cycle, that scores/matches are not retroactively updated, and that it requires a free Prowlo account (with a signup link). This is far richer than the annotations alone.

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

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

The description is front-loaded with the critical deprecation notice and rename, then flows logically through purpose, distinction, return values, effect timing, retroactivity, and account requirement. Every sentence adds necessary information, 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?

Given the tool has no parameters, no output schema, and is a simple list operation, the description covers everything: what it lists, how it differs from sibling tools, what it returns, when changes apply, what is not retroactively updated, and the account prerequisite. It is fully self-contained for an agent to select and invoke correctly.

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

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

The tool has zero parameters and the schema coverage is 100% (empty properties), so there is nothing for the description to add. The baseline of 4 applies for a no-parameter tool, and the description correctly focuses on behavior rather than parameter syntax.

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 is highly specific: it states the tool lists your org's TAGGING RULES, immediately clarifies it is the renamed version of tag_rule_list, and explicitly distinguishes it from keyword_monitor_list. This fully disambiguates the tool from all siblings.

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

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

The description gives explicit guidance: it tells the agent this is for tagging rules (not the Keyword Monitor) and directs to use keyword_monitor_list for keyword search. It also names the replacement tool (tag_rule_list), making alternatives 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?

Annotations only indicate it is not read-only and not destructive. The description adds significant behavioral context: it creates a Watcher with platform 'reddit_search', draws from the plan's keyword limit, is not metered, and requires a free account. It does not detail return values or failure modes, but covers the key side effects and prerequisites.

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

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

The description is somewhat long but every sentence adds value: it states the core function, the exact use case, the underlying watcher lifecycle, keyword limits, metering, and account requirement. It is front-loaded with the purpose, though the final parenthetical about signup could be clearer. Slightly dense but not wasteful.

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 does not explain what the tool returns, which is a minor gap. However, it covers the essential aspects: what it does, when to use it, how it relates to sibling tools, the keyword limit, metering, and authentication requirement. This is sufficient for an agent to select and invoke the tool correctly in most scenarios.

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

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 does not add parameter-specific details beyond what the schema already provides; it only reiterates the general purpose. The tags and description parameters are already well-explained in the schema, so no extra value is added.

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

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

The description opens with a specific verb and resource: 'Add a Keyword Monitor entry' and explains what it does: 'searches all of Reddit daily for this query and ingests matches into your Dataset.' It explicitly states it is the tool for 'track keyword X on Reddit' and differentiates itself from sibling tools like watcher_create by noting it creates a Watcher with platform 'reddit_search' under the hood, managed later by watcher_update/watcher_delete.

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 when-to-use guidance: 'This is the tool for "track keyword X on Reddit".' It also provides context on alternatives: watcher_update/watcher_delete manage the created watcher afterwards. It mentions the plan's keyword limit (see keyword_monitor_list) and states that it is 'Not metered,' plus a prerequisite of a free Prowlo account, all of which inform usage.

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

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

Even with readOnlyHint and idempotentHint annotations, the description adds substantial behavioral context: daily Reddit query behavior, ingestion into Dataset, quota return format (including max -1 = unlimited), Watcher id relationship, and rate/account caveats. This goes well beyond the annotation hints.

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

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

The description is dense but every sentence earns its place: definition, behavioral scope, quota detail, related operations, exclusions, cost/rate, and account prerequisite. It is structured with parentheticals and explicit cross-references, making it easy to scan despite its length.

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

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

For a read-only tool with no output schema, the description fully covers what the agent needs to know: what it lists, how it works, what it returns, related tools, and caveats. It is complete enough to invoke correctly without additional discovery.

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

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

The tool has zero parameters and schema coverage is 100%, so no parameter explanation is needed. The description appropriately focuses on return behavior (quota) rather than parameter syntax. Per the rubric, a baseline of 4 applies 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 opens with a specific verb and resource: 'List your Keyword Monitor entries', and further clarifies exactly what these entries are (daily Reddit searches ingested into your Dataset). It also distinguishes itself from sibling tools by explicitly stating 'NOT the tagging rules — see tag_rule_list', and references related operations like keyword_monitor_create, watcher_update, and watcher_delete.

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

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

The description explicitly tells when not to use it ('NOT the tagging rules') and points to the correct alternative (tag_rule_list). It also frames the tool's operational context: it is not a live Reddit call, is free but rate-limited, and requires a Prowlo account. Related add/pause/delete actions are mapped to sibling tools, providing clear navigational 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?

Beyond the annotations (readOnly false, idempotent true, destructive false), the description adds valuable behavioral context: renaming keeps old tags, changes take effect later, and retroactive updates do not occur. It also mentions the account requirement. No contradiction with annotations.

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

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

The description is moderately long but each sentence serves a purpose: deprecation notice, resource clarification, parameter mapping, behavioral timing, and account note. The structure front-loads the deprecation and disambiguation, making it scannable. Slightly verbose but justified.

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

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

Given the tool's complexity and lack of output schema, the description covers all necessary context: deprecation, sibling alternatives, parameter usage, timing, retroactivity, and account prerequisite. It is sufficient for an agent 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 schema already provides 100% coverage with detailed descriptions for each parameter. The description adds value by grouping parameters functionally (rename, refer to, pause/resume) and clarifying optional combinations, which aids in correct usage beyond the schema's individual property descriptions.

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

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

The description clearly identifies the tool as updating a TAGGING RULE, explicitly distinguishing it from Keyword Monitor entries. It provides the specific verb and resource, and distinguishes from sibling tools like watcher_update and tag_rule_update. The mention of the dashboard context ('Tagging rules') further reinforces 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 explicitly states when to use this tool: for tagging rules, not keyword monitors. It names the alternative tool (watcher_update) and provides deprecation guidance pointing to tag_rule_update. It also notes that changes take effect on the next scheduled cycle, giving clear context on when to expect results.

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

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

The description goes well beyond the readOnly/idempotent hints, disclosing pagination quirks (page can hold fewer than limit), suppression of coincidental matches, the `verification` field, automatic switch to 'matched' view for tags/watcherId, and trimming of long bodies. These are important behavioral traits not in annotations.

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

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

The description is dense but every sentence adds value: purpose, non-live caveat, filter summary, pagination, behavioral quirks, and full-body redirect. It is well-structured and front-loaded with the core purpose.

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

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

Given 17 parameters and no output schema, the description covers key return behavior (verification field, trimming), pagination semantics, account requirement, rate limit, and relationship to get_record. This is a fully-specified context for a complex tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful parameter context: explains `any` as brand-variant OR-group, the side effect of tags/watcherId forcing matched view, and the includeSuppressed behavior. This goes beyond schema descriptions.

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

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

The description clearly identifies a specific verb (List) and resource (records in your Dataset), and distinguishes itself from a live Reddit call and from get_record (which retrieves full bodies). This is a specific, non-generic purpose that differentiates from sibling tools.

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

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

Explicitly states when NOT to use it ('NOT a live Reddit call') and redirects to an alternative for a related need ('use get_record for a record’s full body'). This provides clear usage context versus 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?

The annotations already declare readOnlyHint and idempotentHint, and the description adds extra behavioral context: it is 'free, rate-limited only' and not a live Reddit call, which informs cost and latency expectations. It also discloses the account requirement and the reddit_search subreddit field quirk, going well beyond the structured annotations.

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

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

The description is packed with useful information and front-loads the core purpose in the first sentence. Subsequent sentences add details about output fields, an edge case, and constraints. It is slightly long with the parenthetical signup link, but every sentence earns its place and it remains focused.

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

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

Despite having no output schema, the description outlines the key return fields (sources, paused state, tags, record counts, today's arrivals) and clarifies the reddit_search subreddit quirk. It also notes authentication requirements and rate-limit behavior, making it complete for a zero-parameter list 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 tool has zero parameters, so the baseline is 4. The description adds no parameter details (since none exist), but it does explain what the response contains, which helps the agent interpret output rather than input. There is nothing more to add 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 opens with a specific verb+resource: 'List the Watchers configured for your organization,' immediately establishing what it does. It distinguishes from siblings by noting 'the same ones the dashboard manages' and clarifying that reddit_search watchers correspond to Keyword Monitor entries, which sets it apart from other listing tools like keyword_monitor_list.

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

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

It provides clear context: use it to see organization watchers, their sources, paused state, tags, and counts. It warns that it is 'NOT a live Reddit call,' implying it is not for real-time data, and notes a free Prowlo account is required. However, it does not explicitly name alternative tools for live Reddit data, so the exclusion is implied rather than stated.

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

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

Annotations only state read-only and idempotent, but the description adds extensive behavioral context: rate limiting, key default behavior for suppressed records, verification field, body trimming, and account prerequisite. This goes far beyond annotations and enriches agent understanding.

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, dense paragraph that front-loads the core purpose and then efficiently covers key behaviors. It is longer than absolutely necessary but every sentence adds meaningful value 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?

With no output schema, the description carries the burden of explaining response behavior. It mentions verification fields, trimming, and implies pagination via cursor references in the schema. It could be more explicit about the overall response structure, but is adequate for a complex search tool.

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

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

Schema coverage is 100%, but the description adds valuable semantics for key parameters like `any` (brand-variant OR-group), `includeSuppressed` behavior, and the verification field. It also summarizes the broader filter set, making param behavior clearer than schema alone.

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

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

The description clearly states 'Semantic or keyword search across your Dataset' with specific detail on vector and full-text search. It distinguishes from siblings by explicitly stating 'NOT a live Reddit call' and pointing to get_record for full bodies, making its scope precise.

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

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

Provides explicit usage context: it is not live, has rate limits, requires a Prowlo account, and directs users to get_record for full bodies. This offers clear when-to-use guidance relative to 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 declare readOnlyHint=true, and the description reinforces this with 'read-only' while adding cost ('1 credit') and account requirements ('requires a free Prowlo account'). It also clarifies the platform limitation (hackernews has no channels) and the behavior of `include:["rules"]`. This adds valuable context beyond the annotation, though response format is not disclosed.

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 purpose, and every sentence adds value: the two modes, the platform restriction, cost, read-only status, and account prerequisite. No wasted words.

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

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

Given no output schema, the description does not explain return format, but covers the essential operational details: search vs. exact lookup, inclusion of rules, platform restriction, credit cost, and account requirement. It lacks only minor details like error conditions or response schema, which are less critical for a read-only discovery 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%, so the schema already documents each parameter. The description adds relational semantics by explaining the choice between `query` and `channel`, and that `include` is only valid in channel mode. This goes beyond individual parameter descriptions to clarify usage patterns.

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: 'Discover or inspect channels (Reddit subreddits).' It goes beyond the name by specifying the resource type (subreddits) and the two operational modes (query vs exact channel). It also distinguishes from siblings by noting 'Reddit only — hackernews has no channels,' making it clear this tool is for Reddit channel discovery.

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

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

The description provides clear usage context: 'Pass `query` to search, or an exact `channel` for its metadata' and explains the `include` parameter usage in channel mode. It explicitly excludes hackernews, but does not name alternative tools for other platforms or use cases. The prerequisite account note is helpful, but no when-to-use vs. sibling-specific guidance is given.

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

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

Annotations already provide readOnlyHint=true, and the description reinforces this with 'read-only.' It adds substantial extra context: '1 credit' cost, 'Reddit comments via RSS are flat/unscored,' and the account requirement. This goes well beyond the minimal annotation.

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

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

The description is compact and information-dense: purpose, parameter clarifications, cost, read-only, RSS caveat, and account requirement all fit in three sentences with no 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 simplicity and the absence of an output schema, the description covers purpose, parameters, cost, read-only nature, and comment behavior. It doesn't detail the exact return structure, but the phrase 'with its comment thread' suffices for a fetch-one tool. A slightly more explicit mention of when to use this vs. listing tools would push it to 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 schema has descriptions for id and platform only, while commentLimit and includeComments lack schema descriptions. The description compensates by explaining id formats (permalink URL, t3_xxx, bare id, HN numeric) and clarifying includeComments default and commentLimit ≤ 20. This adds meaning beyond the schema.

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

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

Description opens with 'Fetch one post/story with its comment thread,' a specific verb and resource. It clearly distinguishes from siblings like social_list_posts (listing multiple posts) and social_get_user (user data).

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 tool is clearly intended for retrieving a single post/story by ID, but it does not explicitly name alternatives or state exclusions. It does give context on when to use it (you have a post ID) and provides a prerequisite about the Prowlo account.

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

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

Beyond the readOnlyHint annotation, the description discloses the credit cost ('1 credit'), account requirement, and the behavior of returning a signup link if no account exists. It also specifies what data is fetched per platform, adding value beyond the annotation. However, it omits error specifics or rate limits.

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

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

The description is two terse sentences, front-loaded with the primary action and immediately followed by relevant details (platform fields, credit, read-only, account note). Every word serves a purpose, with no redundancy or filler.

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

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

For a simple 2-parameter read-only tool without an output schema, the description thoroughly explains the return value per platform, cost, and account prerequisite. It lacks an explicit return format or error-handling details, but for typical use it 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 schema already covers both parameters with descriptions, but the tool description adds meaning by explaining that the 'platform' parameter determines which fields are returned (reddit: account age, karma; hackernews: about, created). This deepens understanding of how parameters affect the output beyond the schema's basic enum values.

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 'Fetch a user profile', a specific verb-object pair that clearly identifies the tool's function. It further differentiates from siblings by listing platform-specific data (reddit vs hackernews fields), which distinguishes it from social_get_post and social_get_user_activity.

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 on when to use the tool (fetching user profiles) and adds practical notes like '1 credit' and account requirement, but it does not explicitly contrast with alternative tools or state exclusions. Usage is implied rather than explicitly guided.

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

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

Beyond the readOnlyHint annotation, the description discloses credit cost, account requirement with signup link behavior, and source details (reddit via RSS, newest-first, ~20). This adds meaningful behavioral context.

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

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

The description is tightly packed: main purpose, kind parameter, source/ordering, cost, and account requirement are each conveyed in brief clauses. It front-loads the 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?

For a simple read-only tool with no output schema, the description covers the core semantics, source, ordering, cost, and account prerequisite. It doesn't explicitly describe the return structure, but that is implicit in 'fetch submissions or comments'.

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

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

The description clarifies the kind parameter ('kind=submissions|comments (default submissions)') and hints at the limit default (~20). The schema already documents platform and username, so this complements rather than repeats.

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

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

The first sentence 'Fetch a user's recent submissions or comments' clearly states the tool's function with a specific verb and resource, and the kind parameter specification distinguishes it from sibling tools like social_get_user or social_get_post.

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

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

The description gives implied usage context (fetching recent activity for a user) but does not explicitly name alternatives or state when not to use this tool. It mentions credit cost and account requirement, which are prerequisites, but no exclusions.

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

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

The description adds meaningful context beyond the readOnlyHint annotation: cost (1 credit), account requirement (Prowlo), platform-specific parameter handling (channel ignored for HN, time only for top/controversial), and a read-only note. 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 compact and front-loaded with the core action ('List posts/stories'), then efficiently organizes platform specifics in a semicolon-separated list. There is 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?

It covers platform requirements, defaults, limits, cost, and auth. However, it omits any mention of pagination, continuation tokens, or response structure, which would be helpful for a list endpoint.

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?

Even though schema coverage is 100%, the description adds crucial semantics: channel becomes conditionally required for reddit, limit caps are platform-specific (≤20 for reddit vs ≤30 for HN), time only applies to certain sorts, and sort defaults are clarified. This goes far beyond the schema's property descriptions.

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

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

The description clearly identifies the action ('List posts/stories') and specifies both platforms with distinct behavior. It distinguishes from siblings like social_get_post by focusing on listing, and from social_search by straightforward feed retrieval.

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

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

It provides explicit per-platform instructions: channel is required for reddit, sort defaults for hackernews, and platform-specific limits. However, it does not explicitly name alternative tools or state when not to use this tool, so it lacks explicit exclusion/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?

Beyond readOnlyHint, it discloses 1-credit cost, read-only nature, RSS-caused score/comments anomalies, body truncation, and account prerequisite. These are valuable behavioral disclosures that annotations do not cover.

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

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

Dense and well-organized: purpose, per-platform parameters, caveats, and prerequisite are clearly sequenced. Each sentence conveys useful information, though the length is somewhat high.

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

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

Covers both platforms, parameter constraints, credit cost, known limitations, and account requirement. Missing response format details, but with no output schema and high schema coverage, it is reasonably complete for a complex tool.

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

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

Schema coverage is 100%, so the description mainly restates parameter details with platform-specific grouping. It adds minor clarifications like limit≤20 and unix timestamp for since, but does not significantly enrich the schema definitions.

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?

States 'Live full-text search of a source' and specifies reddit and hackernews platforms, clearly distinguishing from siblings like search_dataset and social_get_post. The verb 'search' and resource scope are specific and unambiguous.

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

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

Provides platform-specific parameter breakdowns and explicitly notes limitations (RSS scores may be 0, long bodies truncated), which indirectly points to social_get_post for full text. However, it does not explicitly name alternative tools or state when not to use this tool.

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

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

Annotations already indicate a non-read-only, non-destructive operation. The description adds useful behavior: changes apply on the next scheduled processing cycle, existing scores/matches are not retroactively updated, and an account is required. This goes beyond the structured fields and sets accurate expectations without contradicting the annotations.

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

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

The description is longer than a typical one-liner, but every sentence earns its place: purpose, alternatives, parameter guidance, prerequisites, and side effects. It is front-loaded with the core definition and uses clear punctuation. Slight redundancy exists (mentioning languageMode twice), but overall it is well-structured for the information density.

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 prerequisites, alternatives, parameter semantics, effect timing, non-retroactivity, and an account requirement — substantial context for a create operation without an output schema. It doesn't explicitly describe the return value, but that is minor for a creation tool. The guidance is sufficient for an agent to invoke it correctly in most scenarios.

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%, but the description adds meaningful context: it explains the difference between keyword and keywords, clarifies that description is used to verify matches and avoid coincidental hits, and details when languageMode 'non-other' is appropriate with an example. It enriches every parameter beyond the raw 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 starts with 'Create TAGGING RULES (the dashboard's 'Tagging rules')' — a specific verb and resource — and explicitly clarifies the scope ('org-wide labels for posts your Watchers already ingest'). It also distinguishes itself from sibling tool keyword_monitor_create, making the purpose unmistakable.

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

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

Provides explicit when-to-use with a direct contrast: 'This does NOT search Reddit: to add a Keyword Monitor entry... use keyword_monitor_create instead.' It also advises creating a Watcher first if none exist and gives conditional guidance on languageMode (e.g., using 'non-other' for common foreign words). Alternatives and prerequisites are clearly stated.

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 significant behavioral context beyond the annotations: it states the action cannot be undone, changes take effect on the next scheduled cycle, and existing scores/matches are not retroactively updated. This complements the destructiveHint and idempotentHint 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?

The description is front-loaded with the core purpose, followed by crucial side effects and a prerequisite. Each sentence adds distinct value without redundancy, maintaining a concise yet thorough structure.

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

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

For a destructive, single-parameter tool with no output schema, the description covers the action, the schedule effect, non-retroactivity, irreversibility, and authentication requirement. It is complete and self-sufficient for an agent to select and invoke the tool correctly.

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

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

The schema covers the only parameter (id) with 100% description coverage, explaining it is the id returned by tag_rule_list. The tool description itself does not add further parameter detail, but with full schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the action ('Remove a TAGGING RULE'), identifies the specific resource ('Tagging rules' dashboard), and explicitly distinguishes it from a similar sibling (watcher_delete). The verb+resource combination is unambiguous and differentiates this tool from tag_rule_update, tag_rule_create, and keyword_monitor 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 provides explicit when-not guidance by clarifying that this is not for Keyword Monitor entries (which are Watchers) and points to the correct alternative (watcher_delete). It also gives context about when to use it (to stop a tagging rule from tagging posts) and notes a prerequisite (free Prowlo account).

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses the return contents ('term, active status, and match statistics'), timing of changes ('next scheduled processing cycle'), non-retroactive effects, and an account prerequisite. These details are valuable for an agent deciding whether to invoke the tool and how to interpret results.

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

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

The description is appropriately sized and front-loaded. It opens with the core purpose and sibling distinction, then adds essential details about matching behavior, return values, and caveats. Every sentence contributes meaning, 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?

Even though there is no output schema, the description explains what the tool returns. It includes all necessary context: what the rules are, when to use this tool versus alternatives, how matching works, behavioral caveats, and account requirements. This is complete for a parameterless read-only listing 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 tool has zero parameters, so there is no parameter ambiguity. The description itself indicates the scope (org-level rules) without needing parameters, which is sufficient. The baseline of 4 applies because no parameters exist to clarify.

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

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

The description clearly states the action ('List') and the resource ('your org's TAGGING RULES'), specifying what these rules do (labels applied to posts your Watchers already ingest). It explicitly distinguishes this tool from the sibling keyword_monitor_list, making its purpose unambiguous.

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

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

It gives explicit guidance on when to use this tool vs. the alternative: 'NOT the dashboard's Keyword Monitor: for the keywords that search all of Reddit daily, use keyword_monitor_list.' This directly steers the agent to the correct sibling based on the use case.

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

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

The description discloses several behavioral traits beyond the annotations: renaming keeps old tags, changes take effect on the next processing cycle, and existing scores/matches are not retroactively updated. This adds significant context not available from the readOnly/idempotent hints alone.

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

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

The description is slightly verbose (multiple clauses, parentheticals) but front-loaded with the primary purpose and sibling differentiation. Each sentence contributes useful context, though the parenthetical about Prowlo accounts could be trimmed without loss.

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

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

For an update tool with no output schema and 4 parameters, the description fully covers behavior, side effects, timing, and constraints. It explains consequences (old tags retained, no retroactive updates) and even the account requirement, making it self-sufficient 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?

Even with 100% schema coverage, the description adds meaning: id is explicitly 'the current term to update (the id returned by tag_rule_list)', keyword is 'new term to rename this rule to', description is used to 'verify that matches are genuinely about it', and active maps to pause/resume. This goes beyond the raw schema.

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

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

The description states a specific verb and resource: 'Update a TAGGING RULE' and further scopes it to the 'Tagging rules' dashboard. It explicitly differentiates from Keyword Monitor entries by pointing to watcher_update, making the tool's purpose unambiguous.

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

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

Provides explicit guidance on when to use this tool vs alternatives: 'not a Keyword Monitor entry (those are Watchers; see watcher_update)'. It also clarifies the three use cases (rename, set description, pause/resume), leaving no doubt about applicability.

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

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

The description discloses key behavioral traits beyond the minimal annotations: 'Points recompute periodically,' 'Not metered,' and the account requirement with a signup link. These are valuable context for an agent to understand side effects and prerequisites, which annotations alone do not provide.

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

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

The description is 4 sentences, front-loaded with the main purpose, and every sentence adds value (definition, parameter clarification, behavior, and prerequisite). It is appropriately sized 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?

The description covers the core concept, key parameters, behavioral traits, and account requirement, making it sufficient for an agent to invoke correctly. However, it does not mention the return value or response structure (no output schema exists), which is a minor gap for a create 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 detailed descriptions for interval and window in the schema. The description repeats this information ('interval is hour or day; window is how far back to compute') without adding new semantics. The cross-reference to search_dataset/list_records filters is in the schema itself, so the description does not compensate beyond baseline.

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

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

The description clearly states 'Create a Trend: a saved match query bucketed over time,' using a specific verb and resource with a definition that distinguishes it from sibling tools like alert_create or keyword_create. The phrase 'bucketed over time' adds unique semantic value beyond the name.

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 on what the tool does, implying when to use it (i.e., to create a time-bucketed saved query), but does not explicitly mention alternatives or exclusions. It lacks a direct 'use this instead of X' comparison, but the definition is sufficient for basic selection.

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

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

The description adds context beyond the annotations by disclosing that the operation is 'Not metered' and requires a free Prowlo account. It also hints at how to obtain an account via 'call it to get a signup link'. This supplements the destructiveHint and idempotentHint annotations with useful operational details, although the phrase 'call it' is somewhat ambiguous.

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 front-loaded with the main action. The second sentence adds relevant notes on metering and account requirements, though the phrase 'call it' is slightly awkward and could be misinterpreted. Overall, it is appropriately sized with no redundancies.

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 delete tool with one parameter and no output schema, the description covers the essential purpose, a parameter reference, and unique operational conditions (metering, account requirements). While it does not detail return values or error behavior, the annotations (destructiveHint, idempotentHint) fill the safety profile, making the description 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?

The schema already fully documents the sole parameter 'id' with description 'Trend id to delete (from trend_list)'. The description repeats 'by id' without adding new semantics. Since schema coverage is 100%, the baseline score of 3 applies; the description does not 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 action ('Delete a Trend by id') with a specific verb and resource. It distinguishes from sibling tools like trend_get, trend_list, trend_update, and trend_create by explicitly indicating deletion. The resource name 'Trend' is 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 provides some usage context: 'Not metered' and 'requires a free Prowlo account — call it to get a signup link'. This implies that usage is conditional on account creation and that the operation is not metered. However, it does not explicitly state when to use this tool versus alternatives (e.g., trend_update for modification) or provide exclusions.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses sparse data behavior (missing buckets should be treated as zero), notes that the tool is not metered, and mentions the Prowlo account requirement. These are significant behavioral details that aid correct usage.

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

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

The description is efficient: two sentences plus a parenthetical. It front-loads the primary purpose, then adds essential behavioral notes (sparse points, metering, authentication) without unnecessary elaboration.

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 single-parameter get tool with no output schema, the description offers a clear outline of the returned data (count + per-intent breakdown) and sparse points behavior. It does not specify error handling or the full response shape, but it is sufficiently complete for typical use.

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

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

The sole parameter 'id' has full schema coverage with the description 'Trend id to fetch (from trend_list),' so the schema already communicates the parameter's meaning. The tool description adds no further parameter-level semantics, matching the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Get one Trend with its computed time-series points,' specifying the resource and the key output. It distinguishes from trend_list by emphasizing a single Trend and its time-series data.

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 through the parameter description ('from trend_list') and the focus on a single Trend, but it does not explicitly name alternative tools or state when to prefer this over trend_list. No clear when-not-to-use guidance is given.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses key behavioral details: it 'Includes computed point counts' and explains the sparse nature of points with a concrete example (30d daily trend with one day of matches → pointCount 1). It also states 'Not metered' and the account requirement, offering valuable context about cost and access that annotations do not cover. There is no contradiction with the annotations.

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

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

The description is front-loaded with the core action ('List your organization’s Trends') and then adds necessary context in a logical order. The pointCount sparsity explanation and 'Not metered' note earn their place. The parenthetical about the Prowlo account is a bit clunky ('call it to get a signup link') but still informative. Slight redundancy in explaining Trends could be trimmed, but overall it is 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 zero-parameter, read-only list operation with no output schema, the description is impressively complete. It defines the domain (Trends), states what is included (computed point counts), warns about a non-obvious behavior (sparse points), and mentions both metering status and account requirements. There is no major missing context; the only optional addition would be pagination or ordering, but the description stands on its own.

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

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

The tool has no parameters and the schema is empty, so schema coverage is trivially 100%. The description adds no parameter-specific info, but none is needed. Per the rubric, 0 params yields a baseline of 4, which is appropriate here since there is nothing to explain beyond what the empty schema already communicates.

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 immediately states 'List your organization’s Trends', using the specific verb 'list' with a clear resource. It further defines what a Trend is (saved queries that produce a time-series), which distinguishes it from related tools like trend_get (which likely retrieves a single trend) or trend_create/update. The scope ('your organization’s') makes the action unambiguous.

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

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

The description provides an important prerequisite ('requires a free Prowlo account') and notes that the tool is 'Not metered', giving cost context. However, it does not explicitly contrast with sibling tools such as trend_get or trend_list vs alert_list, nor does it state when not to use this tool. The usage guidance is implied ('list' vs 'get') but not explicitly clarified.

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 (idempotentHint true, destructiveHint false, readOnlyHint false) already indicate a non-destructive, idempotent mutation. The description adds valuable context beyond annotations: 'Only provided fields change' clarifies partial update semantics, 'Not metered' provides cost/usage behavior, and 'requires a free Prowlo account — call it to get a signup link' discloses an authentication requirement. These additions go beyond what the annotations capture.

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: the first sentence states the core purpose and scope, followed by three short, informative clauses. Every sentence earns its place, providing the partial-update behavior, metering note, and account requirement without any 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?

The description is reasonably complete for an update tool with no output schema. It covers the purpose, partial-update semantics, metering, and auth requirement. It does not describe return values or error handling, but those are not required by the output schema. Given the nested query object, one could argue for more detail, but the schema already documents the query shape in depth.

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, so each parameter already carries a description. The tool description adds minimal parameter-level information, focusing only on the list of fields (name, query, interval, window) and the partial-update behavior. With high schema coverage, a baseline of 3 is appropriate; the description does not add significant new meaning beyond the schema.

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

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

The description clearly states the action ('Update') and the resource ('Trend'), and also lists the specific mutable fields (name, query, interval, window). This makes it unambiguous and distinguishes it from sibling tools like trend_create or trend_delete.

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

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

The description implies usage by saying 'Update a Trend' and 'Only provided fields change', which suggests a partial-update pattern. However, it does not explicitly say when to use this tool versus alternatives like trend_create or trend_delete, nor does it mention any prerequisites or context beyond the account requirement.

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

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

Annotations are sparse (readOnlyHint=false, destructiveHint=false), so the description carries weight. It adds useful context: 'Not metered' and 'requires a free Prowlo account.' However, it does not disclose what happens when the tool is invoked (e.g., mutation, no-op, or error), and the phrase 'call it to get a signup link' is ambiguous about whether 'it' refers to this tool.

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

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

The description is short and front-loaded with the deprecation warning. The alternative is named efficiently. The parenthetical about the signup link is somewhat confusing and could be clearer, but overall it is 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?

For a deprecated tool, it clearly signals to avoid using it and points to the replacement. However, it does not explain the actual effect of calling watcher_add_source, and with no output schema, return behavior is unspecified. This is adequate but lacks full operational detail.

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

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

Schema description coverage is 100%, so each parameter already has a meaningful description. The tool description adds no parameter-specific meaning beyond the schema, so the 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 leads with 'Deprecated' and explains that a Watcher watches exactly one community/query, but it never explicitly states that the tool adds a source to a watcher. The alternative name watcher_create helps distinguish it, but the core purpose is only inferable from the tool name and schema.

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

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

The description explicitly instructs the agent to 'Use watcher_create to watch another community' and explains why (one Watcher per source). This is a clear when-not-to-use directive with a named alternative, which is exactly what a deprecated tool needs.

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?

Discloses rich behavioral details beyond annotations: one Watcher per sources entry, derived names, per-plan keyword limits, daily Reddit search behavior, non-metered status, and account/signup requirement. Annotations only say readOnlyHint=false and destructiveHint=false, so there is no contradiction.

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

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

The description is dense but front-loaded with the core purpose, and each clause carries operational information. Parentheticals and dashes keep it organized, though it is longer than necessary; still, no sentence is 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 two-parameter creation tool with no output schema, the description is comprehensive: it covers purpose, special keyword-monitor mode, default community behavior, per-source creation semantics, plan limits, metering, and account prerequisite. The agent has enough context to invoke correctly.

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

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

Schema covers all 2 parameters with descriptions, so baseline is 3. The description adds valuable semantic context: the search query is passed via channel, subreddit is an alias that non-Reddit queries also use, and each sources entry maps to its own Watcher. This goes beyond the schema's field-level descriptions.

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

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

The description opens with 'Create Watchers', clearly identifying the action and resource. It distinguishes the keyword-monitor use case from community watchers and explicitly contrasts with keyword_monitor_create, making the tool's scope unambiguous relative to siblings.

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

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

Provides concrete guidance: use platform 'reddit_search' with query as channel for keyword monitors, use keyword_monitor_create as the one-query shortcut, and understand that each sources entry creates its own Watcher. It also mentions plan limits and account requirements, helping the agent choose appropriately among 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 destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds specifics about what gets destroyed ('source and records'), clarifies that the operation is 'Not metered', and mentions the account requirement, which goes beyond the structured annotations without contradicting them.

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

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

The description is a single sentence with a parenthetical, front-loading the core action and adding side-effect and account context in minimal words. Every clause adds useful information without redundancy.

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

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

For a destructive single-parameter mutation, the description covers the action, side effects, metering, and account requirements. The annotations provide safety and idempotency hints, and there is no output schema, so no return value explanation is needed. The description is sufficiently complete for an agent to invoke safely.

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 fully documents the single 'id' parameter with the description 'Watcher id to delete (from list_watchers)', so schema coverage is 100%. The tool description adds no further parameter details, meeting 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 states 'Delete a Watcher by id' with a clear verb and resource, and adds 'also removes its source and records' to precisely define the scope. This distinguishes it from sibling tools like watcher_remove_source, which only removes a source from a watcher.

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 full watcher deletion and notes side effects (removing source and records), but it does not explicitly state when to use this vs. alternatives like watcher_remove_source or when not to use it. The account requirement is mentioned but no exclusions or alternative tool references are 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 destructiveHint=true and idempotentHint=true, but the description adds valuable behavioral context: the consequence that a source-less Watcher 'ingests nothing' and the recommendation to use watcher_delete instead. It also discloses that the operation is not metered and requires an account. 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 front-loaded. The core purpose is in the first sentence, with two parentheticals adding essential guidance and prerequisites. Every sentence earns its place 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?

For a simple 2-parameter tool with no output schema, the description covers the purpose, the side effect, the alternative tool, and account requirements. It does not describe the return value or error behavior, but that is a minor gap given the simplicity and available 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 description coverage is 100%, with both parameters (sourceId, watcherId) clearly described in the schema. The description adds no new parameter semantics beyond restating 'by source id' and confirming that sourceId refers to the source to remove. Baseline 3 is appropriate because 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 states exactly what the tool does: 'Remove a source from a Watcher by source id.' It uses a specific verb and resource, and immediately differentiates from the sibling tool watcher_delete by warning that a source-less Watcher ingests nothing and that watcher_delete is usually preferred.

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

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

The description provides explicit usage guidance: 'A source-less Watcher ingests nothing — usually you want watcher_delete.' This tells the agent when NOT to use this tool and points to the correct alternative. It also notes 'Not metered' and the requirement for a free Prowlo account, which are relevant operational conditions.

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

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

Adds significant context beyond annotations: names are immutable, tags replace only plain tags (conditional tagging rules unaffected), tool is not metered, and a free Prowlo account is required. These details help the agent anticipate side effects and prerequisites without contradicting the idempotent/non-destructive hints.

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

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

Two sentences front-load the core actions followed by essential caveats. Every part earns its place, with no fluff or redundancy.

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

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

For a simple update tool with good schema and annotations, the description covers behavior, account requirements, and tag nuance. It doesn't describe return values, but no output schema exists and the return is likely self-evident. Slightly more detail on atomicity when both paused and tags are provided could push it to 5, but it's 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?

Schema already covers all parameters with 100% coverage, so baseline is 3. The description adds value by clarifying that 'tags' replaces only plain tags and conditional tagging remains unaffected, and that clearing tags uses []. This nuance helps avoid misuse even though the schema is already descriptive.

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

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

Clearly states the tool updates a Watcher by pausing/resuming and/or replacing tags, distinguishing it from create/delete/source-modification siblings. Also notes names cannot be changed, further clarifying scope.

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

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

Implied usage is clear (use for pause/resume or tag updates), and it explicitly states names cannot be changed via this tool. However, it does not explicitly name alternatives or mention when not to use, so it falls short of fully explicit guidelines.

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