Actora — Agent Identity, Subscriptions & A2A

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

No annotations are supplied, so the description carries the burden; it does imply a non-mutating lookup and partly discloses return content by naming the card fields. It says nothing about behavior on an unknown agentId, permissions, or whether the card is cached/live, which leaves real gaps for an annotation-free 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 with the resource first and the payload contents after the colon; nothing is wasted. It is efficient but at the cost of any usage or behavioral detail.

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

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

There is no output schema, so the description is the only signal about return values, and 'name, capabilities, supported tasks' is a rough sketch of a card's structure. For a simple two-parameter read this is adequate 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 100%, including the chain enum with its default and the Sepolia caveat, so the schema already does the heavy lifting. The description adds no meaning about agentId or chain beyond it, making the baseline 3 appropriate.

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

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

States a specific verb ('Get') and resource ('agent A2A card') and enumerates the returned fields (name, capabilities, supported tasks). It does not distinguish the tool from near-siblings such as actora_identity_get or actora_central_agent_list, which may superficially look like the same record.

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 word 'Get' and the A2A prefix – an agent can infer this is the read step before actora_a2a_create_task or actora_a2a_complete_task. There is no explicit when-to-use or when-not-to-use statement, and no guidance on preferring this over identity or listing lookups.

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 supplied, so the description carries the full behavioral burden. 'On-chain' and 'WRITE operation' do signal an irreversible state-changing transaction, but the description omits who is authorized to complete a task, whether gas/payment is involved, what happens to outputData, and what the response contains. That is thin for a 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?

Two short, front-loaded sentences with zero filler; the verb and the mutation warning come first. The brevity is efficient, but it shades into under-specification rather than genuinely earning every omitted detail.

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

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

For a 3-parameter state-mutating on-chain tool with no annotations and no output schema, the description leaves out authorization requirements, failure modes, and side effects of completion. The schema covers parameters, but the behavioral envelope an agent needs before invoking a write is largely absent.

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% and the schema itself documents chain options, taskId, and the outputData JSON payload, so the baseline applies. The description adds no meaning beyond the schema — it does not clarify the expected shape of outputData or the default chain behavior.

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 ('Complete') and resource ('a task') plus the execution context ('on-chain'), so an agent can tell it apart from actora_a2a_get_task or actora_a2a_my_tasks. It does not explicitly name a sibling or explain how it differs from actora_a2a_create_task, so it stops 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?

The tag 'WRITE operation' hints that this mutates state, but there is no guidance on when to call it versus get_task/create_task, no preconditions (task must be accepted/in-progress, caller must be the assigned agent), and no exclusions. The agent must infer all routing decisions.

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, "on-chain" and "WRITE operation" usefully disclose that this mutates blockchain state rather than performing a read. However, the description omits important operational behavior such as wallet or signing requirements, transaction fees, confirmation and failure semantics, and whether the task becomes active immediately.

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 front-loaded with the action and follows it with a compact, useful write warning. Both sentences earn their place, and there is no filler or unnecessary repetition.

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

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

The schema makes a basic invocation possible, but the overall definition is thin for a state-changing blockchain operation with no annotations or output schema. It lacks lifecycle guidance, operational prerequisites, and any indication of whether the result contains a task ID, transaction hash, or confirmation status.

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%, including the chain enum and default, unsupported Sepolia testnet, taskType examples, JSON inputData, and target agent ID. The description adds no parameter-specific meaning beyond that schema, so the high-coverage baseline of 3 applies.

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

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

The description uses a specific verb and resource: "Create an on-chain A2A task." This distinguishes the basic operation from siblings such as actora_a2a_get_task and actora_a2a_complete_task, but it does not explain the task's role or explicitly differentiate the lifecycle use case.

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 create a task, what prerequisites apply, or which sibling to use for discovery, inspection, or completion. The agent must infer that this is the initial task-creation step and determine how to obtain a valid targetAgentId 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?

No annotations are supplied, so the description carries the full behavioral burden, yet it only says "get". It does not state that the call is read-only, whether authentication or an identity is required, what happens when the taskId does not exist, or what the returned detail includes.

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 padding. It is efficiently sized, though its brevity reflects under-specification rather than disciplined compression.

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 with full schema coverage and no output schema, the minimum bar is met by the name-plus-sentence. Still missing is any hint of the return payload (task status, participants, payload) or failure behavior for an unknown taskId.

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%, with taskId documented as "Task ID" and chain documented with its enum and default. The description adds no meaning beyond the schema, so the baseline of 3 applies.

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

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

The description names a specific verb and resource ("Get A2A task details"), so the basic action is understandable. However, it does not distinguish this tool from siblings such as actora_a2a_my_tasks or actora_a2a_complete_task, leaving the agent to infer that this is the single-task fetch-by-ID operation.

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. The description never says to use this when you already have a taskId, or to use actora_a2a_my_tasks to discover IDs first, so routing 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.

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

With no annotations, the description carries the full burden and discloses almost nothing: no pagination or result cap, no ordering, no empty-wallet behavior, no auth requirements. The only behavioral signal is that it returns IDs rather than full task objects, which is genuinely useful but minimal.

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 or redundancy. It is sized appropriately for what it attempts, though the terseness is under-specification rather than efficiency.

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 and no annotations means the description should explain the return shape (array of ID strings?), any limits, and how to proceed to full task data. For a listing tool in a large sibling set, that guidance 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%, including the chain enum with its default and the Sepolia exclusion, so the schema already does the semantic work. The description adds nothing beyond it, making the baseline 3 appropriate.

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

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

States a specific verb (Get) and resource (task IDs) scoped to a wallet, which is more precise than a bare name restatement. However, it never distinguishes itself from actora_a2a_get_task (single task detail) and creates ambiguity with the tool name 'my_tasks' since it accepts an arbitrary userAddress rather than implying the caller's own tasks.

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 indication that this is a lightweight ID-only listing versus the detail-returning actora_a2a_get_task, and no stated prerequisites. The intended workflow (list IDs, then fetch each with get_task) must be inferred entirely.

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 does real work: it flags the WRITE nature, the auth requirement, the off-chain storage model with negative IDs, and a non-obvious side effect (a default 1 OXA/month plan is created automatically). It omits error behavior, idempotency, and what is returned on success.

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 tight sentences with the key distinctions front-loaded and a useful cross-reference to the update tool. The packed parentheticals ('source="central", off-chain, negative ID') are dense but each element carries information; nothing is filler.

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

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

For a 7-parameter write tool with no annotations and no output schema, the description covers identity model, auth prerequisites, write semantics, and the automatic plan side effect. The main remaining gap is what the response contains (e.g., the new agent's negative ID), which matters 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%, so all 7 parameters are already documented in the input schema, establishing a baseline of 3. The description's note about access_token being a registered-user JWT and the mention of the auto-created plan adds minor context but does not explain name, tags, skills, category, description, or capabilities 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+resource ('Create a centralized agent') and immediately disambiguates it from the on-chain alternative by describing it as off-chain with a negative ID and explicitly 'NOT an on-chain NFT'. That distinction is exactly what separates it from siblings like actora_identity_register.

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 preconditions (requires access_token as a registered-user JWT) and routes plan adjustment to actora_central_agent_update. It does not explicitly state when to prefer this over an on-chain identity creation beyond the NFT contrast, so it stops short of full when/when-not 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, 'Public read' usefully communicates both read-only behavior and public accessibility, while 'off-chain' and central_plans establish data location and provenance. The statement that plans have the same structure as on-chain plans adds useful return behavior, although response-envelope and error behavior remain undisclosed.

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-load the operation and its distinguishing scope, then cover output and access. There is no filler and no unnecessary repetition of individual parameter documentation.

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?

Together with the fully documented schema, the description covers the resource, chain and ID scope, plan output and structural compatibility, and public-read behavior, which is nearly enough to select and invoke this simple list tool. Without an output schema, it could still clarify whether plans are embedded per agent or returned separately and what the paginated response contains.

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?

All five optional parameters are already documented in the schema, including defaults, the page-size maximum, and example filter formats, so the high-coverage baseline applies. The description adds no further semantics, such as whether multiple filters combine with AND or how comma-separated capabilities are matched.

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 opening verb and resource are explicit: it lists centralized agents, then narrows them to source central, off-chain records with negative IDs. The explicit 'NOT on-chain NFTs' clause distinguishes it from the identity and other on-chain 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 off-chain and negative-ID scope, together with the exclusion of on-chain NFTs, provides a clear selection context and when-not signal. It stops short of naming the appropriate sibling for on-chain agents or explaining when this tool's plan results should be used instead of the subscription-plan tools.

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

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

With no annotations, the description carries the full burden. It usefully discloses that this is a WRITE operation and that PATCH semantics mean only supplied fields change, which is real behavioral information. It does not cover permissions beyond the token, error behavior, reversibility of changes, or whether updating non-owned agents fails.

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, front-loaded with the operation and scope, followed by the auth requirement and write classification. No filler or redundancy.

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

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

For a 9-parameter mutation tool with no output schema and no annotations, the description supplies the essentials: ownership scope, auth requirement, write nature, and partial-update semantics. It leaves out return values and error/rollback behavior, but the critical call-time details are 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 coverage is 100%, so the baseline is 3, but the PATCH note adds collective meaning across the 7 optional fields that the schema does not express: omitted fields are preserved rather than cleared. That is genuine added value beyond the per-parameter descriptions.

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

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

The description pairs an explicit verb (Update) with a specific resource (a centralized agent) and narrows scope with 'you own', which separates it from the create/list siblings. It is clear but never names the alternative tools (actora_central_agent_create, actora_central_agent_list) that an agent might confuse it 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?

It states the prerequisite (must be an agent you own, requires a registered-user JWT) and the update style (PATCH), which implies when to use it. There is no explicit when-not guidance or pointer to sibling tools for creating, listing, or delisting agents.

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 more than most: 'Public read' covers the auth/safety profile and 'Resolves off-chain fiat/x402 records first (resolveAccess)' discloses a non-obvious internal resolution ordering that an agent could not guess. It stops short of saying what happens when no off-chain record exists (on-chain fallback?) or how misses are reported.

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 core check before the resolution detail, with no wasted preamble. 'Same rail as the in-app subscription flow' is the weakest sentence, adding orientation but little operational value.

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

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

This is a no-output-schema tool whose description never indicates what a result looks like, a boolean versus a subscription object with plan/expiry fields. For a lookup tool the answer shape is central, and its absence leaves a real gap even though the resolution-path and access details are covered.

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 both parameters are already documented, including 'Centralized agent ID (negative)'. The description only restates that same constraint rather than adding format, range, or normalization meaning. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description opens with a specific verb and resource: 'Check whether a wallet has an active subscription for a centralized agent (negative agentId).' The parenthetical 'negative agentId' narrows the scope enough to separate it in spirit from the sibling actora_subscription_check, but it never names that sibling or states the contrast explicitly, so differentiation is inferred rather than declared.

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 establishes the applicable context (centralized agents, negative agentId) and 'Public read' implicitly signals no credentials are needed. It gives no when-not-to-use guidance and does not route non-central lookups to actora_subscription_check or actora_subscription_detail, leaving the agent to infer the boundary.

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 JWT auth, the two-phase payment/verification flow, and what the first call returns (amountWei / payTo / network). It omits failure modes, idempotency, and whether a partial first call has side effects, which prevents 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?

Two sentences, front-loaded with the action and rail, followed by the auth requirement and the two-step flow. No redundant or filler wording; every clause conveys operational 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 6-parameter mutation tool with no output schema and no annotations, the description covers the essential flow, auth, and first-call return shape. It stops short of describing the activated subscription result or error conditions, but is largely sufficient to invoke correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by explaining the conditional role of txHash (absent = request instructions, present = verify and activate) beyond the schema's terse 'include to verify and activate'. Other parameters like priceWei and period are left to 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 and resource ('Subscribe to a centralized agent via the x402 rail') and names the payment rail, so the agent knows exactly what operation this performs. It does not explicitly distinguish itself from the sibling actora_subscription_subscribe or actora_central_subscription_check, 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?

Gives clear procedural guidance: call first without txHash to get payment instructions, then call again with the txHash after the on-chain transfer. It does not mention when to prefer this over the non-central actora_subscription_subscribe or when to use actora_central_subscription_check instead, so alternatives are left implicit.

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 supplied, so the description carries the full burden. It does disclose a meaningful behavioral fact, that values come from the platform DB rather than the on-chain ConfigurationRegistry, and 'Read' implies a non-mutating call, but it says nothing about auth requirements, what happens when a key is unset, or how structured keys like 'card' or 'tags' are 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?

One sentence, front-loaded with the action and scoping, with the disambiguation carried in a compact parenthetical. Nothing is redundant.

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 3 fully documented params and no output schema, the description is adequate to invoke the tool correctly, but it omits what comes back, which matters given configKey can select scalar fields or structured ones (tags, capabilities, card).

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%, covering chain enum, agentId, and the enumerable configKey options, so the baseline is 3. The description adds only the 'by key' framing and the DB-vs-chain scope, not shape or format details for the returned 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 gives a specific verb ('Read') and resource ('agent spec/config value by key') and explicitly excludes the on-chain ConfigurationRegistry, which clarifies what data source is being read. It implicitly distinguishes itself from actora_config_list (single key vs. list) and actora_config_set (read vs. write), though it never names those 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?

Usage is only implied: 'by key' signals a single-value lookup and the parenthetical rules out the on-chain registry, but there is no explicit instruction on when to prefer actora_config_list or actora_config_set, and no stated prerequisites or error behavior for unknown keys.

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 supplied, so the description carries the full behavioral burden. It discloses the data source ('platform DB') and implies a read-only operation, but says nothing about permissions, whether unset defaults are included, ordering, or what the returned structure looks like.

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, so the purpose appears immediately. The phrasing 'for an agent from the platform DB' is slightly redundant against agentId in the schema but costs only a few 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?

With only two well-documented parameters and no output schema, the definition covers the minimum needed to invoke the tool. It falls short on what a caller receives back (keys only, key/value pairs, nested spec) and on any constraints such as missing configs for an unknown agentId.

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%: agentId is documented as 'Agent ID' and chain has an explicit enum description including default ('bsc') and the note that Sepolia is unsupported. The description adds no further meaning about either parameter, so the baseline of 3 applies.

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

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

The description uses a specific verb ('List') and resource ('agent spec/config values') scoped to a single agent, so an agent can tell what it retrieves. It does not name the adjacent siblings actora_config_get or actora_config_set, so the distinction between listing all values and fetching one value must be inferred from 'all'.

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 word 'all' combined with the required agentId implies a bulk-read use case, which vaguely signals when to prefer this over a single-value get. However, no explicit when-to-use or when-not-to-use guidance is given and the obvious alternative (actora_config_get) is never mentioned.

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 two genuinely useful facts: this is a WRITE operation and it "returns instructions" rather than completing the write directly (implying a follow-up signing step). It still omits permissions required, reversibility, whether unlisted keys are preserved, and the shape of the returned instructions.

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 fragments with no filler, and the critical "WRITE operation" flag is front-loaded. However, the terseness comes at the cost of substance — the endpoint path is stated while the actual semantics of key/value/dataType are not, so the space is not optimally spent.

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 5-parameter mutation tool with no annotations, no output schema, and 40% schema coverage, the description leaves too much open: no explanation of the undocumented parameters, no description of the returned signing instructions, and no note on what state changes occur. It conveys the endpoint and write nature but not enough 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 coverage is only 40% — key, value, and dataType have no schema descriptions at all — and the description adds nothing about them (no key namespace/format, no dataType defaulting behavior, no value encoding). The only schema-documented parameter (chain) is not addressed either, so the low-coverage gap is not compensated.

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?

"Config writes" plus the endpoint hint at a key/value config mutation for an agent, but the description never states the verb+resource plainly ("set a config value for an agent") — the tool name does most of that work. It is distinguishable from actora_config_get/actora_config_list only by implication, not by explicit statement.

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 actora_config_get, actora_config_list, or actora_central_agent_update. The only constraint offered is that writes are owner-signed, with no prerequisites, no when-not conditions, and no mention of what happens if the key already exists.

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

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

No annotations are supplied, so the description carries the full burden and largely fails it. "From the platform DB" hints that results come from stored state rather than a live probe, which is a useful nuance, but the meaning of "live," whether results are paged or cached, and what happens when no live endpoint exists are all undisclosed.

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 short and front-loaded, but it is a single sentence fragment rather than a structured statement. The brevity reflects under-specification rather than tight editing, since nothing about scope or behavior is actually conveyed.

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 annotations and no output schema, this description is too thin. It should at minimum state the return shape (a list of endpoint records), clarify what qualifies as "live," and route the agent away from the probe/status/list 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 100%, including an enum with per-value docs and a default for chain, so the schema already handles parameter meaning. The description adds nothing about agentId or chain, which is acceptable at this coverage level but earns no credit above 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 text is a noun fragment, not a verb+resource statement: it never says it lists or returns endpoints. It essentially restates the tool name (endpoint_active = "only live endpoints") with the added qualifier "from the platform DB," and it does nothing to separate it from siblings like actora_endpoint_list, actora_endpoint_status, or actora_endpoint_probe.

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 named alternative. An agent must guess whether to call this, actora_endpoint_list, actora_endpoint_status, or actora_endpoint_best_mcp; the only implicit signal is a "live only" filter.

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 carries the full burden. It implies a read from a database but says nothing about selection logic, fallback behavior when no endpoint exists, whether the result is cached, or any auth requirement — all material for an endpoint-resolution call.

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, front-loaded sentence with no filler. It is efficient, though the terseness contributes to the missing selection-criteria detail rather than compensating for it.

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 lookup with a fully documented 2-parameter schema and no output schema, the definition is minimally adequate. The unresolved gaps are the meaning of "best" and the empty-result case, which are central to invoking it correctly.

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

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

Schema description coverage is 100% and the chain enum documents the default and the Sepolia exclusion, so the schema does the heavy lifting. The description adds no additional parameter meaning, which is the expected baseline 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 a concrete resource and qualifier ("Best available MCP endpoint URL from the platform DB"), which is enough to tell it apart from list-style siblings like actora_endpoint_list or actora_endpoint_status. However, it never states the criterion for "best" (latency, recency, health score), so the core semantics remain fuzzy.

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 the four closely related sibling tools (actora_endpoint_active, actora_endpoint_list, actora_endpoint_probe, actora_endpoint_status). An agent must guess whether to call this or probe/active first when resolving an endpoint.

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

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

With no annotations, the description must carry the behavioral burden; it does disclose the data source (platform DB) and that non-active endpoints are returned, which is real context beyond the schema. It omits ordering, pagination, and whether results are scoped to the agent or global, which matter for a list 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 with the scope qualifier immediately attached; nothing is redundant or 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 two-parameter list tool with no output schema and no annotations, the description is minimally adequate but leaves the agent guessing about result shape, volume, and scoping. It is complete on what is returned conceptually, incomplete on how it is 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 coverage is 100% and the chain parameter already documents its enum, default, and the Sepolia exclusion. The description adds no meaning about agentId or chain, so baseline 3 applies since the schema does the work.

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 and scope: all registered endpoints from the platform DB, explicitly noting that pending/failed entries are included. That inclusion note implicitly separates it from actora_endpoint_active, but no sibling is named, 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?

Usage is only implied: the '(includes pending/failed)' clause suggests this is the exhaustive view rather than the filtered active/best-MCP views. There is no explicit 'use this when' statement and no named alternative among actora_endpoint_active, actora_endpoint_status, or actora_endpoint_best_mcp.

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 does carry some of the burden: it discloses that the call triggers an outbound probe (not just a read), that the target is the primary endpoint of an already-listed agent, and that an owner JWT is required for authorization. It omits rate limits, timeout behavior, whether results are persisted, and what 'liveness result' actually contains, which matters since there is no output 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 short sentences, zero filler, with the action and target front-loaded and the auth prerequisite second. Nothing is repeated unnecessarily.

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, fully documented schema the description covers the essential action and auth need, and no output schema exists so return-value detail is not strictly required. However, a network-probing tool with no annotations should say more about failure modes and whether the probe mutates or persists any state, leaving 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?

Schema coverage is 100%, so all three parameters are already documented in the schema, including the enum for chain and the access_token auth note. The description's only parameter-adjacent content restates the access_token requirement ('owner JWT') without adding format, scope, or failure semantics, so the baseline of 3 applies.

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

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

States a specific verb ('Re-probe') and resource ('the primary endpoint of a listed agent'), scoped to a2a or mcp endpoints. The 're-' prefix implies a fresh check rather than reading cached state, which distinguishes it implicitly from siblings like actora_endpoint_status or actora_endpoint_active, though those siblings are never named.

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: 're-probe' plus the owner-JWT requirement suggests this is for forcing a fresh liveness check on a known agent. It never says when to prefer it over actora_endpoint_status, actora_endpoint_active, or actora_endpoint_list, so an agent must infer the choice.

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 carries the full burden; it does disclose the auth requirement (owner JWT) and the shape of the health data returned. It does not state that this is a non-mutating read, whether counts are a snapshot or over a time window, or any rate/pagination 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?

Two tightly written sentences: the capability and its returned fields come first, the prerequisite second. No filler or redundancy.

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

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

For a simple one-parameter read tool with no output schema, the description usefully enumerates the return fields and the auth requirement, which is most of what an agent needs. Minor gaps remain (snapshot semantics, per-agent breakdown, relationship to sibling health tools).

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 access_token parameter is fully documented there. The description only restates the requirement and adds 'owner JWT' as a qualifier, which is marginal added 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?

Names the resource precisely ('Owner-level endpoint health across all your agents') and enumerates what it reports (liveness counts, last probe result, retry time). This distinguishes it in spirit from per-endpoint siblings like actora_endpoint_list or actora_endpoint_probe, but it never names those alternatives 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 'across all your agents' implies this is the aggregate overview versus per-endpoint tools, but there is no explicit when-to-use or when-not-to-use statement. With actora_endpoint_list, actora_endpoint_probe, actora_endpoint_active and actora_gateway_health as close siblings, an agent must infer the choice.

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 well: it discloses the state machine (queued → cancelled, running → aborted) and declares terminal-state calls idempotent, which is the key safety fact for a mutation. It stops short of saying whether cancellation waits for the abort to complete, what the response confirms, or what error surfaces if the task does not exist.

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 that front-loads the action and then the per-state outcomes, with a short auth requirement trailing. Every clause conveys something the caller needs; nothing is padding.

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 the essential semantics: what the operation does, how it behaves per state, idempotency, and the auth requirement. The only gap is the absence of any statement about what a successful call returns or confirms.

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%, including the note that access_token is a registered-user JWT, so the schema already documents both parameters. The description's auth note repeats the schema rather than adding format, scope, or acquisition guidance, 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?

Specific verb and resource ('Cancel a task') plus the exact outcome per source state (queued → cancelled; running → aborted). It is trivially distinguishable from siblings like actora_gateway_create_task and actora_gateway_get_task without opening any 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 state-transition clause effectively tells the agent when calling is safe: terminal states are idempotent, so repeat calls are harmless, while queued/running produce distinct outcomes. There is no explicit exclusion or named alternative, but for a terminal cancel operation none is really needed.

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 usefully discloses that the SSE stream is collected into a single reply and that a registered-user JWT is required, but says nothing about error behavior, rate limits, or whether the call creates persistent state.

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 the core behavior front-loaded and the auth constraint appended. No wasted wording, though the parenthetical could be folded more cleanly.

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 tool with no annotations and no output schema, the description is thin: it does not describe the reply shape, error handling, or how inline prompt mode relates to agent_id. Adequate to call it, 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 coverage is 100%, so the schema already documents all six parameters including the inline-prompt vs agent_id modes. The description only reinforces the access_token requirement, adding little beyond the structured fields.

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 ('Single-turn conversation with an agent') and clarifies the transport behavior ('SSE stream collected into a reply'). It implicitly distinguishes itself from session/task siblings via 'single-turn', 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?

The description notes the auth prerequisite (registered-user JWT) but gives no explicit guidance on when to use this versus actora_gateway_create_session or actora_gateway_create_task. Usage is only implied by the 'single-turn' framing.

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 provided, the description carries the full disclosure burden, and it does contribute two real behavioral facts: the operation is idempotent and it requires registered-user JWT auth. It stops short of explaining idempotency semantics (does a repeat call return the existing session id?), what the caller receives, or any failure modes, which matters for a creation endpoint that downstream calls depend on.

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 compact sentences with the core action front-loaded and the auth requirement second; no filler, no restatement of the tool name beyond what is needed. Everything present earns its place.

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

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

For a three-parameter creation tool with full schema coverage and no output schema, the definition covers purpose, idempotency, and auth. The main omission is what the call yields (presumably a session identifier consumed by actora_gateway_chat), which the absence of an output schema makes more important to state, but the remainder is adequate.

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 all three parameters are already documented inline, giving a baseline of 3. The description only restates that access_token is a required registered-user JWT — duplicating the schema — and adds nothing about how title or agent_id affect the created session.

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 ("Create a conversation session") and clarifies the domain term with "dialog container", so an agent knows exactly what object is produced. It does not explicitly contrast itself with the task-oriented siblings (create_task, chat, get_task), but the resource distinction is clear enough to separate it 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?

Usage is only implied: the agent can infer a session is the prerequisite container for chat/agent interactions, and the description states the auth prerequisite (registered-user JWT). There is no explicit statement of when to call this versus actora_gateway_chat or actora_gateway_create_task, and no exclusions or prerequisite sequencing described.

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 zero annotations the description carries the full burden, and it discloses real behavior: asynchronous execution with an immediate taskId return, the queued→running→done state progression, a specific failure mode (403 PARALLEL_TASKS_DISABLED), and the registered-user JWT auth requirement. It stops short of describing what happens to a task on failure or how results are retrieved afterward.

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 front-load the core action and async semantics, then attach the error and auth constraints parenthetically. Every clause carries operational information and there is no filler.

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

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

For a six-parameter mutation tool with no annotations and no output schema, the description covers the essential async contract, auth requirement, and a known error code. The notable gap is not telling the agent how to follow up on the returned taskId (actora_gateway_get_task) or listing any other error 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 100%, so every parameter is already documented in the input schema, including the inline-prompt vs agent_id tradeoff and the BYOK tenant_key_id. The description adds no parameter-level detail beyond restating that access_token is a required registered-user JWT, so the baseline of 3 applies.

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

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

States a specific verb and resource ("Create a background task in a session") and immediately contrasts it with synchronous behavior via "returns immediately with taskId". This implicitly separates it from actora_gateway_chat, but no sibling is named explicitly, so differentiation depends on 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?

The word "background" plus the immediate-return note implies this is for long-running work that should not block, which is usable guidance. However, there is no explicit when-not clause and no pointer to alternatives like actora_gateway_chat for synchronous turns or actora_gateway_get_task for polling results.

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 surface the key operational constraint: a registered-user JWT access_token is required. It does not say whether an unknown or unauthorized task_id produces an error versus an empty result, nor does it mention any rate limits or side effects (though the operation reads as non-mutating).

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 zero filler; the primary action appears first and the auth requirement second. Nothing is redundant.

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

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

For a simple two-parameter read tool with no output schema and fully described parameters, the description covers purpose, return fields, and the authentication prerequisite. Only error behavior for invalid or missing task ids remains unspecified, which is minor.

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 both task_id and access_token including the registered-user JWT requirement. The description's parenthetical restates that constraint rather than adding format or acquisition details, 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 gives a specific verb and resource ('Get task detail by id') and names the returned fields (status, result, error), so an agent knows exactly what it retrieves. It is distinguishable from the sibling list_tasks, but it does not explicitly contrast itself with list_tasks or create_task.

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-id retrieval suggests you need an existing task_id, which list_tasks would supply. No explicit when-to-use or when-not-to-use guidance, and no named alternative for cases like looking up many tasks.

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 supplied, so the description carries the full disclosure burden, yet it says nothing about whether this is a read-only call, whether it hits live RPC endpoints (latency/failure modes), or how the health signal and addresses are returned. Naming the chains is the only behavioral hint, and it does not compensate for the missing safety and failure-mode context.

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

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

A single short line with zero filler and the key content front-loaded. It stops just short of being well-formed enough to be fully self-explanatory, reading as a label rather than a statement of what the caller receives.

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 utility tool this is close to adequate: it tells the agent both categories of data returned. However, with no output schema and no annotations, the description should clarify the return shape (e.g., a status flag plus a chain-to-address map) and whether the call requires network access, which it leaves 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly implies a single unfiltered response covering all three chains rather than requiring per-chain selection.

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 two concrete resources — gateway health and chain contract addresses — and enumerates the supported chains (BSC / Ethereum / Base). It is a fragment rather than a verb-led statement, but no sibling tool covers health checks or contract addresses, so it is readily distinguishable from the actora_* identity/listing/subscription 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?

There is no guidance on when to call this versus any alternative, no mention of preconditions, and no indication of whether it should be used as a connectivity probe before other calls. 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.

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 only restates the authentication requirement already present in the schema. It says nothing about pagination, result ordering, behavior for an invalid or expired session, or whether all tasks are returned or a truncated page.

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 core action front-loaded and the auth prerequisite second. No filler or redundant phrasing.

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

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

For a simple two-parameter read tool with no output schema, the description covers purpose and auth adequately. However, without annotations or a return schema, it should at least sketch the return shape or pagination behavior to be 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 100%, so both session_id and access_token are already documented in the input schema. The description adds no syntax, format, or constraint detail beyond that, making the baseline 3 correct.

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?

Uses a specific verb and resource ("List all tasks") scoped to a session, which clearly separates it from the single-item sibling actora_gateway_get_task. It stops short of explicitly naming 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?

The scope phrase "of a session" implies when this tool applies (enumerating tasks for a known session), but there is no explicit when/when-not guidance and no reference to alternatives such as get_task or cancel_task. Usage must be inferred from the tool name and scope.

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 carries the full disclosure burden and does not meet it. 'Get' implies a read, but there is nothing about the required JWT/authorization context, whether results are scoped to the token's tenant, rate limits, or what the response shape looks like.

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 sentence with zero filler, and the key noun (tenant) is front-loaded. It is efficient, though the terseness pushes the missing information into the other dimensions rather than making the sentence itself wasteful.

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 full schema coverage and no output schema, the description minimally covers what is returned. It leaves unresolved how this differs from actora_tenant_plans and actora_tenant_usage and says nothing about authorization behavior, which is the main gap for an agent that must choose 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?

There is a single parameter with 100% schema description coverage ('Gateway JWT token'), so the schema already explains it. The description adds no meaning about the token's scope or how tenant resolution works, which is the baseline expectation when the schema is complete.

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

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

States a specific verb ('Get') and resource ('tenant') plus the data returned (profile, plan, quota), so an agent knows it is a read of tenant metadata. It does not distinguish itself from the overlapping siblings actora_tenant_plans and actora_tenant_usage, which appear to cover part of the same ground.

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. Given two siblings named for tenant plans and tenant usage, an agent has to guess whether this tool supersedes them or complements them; the description offers no routing signal.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It signals an on-chain read but says nothing about the returned value (boolean? record?), latency/RPC dependency, or behavior for unknown chains — all of which an agent needs for a tool with zero structured behavioral hints.

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 filler, appropriate for a simple predicate tool. It is efficient but borders on under-specified rather than optimally sized.

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 should at minimum state what the check returns and how failures/unsupported chains are surfaced. Neither is covered, leaving a real gap for an agent that must interpret the result.

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 chain parameter already documents its enum, default, and the Sepolia exclusion. The description adds nothing beyond the schema for either agentId or chain, so the baseline of 3 applies.

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

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

"Check whether an agent ID exists on-chain" gives a specific predicate and resource, which is clearly distinct from siblings like actora_identity_get (fetch details) or actora_identity_list (enumerate). It stops short of naming those siblings explicitly, 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 guidance on when to use this versus actora_identity_get or actora_identity_list, and no stated prerequisite (e.g. use before register, or that a false result means the ID is unclaimed). The existence-check use case is only implied by the verb.

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 carries the full disclosure burden and largely fails it. The word "existence" weakly hints that a nonexistent agentId returns a status rather than throwing, which is useful, but there is no statement about read-only safety, permission requirements, cross-chain behavior, or what the response actually looks like. For a lookup with three enumerated chains and no output schema, this is a substantive 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?

A single front-loaded clause with no filler; the em-dash list of returned fields is efficient. It is telegraphic to the point of under-specification, but nothing is wasted or 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?

With only two parameters the tool is simple, and the description does gesture at return values (tokenURI, metadata, existence), which matters because there is no output schema. Still, with zero annotations and no output schema, an agent lacks the behavioral and structural context needed to call this confidently instead of a sibling.

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% — both agentId and the chain enum with its default ("bsc") and its Sepolia exclusion are already documented in the schema. The description adds no parameter-level meaning beyond that. Baseline 3 applies since the schema does all the work.

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

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

The description states a specific verb and resource ("Get agent details") and names three returned fields (tokenURI, metadata, existence), so the intent is discernible. However, it gives no basis for distinguishing this tool from close siblings such as actora_identity_exists, actora_identity_metadata, actora_identity_list, and actora_identity_list_all, which appear to cover overlapping ground. An agent reading all four descriptions would have to guess which to call.

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 prerequisite (e.g., the agent must be registered), and no mention of the alternative tools that would be preferred for a pure existence check or a metadata-only read. Usage must be inferred entirely from the name and the one-line gloss.

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 supplied, so the description carries the full behavioral burden, and it discloses very little. It implies a read-only listing but says nothing about pagination, result ordering, what an empty wallet returns, or whether the wallet must be a registered identity; only the chain support is recoverable, and that is already in 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?

One front-loaded sentence with no padding; verb, resource and scope arrive in the first few words. It is efficient, though the brevity leaves no room for the routing hints a list tool in a large sibling group benefits from.

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 a fully documented schema and no output schema, the description is minimally sufficient: the agent knows what is returned (Agent IDs) in broad terms. Missing are return-shape detail, empty-result behavior, and differentiation from actora_identity_list_all, which the tool's complexity level would reasonably accommodate.

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%, including an enum for chain with a stated default and a note that Sepolia is unsupported, so the schema already does the parameter work. The description adds only that ownerAddress identifies a wallet whose agents are returned and lists the three chains, both of which restate structured fields.

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 (Agent IDs), plus the scoping dimension (owned by a wallet address) and the supported chains. An agent can distinguish it from actora_identity_get or actora_identity_exists, though it never names the closest sibling actora_identity_list_all, so the differentiation is inferred 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 when-to-use or when-not-to-use guidance and no mention of alternatives such as actora_identity_list_all or actora_identity_get. The agent must infer from the name and the required ownerAddress that this is the per-wallet lookup, which is a thinner signal than the sibling set warrants.

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 carries the behavioral burden. It implies a read-only listing and names returned fields, but it omits pagination or result-size behavior, rate limits, authentication needs, and other operational constraints that matter for a 'list all' operation.

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, front-loaded with the core purpose and followed by filter support. There is no redundant or wasted wording.

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

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

The description identifies the returned metadata fields and summarizes the filters, which is adequate for a tool with full schema coverage. But with no annotations and no output schema, it should clarify scale/pagination behavior and explicitly differentiate this from the sibling identity list 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 100%, and the schema already documents each parameter, including defaults and the chain enum. The description only summarizes the filters and notes SDK equivalence, so it adds little parameter meaning 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?

The description states a specific verb and resource: it lists agents and names the returned metadata fields. It does not explicitly distinguish this from the sibling actora_identity_list, so the 'list_all' scope has to be inferred from the name rather than stated contrast.

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 names the supported filters (ID range, active-only, capability), which gives useful usage context. However, it does not say when to choose this over actora_identity_list or actora_identity_get, nor does it state any exclusions or 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?

No annotations are supplied, so the description carries the full behavioral burden. It identifies the operation as a getter and lists returned fields, but it does not disclose error behavior, authentication requirements, rate limits, or what happens when the agent does not exist.

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 wording. It efficiently states the operation, scope, and returned fields.

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

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

For a simple two-parameter getter with full schema coverage, the description is largely complete and usefully enumerates return fields in the absence of an output schema. It could be stronger by clarifying how it differs from sibling identity tools and by noting error behavior.

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 input schema already documents agentId and chain, including the chain enum and default. The description adds no parameter-level meaning beyond what the schema provides, making the baseline score of 3 appropriate.

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

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

The description states a specific verb and resource: "Get structured metadata for one agent," and enumerates the returned fields. It is clear what the tool does, but it does not distinguish itself from sibling tools such as actora_identity_get or actora_identity_list.

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

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

The phrase "for one agent" implies single-agent retrieval, but there is no explicit guidance on when to use this tool versus actora_identity_get, actora_identity_list, or actora_identity_exists. No prerequisites, exclusions, or alternative-selection criteria are provided.

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

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

With no annotations, the description carries the full burden. It does add a genuinely useful behavioral fact — that this is a WRITE operation returning a tx payload rather than executing the registration itself — which tells the agent a signing/broadcast step follows. However, it omits permissions, gas/cost implications, idempotency, and failure behavior for an on-chain 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 short, front-loaded sentences with zero filler; the write semantics are surfaced immediately. It is arguably over-terse for a crypto registration flow, but every sentence present earns its place.

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

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

For a four-parameter on-chain write with no annotations and no output schema, the description is too thin: it does not explain what the returned tx payload is for, what the caller must do with it, or what preconditions (encrypted payload already pinned) the required parameters imply. The complexity of the tool outpaces the disclosure.

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%, including a default value and an enum note for chain, so the schema already documents all four parameters well. The description adds nothing beyond the schema about tokenURI, encryptedPayloadCid or eciesEncryptedKey, which is acceptable but not illuminating — notably it never hints at the ordering dependency between payload upload and this 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?

A specific verb-plus-resource statement ('Register a new Agent on-chain') that clearly separates this from read-oriented siblings like actora_identity_get, actora_identity_list and actora_identity_exists. It does not name a sibling alternative explicitly, but the operation 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?

The description gives no when-to-use guidance, no prerequisite ordering (e.g. that the encrypted payload must already exist on IPFS), and no indication of when an agent should call this versus actora_central_agent_create. Usage must be inferred entirely from the tool name and the required parameter names.

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 supplied, so the description carries the full disclosure burden, and it does almost nothing: it does not say whether the count is chain-scoped, aggregate across all chains, or what the return shape is (a bare integer vs. an object). Given that the only parameter is a chain selector, the omission of any statement about scoping is a real 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?

It is a single short, front-loaded sentence with no filler. It is efficient but borders on under-specification rather than being genuinely well-structured.

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?

This is a low-complexity, zero-required-parameter tool, so not much is needed, but with no output schema the description should at least state that the result is a numeric count and whether the chain parameter scopes it. Those two omissions are the only things keeping it from feeling 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 100% and the single 'chain' parameter is fully documented with enum values and a default in the schema itself. The description adds no meaning beyond that, so the baseline of 3 applies.

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

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

The description names a specific quantity ('total number of agents registered'), which is clearly a count operation over the identity/agent resource. It does not, however, differentiate itself from siblings like actora_identity_list_all or actora_identity_list, so an agent must infer that this returns a scalar rather than a collection.

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 count versus listing agents (actora_identity_list, actora_identity_list_all) or checking existence (actora_identity_exists). The agent is left to guess the intended call site 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.

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 that this is a WRITE operation and that endpoints are marked 'delisted' rather than destroyed, which usefully implies a soft state change. It says nothing about reversibility, what happens if the listing does not exist or the caller is not the owner, or what the call returns.

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, front-loaded sentences with no filler; the operation and its effect lead, and the auth requirement and WRITE flag follow. The trailing 'WRITE operation' partly repeats what 'Remove' already implies, which keeps it from 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 3-parameter mutation tool with no annotations and no output schema, the description covers purpose, side effect, and auth, which is the core an agent needs. It is still thin on failure modes and response behavior, which matters for a destructive-style operation.

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

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

Schema description coverage is 100%, so the schema already documents chain, agentId, and access_token, making 3 the baseline. The description only reinforces the access_token parameter by clarifying it must be an owner JWT, adding marginal meaning beyond the schema's 'Gateway JWT — owner auth (required)'.

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 ('Remove a listing (delist)') plus the side effect on endpoints ('mark its endpoints as delisted'), which separates it from actora_listing_set and actora_listing_get. It never names those siblings explicitly, so the 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?

The description supplies a precondition ('Requires access_token (owner JWT)') that effectively gates usage to listing owners, but it gives no explicit when-to-use versus when-not-to-use guidance and does not point to any alternative tool such as actora_listing_set for modifying rather than removing a listing.

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

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

With no annotations supplied, the description carries the full behavioral burden, and 'Public read' usefully discloses that no auth or subscription is required and that the call has no side effects. It does not cover failure behavior (unlisted agent) or rate limits, but the key safety profile is stated explicitly.

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 capability front-loaded and the access/scope caveat second. Every clause earns its place.

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

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

For a simple two-parameter read tool with no output schema, the description compensates well by naming the fields returned in the listing object. It is not exhaustive about the response shape or empty-listing behavior, but an agent has enough 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 100%, so both the 'chain' enum (including 'central') and the agentId integer are already documented in the schema. The description's note about negative agentIds for centralized agents reinforces but does not meaningfully extend the schema, matching the baseline of 3.

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

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

The description opens with a specific verb+resource ('Get the marketplace listing for an agent') and enumerates the returned attributes (visibility, pricing type, USD price, payment link), so the agent knows exactly what it retrieves. It does not explicitly contrast with siblings like actora_listing_set, actora_listing_delist, or actora_listing_price, so it falls short of full sibling differentiation.

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

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

'Public read — works for on-chain agents and centralized (negative) agentIds' implies the read-only inspection use case, and the mention of negative agentIds signals applicability to off-chain agents. However, it never states when to prefer this over actora_listing_price or actora_listing_set, nor what happens if no listing exists, leaving usage largely inferred.

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 disclose the two most important traits — this is a WRITE operation and it requires owner-level JWT auth. It is silent on reversibility, what happens to existing subscribers/plans when the model changes, and whether omitting pricingType clears or preserves current pricing.

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 that front-loads the action and resource, with the pricing modes parenthesized and the auth requirement appended. Nothing is padded, though the trailing "WRITE operation" fragment is slightly telegraphic rather than fully integrated.

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?

This is a five-parameter mutation with no nested objects and no output schema, and the schema fully documents every parameter. Given that, the description supplies what the structured data cannot: the write nature and the owner-JWT requirement. Remaining gaps (side effects on existing subscribers) are nice-to-have rather than blocking for correct invocation.

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

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

Schema description coverage is 100%, so every parameter is already documented, including the enum meanings and the conditional requirement on priceUsdCents. The description only restates the pricing model and cents unit, adding no format, unit-boundary, or conditional-omission detail 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?

The description states a specific verb and resource ("Update pricing for an existing listing") and enumerates the three pricing models plus the currency unit. It implicitly separates itself from actora_listing_set by scoping to an *existing* listing, but never names the sibling or states the boundary 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: "existing listing" suggests this is a re-pricing tool rather than a creation tool, and "Requires access_token (owner JWT)" signals an owner-only precondition. There is no explicit when-to-use/when-not guidance and no named alternative such as actora_listing_set or actora_listing_delist.

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 deliver the essentials: it is a WRITE operation, requires owner auth, and triggers a liveness probe against the registered endpoint. It stops short of stating whether an existing listing is overwritten, what happens if the probe fails, or whether the call is idempotent — meaningful gaps for a mutation that also performs network verification.

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 compact sentences, front-loaded with the action and the required auth, with the 'one call' framing making the compound behavior obvious. The dense parentheticals ('visibility / pricing / payment link') trade a little readability for brevity 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?

For a 10-parameter write tool with no annotations and no output schema, the description covers the critical calling context: auth, the central-vs-hosted branch, and the probe side effect. What an agent would still want — return shape or what a probe failure implies — is secondary but not fully addressed.

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 all ten parameters are already documented, including the endpoint-omission and negative-agentId conventions. The description restates those two rules but adds no new semantics for pricing, payment link, protocol default or tags, so 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 pair (publish/update) and resource (listing) plus the endpoint registration side effect, which cleanly separates it from actora_listing_get, actora_listing_delist and actora_listing_price. It does not name any sibling explicitly, so differentiation is inferred from scope 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?

Gives a concrete precondition (owner JWT access_token required) and a decision rule for the centralized-agent case (omit endpoint, negative agentId). It never says when to prefer this over actora_central_agent_update or actora_listing_price, so an agent must infer the boundary from the field list.

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

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

With no annotations, the description carries the burden and does well: it discloses the owner-auth requirement, the ownership scoping of results, and that private key material is never returned, while explicitly closing off export/decrypt capabilities. Gaps remain around pagination, ordering, and whether revoked keys are included, which matter for a list endpoint.

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 operation and scope, followed by the auth requirement and the negative capability. 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 3-parameter read tool with no output schema, the description compensates by naming the returned fields and the auth requirement, so an agent knows what it gets back. It would be complete with a note on result volume/pagination or whether filtering by chain returns multiple records.

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 each parameter is already documented (chain as 'Optional chain filter', agentId, access_token JWT), so the description adds no parameter-level meaning. Listing 'chain' among returned fields could even be momentarily confused with the chain filter 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 (list) plus resource (payload-key records) and even enumerates what each record contains (public key, mode, chain, export count). The explicit 'never the private key' clause separates it from any key-export operation, and no sibling tool covers payload keys.

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?

Establishes the precondition clearly ('for an agent you own', 'Requires access_token') and rules out a related path by noting that exporting/decrypting keys is not exposed over MCP. It stops short of an explicit when-to-use-vs-alternative statement, though no sibling tool competes for this job.

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 supplied, so the description carries the full behavioral burden and discharges almost none of it. It does not state that this is a read-only lookup, what is returned when an agent has no reviews, or whether the aggregate is cached or chain-specific, even though a chain parameter exists.

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 short fragment is certainly brief, but its brevity is under-specification rather than economy. There is no front-loaded verb or scope statement to orient the agent.

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

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

For a simple two-parameter lookup with no output schema, the description should at least say the aggregate is returned for a given agent and what happens when no reviews exist. As written it leaves return semantics and edge cases 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%: agentId is documented and the chain enum spells out its default and the Sepolia exclusion. The description adds no parameter meaning at all, so the baseline of 3 applies.

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

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

The description is a noun fragment ('Average rating and review count') with no verb and no reference to the agent whose reputation is fetched. It gestures at the returned data but does not distinguish this tool from close siblings like actora_reputation_reviews or actora_reputation_rate.

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 mention of prerequisites, and no indication of how this differs from the review-listing or rating-submission siblings. An agent must infer the selection rule 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.

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 does flag that this is a mutation ('WRITE operation'), but discloses nothing about authorization requirements, whether the write is on-chain and costs gas, whether ratings are immutable, or what happens on failure.

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 fragments, front-loaded and free of padding. The terseness is efficient rather than padded, though the telegraphic style verges on under-specification rather than crispness.

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 write tool with no annotations and no output schema, the description leaves too much open: nothing about the effect of the write, gas/transaction behavior, or what the caller gets back. The schema covers the inputs, but the behavioral picture is largely 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%, including a chain enum with default and a note that Sepolia is unsupported, so the schema does the heavy lifting. The description's '(1-5)' merely restates the rating parameter and adds no meaning about agentId, chain, or the optional comment.

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 (rate an agent) plus the valid range, which is enough to distinguish it from read-side siblings like actora_reputation_get and actora_reputation_reviews. It stops short of naming those siblings 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 '(1-5)' and 'WRITE operation' hints imply this is for submitting a new rating rather than reading them, but there is no explicit when-to-use guidance, no prerequisites (e.g. must the agent already be registered?), and no mention of whether re-rating an agent is allowed or overwrites a prior rating.

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 supplied, so the description carries the burden. It does disclose the returned fields, which is useful because there is no output schema, but it does not state read-only behavior, pagination, sorting, or what happens when no reviews exist.

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 fragment with no filler. Its concision is good, though the fragment is under-specified rather than structurally poor.

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 two-parameter tool with full schema coverage, listing the returned fields covers the core return behavior. It is still incomplete because it does not explain use versus sibling reputation tools or mention pagination/chain-default behavior.

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 agentId and chain are already documented. The description adds no parameter meaning beyond the schema, making the baseline 3 appropriate.

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

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

The description identifies the resource as reviews and enumerates returned fields (reviewer, rating, comment, timestamp), so an agent can tell it retrieves reviews for the given agentId. It lacks an explicit verb and does not distinguish this list-style tool from siblings such as actora_reputation_get or actora_reputation_rate.

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 alternatives, and no exclusions. The agent must infer from the tool name and required agentId that this is a read/list operation.

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 supplied, so the description carries the full behavioral burden. Flagging it as a WRITE operation is a useful hint, but it omits critical traits for a destructive action: whether cancellation is irreversible, whether prorated fees are refunded, permission requirements, and what the caller sees afterwards.

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, front-loaded with the action and no filler. The brevity is efficient, though the second sentence is a fragment that could have carried more useful content at negligible cost.

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, likely irreversible financial operation with no annotations and no output schema, the definition is thin. It should say what cancellation destroys, whether it is reversible, and how it relates to actora_subscription_release before an agent commits.

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%, including an enum for chain with default and testnet exclusion, so the schema already explains both parameters. The description adds no meaning beyond that, which is the expected 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 verb and resource ("Cancel a subscription"), so the action is unambiguous. It does not distinguish this from nearby siblings such as actora_subscription_release, leaving the agent to guess which cancellation path applies.

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 actora_subscription_release or actora_subscription_detail/check. The only supplementary statement, "WRITE operation," signals mutation but does not tell the agent under what preconditions cancelling is appropriate.

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, "Check" is the only indication that this is a non-mutating read operation. The description does not clarify whether the result is a boolean or richer status object, how inactive or nonexistent subscriptions are reported, or any authentication and failure 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?

A single short, front-loaded sentence states the operation and its two key scopes without filler. Its brevity is appropriate; the missing sibling distinction is a completeness issue rather than a structural one.

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 fully documented input schema makes the three arguments straightforward to supply, and the operation itself is simple. However, with no output schema or annotations, the result contract and read behavior remain implicit, while the central-versus-noncentral subscription-check distinction is unresolved.

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%, including the chain enum, default, and Sepolia exclusion, so the baseline score applies. The description's references to a wallet and agent add no syntax, format, or chain-selection detail beyond the documented subscriberAddress, agentId, and chain parameters.

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

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

The description specifies the operation ("Check"), resource ("active subscription"), and scope (a wallet for an agent), making the basic function clear. It does not distinguish this tool from actora_central_subscription_check or related subscription-detail tools.

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

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

The wording implies a point-in-time subscription-status lookup, providing minimal usage context. There is no explicit when-to-use or when-not-to-use guidance, prerequisite, or alternative, particularly for choosing between this tool and actora_central_subscription_check or actora_subscription_detail.

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 carries the full burden. It does add one genuinely useful behavioral signal beyond the schema, the explicit "WRITE operation" label, but it omits the material facts for an on-chain mutation: gas/wallet requirements, whether the call is irreversible, what permissions are needed, and whether a transaction hash or plan ID 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?

Two compact sentences with the operation type front-loaded, and zero filler. It is dense to the point of feeling telegraphic, but nothing is wasted and the key facts come first.

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 11-parameter write tool with no output schema, the description is missing only a few things an agent would want.

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

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

Schema description coverage is 100%, so the schema already documents all 11 properties, including the period enum and planType mapping. The description merely restates the period values and the 0/1/2 planType meanings, adding no conditional logic (e.g., when price vs usagePrice is mandatory) beyond what the schema already 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?

States a specific verb and resource: "Create a subscription plan for an agent." That is unambiguous and separable from read-side siblings like actora_subscription_plans or actora_subscription_check, though no sibling is named explicitly as a contrast.

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 implied by the verb: an agent would call this when it wants a new plan before subscribing. There is no explicit when-to-use / when-not-to-use guidance, no mention of the prerequisite (an existing agentId/identity), and no routing to related tools such as actora_subscription_subscribe or actora_subscription_cancel.

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 mentions that trial info and escrow status are included, but it does not state that the operation is read-only, what permissions are required, whether any side effects occur, or what the full 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?

The description is a single front-loaded sentence with no unnecessary wording. It efficiently states the resource and the notable included fields.

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 two-parameter retrieval tool, the description is minimally adequate. However, with no output schema and no annotations, it should do more to explain the return shape and usage context beyond naming trial info and escrow status.

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 input schema already documents both parameters, including the chain enum and default. The description adds no additional parameter meaning beyond what the schema provides, making the baseline score appropriate.

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

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

The description identifies a specific resource, subscription detail, and names included content such as trial info and escrow status. It is clear what the tool retrieves, but it does not explicitly differentiate itself from sibling subscription tools like actora_subscription_check or actora_subscription_my_list.

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

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

There is no guidance on when to use this tool versus alternatives such as actora_subscription_check, actora_subscription_my_list, or actora_subscription_plans. The intended retrieval context is only implied by the word 'detail'.

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 supplied, so the description carries the full disclosure burden, and it says nothing about whether this is a read-only lookup, whether the fee is global or chain-dependent, whether it requires authentication, or how often it changes. The only behavioral hint, the unit in bps, comes from the same sentence that defines the purpose.

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 efficient, though its brevity edges into under-specification for a tool with multiple fee-related siblings.

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 read tool with no output schema and no annotations, the core meaning (fee, in bps, per chain) is conveyed. Still missing is whether the fee is per-chain variable, whether the result is a single number or a structure, and any auth or rate-limit expectations.

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 chain parameter is fully documented with enum values, a stated default ("bsc"), and a Sepolia exclusion. The description adds no additional meaning about how the chain affects the returned fee, so the schema does all the work.

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 verb and resource ("Get current platform fee") and states the unit (bps), which is concrete enough to know what comes back. It does not differentiate from sibling pricing/status tools such as actora_listing_price, actora_central_subscription_check, or actora_subscription_plans, so an agent must infer which fee source this one reports.

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 the many subscription-related siblings (actora_subscription_check, actora_subscription_detail, actora_central_subscription_check). There are no prerequisites or exclusions stated beyond the schema's own note that Sepolia is unsupported.

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 behavioral burden. It usefully discloses that the result is a list of subscription IDs rather than full subscription details, but it does not state that the operation is read-only, whether results include inactive subscriptions, or anything about pagination or authorization.

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 redundant or filler language. Every word contributes directly to the stated purpose.

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

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

For a simple two-parameter read tool with full schema coverage, the description is minimally adequate. However, it does not explain how this differs from related subscription tools or clarify what 'all' means in terms of active/inactive subscriptions.

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 both parameters are already documented, including the chain enum and its default. The description adds only that the listing is wallet-scoped, which is already conveyed by the required userAddress parameter.

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

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

The description states a specific verb and resource: list subscription IDs for a wallet. It does not explicitly distinguish itself from siblings such as actora_subscription_detail, actora_subscription_check, or actora_central_subscription_check, so the agent must infer that this returns only IDs rather than detailed subscription state.

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

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

There is no explicit guidance on when to use this tool instead of subscription_detail, subscription_check, or central_subscription_check. The wallet-scoped listing is implied, but no alternatives or exclusions are named.

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

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

With no annotations supplied, the description carries the full behavioral burden and mostly fails it. 'Get' implies a read, but nothing states that the call is non-mutating, what happens for an unknown planId, or that the chain parameter defaults to bsc. It also omits any note about response shape beyond four field names.

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 that front-loads the purpose and lists the returned fields without filler. It is tight, though arguably too terse given the absence of annotations and output 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?

The description does cover the return fields, which matters since there is no output schema, but it leaves out chain-specific behavior, error cases, and sibling differentiation. For a simple two-parameter read tool this is adequate 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 100%, so both parameters and the chain enum with its default are fully documented in the schema. The description adds nothing beyond that for parameters, so the baseline of 3 applies.

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

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

The description uses a clear verb+resource ('Get plan details') and enumerates the returned fields, so an agent knows exactly what data it retrieves. It does not distinguish this from similarly named siblings such as actora_subscription_detail, leaving ambiguity about which tool surfaces plan metadata versus live subscription state.

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

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

There is no guidance on when to call this rather than actora_subscription_detail, actora_subscription_check, or actora_subscription_fee. Nothing tells the agent that this is the lookup to use before creating or subscribing to a plan, nor any prerequisite about knowing a valid planId.

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 supplied, the description carries the behavioral burden, and it does disclose the single most important trait: the tool is deprecated because the underlying manager settles payments at subscribe/renew time. It omits whether the call errors, returns empty, or silently succeeds — the practical behavior an agent needs before invoking.

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 beginning with 'Deprecated' — the most decision-relevant token comes first, and every clause earns its place by explaining the deprecation rationale. Nothing is padded or redundant.

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 deprecated two-parameter tool with full schema coverage and no output schema, the description covers the crucial 'why not to use it' but leaves two gaps an agent would want closed: what to use instead, and what a call actually returns or raises. Adequate but not fully self-sufficient.

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

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

Schema description coverage is 100%: subscriptionId and the chain enum (bsc/ethereum/base, Sepolia unsupported) are fully documented in the schema. The description adds no parameter-level meaning, which is acceptable at this coverage level but leaves it at baseline.

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

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

The description tells the agent the tool is deprecated and explains why (the ERC8004SubscriptionManager settles on subscribe/renew, so no escrow exists), which implies the tool's nominal job is releasing subscription escrow. However, it never states positively what the tool does or did — the verb 'release' only appears in the resource name and in the negation 'no escrow to release' — so the operation itself is inferred rather than described.

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 deprecation notice strongly implies 'do not call this,' which is the essential usage guidance. It stops short of naming a replacement or sibling (e.g., actora_subscription_cancel or actora_subscription_detail) or saying whether invocation still succeeds as a no-op versus reverting, leaving the agent to guess the next step.

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 carries the full behavioral disclosure burden. "WRITE operation" signals mutation, but the description does not explain cost/payment behavior, authorization requirements, what happens to an existing subscription, or side effects.

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

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

Two short sentences with no wasted wording; the write-operation warning is useful and front-loaded. It is terse, but that terseness is the source of other gaps rather than verbosity here.

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 payment-related parameters, no annotations, and no output schema, the description is too sparse. It omits payment semantics, authorization context, approval/confirmation expectations, and how to choose among related subscription tools.

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%, and the schema documents chain, planId, and valueWei including the chain enum and default. The description adds no additional parameter meaning beyond the structured 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 and resource: "Subscribe to a plan." It is clear what the tool does, but it does not distinguish itself from nearby siblings such as actora_central_subscription_subscribe or actora_subscription_create_plan.

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 guidance on when to use this subscription tool versus alternatives, no prerequisites, and no mention of checking existing subscriptions or retrieving available plans first.

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. "List" implies a non-mutating read and the token constraint discloses an auth prerequisite, but it says nothing about pagination, whether the catalog is a fixed enumeration or tenant-specific, or error behavior for unregistered tokens.

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 compact sentences with no filler, and the purpose is front-loaded ahead of the auth requirement. Slightly dense parenthetical enumeration 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?

For a one-parameter read tool with no output schema, the description covers what the tool returns and the auth requirement, which is close to sufficient. The remaining gap, the exact shape of each plan record, is minor and partially addressed by the enumerated fields.

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

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

Schema coverage is 100% and the schema already labels access_token as a required Gateway JWT. The description adds only that it must be a registered-user token, a marginal clarification; baseline 3 applies when the schema does the heavy lifting.

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 a well-scoped resource ("platform plans for B-side tenants"), and enumerates the plan attributes returned (quota, rate limit, concurrency, BYOK). The scope distinguishes it from actora_tenant_usage, but the description never names that sibling, so differentiation is left implicit.

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 a prerequisite ("Requires access_token (registered-user JWT)") which implies the caller must be a registered user, but offers no explicit when-to-use guidance, no when-not-to-use, and no pointer to actora_tenant_usage for consumption data rather than plan metadata.

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 behavioral burden. It does disclose the auth requirement ('registered-user JWT') and what the payload contains (summary plus daily timeline), which is real added context. It omits read-only guarantees, rate limiting, and any pagination or granularity caveats.

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 payload description is front-loaded ahead of the auth prerequisite. 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 read tool this is close to adequate, but with no output schema the description should say more about the shape of the 'summary' and 'daily timeline' (granularity, per-day fields). The auth prerequisite is covered, so the remaining gap is return-value detail.

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

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

Schema coverage is 100%, with 'days' fully documented (1..365, default 30), so the baseline is 3. The description adds a nuance by calling the token a 'registered-user JWT', though that slightly diverges from the schema's 'Gateway JWT' wording without explaining the difference.

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 and scope: 'Token/tool-call usage summary and daily timeline for the current tenant'. The verb is implicit (retrieve/report) but the resource is unambiguous and distinguishable from siblings like actora_tenant_plans. It does not explicitly name 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?

Usage is only implied: 'for the current tenant' establishes scope, and the resource name suggests you call it to inspect consumption. There is no explicit when-to-use, no when-not-to-use, and no alternative named (e.g. actora_tenant_plans for plan/quota details).

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