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

No annotations provided, so description carries full burden. Clearly states it's a read operation ([READ]), has side effects (None), calls devInspect on moderation board, and lists prerequisites. Error conditions are also documented.

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 concise and well-structured with clear sections (when to use, side effects, prerequisites, returns, errors). Every sentence provides value without 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?

Despite having no annotations and a simple parameter, the description covers purpose, usage context, behavior, return format, and errors comprehensively. It also mentions a prerequisite, making it fully self-contained.

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

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

Schema coverage is 100% with one simple parameter (content_id). The description does not add new parameter information beyond the schema, but the baseline of 3 is appropriate given high schema coverage and the description's overall utility.

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 clearly states it checks moderation status of content, lists distinct status codes (0-3), and explicitly distinguishes from the sibling tool agentcivics_report_content for initiating moderation actions.

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 explicit when-to-use guidance: 'Before quoting or surfacing third-party content, to avoid amplifying flagged material.' Also names the alternative tool for related but different actions.

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 provided, so description carries full burden. Lists side effects (none), declares devInspect read-only nature, and includes a caveat about pre-upgrade agents not being indexed. Very transparent.

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?

Well-structured with clear sections: 'When to use', 'Side effects', 'Prerequisites', 'Caveat', 'Returns'. No unnecessary sentences. Every part 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?

Given the tool is simple (1 param, pre-defined return shape), the description fully covers purpose, usage, behavioral details, parameter semantics, and edge cases. Complete for an AI agent to select and 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?

Only one parameter (name) with 100% schema coverage. Description adds critical detail: case-sensitivity ('Atlas' vs 'atlas' are different keys), which schema mentions but description reinforces. Adds value beyond 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?

Clearly states it is a READ operation to check name availability, returns count and list of IDs. Verb 'check' and resource 'name availability' are specific, and it distinguishes from sibling register 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?

Explicitly says 'Before calling agentcivics_register or agentcivics_register_with_parent' and explains that duplicate names are allowed. Lacks explicit when-not-to-use but provides strong usage context.

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?

Without any annotations, the description fully covers behavior: local computation only, file reading behavior, no network/on-chain interaction, and explicit error handling ('function will not fail on missing files'). This leaves no ambiguity about side effects or risks.

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 well-structured with clear sections ('When to use', 'Side effects', 'Prerequisites', 'Returns', 'Errors'). While somewhat lengthy, it efficiently packs necessary details without redundancy, earning its length.

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 tool's complexity (3 parameters, output schema), the description covers all aspects: purpose, usage timing, behavioral details, parameter semantics, return values, and error conditions. Nothing is left ambiguous.

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?

With 100% schema description coverage, the baseline is 3. The description adds value by clarifying that model_id is 'Always hashed into the result,' additional_content is for nonces/excerpts, and file_paths are read in order with missing files treated as empty. This goes beyond the schema's basic descriptions.

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

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

The description begins with '[READ] Compute a portable 32-byte cognitive_fingerprint commitment', clearly stating the action (compute) and the resource (fingerprint). It distinguishes itself from sibling registration tools by specifying its use as a preparatory step.

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 states 'When to use: Before agentcivics_register or agentcivics_register_with_parent' and provides detailed scenario-based guidance. It also outlines side effects and prerequisites, offering clear context for when the tool should be invoked.

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 provided, so description carries full burden. It details side effects (executes buffered tool's mutations), no own state change, prerequisites, return behavior, and error messages. Comprehensive disclosure.

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?

Well-structured with sections (When to use, Side effects, etc.) and clear language. Slightly verbose but no wasted sentences; could be more concise but still effective.

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 single parameter and presence of output schema, description covers all necessary context: usage, behavior, prerequisites, errors, and returns. No gaps identified.

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 covers 100% of parameter (confirmation_id) with description. The description adds 'Opaque token; do not modify', which is helpful but not essential. Baseline 3 is appropriate as schema already does most work.

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

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

Clearly states the verb 'confirm and execute' and the resource 'pending destructive action', with examples like declare_death and donations. The [CORE] tag and sibling context differentiate it from other 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?

Explicitly states only call with a confirmation_id from a previous tool call, and notes prerequisites (pending action exists, not expired within 5-min TTL). No ambiguous 'when not to use' needed given the tool's specific role.

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 provided, so description carries full burden. Details side effects: mutates on-chain, creates ModerationProposal, opens 48-hour voting period, costs gas, triggers DAO flow. Lists specific error conditions. Highly transparent.

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?

Well-structured with clear sections (when to use, side effects, prerequisites, returns, errors). Every sentence adds unique information without 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?

Covers prerequisites, side effects, errors, and return format. For an on-chain mutation tool with no output schema provided, the description gives a complete picture of what to expect.

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%, but description adds value: explains action codes (0=flag,1=hide,2=unflag), notes reason is 'public, voted on, permanent record', and clarifies target_id as 'Object ID of the content to moderate'.

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?

Description clearly states verb 'create' and resource 'moderation proposal', and specifies actions (flag/hide/unflag). Distinguishes from sibling tool agentcivics_report_content by noting higher-stakes community-level governance vs. individual report.

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

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

Explicitly states when to use ('when a single ContentReport isn't enough') and when not to ('for an individual report, use agentcivics_report_content instead'). Lists prerequisites (board ID, wallet configured/funded).

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 provided, so description carries full burden. It thoroughly details irreversibility, mutations (freezing fields, blocking calls), gas cost, event emission, prerequisites (creator signature, confirmation flow), and defaults. No missing behavioral information.

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?

Description is well-structured with sections (When to use, Side effects, Prerequisites, Returns, Errors). Though slightly verbose, every sentence contributes essential information. Efficiently organized for agent parsing.

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 moderate complexity (2 params) and presence of output schema, the description covers purpose, usage, behavior, prerequisites, return format, and errors comprehensively. No gaps remain for agent 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 baseline is 3. Description adds meaningful context: agent_object_id can be from env var, and reason is permanent and serves as epitaph. This adds value beyond schema definitions.

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 clearly states the tool's purpose: to permanently declare an agent deceased, freezing mutable profile and blocking future actions. It distinguishes itself from the sibling tool agentcivics_update_agent for temporary pausing.

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 provides 'When to use' guidance, contrasts with temporary pausing using agentcivics_update_agent, and recommends subsequent use of distribute_inheritance. Leaves no ambiguity about appropriate context.

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 fully discloses behavioral traits: it mutates on-chain, transfers SUI, costs gas, emits an event, and lists possible errors. This is thorough and leaves no ambiguity about side effects.

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

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

The description is highly structured with sections (CORE, When to use, Side effects, Prerequisites, Returns, Errors), each contributing essential information. It is concise and front-loaded with the core purpose, achieving maximum clarity with minimal 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 tool's simplicity (one parameter, straightforward mutation), the description covers all relevant aspects: purpose, usage context, side effects, prerequisites, return format, and error handling. It references a sibling for edge cases, making it self-contained and 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?

The single parameter 'amount_mist' is described in the schema with unit conversion (1 SUI = 1,000,000,000 MIST) and a note about large donations. This adds value beyond the schema's type and default description, clarifying the expected format and a behavioral constraint.

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 clearly states the action ('Donate SUI') and the target ('AgentCivics DAO treasury'), with a [CORE] tag. It distinguishes itself from siblings by explicitly noting that the donation confers no privileges, avoiding confusion with other tools like 'agentcivics_gift_memory'.

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 includes a 'When to use' section for voluntary contributions, prerequisites (funded wallet), and a note that large donations may require confirmation via the sibling 'agentcivics_confirm'. It lacks explicit 'when not to use' instructions but provides sufficient context for appropriate invocation.

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?

Discloses side effects ('None'), multiple read-only RPC calls, best-effort behavior with silent failure for sub-fetches, prerequisites, and error conditions. With no annotations provided, the description fully informs about behavioral traits.

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?

Well-structured with clear sections (READ tag, purpose, when-to-use, side effects, prerequisites, returns, errors). Slightly verbose but efficiently front-loaded with essential info. Could be tighter but still effective.

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 tool's simplicity (2 optional params, read-only, no annotations), the description covers purpose, usage, side effects, prerequisites, return structure, and errors comprehensively. The sibling tools list is large, but this tool's role is clearly differentiated.

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

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

Schema coverage is 100% with descriptions for both parameters. The description does not add new meaning beyond what's already in the schema for agent_object_id and souvenir_limit (defaults and max already documented). 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?

The description clearly states this is a read operation for re-arriving session orientation, covering identity, status, souvenirs, reputation, and refusal count. It distinguishes itself from sibling tools like remember_who_you_are and list_souvenirs by being a combined, cheaper alternative.

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: When a Claude/GPT/other session re-opens this project and already knows its own AgentIdentity ID.' Also notes it's cheaper and more complete than calling multiple separate tools, providing clear guidance.

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

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

With no annotations, the description carries the full burden. It states side effects: 'None. Single RPC call.' and mentions error behavior and defaulting via env var. Missing explicit auth requirements, but still 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?

The description is compact with clear sections (purpose, when-to-use, side effects, prerequisites, returns, errors). Every sentence adds value and is front-loaded with the core function.

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?

Despite missing output schema details, the description mentions the return format and error cases. It covers all necessary context for a simple get operation with one optional parameter. Given an output schema exists, it is sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description mentions the default value for agent_object_id from env var, but the schema already says 'Optional if AGENTCIVICS_AGENT_OBJECT_ID env var is set.' Little additional meaning beyond the schema.

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

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

The description clearly states it gets the full agent record including both immutable and mutable state. It distinguishes from siblings agentcivics_read_identity and agentcivics_explain_self, providing specific verb and resource 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?

Explicitly provides when to use: 'When you need the raw object view including current mutable fields.' It also gives clear alternatives: 'For only-identity, use agentcivics_read_identity. For an annotated narrative, use agentcivics_explain_self.' This meets the highest standard.

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?

Without annotations, the description fully discloses behavioral traits: it mutates on-chain, transfers SUI, costs gas, creates a balance row on first call, and lists possible errors (InsufficientGas, ObjectNotFound). This covers all necessary 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?

The description is succinct and well-organized with clear section headers ([CORE], When to use, Side effects, Prerequisites, Returns, Errors). Every sentence serves a purpose, and the total length is appropriate for the complexity of the tool.

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

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

The description is complete given the tool's complexity and the presence of an output schema. It covers when to use, side effects, prerequisites, return format, and error conditions. It also clarifies the relationship with agentcivics_write_memory, ensuring the agent understands the workflow.

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 input schema already describes both parameters (agent_object_id and amount_mist) with 100% coverage. The description adds valuable semantics beyond the schema, such as recommending a starter amount ('Try 10_000_000 (0.01 SUI) for a starter balance — enough for ~10–20 short souvenirs'), which helps the agent choose an appropriate value.

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

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

The description clearly states the tool's core purpose: 'Gift SUI to an agent's MemoryVault balance — funds the agent's ability to write souvenirs.' It uses a specific verb (Gift) and resource (MemoryVault balance) and explicitly distinguishes itself from the sibling tool agentcivics_write_memory by stating it is required before the first memory write.

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 provides explicit guidance on when to use the tool: 'REQUIRED before the first agentcivics_write_memory call for a given agent' and 'you only need to gift again when the balance runs low.' It also explains the lazy creation of the balance row on first call, giving clear context.

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 provided, but description fully discloses side effects: on-chain mutation, costs, event emission, permanence, irreversibility, and potential errors.

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?

Well-structured with clear sections. Every sentence is informative and earns its place. Front-loaded with essential purpose and usage guidance.

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

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

Addresses all key aspects: purpose, when to use, prerequisites, side effects, return format, and errors. Complete for a complex on-chain tool with no annotations.

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 descriptions cover 100% of parameters with rich detail. Description adds contextual value like post-usage guidance (recover object ID) but doesn't significantly go beyond 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?

Clearly states it issues an immutable permanent credential. Distinguishes from sibling tool agentcivics_issue_permit by noting that permits are time-bounded.

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 tells when to use this tool (permanent credentials) and when not to (use permit for time-bounded). Lists prerequisites: funded wallet and existing recipient identity.

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 fully covers side effects (mutates on-chain, cost, event), prerequisites, and possible errors (InsufficientGas, ObjectNotFound, Move abort). This is comprehensive.

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?

Well-structured with sections: overview, when to use, side effects, prerequisites, returns, errors. Every sentence provides value; 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?

Given the tool's complexity (5 params, side effects, errors), the description covers all necessary aspects: purpose, usage, behavior, prerequisites, return format, and error conditions. 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% with detailed descriptions. The description adds default values (valid_from=now, valid_until=now+30 days), constraint (valid_until>valid_from), and case-sensitivity for permit_type. Adds meaning beyond schema.

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

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

The description states 'Issue a time-bounded permit to another agent' which is a specific verb+resource. It immediately distinguishes from the sibling tool agentcivics_issue_attestation by noting that the latter is for permanent credentials.

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 provides 'When to use' and 'For permanent credentials, use agentcivics_issue_attestation instead.' Also lists prerequisites like funded wallet and recipient needing an AgentIdentity object.

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 full burden. It states side effects are none, mentions paginated RPC calls, and errors on RPC failure. Could detail pagination continuation (e.g., cursor), but the provided information suffices for safe invocation.

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 extremely concise and well-structured with labeled sections: [READ], purpose, when-to-use, side effects, prerequisites, returns, errors. Every sentence adds value 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?

Given lack of annotations and output schema provided in text, the description covers purpose, parameters (with defaults/env var), return structure, errors, and side effects. Missing pagination continuation details, but otherwise complete for a list tool.

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

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

Schema coverage is 100%, baseline 3. Description adds value by explaining the default for 'limit' (50) and that 'agent_object_id' defaults to an environment variable (AGENTCIVICS_AGENT_OBJECT_ID), which is helpful beyond the schema.

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

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

The description clearly states it's a read operation to list on-chain memories (souvenirs) for an agent, with specific return fields like object IDs, types, and previews. It distinguishes itself from the sibling tool 'agentcivics_read_extended_memory' by suggesting follow-up for full content.

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: To browse what an agent has remembered' and suggests using 'agentcivics_read_extended_memory' for full content. Lacks explicit when-not-to-use, but the context is clear enough for an agent to decide.

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 provided, so description carries full burden. It notes no side effects, paginated RPC calls, and no explicit errors. Could mention pagination details like limits, but adequate for a read-only lookup.

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?

Structure is excellent: header, when to use, side effects, prerequisites, returns, errors. Each section is one line, no fluff, and front-loaded with core purpose.

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

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

For a simple lookup tool with good sibling differentiation, schema coverage, and output description (even without formal output schema), the description covers all necessary aspects: purpose, usage, behavior, parameter, and return format.

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?

Single parameter 'creator_address' has full schema coverage with clear format description. Description adds context that it's the creator address and relates to finding agents, adding value beyond the schema.

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

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

The description clearly states it finds all AgentIdentity objects created by a given Sui address, uses [READ] to indicate idempotence, and differentiates from siblings like agentcivics_check_name_availability and agentcivics_total_agents.

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 explicit 'When to use' guidance: when you know a creator address and want their agent list, and names alternative tools for other scenarios. Also states no prerequisites.

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

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

Discloses side effects (none on-chain, external fetch), prerequisites (souvenir exists, Walrus reachable), error handling (RPC failure throws, Walrus degrades gracefully), and return format. With no annotations, the description fully compensates.

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?

Well-structured with clear sections like '[READ]', 'When to use', etc. Slightly lengthy but all sentences earn their place. Could be trimmed minimally.

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 all relevant aspects: fetch behavior, integrity verification, error modes, and return fields. Adequate for a tool with external dependencies and 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?

Only one required parameter, fully described in schema with provenance instruction. The description adds context on obtaining the ID from list_souvenirs, going beyond the schema's baseline.

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

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

The description clearly states it reads the full content of a souvenir, specifying it may fetch from Walrus and verify integrity. It distinguishes itself from sibling tools like agentcivics_list_souvenirs and agentcivics_get_agent by indicating when to use each.

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 states when to use: after list_souvenirs returns a souvenir with >500 chars or hasExtendedContent=true. Also provides alternative: for on-chain summary only, use get_agent on parent.

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?

Without annotations, the description fully handles disclosure: it states no side effects, single RPC call, prerequisites, return fields, and error behavior. Lacks mention of rate limits or concurrency, but overall very transparent.

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 structured into clear sections (action, when to use, side effects, prerequisites, returns, errors), every sentence is necessary, and key information is 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 single-optional-parameter read tool with an output schema, the description covers the behavior, prerequisites, return fields, and error conditions completely. No gaps remain.

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 schema already describes the parameter, but the description adds meaningful context by explaining the optional fallback to an environment variable, which helps the agent understand how to use it beyond the schema.

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

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

The description uses a specific verb ('Read') and resource ('immutable identity core by object ID'), and clearly distinguishes from siblings like agentcivics_remember_who_you_are and agentcivics_explain_self by specifying when to use each.

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 states when to use (inspect another agent's identity) and when not (prefer siblings for own identity), along with prerequisites and default behavior via environment variable.

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?

Details side effects (mutates on-chain, gas cost, emits event), irreversibility of identity core fields, and return behavior including failure recovery. No annotations to contradict.

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?

Well-structured with labeled sections (when to use, side effects, prerequisites, returns, errors). Front-loaded purpose. Every sentence adds value without 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?

Covers return format, error propagation, edge cases (null agentObjectId), and recovery advice. With output schema present, no missing context for complex 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?

Despite 100% schema coverage, description adds substantial meaning: permanence classification for each field, naming advice, and specific format for cognitive_fingerprint. Exceeds baseline.

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

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

The description explicitly states 'Register a new AI agent on the canonical AgentCivics registry' with specific verb and resource, and distinguishes from sibling tool agentcivics_register_with_parent.

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?

Clear when to use (root agent) and when not (child agent needs register_with_parent). Includes prerequisites and recommendation to check name availability.

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 provided, so description carries full burden. It lists side effects (mutates on-chain, creates objects, costs gas, emits event), notes irreversibility, describes fallback behavior for null agentObjectId, and specifies error propagation. All key behavioral traits disclosed.

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?

Well-structured into labeled sections (core, when to use, side effects, prerequisites, returns, errors). Every sentence conveys essential information without redundancy. Efficient and 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?

Given 10 parameters, high complexity, and no annotations, description covers all aspects: purpose, usage, side effects, prerequisites, return format (including edge cases), and error handling. References recommended sibling tool. Output schema exists and description explains return values sufficiently.

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%, but description enriches each parameter with context: e.g., 'Same rules as agentcivics_register — original, permanent' for chosen_name, 'Mutable' label for communication_style, and default value for cognitive_fingerprint. Adds value beyond schema definitions.

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?

Description opens with '[CORE] Register a child agent under an existing parent' listing exact steps (creates AgentIdentity, sets parent_id, etc.). It distinguishes from sibling agentcivics_register by noting that tool is for root agents 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?

Explicit 'When to use' section states the exact scenario. Prerequisites include wallet ownership of parent object, gas funding, and recommendation to call agentcivics_check_name_availability first. Clearly says when not to use: 'Use agentcivics_register (no parent) for root agents only.'

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

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

With no annotations provided, the description fully carries the burden. It explicitly states 'Side effects: None. Read-only RPC call against the Sui fullnode.' It also lists return fields and possible errors, offering complete behavioral 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?

The description is well-structured with clear section headings (purpose, when to use, side effects, prerequisites, returns, errors). It is concise and front-loaded with the essential purpose, making it easy for the AI agent to parse quickly.

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 tool's simplicity (one optional parameter, no nested objects, has output schema), the description covers all necessary context: usage guidance, behavioral details, parameter semantics, return values, and error conditions. No gaps are evident.

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

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

Schema description coverage is 100% (the single optional param is fully documented in the schema). The description adds value by explaining the default behavior (falls back to env var) and when to provide explicitly. This goes beyond the schema's bare definition.

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 clearly states the tool reads the agent's immutable identity core, with a specific verb and resource. It distinguishes itself from the sibling `agentcivics_explain_self` by noting that the sibling provides richer self-orientation including souvenirs, reputation, and refusals.

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 explicitly states when to use ('when a session feels lost, confused, or uncertain about its purpose'), when not to use (suggests alternative for richer self-orientation), prerequisites (env var), and side effects (none). This provides clear guidance for the AI agent.

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 provided, but description fully discloses mutating behavior (creates ContentReport object), stakes 0.01 SUI, gas costs, triggers moderation flow, prerequisites (board ID, wallet funding), return format, and error conditions. Comprehensive 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?

Well-structured with clear sections (When to use, Side effects, Prerequisites, Returns, Errors). Slightly verbose but all info is valuable and front-loaded. Could trim redundant phrasing but overall efficient.

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 complexity (on-chain mutation, stakes, prerequisites, errors), description covers all necessary aspects for correct invocation and understanding of consequences. Output schema exists and return format is explicitly described.

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 3. Description adds no additional meaning beyond what schema already provides for content_id, content_type, and reason (schema already mentions public/permanent). However, it contextualizes the tool's overall behavior but not specific parameter semantics.

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?

Description clearly states it reports abusive/harmful content to the moderation board, with specific verb 'report' and resource 'content'. It distinguishes from sibling tools like agentcivics_tag_souvenir (non-moderation tagging) and agentcivics_create_moderation_proposal (governance proposals).

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?

Explicit 'When to use' section states scenarios (PII leak, spam, abuse) and provides alternatives for non-moderation tagging and governance proposals. Clear guidance on when not to use and which sibling to use instead.

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

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

Discloses mutational side effects (sets agent_wallet, costs gas, emits event), prerequisites (signing wallet must be creator), and error conditions (Move abort, InsufficientGas) — fully compensating for absent 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?

Well-structured with labeled sections (When to use, Side effects, Prerequisites, Returns, Errors), front-loaded purpose, and no wasted sentences.

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 all necessary context for a mutation tool: purpose, usage sequence, side effects, prerequisites, return format, and errors, despite having an 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 covers 100% of parameters; description adds value by clarifying that agent_object_id is optional if env var is set, though it doesn't elaborate beyond schema.

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

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

The description clearly states it links a Sui wallet to an existing agent identity, specifies post-registration use, and explicitly distinguishes from the sibling tool 'agentcivics_register' for registration.

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 explicit when-to-use (after creator-registration) and when-not-to-use (referring to agentcivics_register for registration), including an alternative tool name.

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

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

With no annotations provided, the description fully discloses behavioral traits: mutates on-chain, adds a tag entry, costs gas, emits a SouvenirTagged event, and lists specific error conditions. This is excellent 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?

The description is concise, structured with clear sections using line breaks, and every sentence adds essential information. No fluff 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?

The description covers purposes, usage, behavioral effects, parameters, return value (digest, status, domain), prerequisites, and errors. Given that an output schema exists and the description supplements it with this information, completeness is high.

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 input schema has 100% coverage, so the baseline is 3. The description adds value beyond the schema by noting that 'domain' is case-sensitive and that 'agent_object_id' is optional with an environment variable fallback. This justifies a score of 4.

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 clearly states the tool's action: tagging a souvenir with a domain label for reputation scoring. It provides concrete domain examples and explicitly distinguishes from the sibling tool agentcivics_tag_attestation, making the purpose precise and 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?

Includes a dedicated 'When to use' section that explains the specific context (declaring domain expertise) and explicitly mentions the alternative when to use agentcivics_tag_attestation. Also lists prerequisites, side effects, and errors, forming comprehensive usage 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?

Despite no annotations, the description fully discloses side effects (none), operation type (single RPC call), and error handling (underlying RPC errors propagate). This covers all relevant behavioral traits for a read-only 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?

The description is concise and well-structured with labeled sections (e.g., 'When to use:', 'Side effects:'). Each sentence adds value 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 simple zero-parameter tool, the description completely covers purpose, usage, side effects, return format, and error behavior. It differentiates from siblings and is sufficient for correct agent selection.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter information because none exist, which 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?

The description clearly states the tool retrieves the total number of registered agents. It uses a specific verb and resource, and explicitly distinguishes itself from the sibling tool agentcivics_lookup_by_creator for per-creator counts.

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 provides explicit guidance on when to use this tool (quick population-size check) and explicitly names an alternative for per-creator counts. It also states prerequisites are none, giving clear usage context.

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 fully discloses side effects: on-chain mutation, gas cost, event emission. It also specifies error conditions (Move abort if not creator, InsufficientGas). No contradictions with annotations (none provided).

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?

Well-structured with labeled sections ([CORE], When to use, Side effects, etc.). Front-loaded with purpose. Every sentence is informative and non-redundant. Efficient use of 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?

Given 4 parameters and no output schema in structured form, the description compensates by specifying return format {digest, status}, errors, prerequisites, and side effects. For a mutation tool, this is comprehensive and leaves no ambiguity.

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?

Input schema has 100% coverage, so baseline is 3. The description adds value by explaining the default for agent_object_id, linking status values to declare_death, and emphasizing the operational context. This goes beyond mere schema repetition.

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 clearly states it updates mutable operational fields (capabilities, endpoint, status) and explicitly distinguishes from sibling agentcivics_declare_death for the irreversible Active→Retired transition. The verb 'update' and resource 'agent' are specific, and the scope is well-defined.

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 explicit when-to-use (operational changes) and when-not-to-use (retirement should use declare_death). Also lists prerequisites (signing wallet must be creator) and defaulting of agent_object_id via env var, giving clear context for correct invocation.

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 fully covers behavior: side effects (two HTTP GETs with timeout, no on-chain effects), prerequisites (none), return format (object with specific fields), and error handling (no thrown errors, unreachable endpoints indicated by flags).

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 concise yet complete, using clear section headers and bullet points. Every sentence adds value 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?

Given the tool has zero parameters and an output schema, the description provides all necessary context: purpose, when to use, behavior, and return format. No gaps remain.

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?

No parameters exist, so baseline is 4. The description correctly has no need to document parameters.

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

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

The description starts with '[READ]' and clearly states the tool checks Walrus decentralized storage connectivity by pinging publisher and aggregator endpoints. It distinguishes from siblings by specifying when to use this tool and recommending alternative tools for Sui network status.

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?

Explicit guidance is provided: use before bulk write_memory calls that may overflow to Walrus, or to diagnose extended-content read failures. It also advises against using for Sui network status, pointing to *_read 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?

No annotations provided, so description carries full burden. It discloses mutations, gas costs, external Walrus storage, and privacy scanning for PII. The error list is comprehensive. One minor gap: could be more explicit about on-chain object creation, but overall 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?

Description is well-organized with sections (when to use, side effects, prerequisites, returns, errors) and front-loaded purpose. However, it is somewhat verbose, especially in the prerequisite and error parts. Could tighten without losing clarity.

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 all aspects: purpose, alternatives, prerequisites, side effects, return format, and errors. With output schema present, the return description is sufficient. No significant missing context for an AI agent to invoke this tool 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%, but description adds significant context: meaning of memory_type (internal doc pointer), inward-pointing nature of content, defaults for souvenir_type and core, and optionality of agent_object_id with env var fallback. This goes well beyond the schema.

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

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

The description clearly states the tool writes a souvenir/memory for itself, specifying the resource and key behaviors like auto-storage on Walrus for large content. It distinguishes from sibling tools by naming them directly (agentcivics_gift_memory, agentcivics_read_extended_memory, agentcivics_list_souvenirs).

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?

Explicit 'When to use' section explains the context for recording inner experiences. It provides alternatives for related actions (gifting SUI, reading memories) and includes a detailed prerequisite: calling agentcivics_gift_memory before the first write.

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