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 thoroughly. It discloses the startup-only read of KHWAN_CORE, the restart requirement, the silent no-op on remote connections, and the /mcp/{core}/{user} path-and-token model. This is exceptional transparency for a list 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 purpose is front-loaded in the first sentence, and the bulleted structure makes the connection-mode distinctions easy to scan. The description is longer than average, but every section addresses a real behavioral pitfall or selection rule; only the mild flourish 'The path asks, the token answers' is expendable, and it is not harmful.

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 zero-parameter list tool with an output schema, this description is complete: it explains what is listed, how the result is determined, the silent-failure trap, and how to switch brains on remote connections. There are no annotation or output-format gaps that the description would need to fill.

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 zero parameters, so there is nothing for the description to add beyond the schema. The conceptual explanation of cores is useful but is not parameter semantics; the baseline of 4 for a zero-parameter tool 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') and a specific resource ('isolated cores available on this account') while also defining what a core is. The listing intent is unmistakable and distinct from the sibling tools, which all perform memory-related actions rather than enumeration.

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 clear context for how the tool's result is determined by connection mode, and gives explicit when-not guidance: on a remote connection, do not advise KHWAN_CORE and instead point the client at a different URL. It does not name sibling alternatives, but none of the siblings are listing tools, so the primary usage ambiguity is well 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 fully bears the responsibility of explaining behavior. It goes beyond expected by stating 'No model is called,' 'ignores what you are working on,' and positions the tool as a debugging window rather than a session-guiding tool. These details illuminate performance, context-invariance, and safety in ways annotations and schema could 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?

Every sentence earns its place: primary behavior, key caveat, usage contexts, args, and returns. It is concise enough to parse quickly yet complete enough to avoid misinference, and its most important disambiguation against khwan_recall appears early instead of buried at the bottom.

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-only inspection tool with an output schema present, the description covers everything needed to call correctly: order of results, context sensitivity, why to invoke it, and what it returns. The explicit when-not-to-use guidance and sibling reference make it complete in context.

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

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

Because schema description coverage is 0%, the description is essential and it fully compensates. It explicitly defines limit as 'max entries to return, newest first (default 20),' adding meaningful semantics beyond the schema's bare 'Limit' integer. For a single parameter, this is complete.

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 opening line uses a specific verb and resource: 'Inspect what this brain currently remembers, newest first.' It also explicitly distinguishes itself from khwan_recall by saying it answers 'is anything in here / did that write land', not 'what is relevant to this task.' This makes the tool's purpose unmistakable even among six siblings.

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

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

The description explicitly carves out when to use this tool vs alternatives: for khwan_recall when you need meaning-ranked, bounded results; for khwan_memory when recall came back empty or when confirming a khwan_remember write persisted. It also states clear no-seeding-a-session boundary, giving an agent decisive routing criteria beyond simple sibling overlap.

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

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

The description discloses a crucial behavioral trait: 'No model is called.' It also explains the exact output types (context, coherence, allowed, etc.), shows how the coherence gate works, and clarifies that turn_token is opaque and must be passed verbatim. This is far beyond the input schema and greatly helps an agent form correct expectations.

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 tightly structured and front-loaded: the command phrase appears first, followed by a brief explanation, then consise Args/Returns lists. There is no redundant prose or restatement of the tool name.

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

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

For a tool that has no output schema, the description fully defines the request input, the returned fields, how to react to allowed/reason, and how to continue into khwan_record. The agent has everything it needs to call and integrate the result 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?

The input schema contains only a required field named 'input', with no description; the description expands it to 'the user's message / the turn you are about to answer', resolving ambiguity. The Returns section is also effectively a response contract, though not technically a parameter description. For a single-parameter tool, semantics are well covered.

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 starts by stating an explicit action ('Pull') and exact timing ('BEFORE you answer') and names the core resources (memory-enriched context). It clearly separates this tool from khwan_record by establishing a prepare/record workflow, so the agent cannot confuse it with siblings.

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

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

The description gives direct, actionable usage: call before answering, ground the reply in context, respect allowed/reason, and pass turn_token to khwan_record afterward. It does not enumerate alternative conditions for khwan_memory or khwan_cores versus khwan_prepare, but the workflow ordering is explicit enough.

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?

Even without annotations, the description discloses key behaviors: the server ranks and enforces a top-3 ceiling, a relevance floor can cause empty facts which is a valid answer, lessons lead the seed text, and no model is called. It explicitly mentions that limit can only narrow not widen, and that seed_text can be empty. This is far beyond what annotations would normally provide.

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 longer than typical but each section earns its place: the opening sentence states purpose, the constraints are genuinely important and specific to the tool, and the returns section aligns with the schema. However, the call-to-action highlighting bold and paragraph spacing adds length; the seed_text return description is slightly redundant with 'facts' and 'lessons' in the returns listing. There is a small amount of wasted space around the returns details, but overall it is structured and scannable.

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 formal annotations, the description thoroughly covers when to call, what it returns, what the limits are, how to interpret empty facts, and how to phrase the query. The output schema fills in the structure details, and the description adds semantics about the returned lessons leading the seed, the count, and seed_text. For a memory tool with no annotations, this is more than complete enough for an agent to invoke it safely and effectively.

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

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

Schema coverage is 0% in this context, so the description carries the full burden. It actually does that: query is defined as a meaningful task description matched on meaning, and limit is described as a cap between 1-3 and can only narrow. That is strong semantic enrichment of the input schema. I'd give 5, but the description doesn't specify the default or required behavior of limit beyond 'leave it alone unless...'—though it implicitly references the default 3. Minor gap relative to perfect.

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 says explicitly that this tool SEEDs a session/subagent with a compact bounded set of relevant memories, names the exact resource (relevant memories/facts) and the verb (seed/recall). It distinguishes itself from siblings by positioning itself as the token-smart entry point for recall at session start, not per-turn, and by noting that no model is called. It is neither tautological nor vague.

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

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

The description gives direct instructions: call ONCE at session start or when a fact scrolled out of context, NOT on every turn. It also explains when to avoid retrying on empty results and warns about the relevance floor. It doesn't explicitly name an alternative sibling, but it clearly defines the expected invocation context and anti-patterns, which is stronger than merely naming a sibling.

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

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

No annotations are provided, so the description carries the full responsibility for behavioral disclosure. It reveals that calling this tool persists state, learns, and returns next-turn prompts or an acknowledgement, which matters because this is a stateful write-like operation. It doesn't cover failure modes or idempotency, but it does address the most impactful behavior: the record affects future turns.

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 appropriately short and front-loaded with the action and intent. The Args/Returns format is scannable, though the same message that the interplay between the initial sentence and the Returns line, keeping it slightly noise. Still, every sentence contributes 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?

Given the tool's simplicity (two required string parameters, no output schema), the description covers the essential context: when to call it, where the token comes from, and what the return will be. It could mention error cases or reiterating confirmation requirement more explicitly, but enough for an agent to call it correctly.

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

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

Schema description coverage is 0%, yet the description adds precise meaning to both required parameters. turn_token is defined as the exact token returned by the matching khwan_prepare, and answer is identified as the actual answer given to the user for that turn—far beyond the schema's simple string types.

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

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

The description states a specific action with a clear resource: hand the answer back to Khwan AFTER replying, so that the interaction persists and Khwan learns. It also distinguishes itself from the sibling workflow by pointing back to khwan_prepare, making the tool's role in a two-step process explicit.

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 explicit timing guidance (AFTER you reply) and explains the exact required input provenance (the token returned by khwan_prepare). This is enough for an agent to know when to call this tool versus the prepare tool, and the sentence about matching token prevents misuse.

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 carries the full burden of behavioral disclosure. It clearly states what happens inside the tool: it stores a fact, makes no model call, outlives the context window, and is later reachable via `khwan_recall`. It also describes the return shape (`stored` and `reason` when not persisted).

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 front-loaded with its core purpose, then gives the strongest usage signal, then provides parameter and return semantics. Every section adds operational value; the relatively longer 'Reach for this' paragraph is justified because it tells the model exactly when to invoke the tool, not just why it exists.

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 tool has exactly one parameter and an output schema, so the required usage surface here is small. The description covers persistence semantics, return value, and a sibling relationship (`khwan_recall`). It gives the agent enough to invoke the tool correctly without needing to infer anything essential.

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

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

Schema description coverage is 0%, but the description's Args section fully compensates: it defines `fact` as a durable rule or preference that must stand alone. It reinforces the meaning with a concrete example contrasting a standalone rule with an unusable utterance. This is ample semantic guidance for a single string 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?

The description is centered on a specific verb and resource: "Persist a durable fact/preference" so future sessions can recall it, and it explicitly says it stores `fact` in the brain with no model call. It distinguishes itself from the prepare→record loop and states it is available to the next `khwan_recall`, which removes ambiguity versus siblings.

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

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

The description gives a very explicit usage trigger: "Reach for this the moment you are corrected." It also contrasts this tool with the more elaborate prepare→record loop, and the 'standing RULE, not the utterance' guidance tells the agent how to phrase the fact. This is far more than a generic call-to-action.

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