trustai.center pay

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 the call is billed to a tai_ key's credits, but it does not explain authentication requirements, rate limits, error behavior, or whether the call is synchronous or streaming.

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, but it is under-specified for a four-parameter billable tool. Conciseness is good, yet the structure does not provide enough operational context.

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

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

Given no annotations, no output schema, and 0% schema description coverage, the definition is materially incomplete. Billing context is valuable, but the description omits return behavior, parameter meanings, and usage prerequisites needed to call this 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 description must compensate for four undocumented parameters. It only vaguely hints that the api_key relates to a tai_ key and says nothing about model, messages, or max_tokens.

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 ('Run') and resource ('chat completion'), and it clarifies the billing scope via a tai_ key's credits. It is clear enough to distinguish this from billing/balance siblings, but it does not explicitly differentiate itself from alternatives such as list_models or explain when chat completion is the right choice.

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 alternatives. It does not mention prerequisites such as obtaining or selecting a model, checking balance first, or when to use list_models instead.

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

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

With no annotations, the description carries the full burden and does well: it discloses the required wallet signature and its exact message format, a 7-day age limit, single-use-per-tx semantics, and the api_key-omission behavior for key issuance. It omits failure modes and whether the credit is immediately reflected in balance, keeping it from a 5.

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

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

Four compact sentences, front-loaded with what the tool does, then the hard requirements, then the operational limits. No redundant restatement of the name or 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 state-changing tool with no annotations and no output schema, the description covers prerequisites, constraints, and idempotency well enough to call correctly. What it returns on success (credited balance vs. a new key) and error behavior remain unstated.

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, and it does for most parameters: signature gets an exact format string, api_key gets an explicit omission rule, and chain/tx_hash are shown composing that signature. The chain enum values themselves are only visible in the schema, and tx_hash format is not elaborated.

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: credit a stablecoin transfer that lacks a matching order or has a non-exact amount. The scope qualifier ('no matching order') implicitly separates it from create_topup/verify_topup, but it never names those siblings explicitly, so the differentiation is left 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?

Clearly establishes the triggering condition — only for transfers without a matching order or with a non-exact amount — which is a real usage rule. It stops short of naming the alternative tools (create_topup, verify_topup) or stating when not to use this one.

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

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

With no annotations, the description must carry the behavioral load, and it does disclose the return payload (deposit address, chain, exact amount) plus the significant side effect that a newly created key is returned only once. It omits whether the order expires, whether calling twice creates duplicate orders, and any auth/rate-limit context, so a 3 is fitting.

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

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

Three short sentences, front-loaded with the action and followed by the return payload and the key-creation caveat. No filler, though the parenthetical '(returned once)' is dense enough that it could be slightly clearer.

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 4-parameter mutation tool with no annotations, no output schema, and low schema coverage, the description covers the essentials (what it creates, what it returns, the one-time key behavior). The undocumented promo parameter and missing lifecycle details (order expiry, duplicate-call behavior) leave real 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?

Schema coverage is 25%: only 'pack' is described in the schema, and chain/promo/api_key are bare. The description compensates for api_key (omit it to mint a new key, returned once) and implies chain's role through the return value, but the 'promo' parameter remains completely unexplained 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?

The description gives a specific verb and resource ('Create a stablecoin top-up order') and even names the return payload, so the operation is unambiguous. It does not explicitly contrast itself with the sibling tools claim_topup and verify_topup, which is the only thing keeping 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?

It supplies one real usage hint ('Omit api_key to create a new key'), which tells the agent how to trigger key provisioning. However, there is no guidance on when to use this versus claim_topup or verify_topup, nor on prerequisites such as authentication or when a created order expires.

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?

No annotations exist, so the description carries the full burden; it does partially meet this by naming the three values returned and implying a non-destructive read via 'Get.' However, it says nothing about whether the key must be valid, behavior when the key is missing/invalid, or whether the call is billable.

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 that front-loads the verb and enumerates the payload with zero filler. Nothing could be removed 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 read tool with one optional parameter and no output schema, the description effectively doubles as a return-value hint by naming balance, cap, and spend. Only auth-failure behavior and the relationship to get_usage/get_stats are 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?

One optional parameter at 100% schema description coverage, so the schema already explains the tai_ key and the Bearer-header alternative. The description only echoes that the call is keyed by a tai_ API key, adding no format, precedence, or error semantics beyond the schema.

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

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

States a specific verb ('Get') and enumerates the exact resources returned: credit balance, spend cap, and amount spent, scoped to a tai_ API key. This differentiates it in substance from get_usage and get_stats, though it never names those siblings to make the boundary 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?

Usage is only implied by the returned fields — an agent can infer 'call this to check account financial state.' There is no explicit when-to-use, no exclusion, and no mention of the overlapping get_usage/get_stats tools, leaving the agent to disambiguate on its own.

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

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

With no annotations, the description carries the full burden. It does disclose the data source ("our database"), the freshness window (last 24h), and that values are live ("Real numbers only"), which is useful context beyond the schema. It says nothing about authentication, caching, or the shape of the returned payload.

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, with the resource and scope front-loaded before the parenthetical contents. "Real numbers only" is slightly cryptic but plausibly communicates that figures are not mocked or estimated.

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

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

For a zero-parameter read tool with no output schema, the description adequately covers what comes back by listing the stat categories. It stops short of describing the response structure, which would matter more 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline applies. The enumerated field list gives useful framing for what the empty-argument call will produce.

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 (public platform stats) and enumerates its contents: tokens/requests over the last 24h, keys created, and top models. That is enough to separate it from per-account siblings like get_usage and get_balance, though the separation 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?

"Public platform stats" implicitly signals this is platform-wide aggregate data rather than the caller's own account data, which is what get_usage and get_balance return. However, no sibling is named and there is no explicit when-to-use or when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose the response payload contents (charges with model/tokens/cost, top-ups, last-24h totals, balance, limits), which is the most useful behavioral fact. It omits whether the call is read-only (only implied by the 'get' prefix), any rate limits, and how much history is returned or paginated.

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

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

A single dense sentence with the resource stated first and the payload contents following; nothing is wasted. It reads as a compact list dump rather than prioritized information, which keeps it just short of top marks.

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 tool with no output schema, the payload enumeration does most of the work of describing the return value. But the limit parameter's behavior (record count vs. time window) and key-selection semantics are left unexplained, leaving real gaps for correct invocation.

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

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

Schema description coverage is 0% and the description explains neither parameter. 'For a tai_ key' weakly gestures at api_key (and does not say whether it defaults to an ambient key), and `limit` (default 50) is never explained as the number of records returned.

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?

Names a specific resource (usage/audit log for a tai_ key) and enumerates what it returns (recent charges, top-ups, 24h totals, balance, limits), so an agent can tell it is a reporting tool. However, it does not distinguish itself from siblings get_balance and get_stats, which clearly overlap with 'balance' and 'totals'.

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 guidance and no reference to the obvious alternatives (get_balance, get_stats, list_models). The agent must infer from sibling names which reporting tool to pick.

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

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

With no annotations, the description carries the burden and does add real behavioral context: non-servable models surface with servable:false, and prices are reported as pricing.vs_list versus maker list price. It omits pagination/limit behavior and the shape of returned records, but the price-basis and discovery semantics are genuinely beyond the schema.

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

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

Two dense sentences with no filler, and the core scope leads. The parenthetical "pricing.vs_list vs maker list price" is slightly jargon-heavy but earns its place by clarifying price semantics.

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 six-parameter discovery tool with no annotations and no output schema, the description covers what to ask for but not what comes back (fields, ordering, limit interaction). It is workable but leaves an agent guessing about result structure.

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?

At 33% schema coverage the description must compensate, and it partially does: it maps text search (q), modality filter, max output price, and sort-by-popularity-or-price into plain language. However, limit (default 50), the price_desc/name sort values, and the interpretation of max_price for media units are left unaddressed.

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 with scope: "List servable text chat models with USD prices." It is clearly distinguishable from siblings like chat_completion or list_trending, though it never explicitly names an alternative to route away from.

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 context for the default scope (text chat models only) and an explicit opt-in path for broader discovery via include=discovery. It lacks any stated exclusions or named alternative tools for adjacent needs such as actually calling a model.

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

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

With no annotations, the description carries the full burden, and it does disclose one real behavioral trait: results are ranked by recent tokens served when available, falling back to a curated ranking, with a 'ranking' field to inspect. It says nothing about ordering ties, pagination, cache freshness, or auth requirements, so the disclosure is partial rather than complete.

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 with the core content front-loaded and the ranking caveat tucked in a parenthetical. It is appropriately sized; the nested parenthetical is slightly awkward but 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?

No annotations and no output schema mean the description should explain the return shape, and it does partially (models, prices, ranking field). It leaves the limit parameter, result ordering guarantees, and the relationship to list_models unaddressed, which is a meaningful gap for a discovery tool.

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

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

Schema description coverage is 0% for the single 'limit' parameter, so the burden falls on the description — which never mentions limit, its default of 10, or what the maximum is. This is the one-sided gap: the only parameter is 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?

The description states a specific resource — featured/trending models with prices — and what distinguishes them (trending, ranked), which is enough to separate it from a generic model-listing tool. It is a noun phrase rather than a verb+resource construction, and it never explicitly contrasts with the sibling list_models, 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 call this instead of list_models, no exclusions, and no prerequisites. Usage is only implied by the word 'trending'; an agent must infer the selection condition 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.

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses that this is a mutation, the currency and UTC-day semantics, and the null-vs-omit distinction, but it doesn't mention required permissions, idempotency, validation/error behavior, 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?

Two tight sentences with no filler; the scope and field list are front-loaded and the null/omit rule follows immediately.

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

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

For a simple 4-parameter setter with no output schema and no annotations, the description covers purpose, units, and null/omit behavior. It could be more complete by stating auth requirements or how errors/validation are reported, but nothing an agent needs to invoke it correctly 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 0%, so the description must compensate. It explains the meaning and units of three of the four parameters and clarifies null-vs-omit semantics; only api_key is left implicit, which is a minor 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 ("Set spend controls") and resource ("tai_ key") and enumerates the exact controls (total cap, daily limit, per-request max) in USD. This is clearly distinct from balance/topup/stats siblings.

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

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

The description explains the key usage rule — omit a field to keep it, pass null to remove it — which is essential for correct invocation. It does not explicitly say when to use this vs. alternative tools or note exclusions, but the tool's purpose is unambiguous among siblings.

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

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

With no annotations, the description carries the full burden, and it does disclose the important side effect (credits the received amount), the tolerance window (-0.5% or $0.01), and the signature fallback for mismatched amounts. It omits idempotency (can the same order be verified twice?) and what happens on failure, which matters for a credit-granting 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?

Two dense sentences with the action and required identifiers front-loaded and the tolerance/signature rule following as supporting detail. No filler.

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

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

Given no annotations, no output schema and completely undocumented parameters, the description covers purpose, precondition, mutation effect, tolerance rule and the signature escape hatch well. Return value and duplicate-verification behavior remain unstated but are the only notable omissions.

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, and it does map all three parameters to meaning — order_id and tx_hash as the required pair, and signature as the optional value needed when the credited amount falls outside tolerance. It does not specify hash/signature format or which chain, a minor residual 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 ('Confirm a top-up') plus the exact identifiers needed to do it, so the agent knows precisely what operation is performed. It does not differentiate itself from the sibling claim_topup, which sounds closely related, leaving ambiguity about which confirmation path to take.

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 'after sending funds' supplies a clear precondition for invocation, which is the key contextual trigger. However, it never states when to use claim_topup instead, nor what to do if verification fails.

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