I manage your Nova products, create/update/delete, payment & logistics config, icons, webhook secre…
Scored across 34 tools
Most tools target a distinct resource+action pair, and descriptions clarify the boundaries between similar verbs (e.g. approve_deposit runs fulfillment vs resend_deposit_fulfillment retries it, assign_bank_credit vs dismiss_bank_credit). The set of set_*_config tools (payment/logistics/mobile_push) is close but each targets a different config blob. Minor overlap remains between deposit and bank-credit reconciliation flows.
Every tool follows a predictable verb_noun snake_case pattern (list_products, set_payment_config, rotate_webhook_secret, approve_deposit). No camelCase or stylistic mixing. The convention holds across all 34 tools including domain-specific ones.
34 tools far exceeds the well-scoped 3-15 range; the surface spans product CRUD, deposits, bank reconciliation, onboarding, webhook secrets, privacy policy, audience resolver, Twitter, and multiple config setters. While it's a broad admin server, the count is heavy and would benefit from consolidation or grouping.
Product CRUD, deposit lifecycle, bank credit reconciliation, and config setters cover the core admin domain well with no obvious dead ends. Minor gaps exist: twitter accounts are list-only (no connect/disconnect), audience resolver has connect but no disconnect, and account deletions are list/complete only.
Approve a pending/expired deposit and run fulfillment.
| Name | Required | Description | Default |
|---|---|---|---|
| deposit_id | Yes | ||
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that fulfillment runs as a side effect, but says nothing about irreversibility, permissions, failure modes, or what 'expired' approval implies.
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 tight sentence with the action and its consequence front-loaded and no wasted words. Brevity here is appropriate for a simple two-identifier operation.
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 mutation tool with no output schema, the description covers the state precondition and side effect but leaves both parameters and any permission/irreversibility details unexplained, so it is only minimally 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 description coverage is 0% and the description never mentions product_id or deposit_id, so it adds no meaning beyond the bare parameter names. Two required identifiers are left for the agent to interpret unaided.
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 verb 'approve' with the resource 'deposit' and adds the fulfillment side effect. It is easily distinguished from the obvious sibling reject_deposit, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'pending/expired deposit' implies a precondition that guides when the tool applies, but no explicit when-to-use guidance or named alternative (e.g., reject_deposit, resend_deposit_fulfillment) is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assign an unmatched bank credit to a pending deposit.
| Name | Required | Description | Default |
|---|---|---|---|
| credit_id | Yes | ||
| deposit_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the credit must be unmatched and the deposit pending, but says nothing about side effects, permissions required, reversibility, or what happens to either object after assignment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words, and the action and target are clear from the first read.
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 mutation tool with no annotations, no output schema, and two undocumented parameters, the description is too thin. It omits error conditions, return behavior, and the state transition that occurs after assignment.
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 0%, and the description adds no meaning beyond the schema's parameter names. An agent can infer that credit_id maps to the bank credit and deposit_id to the deposit, but no format, constraints, or ID semantics are explained.
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 ('Assign') and resource ('unmatched bank credit') with a target ('pending deposit'), so the operation is immediately clear. It does not, however, explicitly distinguish this action from the sibling dismiss_bank_credit, which is the natural opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as dismiss_bank_credit, nor any stated prerequisites or state requirements. The words 'unmatched' and 'pending' imply context but do not constitute actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark one account-deletion request erased, once the storefront record is gone.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| reference | Yes | ||
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It implies a mutation/status change and a dependency, but does not state permissions, reversibility, side effects, or what happens if the precondition is unmet.
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 sentence efficiently front-loads the action and precondition with no wasted words. It could benefit from a bit more operational detail without becoming 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 mutation tool with no annotations and no output schema, the description is too sparse. It omits parameter meanings, permission requirements, and error behavior that an agent would need 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 coverage is 0% and the description gives no mapping for product_id, reference, or note. It does not explain which parameter identifies the deletion request or what the note is used for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (mark an account-deletion request erased) and a precondition (storefront record gone). It distinguishes the operation from list_account_deletions, though it does not explicitly name sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage condition: invoke this tool once the storefront record is gone. It lacks explicit alternatives or when-not guidance, but the precondition is enough to select it over listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect an Audience Resolver publisher token to this product, so it can push content to an AR project's calendar. The token must be minted by hand from the Audience Resolver dashboard first — there's no way to generate one here.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | ||
| publisher_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that this is a linking/mutation operation and that the credential must come from an external dashboard, which is useful. It does not address reversibility, whether an existing connection is overwritten, permission requirements, or failure modes.
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 tight sentences, front-loaded with the action and followed immediately by the prerequisite. No filler and every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation with no annotations and no output schema, the description covers purpose and credential sourcing, which is the most important gap. It leaves open what happens on an invalid token, whether an existing link is replaced, and what the call returns.
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 0%, so the description must compensate. It explains what publisher_token is and where it comes from (the AR dashboard), which is real added meaning, but product_id is never described and no format or identifier conventions are given for either 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?
States a specific verb and resource — connecting an Audience Resolver publisher token to this product — and adds the outcome it enables (pushing content to an AR project's calendar). It is clearly distinguishable from sibling read tools like list_audience_resolver_projects, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a concrete precondition: the token must be hand-minted from the Audience Resolver dashboard first, with no generation available here. That is genuinely actionable guidance, but it does not say when to call this versus related tools or what state the product must already be in.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new product.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Lowercase product id (letters, digits, hyphen, underscore). | |
| name | Yes | ||
| site_url | Yes | ||
| mobile_push | No | ||
| pipeline_type | No | ||
| payment_config | No | ||
| content_enabled | No | Enable/disable the content pipeline for this product. | |
| default_country | No | ||
| logistics_config | No | ||
| opportunity_rules | No | What counts as a worthwhile trend/opportunity for this product — used when picking seeds and expanding opportunities. | |
| seed_picker_rules | No | Guidance for the seed-selection step specifically. | |
| opportunity_system | No | System context for generation prompts: what this product is, in the product's own voice. | |
| article_intent_rules | No | Structure/intent guidance for generated articles. | |
| publish_destinations | No | Where generated content publishes to. Each entry is one of {type: 'webhook', webhook_url, webhook_secret?}, {type: 'x_post', twitter_account_id}, or {type: 'ar_calendar', audience_resolver_project_id, audience_resolver_calendar_id} (requires audience_resolver_publisher_token to be connected first). | |
| content_target_markets | No | ISO-2 country codes this product's autonomous trend tweets should draw trends from (e.g. ['NG'] for a Nigeria-only product, ['NG','US'] to target more than one market). Empty/unset falls back to [default_country]. Without this, trend-driven tweets pull from a US-only trend pool regardless of the product's actual audience. | |
| content_posting_frequency | No | When this product's connected X account posts autonomous trend tweets. Either the legacy string preset ('daily' | '3x_week' | 'weekly' | 'off', defaults to 3x_week = Mon/Wed/Fri) or the object {days: ['mon','wed','fri'], time: '09:00' (Africa/Lagos, 24h), posts_per_day: 1-5}. | |
| intent_creative_direction | No | Free-form style/voice guidance for generated content. | |
| audience_resolver_publisher_token | No | Publisher JWT minted from the Audience Resolver dashboard, connecting this product to an AR account so content can be pushed to its calendars. Set via connect_audience_resolver, not directly. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it discloses nothing beyond the bare purpose sentence. It says nothing about side effects, required permissions, generated content pipelines, publishing destinations, or defaults for the many optional config fields — all of which are material for an 18-parameter mutation.
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 short sentence is technically concise, but here the brevity reflects under-specification rather than efficiency — the sentence only restates the tool name and earns no additional place in the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter mutation tool with nested objects, an enum, no annotations, and no output schema, the description is completely inadequate. An agent receives no information about required inputs, side effects, or defaults needed 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 coverage is only 61%, and the description supplies no parameter meaning at all. Notably, the required fields 'name' and 'site_url' have no descriptions anywhere, and the description does not mention required fields, the id format requirement, or the mutually exclusive publish destination shapes.
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?
"Create a new product" states a verb and a resource, so the basic intent is decipherable, but it adds nothing beyond what the tool name create_product already conveys. It does not distinguish this tool from siblings like update_product, delete_product, or get_product in any substantive way.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when to use this tool versus update_product, get_product, or list_products, nor any prerequisites such as which fields are mandatory. The agent is left to infer the entire usage context from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a product.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Permanently' usefully signals irreversibility, but it omits permissions required, whether deletion cascades to related records, and whether the operation fails or is blocked under certain states.
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 short sentence with the key qualifier ('Permanently') front-loaded and no filler. Nothing could be trimmed without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, irreversible operation with no annotations, no output schema, and 0% parameter documentation, this description is far too thin. It should at minimum state permissions, side effects, and failure conditions.
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 0% for the single product_id parameter, and the description adds no format, source, or lookup guidance. The parameter's meaning must be guessed entirely from its name.
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 verb and resource ('delete a product') with the adverb 'Permanently' narrowing the operation. However, it does not distinguish itself from siblings like update_product, get_product, or list_products, nor does it clarify the delete semantics relative to any archival alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as update_product, nor any preconditions (e.g., whether the product must have no active subscriptions or orders). The agent must infer everything about invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dismiss a bank credit as not a sale.
| Name | Required | Description | Default |
|---|---|---|---|
| credit_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It conveys the resulting state ("not a sale") but says nothing about reversibility, required permissions, whether the credit is removed from reporting/reconciliation, or what happens if the credit was already assigned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is efficient, though the extreme brevity for a mutation tool edges toward under-specification rather than disciplined conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations, no output schema, and an undocumented required parameter, the description is too thin. An agent cannot confirm prerequisites, side effects, or the response shape before invoking 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?
There is one required parameter (credit_id) at 0% schema description coverage, and the description never mentions it. It does not state the expected ID format, where the ID comes from (e.g., list_bank_credits), or what happens with an unknown ID, so it adds no meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb ("dismiss") with a specific resource ("bank credit") and clarifies the semantic effect ("as not a sale"), which meaningfully separates it from the sibling assign_bank_credit. It stops short of naming the alternative tool or the state the credit ends up in, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when this tool should be used versus assign_bank_credit, list_bank_credits, or any other sibling. An agent must infer the trigger condition (a credit that is not a sale) entirely from the one-line effect description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bank-transfer onboarding status (merchant bank, alert inbox, auto-approve).
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: it does not confirm this is a read-only operation, whether it has side effects, what authorization it needs, or what happens when the optional product_id is omitted. 'Status' weakly implies a read, but that is inference, not disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the resource front-loaded and the three sub-areas efficiently packed into a parenthetical; no filler. It is borderline under-specified rather than verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description is the only source of information, yet it never describes the return shape (fields, statuses, booleans vs. enum strings) or how product_id affects the result. For a status-retrieval tool whose entire value is the returned payload, that is a significant 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?
The single parameter product_id has 0% schema description coverage and is never mentioned in the description. It is unclear whether product_id scopes the result to one product's onboarding or whether omitting it returns the account-wide status, which is exactly the ambiguity the description should resolve.
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 noun phrase names a specific resource (bank-transfer onboarding status) and enumerates its three facets — merchant bank, alert inbox, auto-approve — so an agent knows what it is looking up. No sibling tool covers onboarding status, so it is implicitly distinguishable, but there is no explicit verb ('retrieve') and no statement that it is read-only.
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 contains no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_product or list_bank_alert_guides. The agent must infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the product's privacy policy and its public URL.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It conveys read-only intent but says nothing about what happens when no policy has been configured (error vs empty), any auth/permission requirements, or whether the returned URL is signed, cached, or publicly accessible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. Its brevity is efficient, though it comes at the cost of the missing scope and failure-mode detail noted above.
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 one-parameter read tool with no output schema, the description covers the essential what but leaves the caller unsure about the parameter's role and the not-configured case. Adequate but with visible gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter product_id has 0% schema description coverage, and the description never mentions it. The agent must infer that the policy is looked up by product ID rather than workspace or account.
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 verb (Read) and resource (privacy policy) plus the extra return element, its public URL. This implicitly separates it from the sibling set_privacy_policy, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this versus set_privacy_policy or how it relates to get_product. Only the verb 'Read' hints that it is the retrieval counterpart to the setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return full product detail including payment/logistics/mobile-push config.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the scope of the response payload (payment, logistics, mobile-push config), which hints at a read-only fetch, but says nothing about missing-product behavior, permissions, or whether the payload is large/costly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. However, 'full product detail' is slightly vague, so the terseness trades away a little precision.
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 and no annotations, the description is the only source of behavioral and return information. It names the main payload sections but leaves the parameter, error cases, and overall response shape unexplained.
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 0% and the sole parameter product_id is undocumented in both schema and description. The description does not indicate where the id comes from (e.g., list_products) or its format, so it fails to compensate for the coverage gap.
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 verb (Return) and resource (full product detail), and enumerates the notable sections returned (payment/logistics/mobile-push config). It is distinguishable from list_products by the singular 'detail' framing, but it never explicitly contrasts with its read siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no mention of alternatives such as list_products for enumerating products. The agent must infer that this fetches one product by id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the product's fulfillment webhook signing secret.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden, yet it discloses nothing about permissions required to read a signing secret, whether the value is returned in plaintext or masked, or what happens if no webhook is configured. The only behavioral hint is that the return value is a secret, which is implied by the resource name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the scope qualifiers (product, fulfillment webhook, signing) all earn their 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?
Low-complexity tool: one required parameter and no output schema, so the description need not explain return formatting. However, for a tool that hands back a credential, the absence of any note on authorization or secret handling leaves a meaningful 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 0% and the single product_id parameter is undocumented. The phrase "the product's" loosely ties product_id to a product identifier, but adds no format, sourcing, or requirement detail to compensate for the schema gap.
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?
Specific verb (Return) plus a precisely scoped resource (the product's fulfillment webhook signing secret). An agent can distinguish this read-style retrieval from the sibling rotate_webhook_secret by the verb alone, though the description never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no preconditions, and no mention of alternatives such as rotate_webhook_secret or get_product. The agent must infer usage entirely from the name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List in-app account-deletion requests for a product's mobile app, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| status | No | ||
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses ordering ('newest first') and scope ('in-app'), but says nothing about permissions, pagination behavior, default status filtering, or what the response contains.
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 efficient sentence with no filler. It is front-loaded with the action and resource, though it is terse enough to leave important gaps.
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 annotations, no output schema, and four parameters at zero schema coverage, the description is insufficient for correct invocation. It does not explain pagination, status filtering, or result 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?
Schema description coverage is 0%, so the description must compensate for four undocumented parameters. It weakly implies product_id via 'a product's mobile app' but gives no meaning for limit, offset, or the pending_erasure/erased status enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'List in-app account-deletion requests for a product's mobile app.' The ordering clause adds useful scope, though it doesn't explicitly name a sibling alternative.
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 no when-to-use guidance, no exclusions, and no direction to alternatives such as complete_account_deletion. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the content calendars within an Audience Resolver project.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | ||
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'List' implies a safe read, but nothing is said about permissions, pagination, result limits, or what a 'content calendar' contains. For a no-annotation tool this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or redundancy. It is arguably under-specified rather than over-long, so it scores well on conciseness specifically.
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 annotations, no output schema, and 0% schema description coverage, the agent is left without ID semantics, prerequisites, or expected return shape. Too little for a two-required-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both required parameters, so the description must compensate and does not. It alludes to a project scope ('within an Audience Resolver project') but never explains what product_id is, how the two IDs relate, or their expected format.
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 verb ('List') and resource ('content calendars') scoped to an Audience Resolver project. It is clearly distinct from sibling list tools like list_audience_resolver_projects, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus list_audience_resolver_projects or connect_audience_resolver, and no stated prerequisites (e.g. that an Audience Resolver connection must exist). Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Audience Resolver projects reachable by this product's connected publisher token.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It partially earns this by disclosing a dependency on the product's connected publisher token, which signals a likely failure/empty-result mode when unconnected. It says nothing about pagination, result limits, ordering, 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?
One sentence with no filler, and the resource is front-loaded before the scoping clause. It is efficient, though the terseness contributes to the parameter and usage gaps rather than resolving them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity (one required param, no output schema, no nesting), and the description conveys the result set's scope. Still, with no annotations, no output schema, and 0% schema description coverage, the description leaves the parameter and the returned/failure behavior entirely unexplained.
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 0% for the single parameter product_id, so the description must compensate but does not. It only alludes to 'this product' without defining what a product_id is, its format, or where it comes from, leaving the sole parameter undocumented in both places.
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 verb and resource ('List the Audience Resolver projects') with a scope qualifier ('reachable by this product's connected publisher token'). This distinguishes it reasonably from the sibling list_audience_resolver_calendars, though it does not name the sibling explicitly or explain the difference in 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 phrase 'reachable by this product's connected publisher token' implies a prerequisite (a connected Audience Resolver token for the given product), which hints at when the tool is usable. However, it never states when to use this versus connect_audience_resolver or list_audience_resolver_calendars, and there are no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported banks and their alert-forwarding setup guides.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden, which it only partially meets. 'List' and 'guides' imply a side-effect-free read of static reference content, and it discloses what comes back (banks plus guides), but it never explicitly says the operation is read-only or idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler. It is appropriately sized for a no-argument reference tool, though it does nothing to add context beyond the bare 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 zero-parameter, no-output-schema reference tool of low complexity, the description covers what the tool returns. It lacks only explicit read-only assurance and any note on whether the guide content is static.
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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies; no parameter meaning is lost.
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 ('List') and a concrete pair of resources ('supported banks and their alert-forwarding setup guides'), which is clearly distinct from sibling list tools like list_bank_credits or list_products. It is precise but never names an adjacent sibling, so an agent gets the what without explicit routing help.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative mentioned. The agent must infer that this is a static reference lookup rather than a data query, and nothing tells it how this relates to save_alert_sources or test_parse_bank_alert.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List unmatched/review bank credits for reconciliation.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It implies a read-only list but says nothing about default filtering, pagination, sort order, or what fields come back, and it never clarifies that the status parameter can also request matched/dismissed records.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is efficient, though its brevity is partly under-specification rather than pure conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no annotations, no output schema, and an undocumented enum parameter, the description should explain the filter values, defaults, and return shape. As written, an agent cannot tell what happens if status is omitted or how results are returned.
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 0% for the single status parameter, so the description must compensate. It names two of the four enum values ('unmatched', 'review') but never identifies them as a status filter, and omits matched/dismissed entirely, leaving the parameter effectively unexplained.
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?
Specific verb ('List') plus resource ('bank credits') with a functional scope ('for reconciliation'), which separates it from the mutating siblings approve_deposit, assign_bank_credit and dismiss_bank_credit. However the 'unmatched/review' qualifier sits awkwardly against the schema's four-value status enum, leaving the exact scope slightly ambiguous.
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 reconciliation framing implies when the tool is relevant, but there is no explicit when-to-use, no mention of how it differs from list_deposits or the other list_* siblings, and no statement of prerequisites or default behavior. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List payment deposits for a product.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| status | No | ||
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It never confirms this is a read-only operation, never mentions pagination via limit/offset (or default page size), ordering, or whether large deposit sets are truncated — significant gaps for a list tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no wasted words — but the brevity is under-specification rather than genuine conciseness, since it omits the parameter and behavior context the agent needs.
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, no annotations, and four undocumented parameters, the description should do much more: expected return shape, default page size, status filtering, and behavior on an unknown product_id. As written it is not sufficient to invoke the tool confidently.
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 0%, so the schema gives no help on any of the four parameters. The description only gestures at product_id via 'for a product' and says nothing about limit, offset, or the status enum (pending/approved/rejected/expired), leaving the agent to guess at filtering and paging semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('payment deposits') and scopes it to a product, so the agent can distinguish it from approve_deposit/reject_deposit (per-item actions) and list_bank_credits (a different resource). It stops short of explicitly naming or contrasting a sibling, so it falls just below the top tier.
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 when-to-use guidance, no mention of prerequisites, and no pointer to siblings such as list_bank_credits or the deposit-mutating tools. The single clause 'for a product' implies a scope but the description never explains when this listing is the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all products for the signed-in owner.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full behavioral burden, and it only adds the owner scoping. It says nothing about pagination, ordering, result volume, auth requirements, or what the returned records contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the scope constraint is included and nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read tool with no output schema, the description is minimally sufficient to call it, but omits pagination behavior and what fields the listed products return, which an agent would want when deciding between list_products and get_product.
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 takes zero parameters, so there are no parameter semantics to document and the schema cannot be missing anything. Baseline 4 applies for a parameterless signature.
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 verb (List) and resource (products) with the scope qualifier 'for the signed-in owner', which is more informative than the bare name. It implicitly distinguishes itself from get_product by listing all rather than fetching one, but never names the sibling to make the distinction explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus get_product, list_deposits, or the other list_* siblings, and no prerequisites or exclusions. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List connected X/Twitter accounts available to use as an x_post publish destination.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose a real behavioral trait beyond the (empty) schema — that only connected accounts usable as a publish destination are returned — but says nothing about auth requirements, whether disconnected accounts appear, ordering, or result shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the resource and the scoping constraint both land 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?
With no output schema and no annotations, the description is the only source of truth, yet it does not indicate what the returned accounts look like (IDs, handles) or how they should be fed into the publishing flow. For a trivial zero-parameter list this is adequate but leaves a real 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?
The tool takes zero parameters, so there is no parameter semantics to document; the baseline of 4 applies. The description correctly implies the call is unfiltered and non-configurable.
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 pairs a specific verb with a specific resource ('List connected X/Twitter accounts') and adds scope ('available to use as an x_post publish destination'). No sibling tool deals with Twitter accounts, so there is nothing to disambiguate against, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrase 'available to use as an x_post publish destination' hints this should be called to pick an account before publishing, but it never states when to call it, what prerequisites exist, or which tool consumes its output. No when-not guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reject a deposit.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| deposit_id | Yes | ||
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden but delivers almost nothing: no statement about irreversibility, required permissions, side effects on the deposit or product, or whether a rejection can be undone. Only the mutating nature of the verb 'reject' is inferable.
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 single sentence is front-loaded but reflects under-specification rather than genuine conciseness. There is no wasted filler because there is almost no content at all.
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?
A state-changing tool with no annotations, no output schema, and no parameter documentation is left critically underspecified. An agent cannot know what rejecting does, what happens on success, or how it relates to the other deposit-lifecycle siblings.
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 0%, so the description must explain the three parameters, yet it adds nothing. The presence and optionality of 'reason' versus the required product_id/deposit_id pair is undocumented anywhere, leaving the parameter semantics entirely unexplained.
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 a specific verb and resource ('Reject a deposit'), which is unambiguous and distinguishable by antonym from the sibling approve_deposit. It does not, however, state scope or consequences (e.g. what rejection entails versus set_deposit_refund_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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as approve_deposit or set_deposit_refund_status even though those siblings overlap in the deposit lifecycle. The agent is left to infer all routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the product's icon/logo.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Remove' implies a destructive mutation, but the description doesn't say whether the operation is idempotent, what happens if no icon exists, whether it requires ownership/permissions, or whether it is reversible.
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 short sentence, front-loaded with the action and target, with no filler. It is efficient but too terse to be genuinely informative, so it doesn't reach a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and an undocumented required parameter, the description should at least state effect and side effects. It states only the bare action, leaving key invocation context 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 0% and the single product_id parameter is an undocumented string. The description mentions 'product's' but adds no format, identifier-type, or constraint detail, so it fails to compensate for the schema gap.
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?
Clear specific verb (Remove) and resource (product's icon/logo), and it is conceptually distinct from the sibling upload_product_icon. However, it never explicitly contrasts itself with that sibling, so differentiation is inferable rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call this versus update_product (which may also clear an icon) or upload_product_icon. No prerequisites, no mention of what state the product must be in. Only the implied 'you have an icon to remove' context exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resend/retry fulfillment for an approved deposit.
| Name | Required | Description | Default |
|---|---|---|---|
| deposit_id | Yes | ||
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not disclose idempotency, whether retries duplicate fulfillment/side effects, required permissions, or failure handling — significant gaps for an action/mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted words. However, it is under-specified rather than genuinely concise — too little content for the tool's operational complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an action tool with no annotations, no output schema, and fully undocumented parameters, the definition is incomplete. An agent lacks the permission, side-effect, and identifier details needed to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Two required parameters at 0% schema description coverage, and the description offers no semantics for deposit_id or product_id. It does not compensate for the schema gap or clarify which identifiers are expected.
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 verb and resource ('Resend/retry fulfillment') plus the qualifying condition ('for an approved deposit'). It is clearly distinguishable from approve_deposit/reject_deposit, though it doesn't name a sibling it might be confused with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an approved deposit' implies a precondition (the deposit must already be approved), but there is no explicit when-to-use vs when-not, no mention of alternatives, and no guidance on repeated retries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rotate the bank-alert forwarding inbox address.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it only restates the action. It does not say whether the previous forwarding address is invalidated, whether mail flow is interrupted, whether this is reversible, what authorization is required, or what the response contains. For an operation that mutates live alert routing, those omissions matter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; efficient. It is short to the point of under-specification rather than verbose, so credit is for structure, not completeness.
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, no-output-schema tool this is minimally adequate: the agent knows what the tool does. But it does not cover the outcome of rotation (e.g., a new address being generated and returned) or the operational consequences, which an agent may need before triggering a change to bank-alert forwarding.
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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool 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 gives a specific verb (rotate) and a specific resource (the bank-alert forwarding inbox address), so the agent knows exactly what changes. It is clear on its own, but it does not distinguish itself from the sibling rotate_webhook_secret or from the surrounding bank-alert tools like save_alert_sources, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to rotate, under what conditions (compromise, rotation policy, config change), or which sibling to use instead. The agent gets no routing guidance at all beyond the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rotate the product's fulfillment webhook signing secret.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it omits the critical consequence of rotation — that the previous signing secret is invalidated and any existing webhook consumers must be reconfigured. It also says nothing about permissions or whether the new secret is returned.
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 tight sentence with the verb and resource front-loaded and no filler. It is efficient, though the extreme brevity edges toward under-specification for a mutating tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive-style mutation with no annotations, no output schema, and an undocumented parameter, the description should explain whether the new secret is returned (essential for a rotation) and what happens to the old one. Neither is covered, leaving an agent without the information needed to call it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One required parameter (product_id) at 0% schema coverage, so the schema contributes nothing. The description only implies that the secret belongs to a product ('the product's ... secret'), which is the bare minimum and does not clarify the identifier format or scope.
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 verb (rotate) and resource (the product's fulfillment webhook signing secret), which is far more precise than a bare 'rotate secret'. It implicitly contrasts with the read-only sibling get_webhook_secret, but never names it or any other alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance: no trigger condition (compromise, scheduled rotation), no prerequisite, and no pointer to get_webhook_secret for retrieving the current secret. It only restates the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the allowlist of bank-alert source email addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| alert_source_emails | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does not say whether 'Save' replaces the entire allowlist or appends to it, whether existing entries are destroyed, what permissions are required, or how the result is confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the purpose and target are stated 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 one-parameter mutation tool with no annotations and no output schema, the description identifies what is saved but omits the replace-vs-merge semantics and permission expectations that an agent needs to call it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does convey that the parameter is the set of bank-alert source email addresses, but adds no format, count, or validation detail beyond the parameter name alert_source_emails.
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 ('Save') and a specific resource ('the allowlist of bank-alert source email addresses'), which is unambiguous. It does not, however, explicitly distinguish itself from nearby siblings such as list_bank_alert_guides or test_parse_bank_alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool, no prerequisites, and no mention of alternatives. An agent must infer that this is the write-side counterpart to the bank-alert listing/testing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the merchant bank account used to receive bank-transfer payments.
| Name | Required | Description | Default |
|---|---|---|---|
| bank_name | Yes | ||
| product_id | No | ||
| account_name | Yes | ||
| account_number | Yes | 10-digit NUBAN account number. | |
| alert_source_emails | No | ||
| auto_approve_enabled | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Save' implies a mutation, but it does not disclose whether this upserts or replaces an existing account, whether prior bank details are overwritten, what auto_approve_enabled does, or what permissions are required. This is a significant gap for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that wastes no words and puts the resource and purpose immediately. Its brevity borders on under-specification, but as a structural matter it is clean.
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 6-parameter mutation tool with no annotations, no output schema, and 83% of parameters undocumented, the description is far too thin. An agent cannot confidently call this tool without guessing at the meaning of product_id and the two optional config parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 17%, so the description is expected to compensate and does not: it explains none of the 6 parameters, including the non-obvious product_id, alert_source_emails, and auto_approve_enabled. Only account_number is described, and that is in the schema, not the 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?
States a specific verb ('Save') and resource ('merchant bank account') plus the business purpose ('receive bank-transfer payments'), which lets an agent distinguish it from siblings like set_payment_config or save_alert_sources. It lacks an explicit naming of a sibling it is not, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus alternatives such as set_payment_config or assign_bank_credit, nor any prerequisite or exclusion. The agent must infer usage entirely from the one-line purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the refund_status on an approved deposit.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| deposit_id | Yes | ||
| product_id | Yes | ||
| refund_status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it only asserts that a field is set. It does not disclose valid status values, whether the change is reversible, what permissions are required, or what happens to an already-set status. For a mutation tool this is a substantial gap.
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 single sentence is front-loaded and free of filler, which is good. But for a four-parameter mutation it is arguably too terse, omitting information the agent needs rather than being efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A write tool with no annotations, no output schema, and zero schema description coverage needs the description to explain valid values, preconditions, and side effects. This one-liner leaves all of that unspecified, so an agent cannot call it reliably.
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 0% across four parameters, so the description must compensate but only hints at refund_status and the deposit. product_id and note are entirely undocumented, and no accepted values for refund_status are given, leaving the agent to guess the payload.
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 verb (set) and resource (refund_status on a deposit), which cleanly distinguishes it from siblings like approve_deposit, reject_deposit, and list_deposits. The qualifier 'approved' also signals the required state of the target. It stops short of 5 only because it never says what refund_status values mean.
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?
'on an approved deposit' implies a precondition and narrows the context to already-approved deposits, so usage is partially implied. However, it never says when to use this versus reject_deposit or resend_deposit_fulfillment, nor what happens if the deposit is not approved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the product's logistics_config.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | ||
| logistics_config | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it discloses nothing beyond the word 'Set'. It does not say whether the config replaces or merges with existing values, what permissions are needed, what validation applies, or what happens on invalid input for a required nested object.
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 sentence is short and front-loaded, but this is under-specification rather than true conciseness. It wastes no words yet omits everything needed to call the tool correctly.
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?
A mutation tool taking a required, undocumented nested object, with no annotations and no output schema, demands far more from the description than one line. Nothing the agent needs to invoke this safely or correctly is present.
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 0% for both parameters, and the nested logistics_config object has no documented shape at all. The description's single mention of 'logistics_config' adds no meaning beyond what the parameter name already conveys, leaving the agent unable to construct a valid value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Set') and resource ('logistics_config') scoped to a product, which is more than a bare tautology and lets the agent separate it from siblings like set_payment_config and set_mobile_push_config. However, 'logistics_config' is never explained, so the agent has no idea what aspect of logistics is being controlled or what the config represents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when this tool should be used versus alternatives, no prerequisites, and no exclusions. The agent is left to infer usage entirely from the tool name and the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the product's mobile_push config.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | ||
| mobile_push | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It implies a mutation of product configuration but says nothing about permissions required, whether the mobile_push object replaces or merges existing config, or what side effects occur. This is a significant gap for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single short sentence with zero filler, which is structurally clean. But the brevity stems from under-specification rather than efficient communication, so it does not earn a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, 0% schema coverage, and a required nested object parameter, the description omits everything the agent needs to invoke it safely and correctly. It is far from 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 description coverage is 0% and the description merely restates the parameter names. Critically, mobile_push is a required nested object whose accepted structure is entirely undocumented in both the schema and the description, leaving the agent unable to construct a valid call.
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 a specific verb (Set) and resource (the product's mobile_push config), which distinguishes it from sibling config setters like set_logistics_config and set_payment_config. However, it does not explain what the mobile_push config governs, so the resource is named but not characterized.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus siblings such as set_payment_config or set_logistics_config, nor any prerequisites (e.g., whether the product must exist or be in a particular state). The agent must infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set/merge the product's payment_config (enable payments, catalog_mode, skus, discount, custom_fields, webhook URLs, return URLs, sandbox).
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | ||
| payment_config | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses merge semantics rather than full replacement, and lists the config scope, but omits permissions, side effects, error behavior, and what happens to unspecified fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with a dense but relevant parenthetical listing the config domains. Every element earns its place and there is no wasted 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?
For a mutation tool with a nested object, no annotations, no output schema, and 0% schema coverage, the description supplies essential config vocabulary but still lacks usage guidance, auth requirements, and deeper merge semantics. It is partially but not fully 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 description coverage is 0%, so the description must compensate. It names likely payment_config keys such as enable payments, catalog_mode, skus, discount, custom_fields, webhook URLs, return URLs, and sandbox, adding meaning beyond the opaque object type. However, product_id is left undescribed and no value types or defaults are given.
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 the specific verb set/merge and resource product's payment_config, and enumerates the config domains. It distinguishes itself from siblings like set_logistics_config and set_mobile_push_config by resource, though it does not 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?
Provides no when-to-use guidance, prerequisites, or alternatives. An agent must infer that this is the correct tool when configuring payments versus update_product or other config setters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish the product's privacy policy, served publicly at /legal/{product_id}/privacy for app store review links. privacy takes entity, contact_email, sections[{heading, body}], and optional intro, effective_date (YYYY-MM-DD) and published.
| Name | Required | Description | Default |
|---|---|---|---|
| privacy | Yes | ||
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden: it usefully discloses that the result is served publicly at a stable URL and that 'published' is a toggle, which is real behavioral context. It omits auth requirements, whether an existing policy is replaced, and reversibility of publication.
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 action and public-serving consequence, followed by compact parameter enumeration. Slightly listy phrasing but no wasted 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 a nested-object parameter with zero schema documentation and no output schema, the description covers the nested fields adequately. It still leaves open whether publishing replaces an existing policy, what the tool returns, and what 'published' defaults to.
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 0% and the privacy parameter is an untyped object, so the description must compensate; it enumerates entity, contact_email, sections[{heading, body}], and optional intro, effective_date (YYYY-MM-DD), and published. Only product_id is left unexplained, and the URL template conveys its 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?
States a specific verb (publish) and resource (privacy policy), plus the concrete public URL it produces at /legal/{product_id}/privacy. Sibling get_privacy_policy is clearly the read counterpart, so an agent can distinguish them without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for app store review links' implies the intended scenario, giving implied usage rather than explicit guidance. There is no statement of when not to use it, whether it overwrites an existing policy, or a pointer to get_privacy_policy as the read alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test-parse a bank alert email (debug the alert parser).
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | ||
| text | Yes | ||
| subject | No | ||
| from_addr | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it discloses little beyond the word 'Test'. It does not confirm the operation is read-only/side-effect free, does not say whether it persists anything, and does not describe what the parse result contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no waste; the parenthetical earns its place by explaining the why. It is efficient, though the extreme brevity is part of the overall specification gap rather than a virtue in itself.
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?
No output schema, no annotations, and 0% parameter documentation mean the description must carry everything, and it does not. An agent cannot tell what the parser returns, how text vs html are prioritized, or whether this is safe to call repeatedly.
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 0% across four parameters (from_addr, text required; subject, html optional). The description says only 'email', which weakly implies the fields map to email components, but adds no format, required-ness, or precedence guidance to compensate for the coverage gap.
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?
Specific verb ('test-parse') plus resource ('bank alert email') with a parenthetical clarifying intent (debug the alert parser). An agent can tell this is a diagnostic entry point distinct from siblings like save_alert_sources or list_bank_alert_guides, though the description never names those neighbors explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Test-' prefix and 'debug the alert parser' imply a non-production, diagnostic context, which is genuine usage signal. However, it never states when to reach for this versus normal alert ingestion, whether it requires real email content, or that it has no side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update product fields (partial patch — only send fields to change).
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Lowercase product id (letters, digits, hyphen, underscore). | |
| name | No | ||
| site_url | No | ||
| mobile_push | No | ||
| pipeline_type | No | ||
| payment_config | No | ||
| content_enabled | No | Enable/disable the content pipeline for this product. | |
| default_country | No | ||
| logistics_config | No | ||
| opportunity_rules | No | What counts as a worthwhile trend/opportunity for this product — used when picking seeds and expanding opportunities. | |
| seed_picker_rules | No | Guidance for the seed-selection step specifically. | |
| opportunity_system | No | System context for generation prompts: what this product is, in the product's own voice. | |
| article_intent_rules | No | Structure/intent guidance for generated articles. | |
| publish_destinations | No | Where generated content publishes to. Each entry is one of {type: 'webhook', webhook_url, webhook_secret?}, {type: 'x_post', twitter_account_id}, or {type: 'ar_calendar', audience_resolver_project_id, audience_resolver_calendar_id} (requires audience_resolver_publisher_token to be connected first). | |
| content_target_markets | No | ISO-2 country codes this product's autonomous trend tweets should draw trends from (e.g. ['NG'] for a Nigeria-only product, ['NG','US'] to target more than one market). Empty/unset falls back to [default_country]. Without this, trend-driven tweets pull from a US-only trend pool regardless of the product's actual audience. | |
| content_posting_frequency | No | When this product's connected X account posts autonomous trend tweets. Either the legacy string preset ('daily' | '3x_week' | 'weekly' | 'off', defaults to 3x_week = Mon/Wed/Fri) or the object {days: ['mon','wed','fri'], time: '09:00' (Africa/Lagos, 24h), posts_per_day: 1-5}. | |
| intent_creative_direction | No | Free-form style/voice guidance for generated content. | |
| audience_resolver_publisher_token | No | Publisher JWT minted from the Audience Resolver dashboard, connecting this product to an AR account so content can be pushed to its calendars. Set via connect_audience_resolver, not directly. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose genuinely useful behavior — patch semantics implying unspecified fields are preserved — but says nothing about permissions/auth, whether changes are reversible, or side effects such as triggering content regeneration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero waste, and the parenthetical earns its place by conveying patch semantics rather than restating the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter tool with nested objects, an enum, no annotations, and no output schema, the description is far too thin. It leaves the sibling-overlap ambiguity unresolved and provides no signal about which fields matter or what the response looks like.
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 61% across 18 parameters, so seven fields (name, site_url, mobile_push, pipeline_type, payment_config, default_country, logistics_config) are undocumented in both schema and description. The description adds only the generic patch instruction and no per-field meaning, so it does not compensate for the coverage gap.
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 verb and resource ('Update product fields') and the parenthetical clarifies the mutation style (partial patch). The name alone already separates it from create_product/delete_product/get_product siblings, but the description does not itself contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Only send fields to change' is an invocation hint, not usage guidance. Nothing tells the agent when to use this tool rather than the overlapping siblings set_payment_config, set_logistics_config, set_mobile_push_config, or connect_audience_resolver, which all touch fields present in this schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a product icon/logo (base64-encoded JPEG/PNG/WebP, max 2MB).
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | ||
| content_type | Yes | ||
| image_base64 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose a real behavioral constraint absent from the schema: a 2MB maximum and the accepted image formats. However, it omits what a mutation tool really needs to convey — whether re-uploading replaces an existing icon, idempotency, required permissions, and failure modes.
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 sentence with zero filler, front-loading the action and resource before the encoding/size constraints. Nothing could be trimmed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter, 0%-coverage mutation tool with no annotations and no output schema, the description covers the image payload reasonably but leaves the product_id parameter, replacement semantics, and likely error conditions undocumented. Adequate minimum, but not 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 description coverage is 0%, so the description must compensate; it partially does by clarifying that image_base64 must be base64-encoded and by naming the accepted formats that map to the content_type enum. It says nothing about product_id (format, where it comes from) and gives no guidance on when to prefer jpeg vs jpg vs png vs webp.
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 gives a specific verb (upload) plus the resource (product icon/logo), so the operation is unmistakable and clearly distinct from siblings such as remove_product_icon, create_product, and update_product. It does not explicitly name or contrast those siblings, which keeps it short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives; the agent must infer from the name that this sets an existing product's icon while remove_product_icon clears it. No preconditions (e.g., product must exist / ownership) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
complete_account_deletionget_privacy_policylist_account_deletionsset_privacy_policycreate_product1 field changedInput schema / properties / content_target_marketsAdded value: +{
+ "description": "ISO-2 country codes this product's autonomous trend tweets should draw trends from (e.g. ['NG'] for a Nigeria-only product, ['NG','US'] to target more than one market). Empty/unset falls back to [default_country]. Without this, trend-driven tweets pull from a US-only trend pool regardless of the product's actual audience.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}update_product1 field changedInput schema / properties / content_target_marketsAdded value: +{
+ "description": "ISO-2 country codes this product's autonomous trend tweets should draw trends from (e.g. ['NG'] for a Nigeria-only product, ['NG','US'] to target more than one market). Empty/unset falls back to [default_country]. Without this, trend-driven tweets pull from a US-only trend pool regardless of the product's actual audience.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}create_product4 fields changedInput schema / properties / content_posting_frequency / anyOfAdded value: +[
+ {
+ "enum": [
+ "daily",
+ "3x_week",
+ "weekly",
+ "off"
+ ],
+ "type": "string"
+ },
+ {
+ "properties": {
+ "days": {
+ "items": {
+ "enum": [
+ "mon",
+ "tue",
+ "wed",
+ "thu",
+ "fri",
+ "sat",
+ "sun"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "posts_per_day": {
+ "maximum": 5,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "time": {
+ "description": "HH:MM, 24-hour, Africa/Lagos",
+ "type": "string"
+ }
+ },
+ "required": [
+ "days"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / content_posting_frequency / descriptionPrevious value: -"How often this product's connected X account posts autonomous trend tweets. Defaults to 3x_week (Mon/Wed/Fri)."New value: +"When this product's connected X account posts autonomous trend tweets. Either the legacy string preset ('daily' | '3x_week' | 'weekly' | 'off', defaults to 3x_week = Mon/Wed/Fri) or the object {days: ['mon','wed','fri'], time: '09:00' (Africa/Lagos, 24h), posts_per_day: 1-5}."Input schema / properties / content_posting_frequency / enumRemoved value: -[
- "daily",
- "3x_week",
- "weekly",
- "off"
-]Input schema / properties / content_posting_frequency / typeRemoved value: -"string"update_product4 fields changedInput schema / properties / content_posting_frequency / anyOfAdded value: +[
+ {
+ "enum": [
+ "daily",
+ "3x_week",
+ "weekly",
+ "off"
+ ],
+ "type": "string"
+ },
+ {
+ "properties": {
+ "days": {
+ "items": {
+ "enum": [
+ "mon",
+ "tue",
+ "wed",
+ "thu",
+ "fri",
+ "sat",
+ "sun"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "posts_per_day": {
+ "maximum": 5,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "time": {
+ "description": "HH:MM, 24-hour, Africa/Lagos",
+ "type": "string"
+ }
+ },
+ "required": [
+ "days"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / content_posting_frequency / descriptionPrevious value: -"How often this product's connected X account posts autonomous trend tweets. Defaults to 3x_week (Mon/Wed/Fri)."New value: +"When this product's connected X account posts autonomous trend tweets. Either the legacy string preset ('daily' | '3x_week' | 'weekly' | 'off', defaults to 3x_week = Mon/Wed/Fri) or the object {days: ['mon','wed','fri'], time: '09:00' (Africa/Lagos, 24h), posts_per_day: 1-5}."Input schema / properties / content_posting_frequency / enumRemoved value: -[
- "daily",
- "3x_week",
- "weekly",
- "off"
-]Input schema / properties / content_posting_frequency / typeRemoved value: -"string"create_product6 fields changedInput schema / properties / article_intent_rulesAdded value: +{
+ "description": "Structure/intent guidance for generated articles.",
+ "type": "string"
+}Input schema / properties / content_posting_frequencyAdded value: +{
+ "description": "How often this product's connected X account posts autonomous trend tweets. Defaults to 3x_week (Mon/Wed/Fri).",
+ "enum": [
+ "daily",
+ "3x_week",
+ "weekly",
+ "off"
+ ],
+ "type": "string"
+}Input schema / properties / intent_creative_directionAdded value: +{
+ "description": "Free-form style/voice guidance for generated content.",
+ "type": "string"
+}Input schema / properties / opportunity_rulesAdded value: +{
+ "description": "What counts as a worthwhile trend/opportunity for this product — used when picking seeds and expanding opportunities.",
+ "type": "string"
+}Input schema / properties / opportunity_systemAdded value: +{
+ "description": "System context for generation prompts: what this product is, in the product's own voice.",
+ "type": "string"
+}Input schema / properties / seed_picker_rulesAdded value: +{
+ "description": "Guidance for the seed-selection step specifically.",
+ "type": "string"
+}update_product6 fields changedInput schema / properties / article_intent_rulesAdded value: +{
+ "description": "Structure/intent guidance for generated articles.",
+ "type": "string"
+}Input schema / properties / content_posting_frequencyAdded value: +{
+ "description": "How often this product's connected X account posts autonomous trend tweets. Defaults to 3x_week (Mon/Wed/Fri).",
+ "enum": [
+ "daily",
+ "3x_week",
+ "weekly",
+ "off"
+ ],
+ "type": "string"
+}Input schema / properties / intent_creative_directionAdded value: +{
+ "description": "Free-form style/voice guidance for generated content.",
+ "type": "string"
+}Input schema / properties / opportunity_rulesAdded value: +{
+ "description": "What counts as a worthwhile trend/opportunity for this product — used when picking seeds and expanding opportunities.",
+ "type": "string"
+}Input schema / properties / opportunity_systemAdded value: +{
+ "description": "System context for generation prompts: what this product is, in the product's own voice.",
+ "type": "string"
+}Input schema / properties / seed_picker_rulesAdded value: +{
+ "description": "Guidance for the seed-selection step specifically.",
+ "type": "string"
+}connect_audience_resolvercreate_product5 fields changedInput schema / properties / audience_resolver_publisher_tokenAdded value: +{
+ "description": "Publisher JWT minted from the Audience Resolver dashboard, connecting this product to an AR account so content can be pushed to its calendars. Set via connect_audience_resolver, not directly.",
+ "type": "string"
+}Input schema / properties / publish_destinations / descriptionPrevious value: -"Where generated content publishes to. Each entry is either {type: 'webhook', webhook_url, webhook_secret?} or {type: 'x_post', twitter_account_id}."New value: +"Where generated content publishes to. Each entry is one of {type: 'webhook', webhook_url, webhook_secret?}, {type: 'x_post', twitter_account_id}, or {type: 'ar_calendar', audience_resolver_project_id, audience_resolver_calendar_id} (requires audience_resolver_publisher_token to be connected first)."Input schema / properties / publish_destinations / items / properties / audience_resolver_calendar_idAdded value: +{
+ "type": "string"
+}Input schema / properties / publish_destinations / items / properties / audience_resolver_project_idAdded value: +{
+ "type": "string"
+}Input schema / properties / publish_destinations / items / properties / type / enumPrevious value: -[
- "webhook",
- "x_post"
-]New value: +[
+ "webhook",
+ "x_post",
+ "ar_calendar"
+]list_audience_resolver_calendarslist_audience_resolver_projectsupdate_product5 fields changedInput schema / properties / audience_resolver_publisher_tokenAdded value: +{
+ "description": "Publisher JWT minted from the Audience Resolver dashboard, connecting this product to an AR account so content can be pushed to its calendars. Set via connect_audience_resolver, not directly.",
+ "type": "string"
+}Input schema / properties / publish_destinations / descriptionPrevious value: -"Where generated content publishes to. Each entry is either {type: 'webhook', webhook_url, webhook_secret?} or {type: 'x_post', twitter_account_id}."New value: +"Where generated content publishes to. Each entry is one of {type: 'webhook', webhook_url, webhook_secret?}, {type: 'x_post', twitter_account_id}, or {type: 'ar_calendar', audience_resolver_project_id, audience_resolver_calendar_id} (requires audience_resolver_publisher_token to be connected first)."Input schema / properties / publish_destinations / items / properties / audience_resolver_calendar_idAdded value: +{
+ "type": "string"
+}Input schema / properties / publish_destinations / items / properties / audience_resolver_project_idAdded value: +{
+ "type": "string"
+}Input schema / properties / publish_destinations / items / properties / type / enumPrevious value: -[
- "webhook",
- "x_post"
-]New value: +[
+ "webhook",
+ "x_post",
+ "ar_calendar"
+]create_product2 fields changedInput schema / properties / content_enabledAdded value: +{
+ "description": "Enable/disable the content pipeline for this product.",
+ "type": "boolean"
+}Input schema / properties / publish_destinationsAdded value: +{
+ "description": "Where generated content publishes to. Each entry is either {type: 'webhook', webhook_url, webhook_secret?} or {type: 'x_post', twitter_account_id}.",
+ "items": {
+ "properties": {
+ "twitter_account_id": {
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "webhook",
+ "x_post"
+ ],
+ "type": "string"
+ },
+ "webhook_secret": {
+ "type": "string"
+ },
+ "webhook_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}list_twitter_accountsupdate_product2 fields changedInput schema / properties / content_enabledAdded value: +{
+ "description": "Enable/disable the content pipeline for this product.",
+ "type": "boolean"
+}Input schema / properties / publish_destinationsAdded value: +{
+ "description": "Where generated content publishes to. Each entry is either {type: 'webhook', webhook_url, webhook_secret?} or {type: 'x_post', twitter_account_id}.",
+ "items": {
+ "properties": {
+ "twitter_account_id": {
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "webhook",
+ "x_post"
+ ],
+ "type": "string"
+ },
+ "webhook_secret": {
+ "type": "string"
+ },
+ "webhook_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}approve_depositassign_bank_creditcreate_productdelete_productdismiss_bank_creditget_onboarding_statusget_productget_webhook_secretlist_bank_alert_guideslist_bank_creditslist_depositslist_productsreject_depositremove_product_iconresend_deposit_fulfillmentrotate_inboxrotate_webhook_secretsave_alert_sourcessave_merchant_bankset_deposit_refund_statusset_logistics_configset_mobile_push_configset_payment_configtest_parse_bank_alertupdate_productupload_product_iconManage products, orders, customers, inventory, and store configuration
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
Manage your NanoCart store from any AI agent: products, orders, coupons, subscribers, reports.
Let your AI manage WooCommerce and Shopify stores: products, SEO, descriptions and images.
Add one secure layer between your agents and this server.
