rocketsloth

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, covering the core safety profile. The description supplements this by clarifying it is only a catalog, listing the informational content, and saying no authentication is needed.

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

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

Three short, focused sentences with no filler. The most important distinction 'Catalog only' is front-loaded, followed by the content summary and the follow-up action.

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

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

For a zero-input, no-output-schema, read-only catalog, this is complete: an agent knows why to call it, what it will contain, and the next step. Nothing needed for invocation or correct behavior is missing.

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

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

The schema has zero parameters and existing properties, so full coverage is given and the description correctly implies no input is required. The additional 'No authentication required' and 'Call apply next with...' context helps distinguish this from next steps, though no parameter semantics are needed 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 states a specific verb and resource: it is a catalog and a read-only informational tool, not an application. It distinguishes itself from sibling tools by naming the 'apply' flow and listing the catalog content (integration model, payout terms, tool 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 explicitly frames this tool as a non-application prerequisite and instructs the agent to call 'apply' next with the exact parameters. It also states that no authentication is required, which helps the agent decide when to invoke this safely.

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, the description discloses important behaviors: accepted authentication methods, the automatic resubmission of the application within about an hour, the revocation and replacement of the API token for rotate_token, and the limitation that rotate_token is unavailable to web sessions. These specifics add genuine transparency beyond the destructiveHint=true annotation and help the agent set correct expectations.

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

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

The description is dense and front-loaded with the primary purpose, and every clause contributes substantive information. It is structured around the action values, making it fairly scannable. However, the long parenthetical-heavy single paragraph could be more readable as a concise list, so it loses one point for structural polish.

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 5 parameters, no output schema, and a destructive annotation, the description is detailed enough for an agent to select and invoke the correct action. It covers authentication, action semantics, field-specific guidance, and a key limitation. The main gap is that it does not describe the return value or response format for each action, which would be helpful since no output schema is provided.

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 covers all 5 parameters with descriptions, so the baseline is 3. The tool description adds meaningful semantics: it explains the default value of action, the meaning of view, the purpose of google_email with a concrete condition, and the functional difference of rotate_token. This enriches parameter understanding without duplicating the schema verbatim.

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 clear verb-resource pair ('View or update your account') and enumerates the specific actions available: view, update, and rotate_token. It also clarifies the scope of each action (e.g., 'view' covers account and site status; 'rotate_token' revokes and issues a new API token), which distinguishes it from related account-adjacent 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 context-sensitive guidance: it tells agents not to ask for an sk_ token when a Bearer web session is already active, explains when to set google_email (when the on-file Google email already has an Ad Manager account or invitation), and notes that web sessions cannot use rotate_token and should use https://rocketsloth.ai/recover instead. It does not explicitly contrast this tool with all sibling tools, but the most relevant alternative (recover) is named.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds behavioral context by noting both read and write capabilities ('view and adjust'), listing concrete operations like 'enable/disable' and 'update', and explaining authentication token/session acceptance. This goes beyond the schema.

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

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

Three dense sentences; front-loaded with purpose. The second and third sentences are long but packed with essential resource/action details. Could be more scannable with bullets, but every piece of information is useful.

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 authentication, discovery mechanism, all current resources with their sub-actions, and explicitly addresses the session-vs-token nuance. No output schema exists, but the description's guidance on calling with no action to discover what's available is sufficient for the 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 merely defines resource as 'The resource to act on,' but the description enriches it by listing valid resource values (anchor, video_formats, rewarded) and the exact actions possible for each. It also clarifies the 'action' parameter's role and the utility of calling without an action. This substantially compensates for the schema's minimal descriptions.

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

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

The description clearly states the tool's function: 'View and adjust ad settings for your site.' It then enumerates specific resources (anchor, video_formats, rewarded) and their associated operations (get/update, get/enable/disable), making it distinct from sibling tools like payments or subscriptions.

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

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

Provides explicit usage guidance: pass resource and action, call with no action to discover available options, and clarifies authentication preferences (prefer Bearer session over asking for sk_ token). It doesn't explicitly contrast with sibling tools, but the specificity of ad settings makes the use case 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?

Discloses that the first call after approval returns the API token only once, and that units upgrade to full demand automatically, indicating side effects beyond a simple read.

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 verbose, repeating authentication details, but 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?

Provides necessary context about authentication methods and behavioral changes, covering the tool's purpose effectively.

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

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

The schema describes the token parameter, and the description reiterates it, clarifying it can be sent via header.

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 checks application status using a token. Distinct from siblings like 'apply' or 'reporting'.

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

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

No explicit guidance on when to use this over other tools, but the description provides context on behavior during pending/approved states, implying when to check.

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 idempotentHint=true and destructiveHint=false, and the description complements this with no-auth required, rate limiting per IP, and a promise that the service never asks for sensitive data in chat. It also discloses the return shape (an at_... application token) 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 but tightly packed: ordering, non-obvious parameter semantics, human signup fallback, next-step routing, security note, and rate limits. It is front-loaded with 'Call this first after connecting...' and each sentence contributes useful information without rambling.

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?

There is no output schema, yet the description tells the agent it receives a token, must call integration next, needs no auth, is rate limited, and that it should not concern itself with sensitive data. The only absent element is what to do after an application already exists, but that is covered by sibling tools and not necessary for a run-once introductory 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 schema covers 100% of parameters, so the baseline is 3. The description adds only minor semantic hints (http/https URL not yet live; publisher_name is not agent_name), both of which the schema already provides. It omits google_email entirely, but the schema documents it clearly, so no deficiency at baseline.

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

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

The description explicitly states the action (apply as a publisher), positions it as 'Call this first after connecting,' and clarifies that connecting the MCP server alone is not an application. This makes the tool's purpose distinct from both the generic 'apply' name and sibling tools like 'integration' or 'application_status'.

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 routes usage: 'Call this first after connecting,' then 'Call integration immediately with it.' It clearly instructs when to use the tool and what to do next. It lacks explicit 'do not use when...' exclusions, but as a one-time-first-step tool it is well-specified.

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 clearly states 'No authentication required; rate limited per IP' which provides practical behavioral context beyond the annotations. The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds a critical constraint (rate limiting).

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 achieve clarity, guidance, and behavioral disclosure with zero waste. The instruction about thread_id is front-loaded and actionable.

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 general Q&A tool with no output schema and only two well-documented parameters, the description is complete enough. It gives the scope, a key usage hint (threading), and a behavioral constraint (rate limit). A minor gap: it doesn't mention what happens if an out-of-scope question is asked, but the explicit domain list compensates.

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 fully documents both parameters. The description adds detail by specifying the domains the question covers ('about integration, ad units, application, reporting, or payments') and the threading behavior for thread_id, going slightly beyond the schema's basic descriptions. However, with complete schema coverage, the contribution is modest, earning 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 clear verb ('Ask') and specific resource ('the Rocket Sloth setup agent'), and explicitly lists the covered domains (integration, ad units, application, reporting, or payments). This differentiates it well from sibling tools like 'about', 'integration', 'reporting', or 'payments' which might also involve asking questions but likely in a more specialized manner.

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 on when to use it ('Ask the Rocket Sloth setup agent anything about...') and how to use it correctly ('Pass the returned thread_id on follow-up questions to keep context'). It does not explicitly mention when not to use alternatives, but the domain list implicitly covers it, and the depth of context is appropriate for a general Q&A 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds value by specifying the exact format of the returned data (statuses, responsible parties, instructions, next_action) and the authentication caveat about not prompting for tokens, which is useful behavioral context beyond the annotations.

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

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

The description is a single dense paragraph that front-loads authentication requirements and then clearly enumerates the return content. Each clause contributes useful information without redundancy, though it could be slightly trimmed for maximum compactness while preserving all key details.

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

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

Despite having no output schema, the description fully explains the structure of the returned checklist (statuses, responsible parties, instructions, next_action). It also notes that the checklist is embedded in application_status, giving cross-reference for alternative access. This is complete for a read-only informational tool with a well-defined response shape.

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 single token parameter with a description, but the tool description adds significant context: it explains that a Bearer web session from the in-page agent also works and explicitly instructs never to ask for a token when already authenticated. This goes beyond the schema's description, enhancing parameter understanding.

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

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

The description clearly states the tool's purpose: it returns the onboarding checklist with steps, statuses, and the next action. It distinguishes itself from siblings by noting that the same checklist is embedded in application_status, which sets it apart as the detailed checklist view.

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 authentication guidance, including acceptable token types and the web session alternative, and warns against asking users for tokens when a session exists. It implies when to use this tool (to see the full checklist) and hints at an alternative (application_status for a lighter view), though it doesn't explicitly contrast with all sibling 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 state readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds authentication specifics (token types, Bearer session) and clarifies the verify parameter triggers external fetch. No contradictions with annotations, and it goes beyond the schema by explaining behavior.

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

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

Description is a single, information-dense sentence with parentheticals. It is front-loaded with the primary purpose and includes necessary auth details without excessive verbosity. Could be slightly more concise but each clause serves a purpose.

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

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

Covers authentication prerequisites, availability timing, and optional verification behavior. While no explicit return format is mentioned, the description sufficiently covers the tool's functionality given no output schema exists. The inclusion of placement guidance adds value.

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 description enriches both parameters: explains token formats (at_..., sk_...) and that a Bearer session also works, and explains verify=true triggers a check. This adds clarity not present in 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 explicitly states it retrieves the exact script tag and ad-unit markup, clearly distinguishing it from sibling tools like apply or ad_settings. The verb 'Get' plus specific resource makes 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 (available immediately after apply), authentication methods (token or Bearer session), and when to use verify=true. It also advises against asking users to paste tokens when session already authenticates, effectively excluding misuse.

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 clearly states the tool is read-only, what actions it exposes, and that it will not collect bank, card, tax, or government ID information. It also discloses accepted authentication modes and redirects sensitive changes to the dashboard, adding context beyond the provided 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 somewhat dense, but every clause adds useful information: authentication behavior, allowed actions, returned data, read-only boundaries, and privacy limitations. There is no filler or redundancy; it front-loads the core purpose immediately.

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

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

For a simple two-parameter read-only tool with no output schema, the description gives a complete picture of expectations, behaviors, and boundaries. It tells the agent exactly what each action returns and what the tool will not do, which is sufficient for safe invocation.

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

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

Although the schema already describes both parameters well, the description enriches the token parameter by explaining when an existing Bearer web session is acceptable and that the user should not be asked for an sk_ token in that case. It also reinforces action semantics with concrete payout data 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 says 'View your payout status' and then defines the two supported actions (settings and history) with specific data returned. This distinguishes the tool from siblings like account, subscriptions, and reporting by tying it to payout-specific information.

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

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

The description provides explicit guidance on when to use the tool and when not to: payout method changes and tax forms should be handled on the secure web dashboard. It also gives important auth behavior guidance, telling the agent not to ask the user for an sk_ token when a working web session already exists.

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 show destructiveHint=true, but the description adds important behavioral context: the tool is part of a multi-step process that ends with calling apply again. It does not describe error handling or failure modes, but the core mutation and required follow-up are well communicated.

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

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

The description is only three sentences, front-loaded with the main purpose, and every sentence earns its place by adding critical workflow information. No extraneous text.

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 three parameters and no output schema, the description covers the entire intended usage lifecycle, references the sibling tool 'apply', and provides enough context for an agent to correctly invoke the tool in sequence. Nothing essential is missing.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds semantic value by explaining the conditional workflow (when to use action=start vs. action=verify, and how method relates to the verification step), which goes 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 opens with a specific verb and resource: 'Free up a site that has an inactive previous registration.' It clearly distinguishes itself from sibling tools like 'apply' by explaining when reclaim is needed ('If apply says the site is already registered').

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

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

The description provides a complete step-by-step workflow: use action=start to get verification options, complete one, then action=verify, then call apply again. It explicitly states the prerequisite context and what action to take, effectively guiding when and how to use the tool.

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

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

Annotations already indicate destructiveHint=true, and the description adds concrete detail: confirm revokes all old tokens, emails a short-lived code, and returns fresh tokens. It also discloses no authentication required and rate limiting per IP/site, 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 compact, with purpose front-loaded in the first sentence and actionable details following. It uses three sentences to convey actions, prerequisites, and limitations without redundant wording.

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

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

Given there is no output schema, the description covers return values (fresh application/API token) and the side effects (revoking old tokens). It also includes rate limits and authentication requirements, making it 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?

Schema coverage is 100% with parameter descriptions, but the description enriches meaning by explaining the workflow: action=start emails a code, action=confirm with code verifies and returns tokens. It also ties site_url to the apply registration, adding context not in the schema.

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

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

The description clearly states the tool recovers account access when tokens are lost, and enumerates the two actions (start/confirm) with their specific purposes. It distinguishes itself from sibling tools like apply by referencing the registration prerequisite. This is a specific verb+resource with clear scope.

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

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

The description gives clear usage context: when application/API tokens are lost, use action=start then action=confirm. It also notes that site_url must have been previously registered with apply, providing a prerequisite. However, it does not explicitly compare with alternative tools like reclaim or state when not to use, so it stops short of full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds valuable behavioral context about accepted authentication methods (API token or Bearer web session) and clarifies that the agent should leverage an existing session. It doesn't describe return formatting, but the read-only, idempotent nature is well covered.

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

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

The description is compact and front-loaded with the core purpose. The authentication caveat and action list are essential and are stated without redundancy. Every clause contributes necessary information for correct invocation.

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

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

The description covers the main invocation details: authentication, action selection, and optional date range. Since there is no output schema, it doesn't explain return values, but the action names are fairly self-explanatory. It is reasonably complete for a read-only reporting tool, though per-action output specifics are not detailed.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds semantic value by explaining that an approved Bearer web session is accepted as an alternative to an sk_ token and by reinforcing the YYYY-MM-DD format for dates. This goes slightly beyond the schema's parameter notes.

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

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

The description clearly identifies the tool as 'Revenue and traffic reporting for your account' and enumerates specific action modes (overview, earnings_history, epmv_trend, etc.), making its purpose concrete. This distinguishes it from sibling tools like payments, account, or subscriptions, which cover different financial/account functions.

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: the tool is for revenue/traffic reporting and should be invoked with an action plus optional date range. It also gives explicit authentication guidance, including not asking for an sk_ token when a working web session exists. It does not explicitly discuss alternatives or exclusions among siblings, but the domain is clear enough.

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

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

Annotations provide no behavioral hints (readOnly/other flags all false), so the description must carry the burden. It discloses authentication behavior (token or Bearer session) and the dynamic action dispatch behavior. However, it does not describe whether actions are destructive or what responses look like, leaving the agent to discover via the 'no action' call. It adds some context but is not fully transparent.

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. The first sentence front-loads the core purpose and authentication guidance; the second explains the resource/action pattern and discovery. Every phrase earns its place – no fluff or repetition. It is concise yet informative.

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 is a generic dispatcher with 4 optional params and no output schema, the description adequately explains the interaction pattern (resource/action) and the discovery mechanism. It does not enumerate possible actions or responses, but that is intentionally deferred via the 'no action' call. For a routing tool with this complexity, the description is complete enough, though it could mention typical resources or examples.

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 all parameters with descriptions (100% coverage), so baseline is 3. The description adds value by explaining the token variable (sk_... or Bearer header) and the action parameter's omit behavior ('call with no action to see what's available'), which enriches the schema's generic description. It also clarifies that 'params' is optional for action-specific arguments, though it doesn't detail those arguments.

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: 'Manage reader subscriptions and donations' – a specific verb (manage) with a clear resource domain. It distinguishes from siblings by focusing on subscriptions/donations, which is distinct from payments, reporting, etc. The additional usage pattern ('Pass resource and action') reinforces the purpose.

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

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

The description provides clear usage context: authentication requirements (API token or Bearer session) and explicitly instructs not to ask for a token when a session exists. It also indicates a discovery mechanism ('call with no action to see what's available'), implying the tool is to be used for subscription/donation actions. It lacks explicit exclusion of alternatives, but the context is strong enough for an agent to decide.

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 signal not read-only/idempotent/destructive; the description adds useful behavior beyond that: accepted auth mechanisms (sk_ token or Bearer web session), a discovery workflow, and specific embed output markup. 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?

Three dense sentences front-loaded with the core purpose. The auth caveat is a long parenthetical, but every clause contributes operational value. Slightly verbose in spots, but there is no 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?

It covers auth, the resource/action pattern, discovery, and embed output markup. However, there is no output schema and the description does not enumerate all resources/actions or describe response shapes generally. The 'call with no action to see what's available' instruction mitigates this gap but doesn't fully close it.

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

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

The input schema already describes all 4 parameters, so the baseline is 3. The description adds value with concrete examples like 'resource=player action=list', 'resource=embed', and clarifies that omitting action triggers discovery. The nested params object remains loose, but schema plus description are adequate.

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 'Manage video monetization' and then gives concrete usage patterns ('resource=player action=list', 'resource=embed'), making the tool's scope clear. It doesn't explicitly contrast with sibling monetization tools like payments or ad_settings, but the focus on video and embed markup provides enough differentiation.

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 instructions: 'Pass resource and action', 'call with no action to see what's available', and 'Use resource=embed to get the content-player unit markup'. It also provides a clear when-not: don't ask for an sk_ token when a working web session exists. No sibling alternatives are named, so it stops 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.