AIfa Memory

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world call, so the safety burden is lifted. The description adds genuinely useful behavioral context by specifying the accounting window ('this month') and the currency of earnings (USDT). It does not state whether memory allowance resets monthly or what happens at exhaustion, which would be the most decision-relevant detail for a self-funding agent.

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 returned data and closing with the agent-facing rationale. The first sentence is a comma-spliced list without a main verb, which is slightly awkward but compact and wastes no words.

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

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

For a zero-parameter tool with no output schema, the description must carry the return-value burden, and it does list the four data groups. It is still thin on framing: units, whether usage is a count of bytes or entries, and how 'left this month' is computed are all left implicit. Adequate to select the tool, incomplete for interpreting its output.

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 for the description to compensate for. Baseline 4 applies; nothing in the description misleads about inputs.

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 enumerates exactly what the tool reports: plan, monthly permanent-memory (Arweave) usage and remaining allowance, referral earnings in USDT, and the referral link. The resource is unambiguous even without an explicit verb. It does not, however, explicitly distinguish itself from siblings like 'plans' or 'my_deals', which surface adjacent account data.

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

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

The closing line 'Useful for autonomous agents that fund their own memory' implies a usage context, but there is no explicit when-to-use rule, no when-not guidance, and no named alternative. An agent must infer that it calls this to check quota or earnings before invoking buy_plan or memory_write.

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

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

Annotations already declare it is a non-read-only, open-world, non-idempotent, non-destructive call, and the description adds genuinely useful lifecycle context: it returns an invoice URL, nothing is charged until payment, and the plan activates automatically afterward. It does not warn that repeated calls produce multiple separate invoices (relevant given idempotentHint=false), nor does it mention auth or invoice expiry.

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

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

Three tight sentences, front-loaded with what the tool does and what it returns; the tier/pricing breakdown follows as supporting detail. No filler or repetition of the schema.

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 purchase tool with no output schema, the description covers the essential facts: output is a URL, no immediate charge, automatic activation, and per-tier pricing. Minor gaps remain around what the agent should do with the URL and whether calling twice creates duplicate invoices.

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

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

Schema coverage is 100% and the enum labels are already in the schema, so the baseline is 3. The description earns extra credit by attaching real prices and billing cadence to each tier ($15/month, $100/month, $1,000 once-per-device then $200/month), which is decision-relevant meaning the schema does not carry.

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

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

The description opens with a specific verb+resource ("Creates a crypto payment invoice") and identifies the processor (NOWPayments), the payment rails (USDT and other coins), and the scope ("YOUR OWN account"), which separates it from client-facing siblings like client_report or find_clients. An agent can distinguish this from the display-only `plans` sibling without opening either schema.

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

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

The "for YOUR OWN account" qualifier and the note that nothing is charged until payment give clear context for when this is the right call. It stops short of naming an alternative (e.g., check `plans` first, or `account_status` to see if already subscribed) or excluding cases where an invoice should not be created.

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

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

Annotations already declare this read-only and idempotent, so the bar is lower, and the description still adds real behavioral context: the partner code is stored in the client's browser for 60 days, and the client both checks and pays on the same page. It does not describe the response shape, but for a link-generating tool that is a minor omission.

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

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

Two sentences, front-loaded with the core artifact (the partner link), followed by tracking behavior and the optional parameter's effect. No filler and nothing buried.

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-optional-parameter, non-destructive tool with no output schema, the description covers what is produced, its tracking lifetime, and the parameter's effect. The only gap is an explicit statement that the return value is a URL, which is implied rather than stated.

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

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

Schema coverage is 100% and the schema already lists example slugs, so the schema carries the basic meaning. The description adds value beyond it by explaining the effect of supplying a service: the link then surfaces that service's price and the partner's share, which the schema does not convey.

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 resource – a partner referral link to the AIfa Works accessibility page – and explains what the link does for the client (free check, then paid service on the same page). It is clearly distinct from siblings like partner_kit or plans. The only shortfall is that the producing verb ('generate', 'get') is implicit in the noun phrase.

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 client-facing context ('the client runs a free check... and pays') implies when to use it, and 'optionally name a service' gives a secondary usage mode. However, it never states when not to use it, nor points to an alternative sibling such as partner_kit, leaving routing to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is low. The description still adds real behavior the annotations cannot: no new scan of a third-party site is performed, only published research data is used, and the partner code is embedded in the link under channel "report". What is missing is any note on failure modes for an unknown or unscanned domain.

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 core capability is front-loaded, which is good, but the first sentence is overloaded with marketing copy (free check, audit from $50, code fixes from $99) that describes the landing page rather than the tool's behavior. That pricing detail is relevant only indirectly and crowds out more useful invocation guidance.

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 tool with no output schema, the description covers what comes back (the link plus the findings to quote) and the data provenance constraint. It is nearly complete; only the edge case of a domain with no existing research is unaddressed.

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

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

Schema description coverage is 100% — the single `site` parameter is already documented as a domain with an example. The description adds no extra meaning about the parameter (no normalization rules, no requirement that the domain already be in the research corpus), so the baseline 3 applies.

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

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

The description names a concrete artifact (a ready link to a report page) and what it contains (AIfa research findings from a keyboard test and axe-core rule check), plus what it returns. It does not, however, distinguish this from the sibling tool `client_link` or say how it relates to `find_clients`, so an agent must guess which link-producing tool is correct.

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: you would call this when you want to hand a site owner a quotable report. There is no explicit statement of when to prefer it over `client_link` or `find_clients`, and no prerequisites mentioned. The partner-code/channel detail hints at context but does not define selection criteria.

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

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

Annotations already establish that this is not read-only, not idempotent, not destructive, and closed-world. The description adds substantial behavior beyond that: daily allocation limit, worst-first ordering, exclusive 30-day reservation, skipped shared platforms, report_link/channel details, and outreach rules. It also aligns with the annotations rather than contradicting them.

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

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

The description is dense but front-loads the allocation limit and core outcome, then adds reservation, filtering, region format, and rules. Some region-format wording duplicates the schema, but overall the structure is purposeful and not padded.

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 tool with no output schema, the description covers the essential context: purpose, region input, daily cap, ordering, reservation exclusivity, filtering, report_link presence, and outreach constraints. Return format is only partially described through the report_link mention, which keeps it short of perfect completeness.

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 only one parameter and schema description coverage is 100%, so the schema already documents the region format. The description repeats the US-state and country-code examples without adding new syntax or constraints beyond what the schema provides, making 3 the appropriate baseline.

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

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

The description states a specific outcome: it returns up to 20 new client sites per day in a region where research found accessibility barriers, ordered worst-first, each with a report_link. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as client_link or client_report.

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

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

The description gives clear usage context: one call per region, a daily cap of 20 new sites, a 30-day reservation, and filtering of shared platforms. It does not name alternatives or explain when not to use the tool, but the intended scenario and constraints are explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds genuinely new context — that the response describes memory location and protection mechanisms and contains no user data — but it does not say anything about response shape or size.

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 short sentences, zero waste, and the scope qualifier ('No user data') is placed at the end where it reads as a caveat. The telegraphic 'What this memory is' phrasing is slightly cryptic but not padded.

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

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

For a parameterless, non-destructive info tool with annotations covering the safety profile and no output schema, the description supplies enough to know what the call returns at a high level. It stops short of describing the actual return fields, which is the only notable 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 the baseline is 4. Nothing about parameter meaning needs explaining, and the description correctly does not invent any.

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 resource — this memory store itself — and enumerates the three things it reports: what the memory is, where it lives, and how it is protected. Combined with the title, an agent can tell this is a self-description/info tool, distinct from siblings like memory_search or memory_write, though the differentiation is implied 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?

There is no explicit statement of when to call this versus memory_search, memory_recent, or memory_export. The phrase 'No user data' implicitly warns against using it to retrieve user content, but that is the only usage signal and it is never framed as a routing rule.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, and the description adds genuinely new operational detail: chunked returns of up to 100,000 characters, the termination signal ("last": true), record ordering, and the account-scoping restriction. That is exactly the kind of mechanics an agent needs to drive a paginated export correctly.

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 what the tool returns and followed by how to page through it. Every clause carries information: format, ordering, chunk size, loop condition, and scope.

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, but the description discloses the return format (Markdown), ordering, chunk size, and the stop condition, so an agent can consume the results without guessing. For a single-parameter read tool, nothing material is missing.

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

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

Schema coverage is 100% and the single `part` parameter is documented in the schema itself, so the baseline is 3. The description earns an extra point by explaining the iteration protocol around that parameter and how the agent knows it is finished, which the schema alone does not convey.

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

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

States a specific resource (the complete verbatim memory of the account), an ordering (oldest first), a format (Markdown), and a purpose (keep a copy or move it elsewhere). The 'complete verbatim' scoping implicitly separates it from siblings like memory_recent, memory_search, and memory_about without the agent needing to open another schema.

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

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

Gives clear when-to-use context ('to keep a copy or move it elsewhere') and an explicit invocation procedure for pagination: call part 1, then 2, 3… until "last": true. It does not name a sibling alternative or state a when-not condition, which keeps it just short of a 5.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds useful context that results are ordered newest-first and span all channels, but says nothing about pagination, truncation at the limit, or what a record 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?

One sentence with zero filler, front-loaded with the resource and immediately followed by ordering and scope. Nothing could be cut 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 simple single-parameter read with annotations covering safety and a fully described schema, the description is nearly sufficient. The one gap is the absence of routing guidance against the closely related memory_search and memory_about 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 coverage is 100% and the single optional 'limit' parameter is fully documented in the schema (default 20, max 50). The description adds no meaning beyond that, so the baseline 3 applies.

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

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

The description names a specific resource (the user's memory records) and states both ordering ('newest first') and scope ('across all channels'). It implicitly separates itself from memory_search by emphasizing recency rather than query matching, though it never names that sibling.

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

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

Usage is only implied: an agent can infer this is the tool for 'show me the latest memories' with no query. There is no explicit statement of when to prefer memory_search or memory_about instead, and no mention of prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured fields. The description's genuine addition is the data scope — conversations across four named domains plus agent-written notes — which tells the agent what is and is not in the index. It says nothing about result shape, ranking, or cost, leaving the remaining behavioral picture thin against an already-complete annotation set.

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

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

Two sentences, zero filler, and the highest-value information (what corpus, semantic matching) is front-loaded before the usage instruction. Nothing repeats the title or annotations.

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 read-only search with no output schema, the definition covers what is searched and when to call it, which is most of what an agent needs. The notable gap is the return shape — whether results are snippets, full conversations, or note objects — which an agent must discover empirically since no output schema exists.

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

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

Schema coverage is 100%: both 'query' and 'limit' are documented in the schema, including the default of 8 and the max of 12. The description reinforces that queries are natural-language and meaning-based, but adds no syntax, phrasing, or limit guidance beyond the schema. Baseline 3 is appropriate when the schema carries the parameter burden.

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 ('Search the user's AIfa memory') and adds the crucial qualifier 'by meaning', which signals semantic rather than chronological lookup. It also enumerates the corpus (four domains plus agent-saved notes), so the agent knows exactly what is being searched. It never names a sibling such as memory_recent or memory_about, so differentiation is left partly to inference.

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

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

Explicitly prescribes a moment of use: 'at the start of a task to recover what is already known about the user, their projects and decisions.' That is a clear, actionable trigger. It stops short of when-not-to-use or naming alternatives like memory_recent for time-ordered recall, so it is not a full routing rule.

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

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

Beyond the annotations, the description discloses that records propagate to 'all four sites' and that 'nothing is ever deleted' — useful operational context for a write tool. The 'an identical record is not duplicated' clause largely restates idempotentHint=true, so part of the sentence is redundant with structured data rather than additive.

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 short sentences, zero filler, with the core action and content scope front-loaded before the cross-site and dedup behavior. Every clause carries 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 two-parameter write tool with full schema coverage and complete annotations, the description covers what to store, the cross-site scope, and the no-delete/no-duplicate guarantees. The only minor gap is what a caller gets back on success, which is less critical given there is no output schema.

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

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

Schema coverage is 100%, so both parameters (text with its 8000-character cap, role with its user/assistant enum and default) are already fully documented in the schema. The description adds no extra meaning for the role parameter, which controls attribution and is never mentioned in prose; baseline 3 applies.

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

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

States a specific verb ('Save') and resource ('the user's AIfa memory') and enumerates the kinds of content that belong there (preference, decision, fact, session summary). The write verb implicitly separates it from the read-only siblings (memory_search, memory_recent, memory_about, memory_export), but no sibling is named explicitly, which keeps it from 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?

'Save something worth remembering' plus four concrete content examples gives an agent a clear inclusion test for when to call this. It stops short of stating when not to use it or pointing at memory_search/memory_recent for retrieval, so there is no explicit alternative routing.

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

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

The annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds value by disclosing the returned content, including pending orders and the withdrawal-availability timing, but it says nothing about volume, ordering, time window, or pagination — an agent cannot tell whether this returns every historical deal or a recent slice.

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, front-loaded with the core resource and then the returned fields, with no filler. The colon-and-semicolon structure is dense but readable; minor grammar roughness ('you brought') costs a point.

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

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

With no input parameters and no output schema, the description carries the full burden of explaining returns, and it does list the key fields. However, it omits the scope of the result set (all-time vs recent), any ordering or pagination behavior, and how 'your share' is computed — gaps that matter for a reporting-style tool.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline 4 applies; the field list is a small bonus but not required here.

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

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

The description names the resource (paid service orders the caller brought) and enumerates the returned fields (service, amount paid, your share, withdrawal availability) plus a second bucket of unpaid orders. This is specific enough to distinguish it from siblings like request_payout or account_status, though it never uses an explicit verb such as 'list' and the phrase 'orders you brought' is slightly awkward.

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 and no mention of alternatives, even though request_payout and account_status are obvious neighbours an agent could confuse this with. The only scoping signal is implicit: the tool covers paid and awaiting-payment orders, so an agent must infer that payout execution belongs elsewhere.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the bar is lower; the description still adds meaningful context by stating the returned content is static program material and that no user data is involved, which reassures on privacy. It does not describe the return structure, but with a read-only static resource that is a minor omission.

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

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

One dense sentence, front-loaded with the payoff ('everything to start earning') followed by the concrete contents. It is long but every clause carries substantive information about what will be returned; a short bulleted enumeration would read slightly better but 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?

With one optional enum parameter, no output schema, and full annotation coverage, the definition is close to self-sufficient — the enumerated contents effectively serve as a lightweight description of the return payload. The only gap is that the exact format of the returned kit (text, sections, template bodies) is not stated.

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

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

Schema coverage is 100% and the single optional parameter already carries a description and an enum, so the schema does the heavy lifting. The description's mention of 'three email templates in the chosen language' confirms which portion the language parameter affects, but adds no syntax or default detail beyond what the schema states.

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

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

The description names a specific resource — the partner program kit — and enumerates its contents (rates, 14-day hold, rules, three email templates), so an agent knows this is a reference/content retrieval tool rather than an action. It implicitly separates itself from transactional siblings like request_payout and my_deals but never names one 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?

Usage is only implied: an agent can infer it should call this when a user asks about the partner/referral program, rates, or outreach templates. There is no explicit 'use this when...' statement and no exclusion pointing at alternatives such as plans or my_deals.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond them by stating 'No user data', which tells the agent no auth or user scoping is needed, and by enumerating what the response covers (prices, storage, referral).

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 compact sentence with the substantive content front-loaded and zero filler. The phrase 'how to earn by bringing others' is slightly awkward where 'referral program' would be clearer, costing a perfect score.

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

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

For a static, parameterless lookup with no output schema, the description covers the subject matter well enough to call it correctly. It does not spell out the shape of the returned plan list, but with no output schema that is a minor gap rather than a blocker.

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 the baseline is 4 and there is nothing for the description to disambiguate. No parameter-level detail is needed or missing.

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

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

The description names a specific resource with concrete content: plan prices, what each plan stores permanently, and the referral earning program. That clearly separates it from siblings like buy_plan (purchase) and account_status (user state). It lacks an explicit verb (e.g., 'Returns' or 'Lists'), which keeps it just 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?

Usage is only implied: an agent can infer this is the reference tool to consult before calling buy_plan, but the description never says so or names buy_plan as the next step. There are no explicit when-not conditions either, leaving routing to the sibling set to inference.

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

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true): it discloses that requests are manually reviewed and paid, that the first address is permanently pinned so later requests can only go there, that addresses are screened against the OFAC sanctions list, and that prerequisites can block the call. These are non-obvious consequences an agent could not infer from structured 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?

Front-loaded with the core action, then layers preconditions, sanctions screening, and first-request fields in a logical order; no sentence is filler. It is dense but slightly list-like in the back half, with several policy sentences that could be tightened.

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

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

With no output schema, the description correctly explains the post-call lifecycle (manual review, then marked paid with a transaction hash), so the agent knows the call is asynchronous rather than returning funds immediately. For a one-shot withdrawal with 100% schema coverage, this is close to complete; only a note on what happens to a pinned address if it is rejected or on retry behavior is missing.

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

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

Schema description coverage is 100%, so the baseline is 3; the description still adds meaning by explaining the address pinning rule (why address is optional after the first call) and by grouping legal_name, country, and us_person as a one-time operator self-certification that must accompany the first request. It does not add format detail beyond the schema, but the cross-parameter relationship is genuine added 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?

States a specific verb and resource ("Requests a withdrawal of your whole available referral balance") plus currency (USDT) and network (TRC20), and clarifies that the entire balance is withdrawn rather than a caller-specified amount. An agent can distinguish this from all listed siblings (account_status, buy_plan, plans, etc.) without opening the schema.

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

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

Gives concrete usage conditions: the tool is closed while the plan payment is overdue, service partner earnings unlock 14 days after the client pays, and the first request additionally requires the tax self-certification. It does not name a sibling alternative, and the only redirection ("change it in the cabinet") points outside the tool set, so it stops short of full when/when-not routing.

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

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

Annotations only declare mutation and open-world traits; the description supplies the operational detail those hints cannot: payload shape {event, at, data}, absence of client emails, HMAC-SHA256 signature verification via X-AIfa-Signature, the one-time secret disclosure, https-only on port 443 with a public domain, no redirect following, and a 3-second timeout. These are exactly the constraints an agent needs before calling and are not derivable from idempotentHint/destructiveHint.

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?

Front-loaded with the outcome (what gets posted to your URL), then payload, then security, then constraints, then the disable switch. Dense but every clause carries unique operational information; nothing is repeated from the schema or annotations.

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

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

For a single-parameter configuration tool with no output schema, the description covers the return value (secret returned once), the delivered payload, authentication, network constraints, and teardown. Nothing needed to call it correctly or to consume the result is missing.

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

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

Schema coverage is 100% and the schema already documents url including the empty-string disable case, so the baseline would be 3. The description still adds real meaning: only https, only port 443, public domain names required, redirects not followed — constraints on the accepted value that the schema's "https URL of your endpoint" does not fully spell out.

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 concrete verb and resource plus the exact triggering conditions: a POST on every counted click (event "click") and every commission (event "commission"). An agent knows precisely what this tool configures and what the endpoint will receive, which distinguishes it from every sibling in this affiliate/payout toolset.

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

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

The description makes the invocation conditions clear (give an https URL to enable) and explicitly documents the off-path: "Pass an empty url to switch off." It does not name alternatives or state when not to use it, but no sibling offers overlapping webhook functionality, so there is little to differentiate.

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