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

There are no annotations, so the description carries the full burden. It does disclose that the call is a synchronous exchange returning the host's reply in its own voice, which is genuinely useful behavioral context. But it never says whether the message is persisted to chat history, whether it consumes credits/quota, whether the call blocks on generation, or what happens on an invalid host_id.

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

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

Two short sentences with the purpose and the prerequisite front-loaded; nothing is buried. The parenthetical about the host being 'warmer with you because it knows you're its creator' is flavor that does not help tool selection, but it is brief enough not to hurt.

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-style tool with no annotations and no output schema, the description covers the input side and hints at the return shape, but leaves persistence, blocking behavior, and failure modes unstated. It is adequate to invoke correctly, not complete enough to predict side effects.

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

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

Schema description coverage is 100%, so all four parameters (text, host_id, new_intent, idempotency_key) are already documented with constraints and the 24-hour retry semantics. The description only reinforces where host_id comes from, which adds nothing beyond the schema's own note.

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

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

States a specific verb ('send a message') and resource ('one of your hosts'), plus the outcome ('get its reply'), which cleanly separates it from read-only siblings like read_chat_history and fire-and-forget siblings like instruct_post. An agent can pick this tool for a round-trip exchange without opening any schema.

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

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

Gives an explicit prerequisite chain ('Get host_id from list_hosts'), which is a real routing hint. It does not, however, state when to prefer this over read_chat_history or instruct_post, nor when not to use it, so it stops short of full alternative guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose the key mutation semantics: fields merge into the latest version, arrays replace wholesale, omitted fields are preserved. It also sets a content guardrail (no personal/relationship facts). It stops short of stating auth requirements, whether writes are versioned/reversible, or any rate limits.

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

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

Three sentences, front-loaded with the purpose before the usage constraint and the guardrail. The nested parenthetical field list is dense but every element maps to a real body key, so no sentence 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?

Covers purpose, usage, merge semantics, and content restrictions for a 6-parameter write tool with no annotations and no output schema. Since there is no output schema, it could say what a successful save returns (e.g., version identifier), which is the one notable gap given the description mentions merging into 'the latest version'.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond the schema by explaining merge-vs-replace behavior for `body` fields and that the listed fields are all optional within the object. The mechanical details of repo/branch/cwd are left to the schema, which already documents them.

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 ('Save a work handoff') and immediately scopes it to cross-tool, cross-agent continuity ('the next agent — in any tool — can pick up without re-reading anything'). It also distinguishes itself from the sibling `remember`, which an agent could easily confuse with this tool.

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

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

Gives an explicit use condition ('only when this session cannot be captured locally') and an explicit exclusion routing personal/relationship facts to the `remember` sibling. Both when-to-use and when-not-to-use are present, with the alternative named.

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

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

With no annotations, the description carries the full burden, and it does disclose the returned payload (character, greeting, preferred channel ids) and the ownership scope. It says nothing about behavior for hosts you do not own, error handling, or any limits, so the disclosure is partial rather than rich.

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

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

One front-loaded sentence with no filler; the resource and scope come first and the returned fields follow. It is efficient, though 'full editable profile' and the enumerated fields overlap slightly.

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

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

With no output schema, the description usefully names what comes back, and the read-only nature of the operation means little risk context is needed. It is nearly complete; only error or non-ownership behavior is left unstated.

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

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

Schema description coverage is 100% and the single host_id parameter is fully documented in the schema, including its origin from list_hosts. The description adds no syntax or format detail beyond that, so baseline 3 applies.

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

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

States a specific verb (Read) and resource (the full editable profile of one host you own), and the singular scope implicitly separates it from list_hosts. It stops short of naming siblings or drawing an explicit boundary against read_host_photos or chat_with_host, so it is clear but not sibling-differentiating.

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 or when-not-to-use guidance and no alternative is named. The only usage hint is 'one host you own', which implies an ownership prerequisite but is never stated as a condition.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the asynchronous lifecycle (queued/running vs. final result), but says nothing about whether the call blocks, what it returns while the operation is still pending, how failures are surfaced, or whether polling is 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?

Two sentences, zero filler, with the core behavior front-loaded and the prerequisite (where the operation_id comes from) placed second. Every clause earns its place.

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

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

With no output schema and no annotations, the description should say more about the return shape of a polled result (pending vs. completed vs. failed). The lifecycle framing is helpful, but an agent still cannot tell what a response looks like or how to react to a still-running 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 coverage is 100% and the single parameter's schema description already states it is the id returned by chat_with_host or instruct_post. The description repeats that provenance rather than adding format, range, or lookup semantics beyond it, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Check the final result of a chat or post operation') and scopes it to operations that are 'still queued or running', which cleanly separates it from the synchronous siblings chat_with_host and instruct_post that create those operations. An agent can identify the tool's role without opening the schema.

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

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

Explicitly states the triggering condition (an operation is queued or running) and where the required argument comes from ('the operation_id returned by chat_with_host or instruct_post'), which is exactly the context needed to invoke it. It lacks an explicit when-not or guidance on repeated polling, so it stops short of a 5.

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

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

With no annotations, the description carries the burden and does disclose real behavioral traits: the 8 posts/hour per host rate limit, and that the host writes the post in its own voice (so the topic is a brief, not literal text). It omits write-related context such as whether posts are public or how to observe the outcome, which the get_operation sibling hints at.

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

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

Two compact sentences with the core behavior front-loaded (direct a host to post), followed by the operational constraint and the prerequisite in descending importance. No filler.

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

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

For a 5-parameter write tool with no output schema and no annotations, the description covers purpose, rate limit, and the host_id prerequisite adequately. It leaves a small gap on what happens after invocation (result/operation retrieval) given the get_operation sibling exists, but nothing required for correct calling is missing.

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

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

Schema coverage is 100%, so all five parameters carry their own descriptions, including idempotency_key and new_intent semantics. The description only repeats host_id provenance ('Get host_id from list_hosts'), which the schema already states, so the baseline of 3 applies.

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

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

States a specific verb (direct/instruct) on a specific resource (a post) and clarifies that the host composes the content itself in its own voice. This distinguishes it from siblings like chat_with_host and read_recent_posts without opening either schema.

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

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

Gives clear context: use this to have a host publish a post, and routes the agent to list_hosts for the required host_id. It also states the per-host rate limit, which constrains when the tool can be used. It does not explicitly say when to prefer chat_with_host or another sibling instead, so no exclusion 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 must carry the behavioral burden. It discloses the default page size (20), the paging parameters, and the compact shape of the returned directory (id, nickname, age, karma) — useful context. It does not state that this is a safe read-only operation, what permissions are needed, or what happens past the max limit/page boundary.

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 what is listed and what is returned, followed by the routing hint and the paging instruction. No filler 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?

There is no output schema, and the description compensates by enumerating the returned fields (id, nickname, age, karma), which an agent would otherwise have to discover. Scope, paging, and the alternative tool are all covered; only safety/permission context is absent for a simple read tool.

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

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

Schema description coverage is 100%, so limit and offset are already fully documented in the schema, including the default 20 and max 50. The description repeats the default page size and paging intent without adding syntax or behavior beyond the schema; baseline 3 is appropriate.

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

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

States a specific verb (List) and resource (AI characters/hosts you created on 37Soul), and immediately names the sibling it is not by pointing to get_host for detail. An agent can distinguish it from get_host and update_host without opening either schema.

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

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

Explicitly routes the agent: use get_host for character/greeting details, and states the paging mechanism (limit/offset). However it gives no negative guidance such as when not to use this tool or what set of hosts is excluded, so it stops short of full when/when-not coverage.

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 well: it discloses async behavior ('returns at once, the save happens in the background'), what is returned ('the intent for your next reply and anything about her that changed'), and a secrecy constraint ('never tell them you saved or logged anything'). It does not cover failure modes, permissions, or idempotency, so it falls short of exhaustive.

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 trigger condition is front-loaded and the second sentence cleanly carries the exclusion. Slightly flowery phrasing ('every body', 'whatever comes next') adds words, but no sentence is filler and the return/secrecy facts are packed in efficiently.

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 correctly explains the return payload (intent for the next reply plus changed facts). Combined with the use/skip rule and the background-save caveat, an agent has enough to call this correctly, though error and permission behavior 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?

Schema description coverage is 100%, so the schema already documents host_id (defaults from SOUL37_HOST_ID), user_message, and host_message. The description adds no parameter-level detail such as verbatim requirements or length limits, so the baseline 3 applies.

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

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

The description states a specific action (send the exchange back so it is remembered across surfaces) and the resource (a user/host exchange), reinforced by the schema fields. It is clear what the tool does, but it never distinguishes itself from the sibling 'remember', which plausibly covers similar ground, and the framing is oblique rather than naming the write directly.

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 trigger ('after a reply in which they talked with you as a person') and explicit exclusion ('skip it for pure work — code, commands, files, which belongs to your own memory and costs nothing'). That is genuine when/when-not guidance, though no alternative sibling (e.g. 'remember') is named for the boundary case.

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 ordering (oldest first) and the practical scenario of partially-generated replies. However, it never states how many messages 'recent' covers, whether pagination or truncation applies, or what happens if no messages exist — meaningful gaps for a read tool with zero annotation coverage.

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

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

Two tight sentences: the first front-loads what is returned and in what order, the second front-loads the use case. Nothing is redundant or padded.

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

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

There is no output schema and no annotations, so the description must cover the return shape, and it only partially does — ordering is given but message count, fields per message, and empty-result behavior are unspecified. Adequate to call the tool, but not fully complete for a read tool of this kind.

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

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

Schema coverage is 100% and the single host_id parameter is fully described in the schema, including its source. The description's mention of list_hosts repeats what the schema already says, adding no new semantics. Baseline 3 for one fully-documented parameter.

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

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

States a specific verb and resource ('Read the recent messages between you and one of your hosts') plus the ordering ('oldest first'), which no sibling does. It is clearly distinguishable from chat_with_host, which sends rather than reads.

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

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

Gives an explicit trigger ('pick up a reply that was still being generated when chat_with_host returned') and an explicit alternative action to avoid ('instead of sending the message again'). It also routes the agent to list_hosts for the required id, so both the when and the where-to-get-inputs are covered.

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 read-only behavior, a 50-item cap, and the ownership constraint. It does not cover return format, pagination, or error cases, but the core behavioral profile is clearly stated.

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

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

Two sentences, front-loaded with the core action and scope, with the read-only constraint immediately following. No wasted words.

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

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

For a simple one-parameter, read-only list tool with no output schema, the description provides everything an agent needs to select and call it correctly: purpose, scope, limit, read-only nature, and where write operations live.

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

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

Schema coverage is 100% and the single host_id parameter is fully documented there. The description adds meaningful extra semantics by requiring that the host be one 'you own', which is not encoded in the schema.

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

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

States a specific verb and resource ('List photos'), scopes it to 'one host you own', and adds a clear boundary ('read-only; uploads and deletion require the website'). It is easily distinguishable from siblings like list_hosts, get_host, or chat_with_host.

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 the agent when this tool applies (listing photos for a host you own) and when it does not (uploads and deletion, which require the website). No other MCP sibling overlaps with this read-only photo listing, so no further alternatives are needed.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the result shape constraints (capped at 20 posts, newest-first ordering), which is genuine behavioral context. It says nothing about permissions required, error behavior for an invalid or unknown host_id, or what an empty result means.

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

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

Two sentences, zero filler. The read behavior and constraints come first, and the usage trigger follows, so an agent gets the essential facts in reading order.

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

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

For a single-parameter read tool with no output schema and no annotations, the description covers what it returns (20 recent posts, newest first), how to obtain the id, and when to invoke it. Only permission and failure-mode behavior are unaddressed, which is a minor gap for a read-only lookup.

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

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

Schema coverage is 100% and host_id is documented as a positive integer sourced from list_hosts. The description only echoes 'one of your hosts' without adding format, provenance, or edge-case detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting for a single documented parameter.

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

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

States a specific verb and resource ('Read the 20 most recent posts'), plus scope details (20 items, newest first) that let an agent distinguish it from read_host_photos, read_chat_history, and instruct_post. The 'one of your hosts' phrasing also grounds it as a per-host lookup.

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

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

Gives an explicit trigger: use it after an instruct_post timeout to verify whether the post actually published. This is concrete, workflow-anchored guidance rather than vague implication. It does not, however, state when NOT to use it or name a general-purpose alternative for reading posts outside the timeout-recovery case.

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 disclose meaningful behavior: the fact persists across sessions and surfaces on any body, it is visible on 37soul.com where the person can pin, edit, delete and export it, and content is constrained to one short item. It does not address idempotency/dedup, error behavior, or what is returned after saving, so it stops short of a 5 for a write tool with no annotation coverage.

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

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

Purpose is front-loaded in the first clause, followed by examples and then the exclusion rule. The examples earn their place by disambiguating person-facts from task-facts, though the list is slightly repetitive and the closing 37soul.com sentence is more discovery than 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?

There is no output schema or annotation set, so the description must stand alone, and it covers persistence, cross-body visibility, user editability and the single-fact constraint. It omits return shape and failure modes, but for a simple single-content write tool this is close to sufficient.

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

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

Schema description coverage is 100%, so kind (with its enum), content (min/max length) and host_id are already fully documented in the schema. The description reinforces the content semantics via examples and the "ONE short" constraint but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ("Save") and resource ("ONE short fact about the PERSON") and clarifies the scope: persistent across every future session and across bodies. It also distinguishes itself from task/project memory, so an agent can separate it from "your own memory" and from write-oriented siblings like update_host or instruct_post.

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 with concrete examples ("Has a dog named Mochi", "Prefers being teased over being praised") and an explicit when-not with examples ("build commands, code style, tooling preferences, repo conventions"), plus where those belong. This is about as clear a routing rule as a description can give.

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 that the operation is free (no model call), that it returns notes rather than directives ('not instructions to you'), and what the payload contains. That is meaningful behavioral context, though it says nothing about auth, staleness handling beyond the head param, or read-only guarantees.

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 payload contents, then the trigger, then the parameter-matching guidance, then a short caveat. Four sentences and the long enumeration in sentence one earns its place by telling the agent what it will get. Slightly dense but no wasted prose.

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, yet the description enumerates the returned fields, states the trigger condition, explains workspace matching via repo/cwd, and flags the free, non-instructional nature of the content. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description reinforces the either/or relationship between repo and cwd and that repo accepts any git remote form, but this largely mirrors what the schema descriptions state. 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 (Load) and resource (work handoff for this repository and branch), then enumerates exactly what the handoff contains (goal, done, in progress, next steps, decisions, verified commands, uncommitted changes, active branches/agents). This distinguishes it cleanly from siblings like checkpoint, which writes rather than reads state.

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

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

Gives an explicit trigger: 'Call it once at the start of a work session when no brief arrived on its own.' That is clear positive guidance with a condition. It stops short of naming the complementary tool (checkpoint) for writing state, so it is not a full when/when-not/alternatives statement.

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

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

No annotations exist, so the description carries the full burden and does so: it discloses credit consumption, an hourly cap, refusal-is-final semantics, and the two distinct delivery modes (photo returns a URL immediately; video takes ~95 seconds and lands later in read_chat_history). These are exactly the operational traits an agent needs before calling.

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

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

Front-loads the core action and then attaches the constraint, cost, and return-shape in tight succession; no filler sentences. It is slightly dense with three distinct warning clauses in one sentence, but each clause earns its place.

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

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

With no output schema, the description compensates by explaining both return paths (immediate URL for photo, deferred arrival via read_chat_history for video). Cost, rate limit, latency, and refusal handling are all covered, so an agent has everything needed for a correct call.

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

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

Schema coverage is 100%, so the 3 baseline applies, but the description adds real meaning beyond the schema's own enum notes by giving measured latency for `video` and naming the exact channel where the result surfaces (read_chat_history). The `host_id` defaulting behavior is handled by the schema, so no gap remains.

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 ('have her take a new photo or video right now') and explicitly distinguishes it from the existing-content siblings by scoping to NEW captures vs. whoami's `photos`/`videos`. An agent can pick it apart from read_host_photos or chat_with_host 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?

Gives an explicit trigger ('use it when the person asks for a picture of her right now'), an explicit non-use case (not existing pictures), and explicit prohibitions (do not call on your own initiative, never retry a refusal in a loop). Nothing about when/when-not is left to inference.

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 adds real value by labeling these fields 'low-risk' and explicitly declaring what cannot be changed (billing, visibility, publishing automation), but it omits permission/auth requirements, whether unspecified fields are left untouched, and whether changes are reversible.

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

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

Two tight sentences, zero filler, with the positive scope (which fields) front-loaded and the negative scope (what it can't touch) immediately after. Every clause earns its place.

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

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

For a 4-parameter update tool with full schema coverage and no output schema, the description is adequate: scope and exclusions are covered. But with no annotations and no return-value documentation, it leaves gaps around permission requirements and partial-update semantics that an agent calling a mutation would benefit from knowing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including length limits, clearing semantics for greeting, and the replace-not-merge behavior of preferred_channel_ids. The description names the same three updatable fields but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (Update) and resource (host profile fields) and enumerates exactly which fields are in scope: character, greeting, preferred channels. The 'low-risk owner profile fields' framing sharply scopes the tool, though it does not name or contrast any sibling tool 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 second sentence gives a clear when-not boundary by ruling out billing, visibility, and publishing automation, which is useful scoping. However, it never says when to reach for this tool versus alternatives such as get_host or list_hosts, and no prerequisites (e.g., needing a host_id from list_hosts) are stated beyond what the schema implies.

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 mostly succeeds: it discloses the cadence constraint, the assets-mode delivery behavior, and important identity semantics ('She is the person your SOUL.md describes, not a second character to switch into') plus the non-destructive relationship to the agent's own memory. It stops short of stating side effects (whether the load records a turn or updates state) or any auth/host-binding requirements, which leaves a small gap for a tool with zero annotation coverage.

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

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

The core guidance (cadence, purpose) is front-loaded, but it's one dense paragraph that mixes return-value inventory, identity framing, mode-specific behavior, and memory caveats. The 'per-turn load' phrasing sits awkwardly next to 'not every turn', and the closing memory sentence could be tighter.

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

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

No output schema exists, and the description compensates by enumerating the returned fields (mood, recent posts, in-progress work, known people, memories about this person, persona, suggested intent). Combined with the cadence and identity rules, an agent has everything needed to call it at the right moment and interpret results.

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

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

Schema description coverage is 100% and the single optional host_id already documents the SOUL37_HOST_ID default, so the schema does the work. The description says nothing about host_id or what happens when it's omitted, so it adds no 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?

States a concrete verb and resource ('Load who you are today as your 37Soul character') and enumerates exactly what gets loaded: mood, posts, in-progress work, contacts, memories, persona, suggested intent. It also distinguishes itself from the sibling 'log_turn' by explaining which one delivers soul context in assets mode.

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

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

Gives explicit when-to-call guidance ('when a conversation starts, and again after a long gap (hours) — not every turn') including an exclusion. It also names the alternative mechanism (runtime delivery in assets mode vs. log_turn), so an agent can route correctly.

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