Geode

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

Annotations only say non-read-only and non-destructive; the description adds the crucial flow: signature must be generated offline by geode-local-signer and the call is gated per Terms version. It doesn't say what the tool returns on success or what happens if the version already matches, so not 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 tight sentences: the precondition/gating rule first, the signing dependency second. Nothing 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 3-param write tool with full schema docs and annotations, the description covers the essential workflow (offline signing, per-version gating). Minor gap: no mention of success/failure behavior or what to do if the terms version has changed.

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%; each field is documented identically in the schema (SS58 signer address, signature from the signer, ISO 8601 signed timestamp). The description restates the same information rather than adding format or edge-case detail, so baseline 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?

States a specific action — recording a signed Terms-of-Use acceptance — with the exact precondition (once per Terms version, before first write) and the tool that produces the signature. Unambiguously distinct from every sibling tool in the 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?

Gives a clear triggering condition ('required once per Terms version, before your first write') and names the prerequisite tool geode-local-signer accept_terms. No explicit exclusions or alternative paths are stated, so it stops short of a 5.

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

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

The description leads with 'Read-only', reinforcing annotations and telling the agent the call is safe. It adds that it reports the existential deposit and nonce, which goes beyond generic readOnly/destructive hints. It does not cover failure behavior for nonexistent addresses beyond 'whether an address 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?

One sentence, front-loaded with the read-only safety marker, then a compact enumeration of return fields. No wasted words.

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

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

For a simple single-parameter read tool with no output schema, the description lists the key return values, which is the main missing piece. It does not explain how a nonexistent address is represented, a minor 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?

There is only one parameter, and the schema fully documents it (SS58 address). The description adds no format or validation details beyond the schema, 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 resource (an address's on-chain state) and enumerates exactly what is returned: existence, free/reserved/frozen balance, existential deposit, nonce. No sibling tool overlaps this purpose.

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

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

The description implies usage (reading account state) but does not state when to use this versus related tools like geode_profile_get_account_profile or geode_messaging_get_account_settings_data, nor any prerequisites. Usage is inferable but not explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered and the bar is lower. The description nonetheless adds substantive context by disclosing the composite return payload (ToU acceptance state, spending caps, pending intents), which matters because there is no output schema. It omits auth requirements, but for a read-only status call that is a minor 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 tight sentence that front-loads the read-only nature and then lists the three returned components. The 'Read-only:' prefix slightly duplicates the readOnlyHint annotation, but the sentence is otherwise waste-free.

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

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

With no output schema, the description must carry the return-value burden, and it does enumerate the three payload categories an agent needs to know. It stops short of describing format or detail level of those categories, which is a modest gap for a composite status 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?

There is a single parameter with 100% schema description coverage ('Account address (SS58)'), so the schema fully documents it. The description adds no additional meaning about the address argument, 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?

The description names a specific resource (agent status) and enumerates its components: Terms of Use acceptance, spending caps, and pending intents. This is far more informative than the bare title 'Agent status'. It does not, however, differentiate itself from the adjacent geode_account_info or geode_get_intent siblings, leaving the boundary 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?

The description states what is returned but gives no when-to-use guidance, no prerequisites, and no alternatives. It never mentions geode_accept_terms (the write counterpart for the Terms of Use it reports on) or geode_get_intent (which retrieves a single intent), so the agent must guess which of these to call.

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

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

Annotations already flag destructive/openWorld/not-readOnly, but the description adds substantially more: irreversible, keep-alive so the account can never be emptied below minimum balance, two-phase confirmation with a confirm_token, account creation on send to a new address, and rate-cap exposure.

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?

Purpose is front-loaded and every clause carries operational meaning; there is little filler. The single dense paragraph packs the two-step flow, signing step, and caps into one wall of text, which slightly hurts scanability.

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

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

With no output schema, the description correctly explains what the first call returns (confirm_token and real cost) and what to do next, plus constraints. It does not cover confirm_token expiry or mismatch behavior, which matters for an irreversible transfer, but the core flow is adequately documented.

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 signer, dest, amount, and confirm_token; the description adds lifecycle context for confirm_token (returned by first call, reused on second). However, it introduces '`expect`' — a field of geode-local-signer, not of this tool's schema — which could mislead an agent into passing an unsupported 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 precise verb+resource: 'Send GEODE from `signer` to another account', and immediately qualifies it with keep-alive semantics. It is clearly distinguishable from siblings such as geode_submit_intent, which it names as the final step rather than a competitor.

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?

Lays out the exact operating procedure: first call returns confirm_token and real cost, second call retrieves the intent, sign with geode-local-signer, then submit with geode_submit_intent. It also states the new-address minimum (1 GEODE) and that this counts toward per-transaction and 24-hour caps.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds genuinely new context by stating no signature is required and that results can be caller-dependent. It does not describe failure behavior for unresolvable names or the return shape, keeping it short of 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?

Front-loaded with the purpose, then two short supporting clauses — no wasted sentences. The 'Read-only' fragment mildly duplicates readOnlyHint, though 'no signature' keeps the clause from being purely 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 2-parameter, fully documented read tool with no output schema, the description covers what it returns at a high level ('the account address') and the meaning of both parameters. Missing only edge behavior, such as what happens when the name is unregistered.

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, and the description earns an extra point by explaining the *purpose* of `caller` ('the account whose view to read (for caller-dependent results)'), which goes beyond the schema's terse 'optional account address (SS58) to run the query as'. `name` is left to the schema, which documents it well.

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: 'Look up the account address a Geode DNS name points to.' This is distinct from the sibling geode_dns_get_owner (which returns an owner) and geode_dns_set_address (a write), though neither sibling is named explicitly, so the agent must infer the routing from the name.

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 — use this to resolve a name to the address it points to — but there is no explicit when-to-use, when-not-to-use, or pointer to the nearest alternative (geode_dns_get_owner vs geode_dns_set_address). The caller hint gives partial context for when to pass a caller, but not when to pick this tool over a sibling.

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

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

Annotations already declare readOnlyHint and destructiveHint=false, so 'Read-only' is partly redundant. However, 'no signature' discloses the authentication/signing requirement and the caller clause notes that results may be caller-dependent, adding behavioral context beyond the annotations.

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

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

Two short sentences, front-loaded with the core purpose, with the read-only caveat and the caller explanation following. No filler or repetition.

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

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

For a single-parameter lookup with no output schema, the description conveys what is returned (the owning account) and the caller semantics. It stops short of describing the return shape or the not-found case, but nothing critical for calling it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a conceptual detail for `caller` not present in the schema ('the account whose view to read (for caller-dependent results)'), clarifying why the optional parameter changes output.

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 (look up) and resource (the account that owns a Geode DNS name), which is clearly distinguishable in meaning from sibling geode_dns_get_address. It does not explicitly name a sibling to route against, but the 'owner' framing is specific enough that an agent can tell what it returns.

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 some context ('Read-only; no signature') but never states when to use this versus geode_dns_get_address or the mutation siblings (register/set_address/transfer). Usage is only implied by the read-only lookup 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?

Beyond the annotations (which only flag readOnly=false, destructive=false, openWorld=true), the description discloses the critical two-phase behavior: it writes an unsigned transaction and 'nothing happens until you sign it.' This is exactly the kind of non-obvious behavioral trait the annotations cannot convey.

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

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

Two sentences, zero waste, with the core action front-loaded and the deferred-signing caveat immediately after. 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 mutation tool with no output schema, the description adequately explains the two-step intent flow and the external signing requirement. It could note what the returned intent looks like or any name-uniqueness/ownership prerequisites, but the essential invocation path is 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 both parameters (name, signer) are already fully documented in the schema. The description restates that the transaction is prepared for `signer` but adds no format or constraint detail beyond what the schema provides, 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 ('Register a Geode DNS name') bound to `signer`, which is more precise than the title alone. It does not explicitly differentiate from DNS siblings like geode_dns_set_address or geode_dns_transfer, so the agent must infer the distinction from the action verb.

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

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

The description gives clear workflow context: this prepares an intent that must then be signed with geode-local-signer and submitted via geode_submit_intent, explicitly naming the follow-up tool. It stops short of stating when-not to use it or how it differs from the other DNS mutation tools.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds substantial non-obvious behavior: it writes to the chain, produces only an unsigned intent, and has no effect until signed and submitted. It omits ownership/permission requirements and any error conditions, keeping it from a 5.

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

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

Two sentences with zero waste: the purpose is front-loaded, and the second sentence carries only the essential two-step intent workflow. 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 mutation tool with no output schema and full schema coverage, the description supplies the crucial intent/sign/submit lifecycle and the ownership precondition. It could note what the returned intent contains or error cases, but an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents signer, name, and new_address with SS58 format and byte constraints. The description implies the ownership precondition ("a DNS name you own") but adds no syntax or format detail beyond the schema, 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 and resource: "Point a DNS name you own at an account address." This clearly distinguishes a DNS-mapping mutation from read siblings like geode_dns_get_address and from geode_dns_register/geode_dns_transfer, though it doesn't explicitly name those alternatives.

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

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

Explains the operational context clearly: it prepares an unsigned intent that must be signed with geode-local-signer and submitted with geode_submit_intent. This tells the agent what to do next, but it does not explicitly state when to prefer this over geode_dns_register or geode_dns_transfer.

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?

Adds rich behavioral context beyond annotations: writes to the chain, prepares an unsigned intent, requires external signing, is irreversible, and details the two-call confirmation flow with confirm_token. Fully consistent with annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true).

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

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

Three sentences, front-loaded with purpose, then workflow, then irreversibility warning. Every sentence contributes essential information without waste.

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

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

Given a destructive, open-world mutation with no output schema, the description covers the full lifecycle: intent creation, external signing, submission, and the two-step confirmation. Nothing critical is missing for an agent to invoke it correctly.

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

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

Schema coverage is 100% and the schema descriptions for signer, name, new_owner, and confirm_token are already detailed. The description adds no significant meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

States a specific verb and resource: 'Transfer ownership of a DNS name you own to another account.' Clearly distinguishes from siblings like geode_dns_register and geode_dns_set_address.

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 the necessary workflow context: 'this prepares an unsigned transaction (an intent) for `signer`; nothing happens until you sign it with geode-local-signer and submit it with geode_submit_intent.' Also explains the two-step confirm_token process. Does not explicitly exclude alternatives, but the transfer action is unique among siblings.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint, openWorldHint), so the bar is lower. The description still adds useful context beyond them: 'no signature' discloses that no authentication is required, and it describes pagination behavior with offset/limit defaults.

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-loaded with the resource and scope before parameters and pagination. Every clause carries information; 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 paginated read-only list tool with annotations covering safety and a fully documented schema, this is nearly complete: it names returned fields, auth requirements, and pagination. It lacks any note on ordering or default filters, which keeps it short of a 5.

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; limit and offset are merely restated. However, the description adds real meaning for `caller` ('the account whose view to read (for caller-dependent results)') beyond the schema's terse 'account address to run the query as'.

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 (Browse) and resource (all public listings on the Geode coin exchange), and even enumerates the returned fields (offer coin, asking coin, price, payment method, inventory, location). The word 'public' and 'all' distinguishes it from the sibling geode_exchange_view_my_listings.

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 context is implied by 'all public listings' and 'read-only; no signature', but the description never names alternatives such as geode_exchange_view_my_listings or explains when an agent should choose this over them. No explicit when/when-not guidance is given.

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

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

Goes well beyond the annotations: it discloses that this writes to the chain but only as an unsigned transaction (intent) for `signer`, and that nothing takes effect until external signing and submission. This is critical behavior an agent could not infer from readOnlyHint=false / destructiveHint=false alone, and it also notes hide as an option.

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 zero waste: the first front-loads purpose and scope, the second delivers the essential intent/signing behavior. 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 mutation tool with no output schema, the description covers the key complexity (intent-based write flow) and the annotations cover the safety profile. Params are well covered by the schema. It is essentially complete, though it does not clarify that all eight params are mandatory.

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 88%, so the schema already documents nearly every parameter. The description only loosely maps its field list (price, method, inventory, location) to the params without adding format or constraint detail beyond the schema. Baseline 3 is appropriate 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 (edit) and resource (one of your exchange listings) and enumerates the editable fields (price, method, inventory, location) plus the hide option. The scope 'one of your' implicitly separates it from geode_exchange_new_listing, but no sibling is named 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?

It describes the two-step intent flow (sign with geode-local-signer, submit with geode_submit_intent), which is genuine usage context. However, it gives no explicit when-to-use-vs-alternative guidance relative to siblings like geode_exchange_new_listing or geode_exchange_view_my_listings.

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 annotations already declaring readOnlyHint=false and openWorldHint=true, the description adds substantial value by explaining the write model: it writes to the chain and produces an unsigned transaction (intent) that does nothing until signed and submitted. This intent/sign/submit flow is exactly the kind of behavioral detail annotations cannot convey.

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

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

Two sentences, front-loaded with purpose and then the critical transactional behavior, with no wasted words. 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 no-output-schema mutation tool, the description covers both the input intent and the resulting artifact (an unsigned transaction). The main omission is that it does not state what the returned intent looks like or how it is consumed by geode_submit_intent, but it is otherwise complete enough to call 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%, so the schema fully documents all eight parameters. The description only paraphrases the field set (offer coin, want coin, price, method, inventory, location) without adding format or constraint detail 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 states a specific verb (Create) and resource (a listing on the Geode private coin exchange) and enumerates the fields involved. This clearly distinguishes it from geode_exchange_edit_listing and geode_exchange_view_my_listings, though it never explicitly 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?

It explains the post-creation workflow (sign with geode-local-signer, then submit with geode_submit_intent), which is useful usage context, but gives no explicit when-to-use versus edit_listing or browse_all_listings. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'Read-only' repeats structured data. It does add one genuinely useful fact: 'no signature', telling the agent this is a free query rather than a signed transaction. No rate limits or return-shape context beyond that.

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, the primary action front-loaded, with no filler. The trailing 'for caller-dependent results' phrase is slightly cryptic but costs little space.

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 and annotations already covering the safety profile, the description covers purpose, safety, and the caller role. The only real gap is what happens when `caller` is omitted, which an agent must infer.

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 a single optional parameter, so the baseline is 3. The description restates that `caller` is 'the account whose view to read' but adds no format or default-value detail beyond the schema's 'Optional account address (SS58) to run the query as'.

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 (exchange listings) scoped to those created by `caller`, which cleanly separates it from the sibling geode_exchange_browse_all_listings. An agent can pick 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 implied by the 'my listings' scoping rather than stated; the description never names browse_all_listings as the alternative or says when to pass `caller` versus omitting it. The clause 'for caller-dependent results' hints at a default-caller behavior but does not spell out the condition.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real context beyond that: the lifecycle state machine (pending, submitting, done, failed) and the fact that a result only exists after submission, which tells the agent what to expect when polling.

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

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

One compact sentence with the read-only nature front-loaded and no wasted words, which is appropriate for a simple getter. It is efficient but minimal enough that it could absorb one clarifying clause without becoming bloated.

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

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

For a one-parameter read tool with full annotation coverage and no output schema, the description adequately covers what is returned (status, and result once submitted). The only real gap is that the intent_id parameter is left entirely unexplained.

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

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

The single parameter intent_id has 0% schema description coverage, so the description carries the burden, yet it says nothing about the format, origin, or where the id comes from. Only the parameter name itself supplies meaning.

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

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

States a specific verb (read) and resource (an intent) and enumerates the possible statuses (pending, submitting, done, failed), which defines the object precisely. It does not, however, draw an explicit line against the closely related sibling geode_submit_intent, so sibling differentiation is only implied by 'Read-only'.

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

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

'Once submitted, its result' implies the natural workflow of calling this after geode_submit_intent, which is useful implicit guidance. There is no explicit when-to-use statement, no exclusion, and no mention of geode_submit_intent or geode_agent_status as alternatives.

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

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

Annotations give readOnly=false, destructive=false and openWorld=true, but the description adds substantial non-obvious context: this only prepares an unsigned intent for `signer` and is a no-op until signed and submitted. That two-phase lifecycle is exactly the kind of information annotations cannot convey. It stops short of noting irreversibility/on-chain finality of an endorsement.

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, front-loaded with the action and immediately followed by the critical lifecycle constraint. 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?

With only two fully documented parameters, no output schema, and annotations covering the safety profile, the description supplies everything an agent needs: what it does and the sign/submit handoff that must follow. Nothing material is missing.

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

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

Schema description coverage is 100%, so both `signer` (SS58 address, signed locally) and `claim_id` (0x 32-byte hex) are already documented in the schema. The description references `signer` but adds no format or constraint detail beyond what the schema provides; 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+resource: 'Endorse another account's Life and Work claim.' The 'another account's' qualifier distinguishes it from the sibling make_claim_* tools, and it is clearly a distinct action from get_endorsers (which reads endorsement data).

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

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

Explicitly describes the required follow-up workflow: the intent must be signed with geode-local-signer and submitted with geode_submit_intent, otherwise 'nothing happens'. This is strong operational guidance. It lacks an explicit when-not/don't-use condition, so it falls just short of 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context beyond that: 'no signature' discloses the auth requirement and 'caller-dependent results' explains a behavioral nuance, though it omits return shape (no output schema) and rate/limit behavior beyond pagination.

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 purpose, and no filler. The pagination clause duplicates the schema's default/max text, which is minor redundancy but the only wasted content.

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

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

For a read-only list tool with full schema coverage and annotations, the description covers purpose, auth ('no signature'), the caller nuance, and pagination. No output schema exists, so it need not describe return values; only a brief note on result ordering/shape would add anything.

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

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

Schema coverage is 100%, so the baseline is 3. The description still adds meaning by explaining that `caller` is 'the account whose view to read (for caller-dependent results)', which is more informative than the schema's 'run the query as'; it does, however, merely repeat the offset/limit defaults already present in 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: 'List the accounts that endorsed a Life and Work claim.' The verb clearly separates it from the sibling write tool geode_lifeandwork_endorse_claim, and an agent can identify the operation 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?

It conveys the read-only nature and the caller-dependent case, which implies when to pass `caller`, but it never states when to use this tool versus alternatives or any exclusions. Usage is only implied, so a 3 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description goes beyond them by stating 'no signature', which is genuine auth/execution context: it tells the agent no signed transaction is required. It stops short of return-format or pagination detail.

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 clauses, front-loaded with the core action and with the caveat about signing placed immediately after. Nothing is redundant, though the final parenthetical is compressed enough to read as a fragment.

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

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

With no output schema, the description should carry more of the return contract; 'full details ... including its endorsers' is suggestive but does not say what fields come back or whether the result is paginated. For a simple 2-parameter read tool whose annotations already cover safety, this is adequate but leaves a clear 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 the baseline is 3, but the description adds real meaning for `caller` — 'the account whose view to read (for caller-dependent results)' explains why the parameter exists, beyond the schema's terse 'run the query as'. `claim_id` gets no added detail, but the schema already specifies 0x-prefixed 32-byte hex.

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 ('Get full details of one Life and Work claim') and names what is included ('including its endorsers'). It is clear and distinguishable from write siblings like make_claim_* or endorse_claim, though it does not explicitly disambiguate against the adjacent readers geode_lifeandwork_get_endorsers or geode_lifeandwork_get_resume.

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 never states when to choose this over geode_lifeandwork_get_endorsers or get_matching_claims, nor any prerequisites or exclusions. The only contextual hint is that `caller` yields 'caller-dependent results', which is parameter behavior, not usage routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered, but the description adds genuinely useful context beyond them: 'no signature' tells the agent this read needs no signing step, and it documents pagination behavior (default 50, max 200). It does not describe result ordering or format, so it stops short of 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?

Three compact sentences, front-loaded with the core action, then safety, then paging. Every sentence carries information, though the offset/limit details repeat what the schema already states.

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 search with no output schema, the description covers paging, the caller, and safety. The notable gap is claim_type: it is required, has no schema description and no enum, and the description never indicates what integer values are valid (e.g. the education/expertise/gooddeed categories implied by the make_claim siblings).

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

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

Schema coverage is high (86%), so the baseline is 3, but the description adds real meaning for `caller` ('the account whose view to read'), clarifying caller-dependent results beyond the schema's terse 'run the query as'. The offset/limit restatement duplicates the schema, and claim_type still has no value guidance.

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

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

States a specific verb and resource ('Search Life and Work claims') and narrows scope to one claim type matched by up to three keywords. That is clearly distinct from the make_claim_* siblings, though it does not explicitly name an alternative tool to reinforce the distinction.

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: search claims by keyword. There is no statement of when to prefer this over geode_lifeandwork_get_full_details or get_endorsers for a known claim, and no exclusions such as 'requires at least one keyword' beyond the schema's required fields.

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

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

Annotations already carry readOnlyHint=true and destructiveHint=false, so the safety profile is covered; 'Read-only; no signature' aligns with and reinforces that. The description adds genuinely new behavior: pagination with offset/limit defaults (50) and max (200), plus the caller-dependent view semantics.

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

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

Three tight sentences with content, read semantics, parameter nuance, and pagination front-loaded in that order. No filler; every sentence 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?

With no output schema, the description carries the return-value burden and does so by enumerating the claim categories and endorsements. Pagination and caller semantics are also covered, leaving little an agent needs that is missing.

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

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

Schema coverage is 100%, so all four parameters are already documented and the baseline is 3. The description restates pagination defaults and adds a nuance for `caller` ('account whose view to read'), but the schema already describes caller as 'run the query as', so the added meaning is marginal.

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 (resume) and enumerates the substantive content (expertise, work history, education, good deeds, intellectual property) with endorsements. This distinguishes it from siblings like get_full_details, get_endorsers, and get_matching_claims, which each return narrower slices.

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

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

The description implies read-only usage and explains the `caller` view ('for caller-dependent results'), but never states when to prefer this over siblings such as get_full_details or get_endorsers. No explicit when/when-not routing to alternatives.

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

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

Annotations declare readOnly=false, destructive=false, openWorld=true, and the description usefully adds the two-phase intent workflow (prepared, not committed until signed and submitted) plus who the transaction is prepared for. That is meaningful behavioral context beyond the structured hints, though it doesn't discuss failure modes or reversibility.

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

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

Two tight sentences, front-loaded with the action and followed by the commit semantics. No filler, and both sentences earn their place.

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

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

With no output schema, the description still tells the agent the full lifecycle (intent prepared, then sign and submit), which is what matters for a chain-writing tool. The only gap is the required-vs-optional mismatch on the URL parameter.

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 three parameters and the baseline is 3. The description adds no format details, and it actually mischaracterizes the link as 'optional' while url_link_to_see_more is listed as required in 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 ('Add an education claim to your Life and Work resume') and correctly scopes the content to description/keywords plus a link. It does not explicitly differentiate itself from the sibling make_claim_* variants (expertise, workhistory, gooddeed, intellectualproperty), relying on the name to carry that distinction.

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

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

Clearly describes the operating context: this only prepares an unsigned intent for `signer`, and nothing takes effect until signing with geode-local-signer and submitting with geode_submit_intent. It does not, however, say when to choose an education claim over another claim type.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), it discloses high-value behavioral facts: it writes to the chain, prepares an unsigned intent for `signer`, and nothing takes effect until signed with geode-local-signer and submitted via geode_submit_intent. This two-phase commit semantics is exactly the context an agent needs and is not derivable from the annotations or 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 sentences, front-loading what the tool does before the post-call workflow. Every sentence earns its place; only mild density in the second clause 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 chain-writing tool with no output schema, the description covers purpose, the signing/submission workflow, and the target account, while annotations carry the safety profile and the schema carries parameter detail. It is essentially complete, with only minor gaps (no return/confirmation detail after submission).

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 three parameters fully; the baseline is 3. The description restates the fields at a high level ('description or keywords, plus an optional https link') without adding format or constraint detail beyond the schema, and it loosely calls the link 'optional' while the schema marks it 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 (Add) and resource (expertise claim to a Life and Work resume), and the 'expertise' qualifier distinguishes it from the sibling make_claim_education/gooddeed/intellectualproperty/workhistory tools. An agent can tell what this does and which claim type it targets 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 description conveys the workflow context (prepare, sign, submit) which implies when to call it, but it never explicitly states when to use this versus the other make_claim_* variants or any exclusions. Usage is implied by the claim type rather than spelled out.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds meaningful context beyond that: it prepares an unsigned transaction (intent) and nothing happens until signed and submitted, naming both the signing tool and submit tool. This resolves the key ambiguity of a write tool in a two-step intent model.

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-loaded with the purpose, then the workflow caveat. No filler; 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 no-output-schema mutation tool, the description adequately covers the intent-then-sign-then-submit lifecycle and the target account. Given rich schema descriptions, this is complete enough 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 coverage is 100%, so all three parameters are documented in-schema, making 3 the baseline. The description loosely summarizes the fields ('description or keywords, plus an optional https link'), which adds marginal framing but no syntax or constraint 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?

States a specific verb and resource ('Add a good-deed claim to your Life and Work resume') with scope detail (description/keywords plus link). It clearly distinguishes itself from sibling make_claim tools like education, expertise, and workhistory by naming the claim type.

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

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

Gives clear context on when to use it and importantly describes the follow-up workflow (sign with geode-local-signer, submit with geode_submit_intent). It does not explicitly state when to prefer a different make_claim_* sibling, but the good-deed scope is unambiguous.

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

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

Annotations already mark this as non-read-only and open-world, but the description adds crucial behavioral detail: it writes to the chain, prepares an unsigned transaction (intent) for the signer, and nothing happens until signed and submitted. This goes well beyond what the annotations provide and is exactly the kind of operational context an agent needs.

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

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

Two sentences, front-loaded with the core action and followed by the essential workflow. No wasted words, and every sentence earns its place.

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

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

For a write-intent tool with no output schema, the description provides everything needed: what it does, that it prepares an unsigned transaction, and the required follow-up steps. The schema fully covers parameters, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description mentions signer and the IP file hash, but does not add syntax or format details beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb (add) and resource (intellectual-property claim to Life and Work resume) and includes the distinguishing parameter (hash of your IP file). This differentiates it from sibling make_claim_education/expertise/gooddeed/workhistory tools without needing to inspect schemas.

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

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

Gives clear context for when to use this tool: to add an IP claim to the resume. It also describes the required workflow (prepare intent, sign with geode-local-signer, submit with geode_submit_intent). It does not explicitly name alternatives or when-not to use it, so not a full 5.

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

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

Annotations declare a write (readOnlyHint=false) but the description adds the key behavioral fact that no state changes until the returned intent is signed and submitted, which the annotations do not convey. It doesn't cover failure modes or what the intent payload contains, but it discloses the critical two-step commit model.

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 zero waste; the core action is front-loaded and the critical workflow constraint follows immediately. 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 mutation tool with full annotation coverage and no output schema, the description supplies exactly what is missing: the resume context and the unsigned-intent commit model. Nothing an agent needs to invoke it correctly is 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 coverage is 100%, so the schema already documents all three parameters with byte limits. The description adds only 'description or keywords, plus an optional https link', which slightly conflicts with the schema marking url_link_to_see_more as required (though the schema notes empty string is allowed). Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Add a work-history claim to your Life and Work resume') and parenthetically names the content it accepts. This clearly distinguishes it from siblings like make_claim_education or make_claim_expertise that target other claim types.

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 a clear workflow context: it prepares an intent that must be signed with geode-local-signer and submitted with geode_submit_intent, explicitly naming the follow-up tools. It does not state when to choose this claim type over the other make_claim_* siblings, but the context is well established.

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

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

Annotations only flag the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds the crucial behavioral fact an agent cannot infer: this is a two-phase write — it only prepares an intent, and nothing is committed until an external signer plus geode_submit_intent complete the flow. No contradiction with the non-destructive annotation.

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

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

Two sentences, no filler. The core action is front-loaded, and the transaction-follow-through caveat follows immediately where an agent will read it before invoking.

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

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

With no output schema, the description should explain the return and edge cases; it does imply the return is an unsigned intent and names the follow-on tools. It does not cover failure modes (claim not found, not your claim) or whether hiding is reversible/retains endorsements, but the essential call path is 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 67% (signer and claim_id documented; set_to_show bare). The description reinforces the signer role and implies the boolean via 'show or hide', but adds no new semantics beyond the schema — e.g. it never says the claim must be one you own. Baseline 3 is appropriate when only a third of the params lack description.

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

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

States a specific toggle verb ('show or hide') applied to a specific resource ('one of your Life and Work claims on your resume'). This is clearly separable from the sibling make_claim_* tools (which create claims) and endorse_claim (which signs support), so an agent can route correctly 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?

Gives concrete pipeline context: it prepares an unsigned intent for `signer`, and 'nothing happens until you sign it with geode-local-signer and submit it with geode_submit_intent'. This names the required follow-on tools. It stops short of stating when to prefer this over related lifecycle operations (e.g. after making a claim), but the action constraints are explicit.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, and the description goes well beyond them by explaining the two-phase mutation model: it only prepares an unsigned intent and nothing takes effect until the caller signs and submits. This is exactly the state-changing behavior an agent needs to know 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?

Two tightly written sentences with zero waste; the field list and the critical signing caveat are both front-loaded.

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

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

For a 16-parameter mutation tool with no output schema, the description covers the essential behavior (intent preparation, no immediate effect) and the required follow-up tools. A minor gap is guidance on digital vs physical product differences, but the schema's boolean documents that.

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 94%, so the schema already documents all 16 parameters in detail. The description's enumeration of title, price, brand, category, description, inventory, media links, delivery details and zeno percent is a useful summary but adds little beyond the schema's own per-field 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?

States a specific verb+resource ('List a product... in your store') and enumerates the payload fields, making it clearly distinguishable from geode_market_add_a_service and geode_market_update_product_details.

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 clear workflow context: it writes to the chain by preparing an unsigned intent for signer, then requires geode-local-signer and geode_submit_intent. It doesn't explicitly contrast with update_product_details or delete_a_product, but the operational context is well specified.

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

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) by disclosing that this is a two-phase write: it writes to the chain but produces an unsigned transaction that does nothing until signed and submitted. This sequencing and the external signer requirement are exactly the kind of context annotations cannot convey.

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

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

Two sentences, front-loaded with the purpose and followed by the critical write/sign workflow. No filler; 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?

No output schema exists, and the description compensates by explaining that the result is an intent to be signed and submitted, which is the essential lifecycle information for a 13-parameter prepare-intent tool. It stops short of describing the returned intent identifier or failure modes, but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 92%, so the schema already documents the field formats and constraints. The description lists the fields (title, price, category, description, inventory, media/booking links, zeno percentage) but adds little beyond the schema; its claim that the zeno percentage is 'optional' conflicts with the schema marking zeno_percent required. 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 and resource ('List a service (online or in person) in your store') and enumerates the fields being set. The 'service' framing plus 'online or in person' cleanly distinguishes it from the sibling geode_market_add_a_product.

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 workflow context: it prepares an unsigned intent that must be signed with geode-local-signer and submitted with geode_submit_intent. It names the downstream steps but offers no explicit exclusions or a direct comparison to add_a_product/update_service_details, so no full 5.

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

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

Annotations only declare the write/safe/open-world profile; the description adds the crucial two-phase behavior — nothing happens until the intent is signed and submitted. That is exactly the kind of context an agent cannot infer from readOnlyHint=false alone, and it prevents the agent from assuming the cart is mutated 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?

Two sentences, front-loaded with the action and its arguments, followed by the operational caveat. No filler; 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 mutation tool with full parameter documentation, annotations covering the safety profile, and no output schema, the description supplies everything needed: the action, its inputs, and the sign/submit lifecycle. Nothing essential is missing.

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

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

Schema description coverage is 100%, so signer, quantity, and add_item_id are already documented in the schema. The description restates 'by id' and 'with a quantity' and reinforces that the intent is prepared for `signer`, but adds no format or constraint detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Add a product or service ... to your Marketplace cart') plus the two key qualifiers (by id, with a quantity). This clearly distinguishes it from siblings like geode_market_update_cart_item_quantity and geode_market_remove_item_from_cart.

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 workflow context: it prepares an unsigned transaction for `signer` and routes the agent to geode-local-signer for signing and geode_submit_intent for submission. It stops short of explicitly stating when to choose this over update_cart_item_quantity (new item vs existing item), so it lacks a true exclusion.

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

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

Annotations only give readOnlyHint=false, destructiveHint=false, openWorldHint=true; the description adds the non-obvious two-phase commit behavior (write is deferred until signature and submission). It omits remaining behavioral facts such as whether the bookmark is reversible or whether the intent expires, so it falls just short of full transparency.

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 zero filler; the action is front-loaded and the deferred-write caveat follows immediately, each sentence earning 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 two-parameter mutation with no output schema, the description supplies the essential lifecycle information (unsigned intent, sign, submit) so an agent knows the call alone accomplishes nothing on-chain. Minor gaps remain around cost/reversibility of the bookmark.

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 both parameters are documented with SS58 format and signing context, so the schema carries the load. The description reinforces the signer's role but adds nothing about `seller` beyond what the schema already says, matching the baseline for fully-covered schemas.

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 ("Bookmark a seller's store") in the first clause, which is immediately distinguishable from the sibling geode_market_remove_store_bookmark and from browsing tools like geode_market_go_to_store. An agent can select this 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?

Explicitly frames the usage context: it prepares an unsigned intent that must be signed with geode-local-signer and submitted with geode_submit_intent before anything happens. That names the follow-up tools, but it does not state when NOT to use this (e.g., to un-bookmark, use remove_store_bookmark).

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

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

Goes well beyond annotations: explains the two-stage delivery model (digital immediate, physical after shipping), value floor requirement, and crucially that this only prepares an unsigned intent and nothing happens until signing and submission. This is exactly the kind of multi-step behavioral context annotations cannot convey.

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

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

Front-loads the action, then the value constraint, then delivery semantics, then the sign/submit flow. Dense but 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?

Covers the mutation's consequences, the required follow-up workflow, and the delivery outcome. With no output schema, this is complete enough for an agent 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 baseline is 3, but the description adds real value by tying `value` to the cart total minimum and referencing view_my_cart. It also contextualizes `signer` within the signing flow. It does not explain `confirm_token` (irreversibility token) in the description, but the schema already does.

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 (Buy) and resource (everything in your cart), clearly distinct from sibling cart tools like add/remove/update_quantity and from view_my_cart. The agent can tell exactly what this tool does.

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?

Points to geode_market_view_my_cart for the cart total and to geode-local-signer/geode_submit_intent for the follow-up flow. It does not explicitly state when not to use it (e.g., for orders outside a cart) but the purchase context is clear.

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

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

Annotations already flag destructive and open-world, but the description adds materially more: the operation is intent-based and has no effect until signed and submitted, and it is irreversible with a two-step confirm_token handshake. This is exactly the behavioral context an agent needs before invoking a destructive 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?

Three sentences, each earning its place: purpose first, then the write/sign flow, then the irreversibility warning. The most consequential constraint (irreversible, needs second call) is placed last but is short and front-loaded enough to be noticed.

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

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

With no output schema, the description still explains what the first call returns (confirm_token) and what the agent must do with it, plus the required follow-up tools. Nothing needed to invoke this destructive tool correctly is missing.

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

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

Schema description coverage is 100% and the schema already documents all three parameters, so the baseline is 3. The description goes further by explaining the lifecycle of confirm_token (returned by the first call, replayed on the second) and the deferred role of signer, which is usage semantics the schema doesn't convey.

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

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

States a specific verb and resource ('Delete one of your products from your store'), and the resource itself separates it from the sibling geode_market_delete_a_service without ambiguity. An agent can select it from the name plus first sentence alone.

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 clear workflow context: the call only prepares an intent, which must be signed with geode-local-signer and submitted with geode_submit_intent, and the second call requires the confirm_token. It does not explicitly state exclusions (e.g., use the delete_a_service sibling for services), 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?

Goes well beyond the annotations (which only flag destructive/openWorld/not-readOnly) by disclosing that nothing executes until the unsigned intent is signed and submitted, that the action is irreversible, and that a confirm_token handshake gates the second call. This is exactly the extra behavioral context the annotations cannot convey.

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

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

Three tight sentences, front-loaded with purpose, then the execution model, then the danger/confirmation rule. No filler; each sentence carries distinct decision-relevant 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 destructive, no-output-schema mutation with full annotation coverage, the description supplies the workflow, irreversibility and confirmation protocol an agent needs. Only minor gap is not stating downstream effects (e.g. effect on existing orders/listings) or return shape, which is acceptable given no output schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that signer is the account the transaction is prepared for and clarifies the confirm_token round-trip (first call returns it, second call proceeds), which the schema merely labels

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 (Delete), a bounded resource (one of your services) and scope (from your store), letting an agent distinguish it from siblings like geode_market_delete_a_product, add_a_service, and update_service_details 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?

Gives clear operational context – the chain-write workflow via geode-local-signer and geode_submit_intent, plus the two-call confirm_token sequence – but does not name a competing tool or an explicit when-not-to-use condition. Strong routing context, no exclusions.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description goes well beyond them: it discloses that the call only prepares an unsigned intent, that nothing takes effect until signing and submission, that the action is irreversible, and that the first call returns a confirm_token needed for a second call. That is exactly the extra behavioral context an agent needs before touching a destructive write.

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

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

Three tight sentences, front-loaded with actor and action, then the write/signing flow, then the irreversible two-step confirmation. No filler and no repetition; each sentence carries a distinct load.

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

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

For a destructive, open-world mutation with no output schema, the description covers everything material: what it does, that it writes to chain, that it is intent-based and requires signing/submission, and that it is gated by a confirm_token. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already explains signer, order_id, and confirm_token, and the description adds no new syntax, format, or constraint detail for them. It restates the signer role and the token round-trip, which is helpful framing but redundant with the structured fields, 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 (deny), the exact resource (a buyer's problem report on an order), and the acting role (Seller), which is enough to separate it from sibling resolution tools like geode_market_issue_refund or geode_market_issue_replacement without opening a schema. An agent can tell at a glance that this rejects a claim rather than granting one.

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

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

It gives clear context for use (seller responding to a buyer problem report) and spells out the required follow-through workflow: sign with geode-local-signer and submit with geode_submit_intent. What it omits is any explicit exclusion or alternative, e.g. which sibling to call instead when the seller wants to accept or refund the claim.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description's 'Read-only' repeats the annotation, but 'no signature' adds genuine auth context (no signing required) and the caller note explains view-dependence. Return/pagination behavior is not covered, so it stays at a 3.

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: purpose first, then the read-only/auth note, then the optional-parameter caveat. No filler.

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

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

With no output schema, the description does the work of naming return contents (profile, products, services) and explaining the optional param. Complete enough to call correctly; only list pagination/ordering is unaddressed, a minor 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 baseline is 3. The description goes beyond the schema by clarifying that `caller` is the account whose view to read (for caller-dependent results), which the schema's 'run the query as' only partially conveys. That added meaning earns the bump.

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 (View) and resource (a seller's public Marketplace store) and enumerates the content returned (seller profile, products and services). The word 'public' plus 'a seller's' distinguishes it from sibling tools like geode_market_view_my_seller_profile and the search_stores variants.

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 name and the 'public store' framing — you call it to browse a specific seller's storefront. However, no alternative is named (e.g., search_stores_by_keyword for discovery vs. this for a known seller), and no when-not guidance is given.

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

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

Goes well beyond the annotations: it explains that the call writes to chain but only prepares an unsigned intent, that signing happens locally via geode-local-signer and submission via geode_submit_intent, and that the action is irreversible with a confirm_token round-trip. This is exactly the operational context the destructiveHint/openWorldHint annotations cannot convey.

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

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

Front-loaded with actor and action, then the amount semantics, then the write/sign/submit flow, then the irreversibility caveat. Four tight sentences with no filler; each one carries a distinct fact the agent needs.

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

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

For a destructive, chain-writing tool with full schema coverage and no output schema, the description covers the mutation lifecycle (intent, sign, submit), the confirmation requirement, and the source of funds. Nothing material to correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by clarifying that `value` is the refund drawn from the seller's own balance (the schema only says 'GEODE to send') and by explaining the confirm_token's role in the second call. Minor addition, but genuinely beyond the schema text.

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 ('resolve a reported problem by refunding the buyer') and pins the actor role ('Seller'), which separates it from buyer-side siblings and from adjacent seller actions like geode_market_issue_replacement or geode_market_deny_resolution_request. An agent can identify the operation without opening the schema.

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

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

Gives clear usage context (a seller responding to a reported problem) and describes the required two-step confirm workflow. It does not explicitly name when to prefer this over the sibling resolution tools (replacement, deny), so it falls short of full alternative-routing 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 annotations already declaring readOnlyHint=false and destructiveHint=false, the bar is lower, yet the description adds real value: it discloses the two-step intent model ('prepares an unsigned transaction ... nothing happens until you sign it with geode-local-signer and submit it with geode_submit_intent'). It stops short of covering reversibility or failure behavior, so a 4 rather than 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 tight sentences, front-loaded with purpose before the mechanical intent/signing detail. Every clause earns its place with no redundancy.

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

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

For a no-output-schema mutation tool, the description explains the actor, the intended effect, and the full signing/submission workflow, which is what an agent needs to invoke it correctly. Minor gaps remain around what happens on failure or how the replacement links to the original order.

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

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

Schema description coverage is 100%, so the baseline is 3. The description loosely references 'signer' and 'tracking' ('with new tracking information', 'for `signer`') but adds no format or constraint detail beyond what the schema already documents.

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+resource ('issue replacement' / 'sending a replacement') and adds a role qualifier ('Seller') plus the distinguishing detail 'with new tracking information', which implicitly separates it from geode_market_issue_refund. However, it never explicitly names the sibling tools (issue_refund, deny_resolution_request) it must be distinguished from, 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?

It identifies the actor ('Seller: resolve a reported problem') and the situation, which implies when to use it, but gives no explicit when-not guidance and never names the alternatives (issue refund, deny resolution request) that a seller would pick between. Usage is implied rather than stated.

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

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

Annotations cover the safety profile (readOnly=false, destructive=false, openWorld=true), but the description adds genuinely important context: this only prepares an unsigned intent and nothing happens until it is signed with geode-local-signer and submitted with geode_submit_intent. It omits fee/permission details, keeping it below 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 tightly written sentences, front-loaded with the actor and action, then the chain-writing constraint. No filler or repetition of the title.

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 write tool with no output schema, the description supplies the essential two-step intent workflow an agent must know. It does not describe what comes back (e.g., the intent id) or any cost, but those are minor gaps given the annotations and complete schema.

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

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

Schema coverage is 100%, so every parameter is already documented with format constraints in the schema. The description only alludes to 'signer' via the unsigned-transaction sentence, adding no syntax or format detail beyond the schema, 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?

States a specific verb+resource (send a message about an order), names the direction (to its buyer), and prefixes the required role ('Seller:'), which cleanly distinguishes it from the buyer-facing sibling geode_market_message_the_seller. An agent can select it without inspecting 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?

The 'Seller:' prefix and 'about an order' scoping give clear context for when this applies, and the follow-up workflow (sign then submit) is spelled out. It stops short of explicitly naming the alternative tool a buyer would use, so it is clear-but-not-exhaustive.

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

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

Annotations only cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds the crucial non-obvious trait that this does not mutate state by itself: it prepares an unsigned intent that only takes effect after signing and submitting. It stops short of noting fee costs or that the message becomes publicly visible on-chain.

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, with the purpose front-loaded before the intent/signing mechanics. Every clause earns its place by preventing a misuse (treating the call as a completed send).

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-required-param write tool with no output schema, the description supplies what the schema cannot: the intent workflow and the two sibling tools needed to complete it. It could go slightly further on what the returned intent contains or that get_intent can inspect it, but nothing essential 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%, and the schema already documents signer, message, order_id, and photo_or_youtube_url in detail (byte limits, hex format, URL rules). The description only echoes `signer`, so it adds nothing beyond the structured fields; 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 (send a message), the resource (an order), the recipient (its seller), and the constraint (must be one of your orders). This cleanly separates it from the sibling geode_market_message_the_buyer and from the generic geode_messaging_send_private_message 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 description makes the context of use explicit (messaging a seller about one of your orders) and names the required follow-up tools, geode-local-signer and geode_submit_intent, so the agent knows this is step one of a two-step flow. It does not state when to prefer this over generic private messaging, but the domain scoping is clear.

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

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

Goes well beyond the annotations by disclosing the two-step intent model: the call only prepares an unsigned transaction for `signer`, and nothing is committed until geode-local-signer signs and geode_submit_intent submits. This is exactly the behavioral context an agent needs to avoid assuming an immediate on-chain write.

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. The rate/review action is front-loaded, and the chain-write caveat follows immediately. Every clause carries information; 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 mutation tool with no output schema, it adequately explains the intent/sign/submit lifecycle. It leaves out whether a rating is final or editable and any fee/gas implications, which would be useful for a one-shot chain write.

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 baseline is 3, but the description adds the rating bound of "1 to 5" that the schema's "non-negative integer as a string" does not state, and it reinforces that `signer` is the account the transaction is prepared for. Review length limits and order_id format remain schema-only.

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 (rate/review) and resource (the buyer of one of your orders), with the seller-side scope made explicit in the first word. This cleanly separates it from the sibling geode_market_rate_a_product_or_service without the agent needing to open either schema.

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

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

"Seller: ... the buyer of one of your orders" implies the precondition (you are the seller with a completed order) and gives clear context for when it applies. It does not explicitly name the alternative (rating a product/service) or state exclusions, so it falls short of a 5.

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

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

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=true. The description goes well beyond them by disclosing that this writes to the chain via a two-phase intent flow: it prepares an unsigned transaction for `signer` and nothing takes effect until the caller signs with geode-local-signer and submits with geode_submit_intent. That is exactly the kind of non-obvious behavioral context an agent needs.

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 followed by the essential workflow caveat. Every clause carries weight; no filler or restatement of the tool name.

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

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

For a mutation tool with annotations covering the safety profile and no output schema, the description supplies the critical missing piece: the intent/sign/submit lifecycle and the fact that nothing commits until submission. It does not cover edge cases such as re-rating an item or failure behavior, but nothing essential for a correct invocation is 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 coverage is 100%, so the baseline is 3, but the description adds a constraint the schema omits: the rating must be 1 to 5, whereas the schema only says 'Non-negative integer as a string of digits'. It also reinforces that the transaction is bound to the `signer` account, which the schema states but ties into the workflow.

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 ('Rate (1 to 5) and review a product or service'), and the resource ('product or service') implicitly separates it from the sibling geode_market_rate_a_buyer. However, it never names or contrasts against that sibling explicitly, so an agent must infer the distinction from the tool name alone.

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

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

There is no statement of when to use this tool versus alternatives such as geode_market_rate_a_buyer or the other market write tools. The second sentence explains the signing/submission workflow rather than selection criteria, so usage must be inferred entirely from the purpose sentence.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true, and the description goes well beyond them: it discloses the intent/signing model, that nothing takes effect until the intent is signed and submitted, the exact downstream tools, and the two-phase confirm_token confirmation flow for an irreversible action. This is exactly the behavioral context an agent needs before invoking a destructive 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?

Three compact clauses, front-loaded with the action and precondition before the mechanics and the irreversibility warning. No filler; every sentence changes how the agent should behave.

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

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

For a destructive write tool with no output schema, the description covers the mutation, its side effect, the signing/submission handoff, and the confirmation requirement. Nothing an agent needs to call it safely is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: it explains that the transaction is prepared for 'signer' and that confirm_token comes from the first call and gates the second, irreversible call. That clarifies the multi-call lifecycle of the parameters rather than merely restating their types.

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 ('refuse an order'), the acting role ('Seller'), and the precondition ('has not shipped yet'), plus the consequence ('the buyer is refunded in full'). This clearly separates it from siblings like geode_market_deny_resolution_request and geode_market_issue_refund 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?

Gives a clear applicability condition (order has not shipped yet, seller perspective) and routes the agent through the required follow-on tools (geode-local-signer, geode_submit_intent). It does not explicitly name when to prefer this over adjacent refund/denial tools, so it falls short of a full when/when-not/alternatives treatment.

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

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

Annotations only say readOnlyHint=false, destructiveHint=false, openWorldHint=true; the description adds the crucial two-phase semantics — it writes to the chain but produces an unsigned intent, and nothing takes effect until signed and submitted. This is exactly the kind of context annotations cannot convey, and nothing contradicts them.

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

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

Two tight sentences, zero filler, with the mutating action front-loaded and the signing-submission requirement immediately after. 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 2-parameter mutation with no output schema, the description supplies the full lifecycle (prepare → sign → submit), which is the only missing piece beyond the schema and annotations. An agent can invoke it correctly without further context.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema; the description only reinforces that the intent is prepared for `signer`. Baseline 3 applies since the schema does the heavy lifting and the description adds no format or syntax detail.

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 an item from your cart') that is immediately distinguishable from siblings like geode_market_add_item_to_cart and geode_market_update_cart_item_quantity. No ambiguity about what the tool mutates.

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?

Names the required follow-up path explicitly ('sign it with geode-local-signer and submit it with geode_submit_intent'), which tells the agent this is step one of a multi-tool workflow. It does not state when to prefer this over directly updating quantity or whether the item must already exist, but the operative workflow context is clear.

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

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

With annotations only declaring readOnlyHint=false and destructiveHint=false, the description adds the crucial behavioral fact that this is a two-phase deferred write: nothing happens on-chain until the caller signs and submits. That is real value beyond the structured fields and is consistent with the annotations.

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

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

Two sentences, front-loaded with the action and followed by the execution caveat. Every clause earns its place with no filler.

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

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

With no output schema, the description does not need to explain return values, and it covers the deferred-signing lifecycle well. It omits any prerequisite (e.g., the bookmark or store must exist) but is otherwise complete for this simple two-param mutation.

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 both parameters are fully documented in the schema, so baseline 3 applies. The description references `signer` but only restates what the schema already says, adding no new syntax or constraint detail.

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 store bookmark') and immediately clarifies the non-obvious execution model (prepares an unsigned intent). An agent can distinguish this from the sibling geode_market_bookmark_a_store without inspecting either schema.

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

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

Explicitly names the follow-up tools (geode-local-signer and geode_submit_intent) and the condition under which they are needed, which is actionable workflow guidance. It does not, however, state prerequisites or when-not-to-use this versus other market mutation 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), it discloses the crucial two-step intent flow: it prepares an unsigned transaction and nothing executes until the agent signs and submits it. That is exactly the behavioral context an agent needs for a chain-writing 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?

Purpose is front-loaded in the first sentence, followed by the deadline constraint and then the write mechanism. Three dense sentences, 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 mutation tool with no output schema, it covers what the tool does, its eligibility constraint, and the full signing/submission lifecycle. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description only reinforces the role of `signer`; it adds no new syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb+resource+condition: 'Report that a delivered order arrived damaged.' This clearly distinguishes it from siblings geode_market_report_problem_not_received and geode_market_report_problem_wrong_item 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?

Gives a concrete eligibility window ('Only allowed within 24 hours of delivery') and points to the downstream tools (geode-local-signer, geode_submit_intent). It does not, however, explicitly say when to choose this over the not_received/wrong_item siblings.

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

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

Goes well beyond the annotations by disclosing the full write workflow: it prepares an unsigned transaction (an intent) for `signer`, nothing happens until signed with geode-local-signer and submitted with geode_submit_intent. This is exactly the kind of non-obvious behavioral context annotations cannot convey.

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

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

Three sentences, each earning its place: purpose, constraint, then the critical sign/submit workflow. Front-loaded and free of 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 mutation tool with no output schema and fully documented parameters, the description covers purpose, eligibility, and the intent/sign/submit pipeline an agent must complete. Nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description only reinforces the role of `signer`; it adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb+resource: 'Report that an order marked delivered was not received.' This precisely distinguishes it from its close siblings geode_market_report_problem_damaged and geode_market_report_problem_wrong_item without needing to name them.

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

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

Provides a concrete eligibility condition ('Only allowed within 24 hours of delivery'), which is strong usage guidance. It stops short of explicitly naming alternative report tools or what to do when the window has passed, but the context is clear.

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

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

Provides crucial behavioral context beyond annotations: 'Writes to the chain: this prepares an unsigned transaction (an intent) for `signer`; nothing happens until you sign it with geode-local-signer and submit it with geode_submit_intent.' This explains the multi-step intent flow, which is not in the annotations.

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

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

Two sentences, front-loaded with the purpose and constraint, then the behavioral note. No wasted words.

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

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

Given the complexity of an on-chain write via intent, the description covers the critical flow (prepare, sign, submit) and the time constraint. No output schema is needed. Complete for an agent to use 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 schema already documents all parameters. The description does not add meaning beyond the schema; it references `signer` but doesn't explain parameters like `message` or `order_id` further. Baseline 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?

States a specific verb and resource: 'Report that a delivered order was the wrong item.' This clearly distinguishes it from siblings like report_problem_damaged and report_problem_not_received.

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?

Includes a clear constraint: 'Only allowed within 24 hours of delivery.' This gives explicit context for when to use, though it doesn't explicitly name alternative tools for other problem types.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is largely covered. The description adds the useful auth detail 'no signature' (no signing required) and notes that results can be caller-dependent, which goes beyond what the annotations 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?

Three short clauses with the core action front-loaded; almost nothing is wasted. 'for caller-dependent results' is slightly jargon-heavy but still compact and informative.

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

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

With no output schema, the description should ideally hint at what results look like, which it does not. Otherwise it is adequate: a read-only, signature-free search with a documented caller parameter, and annotations cover the safety profile for this 4-param 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 coverage is 100%, so baseline is 3. The description does clarify the optional `caller` as 'the account whose view to read (for caller-dependent results)', which adds nuance beyond the schema's 'run the query as'. However, it says 'up to three keywords' while the schema marks all three keyword slots as required, a tension that could mislead invocation.

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

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

States a specific verb and resource ('Search Geode Marketplace products by keyword'), which distinguishes it by resource type from the service- and store-search siblings. It stops short of naming those siblings, so the agent must infer the differentiation from the resource noun alone.

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?

Use is implied by the name and description (search products), and the caller note hints at a use case, but there is no explicit when-to-use, when-not-to-use, or pointer to geode_market_search_services_by_keyword / geode_market_search_stores_by_keyword for the other resource types.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so 'Read-only; no signature' mostly repeats annotation info. It does not describe what is returned, pagination, or result ordering. The caller note adds a bit of context but overall adds little beyond annotations.

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

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

Two compact sentences, front-loaded with the core action and mechanism, then the optional caller note. No wasted text.

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

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

For a read-only search tool with annotations covering safety and full schema coverage, the description is nearly sufficient. Missing return format is acceptable since no output schema exists, though a hint on result shape would help.

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 schema documents all four parameters including the caller SS58 address and keyword byte limits. The description only restates 'up to three keywords' and 'caller' without adding syntax or format beyond the schema; 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 (Search) and resource (Geode Marketplace services) with a keyword-based mechanism. It distinguishes itself from geo_market_search_products_by_keyword and geo_market_search_stores_by_keyword implicitly by naming 'services', but does not explicitly name 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?

Implies read-only search usage and explains the optional caller for caller-dependent results, but gives no explicit when-to-use vs alternatives or exclusions (e.g., why use this vs search_products/search_stores). Usage must largely be 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?

Annotations already cover readOnly, destructive, and openWorld hints, so the bar is lower. The description still adds useful behavioral context beyond annotations: 'no signature' (no auth/signing requirement) and the caller-dependent view semantics of the optional caller parameter.

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 core action and scope, followed by the safety/signature note and the caller nuance. 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 keyword-search tool with full schema coverage and annotations covering the safety profile, the description is nearly complete. It implies the return is stores but does not describe result shape or pagination, which is a minor gap given 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 description coverage is 100%, so the schema documents all four parameters, setting the baseline at 3. The description adds nuance to caller ('the account whose view to read (for caller-dependent results)'), but its phrase 'up to three keywords' mildly conflicts with the schema requiring all three keyword 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 ('Search Geode Marketplace stores (seller profiles)') with clear scope ('by up to three keywords'). The parenthetical 'seller profiles' distinguishes it from the sibling search_products and search_services tools without needing to name them.

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

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

The description identifies the resource clearly enough to imply when to use it over product/service searches, and notes read-only/no-signature context. However, it never explicitly states when to choose this tool over the sibling search tools or what conditions select it.

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

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

Annotations only declare write/openWorld/non-destructive. The description adds genuinely non-obvious behavior: the call does not mutate state directly but prepares an unsigned intent for `signer`, and nothing takes effect until it is signed and submitted. This lifecycle detail is exactly the context annotations cannot supply.

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 waste: the first front-loads the purpose, the second adds the essential write-via-intent workflow. Nothing is redundant 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?

For a 3-param write tool with a 100%-covered schema and no output schema, the description supplies the crucial two-step intent/sign/submit model. It stops short of stating what the call itself returns (the unsigned intent), but it is otherwise sufficient to call 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%, so the schema already documents all three parameters (name, location, signer). The description only calls out `signer` as the target account, adding marginal meaning beyond the schema; baseline 3 is appropriate.

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

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

States a specific verb (Set) and resource (Marketplace buyer name and location), and the word 'buyer' cleanly distinguishes it from the sibling geode_market_update_seller_account_settings without opening either schema.

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

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

The description conveys what the tool is for and outlines the follow-up flow (sign with geode-local-signer, submit with geode_submit_intent), which implies when to reach for it. However, it never states when NOT to use it or names an alternative for a conflicting intent, so usage is only implied rather than explicit.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true. The description adds crucial behavioral context beyond annotations: it writes to chain, produces an unsigned transaction (intent), and nothing happens until signed and submitted. This is valuable process information not in the schema or annotations.

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

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

Two sentences, front-loaded with the action, then immediately followed by the critical workflow constraint. No wasted words.

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

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

Given annotations cover safety, schema is complete, and no output schema exists, the description provides enough context for correct invocation. It could mention whether the item must already be in the cart or how to get item_id, but overall it's complete for the tool's scope.

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 fully documents all three parameters. The description does not add parameter-specific details beyond what the schema provides, so baseline 3 is appropriate.

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

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

Specific verb (change quantity) and resource (item in your cart), clearly distinguished from siblings like add/remove item and checkout. The scope 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 clearly states the workflow context: prepares an unsigned intent for the signer, then must be signed and submitted via geode-local-signer and geode_submit_intent. It doesn't explicitly name when not to use it (e.g., use add_item_to_cart for new items), but the mutation nature and intent flow are clear.

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

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

Adds substantial context beyond the annotations: it writes to the chain, it only prepares an unsigned intent for `signer`, and nothing happens until geode-local-signer signs and geode_submit_intent submits. It also discloses the side effect that delivery releases payment, which the destructiveHint=false annotation does not convey.

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

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

Three dense sentences with no filler: role and action first, then the state machine and its payment effect, then the signing flow. Every clause carries actionable 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 mutation tool with no output schema, the description covers the actor, the state transitions, the economic consequence, and the full intent/sign/submit lifecycle, which is everything an agent needs to invoke it correctly.

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

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

Schema coverage is 60%: signer, order_id and tracking_update are documented in the schema, but the shipped and delivered booleans have no descriptions. The description's state-transition wording implicitly maps to those booleans but never explains whether they are set independently or which combinations are valid, so it only partially compensates.

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 (update), resource (an order's tracking), actor (Seller), and the exact state transitions (awaiting → shipped → delivered). This clearly distinguishes it from sibling tools like geode_market_view_my_seller_orders_shipped, which merely read the same states.

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 pins down who uses it (Seller) and the workflow it participates in, including the payment-release consequence of the delivered transition. It gives clear context but does not name alternative tools or state when not to use it (e.g. vs. geode_market_refuse_an_order or issue_refund).

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?

Adds substantial context beyond the annotations: it writes to the chain, produces an unsigned intent bound to `signer`, and requires a separate sign-and-submit step, which the readOnlyHint=false / openWorldHint=true hints do not spell out. It does not disclose whether the 13 mutable fields fully replace existing values or what happens to fields the caller might expect to keep, which matters for a destructiveHint=false 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 sentences, zero filler, and correctly front-loaded: purpose and constraint first, then the write/sign/submit pipeline. 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 14-parameter mutation with no output schema and annotations already covering the safety profile, the description covers the essential unknown: that this is a two-step intent flow rather than an immediate write. It stops short of clarifying full-replace semantics and any ownership/precondition on product_id, which an agent would still need to guess at.

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% (14 well-documented params, including the price decimal/raw duality and byte limits), so the schema carries the parameter burden and the baseline is 3. The description adds only the title immutability constraint and notes that the intent is bound to `signer`; it contributes little 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 and resource ("Update one of your products' details") and adds the meaningful invariant that the title cannot change, which the name alone would not convey. It does not explicitly route away from the near-identical sibling geode_market_update_service_details, so the product/service split is left to inference from the resource noun.

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 usage context: this prepares an unsigned intent for `signer`, and nothing happens until it is signed with geode-local-signer and submitted with geode_submit_intent. It does not state exclusions (e.g., that after creating a product you should use geode_market_add_a_product instead of this, or when a service update is the right sibling), so the when-not side is missing.

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

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

Annotations already flag a write (readOnlyHint=false) with no destruction, but the description adds crucial context beyond them: the operation only writes an unsigned intent to the chain, and nothing takes effect until the agent signs and submits it. This deferred-execution/signing requirement is exactly the kind of behavioral detail annotations cannot convey.

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

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

Two tight sentences, front-loaded with what gets set and immediately followed by the critical execution caveat. No wasted words.

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

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

No output schema exists, but the description covers what an agent needs: which fields are set and the intent/sign/submit lifecycle. For a 7-parameter mutation tool this is complete enough to call 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 schema fully documents all 7 required parameters including byte limits and URL constraints. The description names the fields it sets (name, location, description, links) but adds no syntax or format detail 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?

States a specific verb ('Set') and resource ('your store's name, location, description and links'), which maps unambiguously to the seller-account-settings tool. It is clearly distinguishable from sibling geode_market_update_buyer_account_settings and from the product/service detail update 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?

Explains the multi-step workflow an agent must follow: this prepares an intent, which must then be signed with geode-local-signer and submitted with geode_submit_intent. It gives clear context for completion but does not state explicit exclusions or contrast with the buyer-settings sibling.

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 annotations declaring readOnlyHint=false, the description adds important context beyond them: it explains that it only *prepares* an unsigned intent and 'nothing happens until you sign it with geode-local-signer and submit it with geode_submit_intent'. This is genuinely useful behavioral detail (non-destructive, two-step). Doesn't mention replacing all fields or error side effects, but strong.

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 what it does and a key constraint, then the transaction workflow. No waste.

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 annotations and full schema, the description covers the crucial non-obvious part: it's an intent-preparation step requiring signer and submit. It doesn't explain that all fields are required/replaces the whole service, but overall it's complete enough 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 coverage is 100%, so every parameter is fully documented in the schema. The description adds only the signer workflow context, which maps to the 'signer' param, but doesn't add value for the other 10 params. Baseline 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?

States a specific verb+resource: 'Update one of your services' details'. The parenthetical 'the title cannot change' clarifies scope. It does not explicitly differentiate from sibling geode_market_update_product_details, though 'service' vs 'product' distinguishes it.

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?

Implies usage by an owner of a service, and gives a crucial workflow: prepare intent → sign → submit. But it doesn't say when to use this vs add_a_service or delete_a_service, nor prerequisites like ownership. Adequate but with gaps.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so 'Read-only' largely restates structured data. 'No signature' is a genuinely new auth detail not captured by annotations, and the content enumeration hints at the response shape, but overall additions beyond annotations are modest.

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 purpose front-loaded, then the parameter note. No wasted clauses, though the quoted `caller` and the clause 'for caller-dependent results' are slightly cryptic.

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

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

For a read-only view tool with one optional param, full schema coverage and annotations covering the safety profile, the description is largely sufficient, and it even enumerates the data sections since there is no output schema. It stops short of clarifying what a caller-dependent result actually changes.

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 describes caller as an optional SS58 address to run the query as. The description's 'the account whose view to read (for caller-dependent results)' adds a little meaning about why you would set it, but no format or effect details beyond the schema. 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 ('Get') plus a clearly scoped resource (caller's Marketplace buyer account) with an enumeration of contents: profile, bookmarked stores, digital downloads, orders. This distinguishes the aggregate view from narrower siblings like view_my_orders and view_my_cart, though it never explicitly says so.

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 name and the word 'my'. There is no statement of when to choose this over view_my_orders / view_my_cart / view_my_seller_profile, nor any exclusion. The only usage-like hint is that caller is 'for caller-dependent 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?

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine context beyond that: the cart is 'unpaid', no signature is required, and results are caller-dependent, all of which affect how the call behaves.

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 clauses with zero filler; the core action and return payload are front-loaded, followed by the auth note and the parameter note in descending priority.

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