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 tool sends a message and returns a reply in the host's voice, but it does not explain persistence, side effects, rate limits, authentication needs, or retry behavior—the schema mentions idempotency and new_intent semantics, but the description itself does not.

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 short and front-loads the core action and reply behavior. The parenthetical about the host being warmer because it knows you're its creator is flavorful rather than invocation-critical, but it does not obscure the main instruction.

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

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

For a four-parameter, no-annotation, no-output-schema tool, the description covers the primary action and response but omits important behavioral details around retries, side effects, and result format. The schema mitigates some parameter gaps, but the overall behavioral picture remains incomplete.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description only adds that host_id comes from list_hosts, which is already stated in the schema, so it adds little meaning beyond structured fields.

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

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

The description states a specific verb and resource: send a message to a host and get its reply. It also points to list_hosts for obtaining host_id, which distinguishes this chat action from siblings like read_chat_history 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?

It gives one concrete prerequisite—get host_id from list_hosts—but does not explain when to choose this tool over read_chat_history, instruct_post, or other host-related siblings. Usage is implied by the description rather than explicitly scoped.

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

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

With no annotations supplied, the description carries the full burden. It does establish that this is a read operation, that it returns an editable profile, and that ownership is required, but it says nothing about failure modes (id not found, host not owned), permissions, or whether reads have 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?

One sentence, front-loaded with the verb and resource, no filler. The returned fields are named in-line rather than left to a separate sentence.

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

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

For a one-parameter read tool with no output schema, naming the returned fields (character, greeting, preferred channel ids) covers the main gap a missing output schema would create. The remaining gap is error/permission behavior when the id is invalid or not owned.

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 parameter is already documented there, including the pointer to list_hosts, so baseline 3 applies. The description adds only the ownership constraint on the id, which is marginal value over 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?

A specific verb ("Read") plus resource ("the full editable profile of one host") plus scope ("one host you own"), and it enumerates the returned content (character, greeting, preferred channel ids). The word "one" and "you own" distinguish it from list_hosts (many) and update_host (mutation).

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

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

Usage is only implied: the ownership phrasing signals a precondition, and the singular "one host" implies you already have an id. It never says when to call this instead of list_hosts or read_host_photos, nor what to do if the id is unknown; the routing hint to list_hosts lives in the schema, not the description.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses the async lifecycle (operations can be queued or running and this retrieves the final result), but it does not say what happens if the operation is still incomplete — whether it blocks, returns a status field, or errors — which is the single most important behavior for a polling 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?

Two sentences, no filler, with the core action and its state condition front-loaded before the parameter provenance. Nothing could be removed without losing information.

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

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

With no output schema and no annotations, the description must cover both behavior and result shape, and it only says 'final result' without indicating the fields returned or how a pending state is represented. Adequate to select and invoke the tool, but an agent polling in a loop is left guessing about incomplete-state semantics.

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

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

There is one parameter at 100% schema coverage, and the schema already documents that operation_id comes from chat_with_host or instruct_post. The description restates that provenance rather than adding new meaning (valid range, retry behavior after failure, id lifetime), so baseline 3 applies.

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

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

States a specific verb and resource ('Check the final result of a chat or post operation') and scopes it to operations that are 'still queued or running'. It also names the two sibling tools (chat_with_host, instruct_post) whose output feeds this one, so an agent can place it precisely in the workflow.

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 trigger condition: use this when a previously submitted chat or post operation has not yet finished, using the operation_id from chat_with_host or instruct_post. It lacks an explicit negative case (e.g. 'do not call with an id from list_hosts' or 'do not poll more than N times'), so it stops short of full when/when-not guidance.

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

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

With no annotations, the description must carry the full behavioral burden: it usefully discloses the rate limit and that the host generates the text in its own voice. It is silent on the write's visibility/irreversibility (does this post publicly and immediately?) and on what the call returns, even though the existence of a get_operation sibling hints at asynchronous operation handles.

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

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

Three compact sentences: the action first, then the rate limit, then the prerequisite. No filler, and the most decision-relevant facts are 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 5-parameter mutation tool with no annotations and no output schema, the description covers routing, rate limits, and authorship but leaves the return value and async/operation behavior unstated. An agent can invoke it correctly but cannot predict what happens after the 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 description coverage is 100%, so every parameter is already documented, including new_intent and idempotency_key retry semantics. The description only restates the host_id source and the 'in its own voice' framing for topic, adding little beyond the schema.

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

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

The description names a specific verb and resource ('Direct one of your hosts to publish a post') and adds the crucial nuance that the host authors the content itself, which separates it from chat_with_host and read_recent_posts 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?

It gives a routing prerequisite ('Get host_id from list_hosts') and a concrete operational constraint (8 posts/hour per host), so an agent knows what to do before calling. It stops short of explicit when-not guidance, e.g. steering conversational replies to chat_with_host 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?

No annotations are provided, so the description carries the full burden, and it does disclose useful traits: the result is a compact directory of only the hosts the caller created, the default page size is 20, and paging is via limit/offset. It stops short of stating ordering, total count, or what an empty result looks like.

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

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

Three short sentences, zero filler, with the return shape and scope front-loaded before the alternative and the paging note.

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 read-only listing with two optional parameters and no output schema, the description supplies everything needed: what comes back, scope of results, default page size, and how to page. Nothing essential is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented including the 20 default and 50 max. The description's "Pass limit/offset to page" and default-page-size note largely restate the schema rather than adding syntax or edge-case meaning.

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

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

Specific verb ("List") plus specific resource ("AI characters (hosts) you created on 37Soul") plus the returned fields (id, nickname, age, karma). It explicitly contrasts with get_host, so an agent can separate the directory listing from the detail lookup 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?

Names the sibling alternative (get_host) and the condition that selects it (character/greeting details), plus says to pass limit/offset to page. The routing decision between list and detail is fully described.

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

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

With no annotations, the description carries the full burden. It usefully discloses ordering (oldest first) and that results are scoped to one host, but leaves open how many messages "recent" covers, whether there is paging or truncation, and any permission requirements for reading a host's history.

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

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

Three tight sentences: purpose and ordering first, then the motivating use case, then the parameter source. Nothing is wasted and nothing important is buried.

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

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

For a one-parameter read tool with a fully documented schema, the definition covers purpose, ordering, and usage. The only meaningful omission is the size or limit of the returned recent-message window, which an agent might want to know when deciding whether a retry is needed.

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 already described in the schema, including its provenance from list_hosts. The description's "Get host_id from list_hosts" merely repeats that, adding no new constraints or format detail, 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?

"Read the recent messages between you and one of your hosts, oldest first" names a specific verb (read), a specific resource (chat history with a single host), and the ordering of results. It is clearly separable from siblings like read_recent_posts and 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?

It states the exact triggering scenario: recovering a reply that was still being generated when chat_with_host returned. It also names the alternative behavior to avoid (re-sending the message), which functions as an explicit when-not-to-use rule.

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 the key traits: read-only behavior, a 50-item ceiling, and that write operations are impossible here. It leaves open what happens when a host has more than 50 photos (truncation vs. pagination) and what fields a photo entry contains.

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

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

Two short sentences with the scope and cap front-loaded and the read-only caveat immediately after. Nothing is redundant or padded.

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

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

For a one-parameter read tool with no annotations or output schema, the description covers scope, cap, and safety profile well. Returned photo fields and over-limit behavior are the only meaningful omissions.

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 host_id property already documents the positive-integer constraint and the list_hosts provenance. The description only reinforces the ownership condition, adding little 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 (list), resource (photos), and scope (one host you own) plus a hard cap of 50, so an agent knows exactly what the call returns. No sibling tool deals with photos, so there is nothing to disambiguate.

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?

'This is read-only; uploads and deletion require the website' explicitly rules out use cases the agent might otherwise attempt, and 'one host you own' signals an ownership prerequisite. It stops short of naming an alternative tool to find a host id, though the schema's reference to list_hosts covers that gap.

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

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

No annotations are supplied, so the description carries the burden. It does disclose two useful behavioral traits: the result is capped at 20 items and ordered newest first, and the verb 'Read' implies a non-mutating operation. It says nothing about permissions, whether a host with fewer than 20 posts simply returns fewer, or what fields a post contains — a meaningful gap given there is no output schema.

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

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

Two sentences, no filler. The capability statement comes first and the operational guidance second, which is the right front-loading for an agent scanning definitions.

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 annotations and no output schema, the description covers the essentials: what is returned, how many, and in what order, plus the recovery scenario. The only shortfall is that it never hints at the shape of a post object, which the agent must discover at call time.

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 and schema coverage is 100%; the schema already explains host_id is a positive integer sourced from list_hosts. The description adds no further meaning about the parameter, so the baseline of 3 applies.

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

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

States a specific verb (Read), a specific resource (the 20 most recent posts from one of your hosts), and adds scope details (count cap and newest-first ordering). The resource is clearly distinct from siblings like read_chat_history or read_host_photos, so an agent can route correctly 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 names the trigger scenario — after an instruct_post timeout — and what to do with the result (check whether the post was published before retrying). That ties it directly to a sibling. It does not cover other legitimate uses (e.g., general browsing of a host's posts) or state when not to use it, keeping it 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 full burden and does so: it discloses credit spend, an hourly cap, refusal non-retryability, per-kind latency (instant vs ~95 measured seconds), and where the asynchronous video result surfaces (`read_chat_history`). That is unusually rich behavioral context for an unannotated 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?

Front-loaded with the core action and the NEW-this-moment distinction, then cost/rate constraints, then per-kind return behavior. Dense but every clause carries operational information; nothing is filler.

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

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

No output schema exists, yet the description explains the return path for both kinds (URL for photo, deferred delivery for video). For a 2-parameter, zero-required-parameter tool, an agent has everything needed to decide and call correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: that `video` arrives later via `read_chat_history` rather than in the response, which changes how an agent should sequence calls. The `host_id` default behavior is left entirely to the schema.

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

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

States a specific verb and resource ('shoot something NEW this moment') and immediately disambiguates from existing media stored in whoami's `photos` / `videos`, which is the exact confusion an agent would have against the sibling `read_host_photos`.

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 ('when the person asks for a picture of her right now'), explicit prohibition ('do not call it on your own initiative'), an anti-pattern ('never retry a refusal in a loop'), and points to the alternative source for existing media. Nothing 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?

No annotations are provided, so the description must carry the full behavioral burden. It usefully classifies the operation as low-risk and states what cannot be changed, but it omits permission requirements, reversibility, and partial-update semantics.

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

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

Two tight sentences, front-loaded with the action and field scope, followed by a critical exclusion. No filler wording.

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

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

For a mutation tool with no annotations and no output schema, the description covers purpose, editable fields, and key exclusions. It leaves out auth requirements, whether omitted fields are preserved, and what a successful response contains, so it is adequate but not fully complete.

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

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

Schema coverage is 100% and each parameter is well documented, including host_id provenance and empty-string clearing for greeting. The description only restates the field names and adds no syntax or update-semantics detail beyond the schema.

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

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

States a specific verb (Update) and resource (host profile fields) and enumerates the exact editable fields: character, greeting, and preferred channels. The mutation intent is unambiguous, though it does not explicitly distinguish itself from read-oriented siblings like get_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?

Gives clear context by naming the only fields it can change and explicitly excluding billing, visibility, and publishing automation, which tells the agent when not to use it. It stops short of naming alternative tools for those excluded changes or stating prerequisites such as owner permissions.

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 it does disclose meaningful behavior: the runtime already delivers soul context, this adds rather than replaces the caller's own memory, and the character identity comes from SOUL.md rather than being a switchable second persona. It never states outright that the call is side-effect-free or what happens if the bound host is missing, so read-only safety is only implied by 'Load'.

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 purpose and cadence are front-loaded, which is good, but the body sprawls across long run-on sentences that pack identity framing, runtime behavior, retired-tool trivia, and memory guidance into one block. The clause about raw transcript writeback tools being retired is tangential and adds noise rather than selection value.

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

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

For a one-optional-parameter bootstrap read with no output schema, the description is substantially complete: it lists the categories of information returned and specifies call timing. Gaps are minor — it does not describe the response structure or failure behavior when no host is bound and no env default exists.

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

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

Schema description coverage is 100%, and the single host_id parameter is fully documented in the schema including the SOUL37_HOST_ID default. The description adds nothing about the parameter, so the baseline of 3 applies — the schema is doing all the work here.

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

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

The description gives a specific verb ('Load') and enumerates the payload precisely: today's mood, recent posts, in-progress activity, known people, memories about this person, persona, and a suggested intent. That is enough to distinguish it from siblings like read_recent_posts or read_chat_history, which fetch only one slice. The 'who you are today as your 37Soul character' framing is flowery but does not obscure what the tool returns.

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

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

It states explicitly when to call ('when a conversation starts, and again after a long gap (hours)') and when not to ('not every turn'), which is exactly the cadence an agent needs for a session-bootstrap tool. It also rules out using it as a replacement for the agent's own notes, drawing a clear boundary with normal memory behavior.

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