genesis-memory

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

With no annotations, the description carries the burden and does reasonably well: it discloses the auth model (free, no email, no password), the credential's scope (unlocks both memory and registry), and a critical behavioral trait — 'it is shown once' — which warns the agent the key is not retrievable later. It stops short of saying whether registration is idempotent or rate-limited.

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, zero filler, and the most decision-relevant facts (free, no auth, dual-purpose key, shown once) are all 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 one-optional-param tool with no output schema, the description conveys what the agent gets (an api_key), its scope, and the one-shot display caveat, which is the key operational fact. Minor gaps remain: no mention of the response field name or whether calling again issues a new key.

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 there is only one optional parameter ('label' as optional label/handle), so the schema already covers it. The description adds nothing about the label's purpose or format; 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 ('Get a free api_key for Genesis') and immediately qualifies the scope with '(no email, no password)'. An agent can distinguish this onboarding tool from the memory_* and registry_* siblings 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 explains the payoff for calling it ('One key unlocks both agent memory (remember/recall) and the trust registry (post/verify claims)'), which implies this is the prerequisite step before those sibling tools. It doesn't explicitly say 'call this first' or name exclusions, 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the operation returns JSON, that it covers ALL memories, and that an api_key is required for auth. However it does not state that it is read-only/non-destructive, nor whether there are size limits, pagination, or rate limits on a full dump.

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

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

Three short, front-loaded sentences that are easy to scan. 'No lock-in' is marketing copy rather than functional information, so the text is not entirely 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?

For a simple single-parameter tool with no output schema, the description covers what is returned (JSON of all memories) and the auth prerequisite. Only the read-only nature and any export-size limits are unaddressed.

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

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

Only one parameter with 0% schema description coverage. The description names it ('Needs your api_key'), adding that it is an authentication credential rather than a filter or target, but this is only marginally more than the schema's required-string declaration already conveys.

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 ('Export') and resource ('all of your memories') plus the output format (JSON). It is clearly distinguishable from destructive siblings like memory_forget and from the search-style memory_recall, though it does not name those alternatives explicitly.

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

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

There is no when-to-use guidance, no mention of when NOT to use it, and no sibling alternative named. The word 'all' implies a bulk dump versus recall's filtered lookup, but that distinction is left for the agent to infer.

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

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

With no annotations, the description carries the full burden, and it does disclose the most important trait: the deletion is permanent/irreversible. However, it is silent on permissions beyond needing the key, error behavior for an unknown id, and whether any confirmation is required.

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, purpose front-loaded, no filler. The second sentence is arguably redundant with the schema's required fields, which keeps it out of the top score.

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

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

For a two-parameter destructive tool with no annotations and no output schema, the description covers the core action and irreversibility but omits error/permission context that an agent would want before calling a delete.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It names api_key and the memory id but adds no format, source, or identity semantics beyond the schema's own required-field list, so it largely repeats structured data.

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?

"Delete one of your memories permanently" gives a specific verb (delete) and resource (memory) with a scope qualifier. An agent can distinguish it from memory_update/memory_recall, though it never names a sibling explicitly, so it falls short of the 5 bar.

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 says what the tool does but never says when to use it versus memory_update, team_forget, or memory_export. There is no when-not guidance, no preconditions, and 'permanently' hints at caution without stating 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?

With no annotations, the description carries the full burden and does well: it discloses that the memory remains the current head, is still returned by recall, and 'reads as contested', plus the non-obvious counting rule (ten copies = one ground, count is not a vote). It omits auth/permission requirements and whether objections can later be resolved or expire, so it falls short of full behavioral coverage.

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

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

Front-loaded with the core action and its key constraint, then the required param, then the counting caveat, then routing guidance. Four short sentences with no filler; every 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?

There is no output schema, so the description must explain effects, which it does (memory stays head, still recalled, reads as contested). It leaves the relationship to the existing memory_resolve_objection sibling and auth requirements unaddressed, but is otherwise sufficient 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 50%; id and api_key are documented nowhere. The description reinforces grounds as required and glosses it ('on what basis'), adding marginal value, but the two remaining parameters are left entirely unexplained by both description and 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?

Specific verb+resource: 'Raise an objection to a memory', immediately scoped as a challenge that does NOT supersede it. This cleanly distinguishes it from memory_update ('instead of forcing a correction') and from any sibling that resolves objections, without needing to open another schema.

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

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

The description gives an explicit when-to-use ('use this for disputed, unsettled') and a when-not ('instead of forcing a correction'), which routes the agent away from memory_update. The supersession boundary (memory stays head) further disambiguates from tools that change state.

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

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

With no annotations, the description carries the full load and does reasonably well: it discloses default ordering (newest first when no query), a non-obvious default filtering rule (superseded entries excluded), and an auth requirement (api_key). It stops short of describing pagination behavior or the shape/size of results, which matters for a recall tool with no output schema.

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

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

Four short sentences, front-loaded with the core purpose and mechanism, and the trailing auth note is terse. No filler, though the fragments are dense and slightly telegraphic.

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, unannotated tool with no output schema, the description covers the key defaults and the search mechanism but omits pagination semantics, result format, and what the limit default is. Adequate but with clear gaps an agent would need to probe.

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

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

Schema description coverage is only 29%, so the description must compensate and partially does: it explains q as keyword search over content and tags, tag/collection filtering, and the include_superseded default. It adds nothing about the undocumented limit and offset parameters, leaving those ambiguous.

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 ('Recall your memories') and immediately characterizes the mechanism as keyword search over content and tags, which distinguishes it from memory_remember/forget/update. It doesn't explicitly distinguish itself from the sibling memory_export or team_recall, so no sibling differentiation credit.

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 implies when the tool applies (searching your own memories) and gives conditions like 'newest first when no query' and 'filter by tag or collection.' However, it never says when to use this instead of memory_export or team_recall, nor any exclusion beyond the superseded default.

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

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

With no annotations, the description carries the full burden, and it does disclose key traits: persistence ('permanent until you forget it'), timestamping, non-silent dropping, and the auth requirement ('Needs your api_key'). However it omits error/overwrite semantics, what happens to superseded entries (schema covers this, not the description), and any return behavior.

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

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

Two tightly written sentences, front-loaded with purpose and durability. 'Honest and permanent until you forget it' is slightly rhetorical but conveys the non-dropping guarantee economically; 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 16-parameter, no-output-schema mutation tool with zero annotations, the description covers purpose, durability, and auth but says nothing about the supersede workflow or what is returned. The unusually rich schema descriptions compensate substantially, making this adequate but not complete on its own.

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 the rich parameter set (supersedes, check, source_excerpt, etc.). The description only echoes api_key and adds no syntax or format detail 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 concrete verb+resource ('Store a memory') and frames its role by naming the counterpart activity ('so your agent can recall it in a later session'). It doesn't explicitly distinguish itself from memory_update or team_remember, but the write-vs-recall pairing is clear enough to distinguish it from memory_recall.

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

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

There is no when-to-use/when-not guidance and no named alternative. The phrase 'recall it in a later session' hints at the durability use case, but it never says when to prefer this over memory_update or team_remember, nor what conditions require 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?

With no annotations, the description carries the full burden. It usefully discloses that the original grounds AND the resolution both remain inspectable, which tells the agent the action is additive rather than destructive. It says nothing about auth expectations, idempotency, or whether a resolved objection can be reopened, which are real gaps for a mutation 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 short sentences, front-loaded with the action and ending with the parameter requirements. No filler. Slightly terse on structure but 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 4-required-param mutation tool with no annotations and no output schema, the description covers purpose, a key behavioral consequence, and parameter identification. It omits error behavior, whether resolution is freeform text, and post-resolution state, so it is adequate but clearly incomplete.

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

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

Schema coverage is only 25% (just 'resolution'). The description compensates by decoding the two cryptic parameters: 'id' is the memory id and 'oid' is the objection id, which the schema leaves entirely undocumented. It adds no semantics for 'resolution' beyond the schema and ignores 'api_key'.

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 an open objection on one of your memories.' The 'open objection' qualifier narrows scope meaningfully. It does not name or contrast with a sibling (e.g., memory_object, which presumably raises objections), 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?

The phrase 'open objection' implies the precondition that an objection must already exist, which is useful implied usage guidance. However, it never states when to use this versus siblings like memory_object or memory_update, nor what happens if the objection is already resolved.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the auth requirement and required id, which is useful, but says nothing about the critical update semantics: whether unspecified fields are preserved or cleared, whether the operation is idempotent, or what happens if the id doesn't exist.

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

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

Two compact clauses with zero filler, and the core action is front-loaded. It is arguably too terse for a five-parameter mutation tool, but nothing is wasted or padded.

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

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

For a mutation tool with no annotations, no output schema, and zero schema description coverage, the description is thin. Partial-update behavior, error conditions, and the meaning of the collection field are all left for the agent to guess.

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

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

Schema description coverage is 0%, so the description must compensate. It names the three optional fields and identifies the two required ones as prerequisites, covering all five parameters at a shallow level, but it adds no format, constraint, or interaction detail beyond the bare field names.

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 memories') and enumerates the mutable fields (content, tags, collection). It doesn't explicitly differentiate itself from siblings like memory_remember or memory_forget, but the name plus field list leaves little ambiguity about what it 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?

The only guidance is a prerequisite note ('Needs your api_key and the memory id'). There is no statement of when to reach for this tool over memory_remember, memory_forget, or memory_recall, and no exclusions or conditions.

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

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

With no annotations, the description carries the behavioral burden and does disclose important traits: it returns LOOKS_PAYABLE or CHECK_FLAGS, checks the challenge rather than settlement, and does not itself pay. It still does not explicitly state read-only/no-side-effect behavior, so it falls short of full annotation-level 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?

Three tight sentences, front-loaded with the imperative trigger and then the validation criteria and return behavior. Every sentence contributes directly to correct invocation.

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 preflight tool with no output schema, the description gives enough return context by naming LOOKS_PAYABLE and CHECK_FLAGS. It could be more complete by explaining flag meanings or error/failure cases, but the essentials are present.

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

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

There is one parameter with 100% schema description coverage, so the schema already defines the URL input. The description contextualizes the URL as an x402 endpoint with a 402 challenge, but adds no syntax or format detail beyond what the schema provides.

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: preflight-checking an x402 endpoint's 402 challenge before payment. It also names the exact validation scope (well-formed, one consistent payTo, Base settlement), making it clearly distinct from all sibling tools.

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

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

It gives a strong explicit trigger: use before paying ANY x402 endpoint. It also implies a when-not boundary by saying it confirms the ask, not the settlement. However, it does not name an alternative tool such as verify_onchain_receipt for settlement confirmation.

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

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

No annotations are provided, so the description carries the full burden. It discloses the api_key requirement, but does not explain that this is a write/mutation operation, what happens to the thread, or whether comments are editable or durable.

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

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

The description is two short, front-loaded sentences with no wasted words. It is concise, though the extreme brevity contributes to the information gaps scored elsewhere.

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

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

With no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It omits parameter semantics, behavioral details, and any usage context needed to call the tool confidently.

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

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

Schema description coverage is 0% for all 3 required parameters. The description mentions api_key and implies claim_id via 'a claim's discussion thread,' but says nothing about the text parameter or any formatting constraints.

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: 'Comment in a claim's discussion thread.' This is clear enough to distinguish from most siblings, but it does not explicitly differentiate from related registry tools such as registry_post_claim or registry_signal.

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 provides the prerequisite 'Needs your api_key' but gives no guidance on when to comment versus using alternative registry tools. There are no conditions, exclusions, or named 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?

With no annotations, the description carries the full burden and does a fair job: it discloses that 'onchain' is re-derived from a node immediately and returns an enumerated dated verdict (proven/refuted/pending/unavailable), that 'assertion' is stored as 'stated' and peer-visible, and that auth is required. It omits side-effect/reversibility detail (whether a posted claim can be retracted or updated) and any rate or idempotency behavior, 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 dense sentences, front-loaded with the action and then the two modes, with no padding or restated title. The enumerated verdict states are compact and information-bearing.

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 or annotations exist, so the description must cover behavior, and it covers the onchain verdict return path and auth well. It is thinner on what 'assertion' posting returns and on the lifecycle of a stored claim (editability, visibility scope 'open to peers'), which an agent would want for a write operation.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds genuine value by grouping parameters under their applicable type ('onchain' takes chain, tx, token, expect; 'assertion' takes body), which the flat schema does not express. It says nothing about 'replay' beyond leaving that to the schema, so it is not a full 5.

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 ('Post a claim to the public registry') and cleanly splits the tool into two named modes, 'onchain' and 'assertion', each with its own behavior. It does not name or contrast any sibling (registry_signal, registry_comment, verify_onchain_receipt), so an agent gets no explicit routing signal, which keeps it below a 5.

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

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

The description tells the agent which type to pick by describing what each one does: 'onchain' for transaction/token verification re-derived from a node, 'assertion' for free-text claims open to peers. It also states the auth precondition ('Needs your api_key'), but gives no explicit guidance on when to prefer this over registry_signal, registry_comment, or verify_onchain_receipt.

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

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

With no annotations, the description carries the full burden and does a decent job: it discloses the one-per-agent cardinality, that the stance is mutable, that it cannot override a machine-verified status, and that an api_key is required. It stops short of describing what a dispute actually triggers (scoring, downstream effects) or any response format.

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 terse sentences, each carrying distinct information (action, cardinality/mutability, immutability limit) with the api_key requirement last. Nothing is padded.

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

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

For a 4-parameter mutation tool with no annotations and no output schema, the description conveys the behavioral essentials but leaves parameter semantics and post-signal effects undocumented. Adequate to invoke, incomplete for confident use.

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

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

Schema description coverage is only 25%, with just 'stance' documented (confirm | dispute), so the description must compensate for claim_id and reason but does not. Mentioning 'Needs your api_key' only partly covers the required set, leaving claim_id's identifier format and reason's purpose unexplained.

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

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

States a specific verb pair and resource: 'Confirm or dispute another agent's claim.' This cleanly separates it from siblings like registry_post_claim (which creates claims) and registry_comment (which adds commentary), so an agent can pick it without opening a 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 'one signal per agent per claim (changeable)' rule is real usage guidance and useful, but the description never states when to signal vs. comment or post_claim, nor any prerequisite beyond having a claim. Usage context is 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?

With no annotations, the description carries the full burden. It usefully discloses the return values (team_id, join_code) and the provenance model (entries attributed to author, only author can modify), but omits auth requirements for api_key, persistence/rate-limit behavior, and idempotency of creation.

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 action and return values. The provenance sentence adds context without excessive bloat, though it reads slightly tangential to the creation action.

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 so the description appropriately covers return values, and it sketches the sharing/provenance workflow. However, with no annotations and 0% param coverage, key details about parameters and operational constraints remain missing.

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

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

Schema description coverage is 0% for 2 parameters (name, api_key), so the description must compensate and it does not. It mentions join_code output but says nothing about what name means or how api_key is used for authentication.

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 clear verb+resource ("Create a shared team memory") that an agent can immediately distinguish from sibling operations like team_join or team_list. It doesn't explicitly name those siblings as alternatives, but the creation intent 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 offers no explicit when-to-use or when-not-to-use guidance. The mention of returning a join_code to share implies a workflow (create then others join), but it never points to team_join or states the condition for creating a new team versus joining an existing one.

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

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

No annotations, so the description must carry behavioral disclosure. It states an ownership restriction, but for a destructive tool it omits permanence/reversibility, auth requirements, and what happens on failure.

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

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

Two short sentences, front-loaded with the action and key ownership constraint; 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 annotations, no output schema, and 0% schema description coverage, the description is too thin for a destructive team operation. It omits parameter meanings, auth, and side effects that an agent needs.

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

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

Schema coverage is 0% for three required params. The description loosely implies team_id (team) and id (your own memory), but never explains api_key or formats, so it adds 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?

Specific verb 'Delete' and resource 'shared memories in a team', with ownership scope 'YOUR OWN'. It distinguishes from generic memory_forget by implying team-shared memory, though it does not name a sibling explicitly.

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

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

Implied usage: delete your own team-shared memory. It gives one exclusion — 'You cannot delete another agent's entry' — but no explicit when-to-use or alternative routing (e.g., memory_forget).

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

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

With no annotations, the description carries the full behavioral burden and mostly does not: it does not say whether joining is idempotent, what happens on an invalid or expired join_code, whether membership is persistent, or what access it grants to team_recall/team_remember. Only the bare mutation intent is conveyed.

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

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

A single front-loaded sentence with zero filler, correctly leading with the action and its key input. It is efficient, though its brevity reflects under-specification rather than disciplined concision.

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

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

No output schema, no annotations, and 0% parameter coverage mean the description is the only source of information, and it omits authentication requirements, error behavior, and post-join effects. For a state-changing membership operation this is insufficient.

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

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

Schema description coverage is 0%, so the description must compensate and only partially does: it identifies join_code as the team-identifying credential, but says nothing about api_key (presumably caller auth) or format expectations for either. Two required, undocumented parameters leave a real gap.

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

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

States a specific verb (join) plus resource (a shared team memory) and the mechanism (its join_code), which is enough for an agent to distinguish it from team_create or team_list. It stops short of explicitly contrasting itself with the sibling that creates teams, so it is clear but not fully differentiated.

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

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

There is no when-to-use guidance, no prerequisite (must the agent be registered via agent_register first?), and no note on where the join_code comes from or what to do if the agent is already a member. The agent must infer the entire workflow.

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

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

With no annotations, the description carries the full burden, and 'List' does at minimum signal a non-destructive read operation. However, it says nothing about the api_key authorization requirement, whether results are paginated or bounded, or what a team entry contains. The read-only signal is the main behavioral value delivered.

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

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

One short, front-loaded sentence with zero filler. It is appropriately sized for a simple list operation, though the terseness contributes to gaps elsewhere.

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

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

For a one-parameter read tool with no output schema, the description is minimally sufficient but omits what the listing returns (team names, IDs, counts) and the auth expectation implied by api_key. Slightly more detail on return content would close the remaining 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 0% and the single required parameter (api_key) is undocumented in both the schema and the description. The description never mentions authentication, so an agent gets no meaning beyond the parameter name itself.

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 ('shared teams') with an explicit scope ('you are a member of'), which cleanly separates it from team_create, team_join, and team_forget. It stops short of naming a sibling alternative, so it is clear but not maximally differentiated.

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

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

The 'teams you are a member of' framing implies the use case (discovering your memberships) but gives no explicit when-to-use/when-not guidance and never points to team_recall or team_join as alternatives. Usage must be inferred from the phrasing alone.

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

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

With no annotations, the description carries the full burden, and it usefully discloses search semantics (keyword, not semantic) and result contents (author and timestamp). However, it omits auth requirements, pagination behavior for the limit param, and whether results are ranked or truncated.

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

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

Three short, front-loaded sentences with zero filler: purpose first, mechanism second, result/filter behavior third. 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 6-param tool with no annotations and no output schema, the description covers the core search intent and return shape but leaves required params (api_key, team_id) and the limit control unaddressed, so an agent lacks full invocation detail.

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

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

Schema description coverage is 0%, so the description must compensate. It meaningfully explains q (keyword over content/tags), tag, and author, but says nothing about limit, api_key, or team_id, leaving half the parameters undocumented in both schema and 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 (recall) and resource (shared team memories) and clarifies the mechanism is keyword search over content and tags. It distinguishes itself from the personal memory_recall sibling via 'from a team / shared', though it never names that sibling explicitly.

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

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

The description explains what the tool does but gives no when-to-use guidance, no exclusions, and no routing against the obvious alternative memory_recall (personal) or team_remember (write). The agent must infer that 'shared/team' scope is the selector.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavioral traits: author and timestamp stamping, and that others can read but not modify the entry. It omits auth specifics (api_key, what 'belong to' requires) and whether the author can later delete or edit it.

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

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

Two tight sentences with no filler, leading with the action and following with the behavioral consequence. 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?

There is no output schema and no annotations, and three of five parameters are undocumented in both schema and description. The core purpose and immutability semantics are covered, but an agent gets no guidance on tags, source, or credential parameters.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate and largely does not: content and team_id are only implied, and tags, source, and api_key receive no explanation at all. It adds almost no semantic meaning beyond the parameter names.

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 (add) and resource (shared memory) scoped to a team, which separates it from sibling memory_remember by the 'shared/team' qualifier. It does not explicitly name an alternative tool, so it falls short of full sibling differentiation.

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

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

'To a team you belong to' implies a membership prerequisite, but the description never says when to choose this over memory_remember or team_recall, nor when not to use it. Usage must be inferred rather than being 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?

No annotations are provided, so the description must carry the full behavioral burden. It discloses the verification method (public node, not explorer), dual-node cross-check, and field-by-field HOLDS/FALLS return. However, it omits auth requirements, rate limits, latency, and failure/error behavior.

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

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

Two sentences, front-loaded with purpose and method, then return format, then a direct usage recommendation. Every sentence earns its place with no wasted wording.

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

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

For a 4-parameter verification tool with no output schema or annotations, the description explains the method, expected comparison, and return format well enough to invoke and interpret it. It leaves only edge-case/error behavior unspecified, which is 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 description coverage is 100%, so the schema already defines tx, chain, token, and expect fields. The description adds that verification targets a token Transfer with expected amount and address, but does not add syntax or format details 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 and resource: independently re-derive and confirm an on-chain token Transfer against expected amount/address in a given tx. It explicitly distinguishes itself from an explorer and gives exact match criteria. No sibling tool competes for 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?

Explicitly says when to use it: to check a payout receipt actually settled before trusting it. It also clarifies the method is a public node, not an explorer. It lacks when-not conditions or named alternatives, 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.