Agents by MyInfluence AI

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

Annotations already provide idempotentHint=true and destructiveHint=false, and the description reinforces those with 'Idempotent' and 'Safe to retry.' It adds valuable context beyond annotations by revealing the Stripe webhook automation and the prerequisite condition ('payment completed but brand inactive'), giving the agent a clearer mental model of the tool's role.

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 short sentences. The first sentence front-loads the most important behavioral fact (idempotent), the second states the condition and retry safety. There is no redundant filler or repetition of schema 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?

For a single-parameter action with no output schema, this description provides sufficient context: what triggers it, when to call manually, and that retries are safe. It could mention the result of activation (e.g., brand becomes active) but that is reasonably implied by the name and trigger condition.

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

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

The schema already documents the single parameter 'brand' as a 'Brand slug' with 100% coverage. The description does not add any additional parameter semantics, which is acceptable since the schema is fully self-explanatory for this simple case.

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 title and description clearly define the action: activating a brand. The phrase 'call it only if payment completed but the brand is still inactive' distinguishes this from sibling tools like brand_create or brand_get by specifying the exact state transition. No ambiguity about what resource is affected.

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 conditions for use: only when payment has completed but the brand remains inactive. It also states the tool is normally fired automatically by the Stripe webhook, which tells the agent this is an exceptional manual call. The retry safety note provides additional guidance without needing inference.

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 behaviors beyond the annotations: all downstream work is deferred until payment (so no side effects beyond record creation), the call is cheap and reversible, and accepted_terms records a reseller assertion against the agent id. Annotations only mark non-read-only/non-idempotent/non-destructive, so this is valuable, non-contradictory 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?

Three sentences: purpose, deferred behavior, and required term + next step. No filler; the critical operational detail is front-loaded.

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

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

For a create tool with no output schema, the description covers preconditions, side-effect timing, and the follow-up call. It doesn't specify what the response contains or how to obtain the created brand id, but that is a minor gap given the deferred workflow and sibling tooling.

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?

Adds important semantics for accepted_terms (reseller assertion recorded against agent id) and situates plan as the input consumed by checkout_create, going beyond the schema's one-liners. With 63% schema coverage, the description partially compensates for tone/niche/website, which remain unexplained in both places, so this is good but not complete.

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 'Create a brand owned by this agent' — a specific verb and resource, and the ownership qualifier distinguishes creation from brand_activate/brand_get/brand_list. Sibling tools like checkout_create are clearly later steps, so an agent can identify this as the creation entry point.

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 frames the workflow: the call is cheap/reversible because work is deferred until payment, and instructs 'Follow with checkout_create.' It does not enumerate alternative tools or exclusion conditions, so it isn't a full when-not-to-use statement, but the payment deferral and next-step pointer give clear usage context.

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

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

Annotations already establish that the operation is read-only, idempotent, and non-destructive, so the description's safety burden is low. It adds some value by listing the profile fields returned, but does not disclose behaviors such as response shape or error conditions beyond what annotations already 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 a single, well-structured sentence that front-loads the core purpose and then lists the specific fields in a readable, comma-separated sequence. Every word adds useful information with no redundancy.

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

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

For a single-parameter read-only getter with no output schema, the description compensates by enumerating the key fields the profile contains. It is nearly complete, though it could slightly improve by clarifying how the response relates to brand_list or what a missing brand slug would yield.

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 only parameter is documented as 'Brand slug', so the description adds little beyond the schema. The phrase 'for one brand' reinforces that the parameter identifies a single brand, but no format or usage details are 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 uses a specific verb-resource phrasing, 'Full profile for one brand', and enumerates exactly which profile components are included. It clearly distinguishes brand_get from brand_list by emphasizing 'one brand' vs. a broader 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?

The description implies the tool is used when you need a complete profile for a single brand, but it does not explicitly state when to avoid it or name alternatives like brand_list or brand_activate. Usage context is present but left to inference.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful context about key-scoped visibility and the enriched fields (plan and subscription status), which goes 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 13-word sentence that front-loads the core behavior and then specifies the included fields. 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 zero-parameter, read-only list tool with annotations covering safety, the description fully explains what the agent will get: all reachable brands with plan and subscription status. No additional call-specific details are needed.

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

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

The input schema is empty, so there are no parameters for the description to clarify; the baseline of 4 applies because nothing is left undocumented.

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 names the resource (brands) and defines scope as 'every brand this key can reach,' also noting that plan and subscription status are included. It is clearly distinct from brand_get, which targets a single brand, though it does not use an explicit verb like 'lists.'

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

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

The description implies the tool is for enumerating all brands accessible to the current key, but it gives no explicit when-to-use guidance or comparisons to siblings such as brand_get or plan_list.

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

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

With only minimal annotations (readOnlyHint=false, etc.), the description adds important behavioral context: payment triggers webhook activation of the brand automatically, and the billing is passthrough. This goes beyond what annotations provide and clarifies side effects.

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

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

Two concise sentences with the main purpose front-loaded. No fluff; every phrase adds value.

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

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

Given four parameters and no output schema, the description omits return format details and the role of cancel_url/success_url. The activation-on-payment side effect is noted, but the description is not complete enough for a new agent to call it correctly without schema guesswork.

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

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

Schema description coverage is only 50%, but the description does not compensate. It only mentions 'for a brand' and does not explain the purpose of plan, cancel_url, or success_url, leaving the agent uncertain about how to populate these 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 returns a Stripe Checkout URL for a brand, with a specific verb and resource. It distinguishes itself from siblings like brand_activate by explaining the passthrough payment flow, but it doesn't explicitly name alternatives.

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 context that the URL is for passthrough billing and the brand pays directly, implying when to use it. However, it lacks explicit guidance on when not to use it or how it compares to tools like brand_activate or subscription_status.

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

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

Annotations only say readOnly=false, idempotent=false, destructive=false, which is minimal. The description carries the full burden and does it well: it discloses that the signing secret is returned only once, that telegram_enabled defaults to false, that both channels fire when enabled, that auto_approve is a kill switch, and that rotate_secret breaks existing verification. This is rich behavioral disclosure beyond the schema.

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

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

The description is dense but well-structured: the first sentence states the core purpose, then the secret warning, then the default behavior. It is longer than average, but every sentence adds non-obvious information that is not in the schema. Slight deduction for density; the mode explanation could be more compact, but it is not bloated.

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 9-parameter configuration tool with no output schema, the description covers the critical behavioral traps: one-time secret, default off for Telegram, read-only publish_through, kill-switch auto_approve, and rotate_secret side effects. It also references the sibling tools needed for the publish_through flow. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context on top: it explains the default for telegram_enabled, the one-time secret return tied to rotate_secret, the read-only nature of publish_through, and the kill-switch semantics of auto_approve. It doesn't add syntax details for every parameter, but it clarifies the most behaviorally important ones.

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 ('Set or update where and how this brand's daily content package is delivered'), which clearly distinguishes it from siblings like delivery_replay and delivery_test. It also names related sibling tools (social_connect_link, social_accounts_list) and explains the mode distinction, so an agent can tell this is the configuration tool, not an action tool.

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

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

The description gives explicit when-to-use guidance: it explains the default webhook-only behavior, when Telegram is enabled, when publish_through is available (only brand owner can grant it), and points to social_connect_link and social_accounts_list for the flow. It also warns about rotate_secret breaking verification. This is strong routing and usage context.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false, so the bar for added behavioral context is lower. The description adds value beyond those annotations by explaining the mechanism: it keeps the original idempotency key, causing the client's deduplication to drop the message if the first attempt already arrived. This gives the agent a concrete behavioral consequence not contained in 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 two tight sentences with no filler. The primary action is front-loaded ('Re-queue a past delivery'), and the second sentence delivers the crucial idempotency caveat clearly and memorably.

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 tool with no output schema and annotations covering idempotence and destructiveness, this description is largely complete. It explains the key behavioral nuance an agent needs: duplicate deliveries will be dropped if the original idempotency key was already seen. It does not explicitly state what happens when the first attempt did not arrive, but that is reasonably implied and not a critical gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add meaningful parameter-level detail beyond the schema; it refers to 'a past delivery' but does not, for example, clarify that delivery_id comes from package_list, which the schema already states. Thus the description neither improves nor harms 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 opens with a specific verb and resource: 'Re-queue a past delivery.' It is clear that this tool replays a previously sent delivery rather than creating or testing one. However, it does not explicitly distinguish itself from siblings like delivery_test or delivery_configure, so it stops short of full sibling 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?

The description implies when to use the tool: for a past delivery that needs to be re-queued, with the caveat that original idempotency is preserved. It gives useful context about deduplication behavior but does not explicitly state when not to use it or name alternative tools such as delivery_test or delivery_configure.

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 all false, so the description carries the behavioral disclosure burden. It states that the tool queues a signed sample payload (a mutation) and explains the HMAC verification format, including header, timestamp tolerance, and signing method. This goes beyond a simple 'sends a test' and gives the agent actionable verification details, though it doesn't mention side effects like idempotency or whether it affects configuration.

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, no filler. The first sentence states the primary purpose and timing, the second gives the exact signature verification method. Information is front-loaded and every word earns its place.

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

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

The description covers the tool's action, purpose, and verification details. It implies a pre-existing webhook configuration but doesn't explicitly state a dependency on delivery_configure, which is a minor gap. There is no output schema, but for a test tool that returns nothing meaningful beyond a queued payload, the description is sufficient.

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

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

The input schema has one parameter 'brand' with a clear description ('Brand slug.'), so schema coverage is 100%. The description does not mention the brand parameter, but the schema already explains it. Baseline for full schema coverage is 3, and no additional meaning is needed for this simple parameter.

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: queue a signed sample payload to the configured webhook to verify HMAC verification. It specifies the action (queue), the resource (configured webhook), and the outcome (verify before real content). It also differentiates from sibling tools like delivery_replay and delivery_configure by focusing on testing the signature.

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

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

The description implies when to use this tool: 'before real content depends on it', indicating it's for pre-production testing. It also provides specific verification steps, which guides the agent on how to interpret the result. It does not explicitly name alternatives, but the context makes it clear this is for initial webhook verification rather than replaying or configuring.

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, covering safety. The description adds the behavioral trait that a job id from another tenant is 'simply not found', which is valuable context beyond the annotations. This informs the agent of an edge case without contradicting anything.

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 with no fluff: the first states the core purpose and the second adds a scoping detail. The most important information is front-loaded, and every word contributes. This is an example of effective brevity.

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 fully describe the return format beyond 'Status'. For a simple get operation, this is mostly sufficient, but ambiguous aspects like error handling (e.g., what happens when a job doesn't exist) are only partially covered by 'simply not found'. However, given the tool's simplicity and the annotations providing safety context, the description is adequately complete for an agent to call it correctly.

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

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

Schema description coverage is 100% as both 'brand' and 'job_id' have descriptions ('Brand slug.' and 'Job id returned by a mutating tool.'). The description reinforces the brand scope but adds no new syntactic or semantic detail beyond the schema. Baseline 3 applies because the schema carries the parameter meaning.

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 ('Status of one queued job by id') and the resource ('job'), with a specific scope ('Scoped to the brand'). It is distinguishable from all sibling tools, none of which are job-related, and the phrase 'Status of one queued job' is specific enough for an agent to understand exactly what it retrieves.

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

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

The description implies when to use it (to get a job's status by id) but does not explicitly state alternatives or when not to use it. It mentions the brand scoping, which helps with parameter choice, but lacks any comparison to other tools like pipeline_status or package_get. The context is clear but no exclusions or alternative routing 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 readOnly/idempotent/non-destructive. The description adds useful behavioral context: pull/push consistency and support for pre-delivery content, which is not visible 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?

Three sentences, front-loaded with the core purpose, then two high-value behavioral guarantees. 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?

With no output schema, the description lists the main return contents and two important guarantees. It stops short of specifying not-found/undelivered behavior, but for a simple two-param read this is near 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 covers both brand and request_id with descriptions (100% coverage), so the description adds little beyond identifying request_id as the selector. Baseline 3 applies.

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

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

The description names the exact resource (full content package for one request_id) and enumerates contents (media URLs, captions, music credit). It differentiates from package_list by specifying singular request_id 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?

No explicit alternative or exclusion is given. The use case is implied by 'full content package for one request_id' and the schema's request_id origin, but there is no guidance on when to prefer this over package_list or how it relates to delivery 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 readOnly/idempotent/non-destructive, so the description only adds ordering and a catch-up framing. It does not describe pagination or response shape, but for a read-only list that is acceptable.

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

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

Two sentences, front-loaded with the core purpose, and the catch-up instruction is compact. 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?

For a read-only listing tool with strong annotations and 80% schema coverage, it gives purpose, ordering, and a key use case. It could mention pagination/next_cursor explicitly, but the schema's cursor parameter already hints at 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?

Schema covers 80% of parameters with descriptions, so baseline is 3; the description adds meaningful guidance by pointing to the 'failed'/'dead' status values for catch-up. It does not add to brand/since/cursor, but schema already covers those.

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 a specific resource ('delivery attempts for a brand') and ordering ('newest first'), and adds an outage catch-up use case. It does not explicitly name siblings like delivery_replay, and 'replay what you missed' blurs whether this tool also replays.

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 to use it after an outage and to filter by status 'failed' or 'dead'. It does not name alternative tools or state when not to use, but the context is clear enough for an agent to choose it for catch-up listing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds value by specifying the exact content returned (queued jobs, counts, unused hooks, recent items), which is beyond what annotations provide. No contradictions.

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

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

A single, dense sentence that front-loads the purpose ('Live production state') and lists all return components without any redundant phrasing. 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 1-parameter read-only tool, the description covers the essential output (jobs, counts, hooks, recent items) sufficiently. It lacks explicit response structure details, but given the simplicity and that annotations cover safety, nothing critical 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%—the only parameter 'brand' is fully described as 'Brand slug.' The tool description does not add extra meaning to the parameter, so the baseline of 3 applies.

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

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

The description clearly states this is a live production status tool for a brand, listing specific data points (queued/recent jobs, video counts, unused hooks, recent items). It distinguishes itself from sibling tools like job_get or package_list by focusing on brand-level aggregated state.

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

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

The phrase 'Live production state for a brand' provides clear context for when to use this tool—when an overview of a brand's pipeline is needed. It does not explicitly mention alternatives or exclusions, but the brand-scoped nature is evident from the description.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no contradiction. The description adds context beyond annotations by explaining that the numbers represent daily deliverable volumes and that they determine webhook package counts. This is valuable behavioral context that helps the agent understand what the data means and how it's used.

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, one sentence with a dash to add detail. It front-loads the purpose (listing plans) and explains the key fields. Could be slightly more structured but it's efficient and to the point. 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 zero-parameter read-only tool with no output schema, the description explains what data will be returned and provides context on how it's used (decides webhook package counts). There's no missing information that an agent needs to decide whether to call this tool. The description fully covers the tool's purpose and the meaning of its output fields.

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

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

There are no parameters, so the schema provides no parameter descriptions (100% coverage of an empty schema). The description explains the meaning of the fields that will be returned (price, videos_per_day, etc.), which is essential because the agent can't know what the output contains otherwise. This fully compensates for the lack of a schema description.

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

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

The description clearly states it lists subscription plans with price and daily deliverable volumes (videos_per_day, carousels_per_day, posts_per_day). It tells the agent these numbers determine how many packages a webhook will receive, which is useful. However, it doesn't explicitly distinguish itself from other list tools (e.g., package_list, brand_list) by noting it's about plans, though the name and content imply that.

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 doesn't explicitly state when to use this vs alternatives. It mentions the data is relevant to webhook package counts, but doesn't say 'use this when you need plan pricing/limits' or contrast with package_list. The context is implied by the content but no exclusions are given. Could be improved by noting that this gives the plan-level quotas, not actual 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'read once' guidance and implies the data is stable enum-like values, but it does not disclose further runtime behavior such as whether the response can change after integration or whether authentication is required. Given the strong annotation coverage, a 3 is appropriate.

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

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

A single information-dense sentence followed by one clear usage directive. The list of returned categories is front-loaded, and every phrase earns its place; there is no filler, repetition, or unnecessary detail.

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

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

For a parameterless, read-only metadata endpoint, the description covers what data will be returned and when to call it. It does not provide an exact response shape or field names, but the absence of an output schema and the 'enums' framing make the category list sufficient for integration purposes.

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 an empty input schema, so there is no parameter semantics to document. Per the baseline for parameterless tools, the description correctly focuses on what the response contains rather than input handling.

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 a platform metadata/capabilities endpoint by listing the exact categories of data it returns: content formats, content pillars, caption platforms, video statuses, and available scopes. It is more informative than the title and distinguishes itself from the entity-specific sibling tools, though it stops short of an explicit retrieval verb like 'returns' or 'gets'.

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

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

It explicitly says when to call the tool: 'Read this once at integration time instead of hardcoding enums.' This conveys both timing and rationale, and the 'instead of hardcoding' phrase gives clear intent. It doesn't discuss when not to use it, but no sibling tool appears to overlap with a global capabilities endpoint.

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 cover read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond that: account IDs are never returned and the meaning of publish_mode values is disclosed. This is useful for an agent managing expectations about the output, though it does not detail every possible field or edge case.

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, front-loaded with the core purpose, and each sentence adds necessary information: the accounts and publish mode, the meaning of publish_mode values, and the deliberate omission of account IDs. 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?

Given the simple one-parameter read-only tool with no output schema, the description sufficiently covers what the agent needs to know: what is returned, what the publish_mode values mean, and what is intentionally absent from results. No critical usage or return-value information 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 fully documents the single required parameter 'brand' as a brand slug, so schema coverage is 100%. The description adds no additional parameter-level detail beyond what the schema already states, so the baseline of 3 applies.

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

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

The description clearly states the tool lists connected social accounts and whether the brand publishes to them, which is a specific verb-resource scope. It also explicitly distinguishes the tool's purpose from identity lookup by stating 'Account IDs are never returned — this answers "did my user finish connecting", not "who are they"', making sibling differentiation strong.

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

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

The description gives clear context for when to use the tool: to determine whether a user finished connecting accounts and how publishing is configured. It explicitly excludes identity use cases ('not who are they'), though it does not name a specific alternative sibling tool or provide an explicit when-not-to-use list, so it misses the top score.

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 provide booleans (not read-only, not idempotent, not destructive). The description adds significant behavioral context: the URL is one-time, the system never sees passwords, the owner must authorize, and connecting at least one account triggers a publishing offer. This goes well beyond the annotations, though it doesn't mention error handling or expiration edge cases.

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

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

The description is a single dense paragraph where every sentence earns its place: it opens with the core purpose, then explains the user flow, the security guarantee, the ownership restriction, and the next step. 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?

Given there is no output schema, the description implies the return value is a URL ('Mint a one-time URL') and points to social_accounts_list for status. It covers the full user journey and security model. It doesn't specify the exact response format or failure scenarios, but these are not essential for the 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?

Schema coverage is 100% – both 'brand' and 'ttl_minutes' have clear descriptions ('Brand slug.' and 'How long the link stays valid. Default 60, maximum 7 days.'). The description adds no parameter-specific detail beyond what the schema provides, so the baseline 3 applies.

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

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

The description states a specific verb ('Mint'), resource ('one-time URL'), and purpose ('connect social accounts'), listing target platforms. It distinguishes itself from sibling social_accounts_list by explicitly pointing to it as the result-checking tool, so an agent can tell them apart without ambiguity.

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

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

The description clearly explains the workflow: the URL must be handed to the user, who authorizes on their own; the agent cannot do this step. It also instructs to 'Watch for the result with social_accounts_list,' providing a follow-up. However, it does not explicitly name alternative tools like telegram_link_create or state when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful domain context about delivery stopping after cancellation, which helps the agent interpret the status meaning, but it does not disclose return format or error behavior.

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

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

The description is two concise sentences with no filler. The first sentence front-loads the returned fields and the second provides a practical warning, though the first sentence is a noun phrase rather than a clear verb-led statement.

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 low-complexity tool with one documented parameter, no output schema, and safety annotations, the description adequately covers what data is returned and when to use it. It does not mention error cases or status value meanings, but these are not essential for basic invocation.

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

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

Schema coverage is 100% and the only parameter, 'brand', is already described as a 'Brand slug.' The description's phrase 'for a brand' adds no new semantic detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly identifies the resource (brand subscription) and the data returned (plan, status, renewal date, add-ons), though it lacks an explicit verb like 'retrieves' or 'gets.' It is distinct from sibling tools like brand_get or plan_list because it focuses on subscription-specific fields.

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 a concrete use case: check this before assuming packages will keep arriving, since delivery stops when a subscription is cancelled. It does not name alternatives or explicit when-not-to-use conditions, but the guidance is actionable and clear.

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

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

The description discloses single-use, expiry, and chat binding, and notes that opening the link grants the full review experience; these are meaningful behaviors beyond the annotations. It does not describe the response payload, but for a low-risk link-creation tool this is not a major omission.

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 sentences, all relevant: the purpose is front-loaded, the user experience is summarized, the delivery_configure pairing is stated, and the expiry behavior is closed with an action. No filler or repetition.

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

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

For two parameters with 100% schema coverage and no output schema, the description explains the workflow, the single-use/expiry behavior, and the integration point with delivery_configure. The only minor gap is not explicitly stating the return value, but this is implied by 'mint a link' and 'hand the link.'

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

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

The schema already documents both parameters with descriptions and bounds (brand slug, ttl_minutes default/max/min), so the description does not need to repeat them. It adds only general advice about expiry and minting another link, which reinforces rather than extends the parameter documentation.

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 'Mint a single-use link that connects a human's Telegram chat to this brand, so they can review and approve content in chat,' which uses a specific verb and resource and clearly distinguishes it from siblings like social_connect_link and delivery_configure. It precisely states the purpose and the review/approval workflow.

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

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

The description explicitly tells the agent to pair this with delivery_configure approval_mode 'gate' to require approval before content is delivered, and notes when to mint a replacement if the link goes unused. It does not explicitly list exclusions or alternative tools, but the pairing condition provides clear contextual 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, idempotentHint, and destructiveHint. The description adds value beyond those by explaining that results are cached and re-analysis is free, and by clarifying it reads only a public website. This is useful behavioral context not present in the annotations.

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

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

Three sentences with no filler. The core action and outputs are front-loaded, the workflow connection to brand_create is one sentence, and the caching behavior is stated economically. 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?

For a single-parameter read-only tool with rich annotations, the description covers what the tool does, what it returns, where it fits in onboarding, and the caching side effect. Since there is no output schema, the explicit list of returned fields is especially valuable and sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents the website parameter as a 'Public https:// URL of the brand's site.' The description adds no new parameter-level detail beyond restating 'public website,' 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 uses a specific verb ('Read') and names both the resource ('a public website') and the concrete outputs ('suggested brand settings ... plus scraped brand colours'). It also positions this tool relative to brand_create, so an agent can distinguish analyze from create without opening the sibling 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 gives explicit workflow context: 'Step one of onboarding' and directs the agent to feed the result into brand_create. It does not name alternatives or give when-not-to-use guidance, but for this tool the step-one positioning is a clear and sufficient usage signal.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing exactly what kind of information is returned (principal, scopes, rate limit, brands), which is meaningful behavioral context beyond the annotations. It doesn't cover error behavior or response format, but for a non-destructive identity lookup this is sufficient.

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

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

Two concise sentences with no filler. The first sentence front-loads the core purpose and return fields; the second provides the practical usage trigger. 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 zero-parameter, read-only introspection tool with strong annotations, the description fully covers what the agent needs: what the tool returns, when to call it, and why it is safe. No output schema exists, but the description's enumeration of returned fields is sufficient for the agent to decide and invoke the tool successfully.

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 description coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 applies here; the description appropriately focuses on the tool's behavior and context rather than inventing parameter details.

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

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

The description states a specific verb and resource: 'Identify the calling key' followed by the exact data returned (principal, scopes, rate limit, brands it can reach). This clearly distinguishes it from the sibling tools, which are all action-oriented (create, get, list, configure) rather than identity introspection.

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 the agent when to invoke this tool: 'Call this first when debugging a permission problem.' It also explains why (it answers 'what am I allowed to do' without guessing), giving clear situational guidance and a natural first-step role among the sibling tools.

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