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

With no annotations, the description carries the full burden, and it mostly succeeds: 'Open' signals a non-mutating operation, and the description discloses what the agent receives (persona, index.md, all concepts) and how it behaves when switching agents. It does not explicitly state 'read-only' or 'no side effects,' though the wording strongly implies both.

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: the first defines the function, the second states when to call it, and the third explains how to reuse the tool for switching. There is no filler, no repetition of schema data, and the most important information is front-loaded.

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

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

For a simple one-parameter tool with an output schema, the description covers purpose, timing, and parameter behavior well. It would be slightly more complete if it pointed to list_agents for discovering IDs or explicitly excluded write behavior, but neither omission prevents correct use in the described scenario.

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

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

The schema's only parameter, agent_id, has 0% description coverage, so the tool description must add meaning. It does by making clear the parameter selects which agent's wiki to open and by explaining that passing a different agent_id switches agents. It does not document format or how to discover valid IDs, but for a single obvous string parameter this is sufficient.

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

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

The description uses a specific action ('Open an agent's wiki') and names the returned contents: persona preview, index.md text, and all concepts. This is clearly distinct from a single-page wiki_read or search tool in substance, but it does not explicitly contrast with sibling tools or name alternatives.

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 an explicit trigger: 'Call this when waking an agent in a new project, before working.' It also adds a practical switching pattern: 'Switch agents by calling this with a different agent_id.' It lacks explicit when-not-to-use guidance or named alternatives, but the primary usage context is unmistakable.

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 of behavioral disclosure. It reveals concrete side effects: it creates a multi-file bundle, optionally writes a provided persona or a fill-in template, and refuses to overwrite an existing agent. This goes well beyond the schema by stating the failure condition and pre-existing-agent behavior.

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

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

The description is compact and front-loaded: starting with the core operation, then when to use it, then parameter specifics, then the failure guard. Every sentence adds actionable information and none merely repeats the schema. The structure makes it easy for an agent to scan and extract decision-critical facts quickly.

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

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

For a simple 3-parameter create tool with an output schema present, the description covers what is created, when to use it, how each optional parameter behaves, and the collision behavior. The output schema handles return-value details, so nothing essential to a correct first invocation 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 0%, so the description must add meaning to parameters, and it does. It explains `name` as the display name, defaulting to `agent_id`, and `persona` as free-text identity for the AGENT.md body with an omit-for-template option. `agent_id` is not individually described, but its role is inferable from the required constraint and its use as the fallback for `name`.

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 opens with a precise verb and resource: 'Create a new agent bundle' and enumerates exactly what is created ('directory + AGENT.md persona + index.md + log.md'). This clearly differentiates it from sibling tools like delete_agent and the wiki_* operations. The 'Use when starting a new role' clause anchors the tool's specific purpose.

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

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

The description gives a clear trigger: 'Use when starting a new role that doesn't exist yet.' It also warns that the tool fails if the agent already exists and says 'don't clobber,' which implicitly tells the agent not to use it for existing roles. It does not explicitly name alternative tools for updates, but the usage context is unambiguous.

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 well: it flags IRREVERSIBLE destruction, instructs the agent to confirm with the user, and documents the path-safety guard ('Refuses paths that escape the agents dir'). This is strong behavioral disclosure.

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

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

Three sentences, each earning its place: scope, destruction warning, and usage context. Critical information is front-loaded with no filler or redundancy.

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

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

For a single-parameter destructive action with no annotations, the description covers what gets deleted, when to use it, and safety constraints. It only lacks an explicit pointer to list_agents or agent_index for obtaining a valid agent_id.

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

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

Schema coverage is 0% and the description never explains agent_id: its format, where to find it, or whether it is a name, path, or ID. The path-safety note gives only an indirect hint, leaving the single parameter materially underspecified.

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: 'Delete an agent's entire bundle (all concepts + persona + log).' This clearly explains the tool's scope and distinguishes it from the sibling wiki tools that operate on individual concepts or logs.

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 an explicit trigger: 'Use when an agent is retired or created by mistake.' It does not enumerate alternatives, but no sibling tool offers a comparable deletion operation, so the usage context is sufficient.

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 discloses the filtering behavior (only agents owning an OKF bundle) but does not explicitly state that it is read-only, or mention pagination, ordering, or side effects. The read-only nature is implied by 'list', and output schema covers response shape, so it is minimally adequate.

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

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

A single, front-loaded sentence with no filler. It communicates the exact purpose efficiently and wastes no 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, zero-parameter listing tool with an output schema, the description is largely sufficient. It defines the scope (every agent with an OKF bundle) and the presence of an output schema covers return values. The only minor gap is lack of explicit read-only confirmation, but this is implied by the verb.

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

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

The tool has zero parameters, so the schema is trivially complete. The description adds no parameter details, but the baseline for zero-parameter tools is 4, which is appropriate.

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

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

The description uses a specific verb ('List') and resource ('every agent that owns an OKF knowledge bundle'), clearly distinguishing the tool's scope. It is not a tautology and separates it from create/delete operations, though it doesn't explicitly name a sibling alternative.

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

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

No guidance on when to use this tool versus alternatives like agent_index or wiki_search. There are no exclusions or context cues for selection, leaving the agent to infer usage from the name and description alone.

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

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

With no annotations provided, the description carries the full burden of exposing behavior. It does state that the operation appends to a log file under today's date group, implying non-destructive modification. However, it omits details such as whether the file is created if missing, how existing entries are formatted, or any permission requirements, which would be valuable for an agent deciding to invoke it.

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

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

A single, well-structured sentence that front-loads the verb and resource, with no padding. Every word adds meaning, making it easy to parse quickly.

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

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

For a simple append operation, the description covers the core action and destination. Given an output schema exists, return values are not required. However, it lacks context about edge cases (file creation, date formatting) and parameter specifics, leaving some room for misinterpretation.

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 description coverage, so the description must clarify the parameters. While the names 'agent_id', 'action', and 'detail' are self-explanatory to some degree, the description neither explicitly maps them to the append operation nor explains any constraints or formats. This is a clear gap given the low schema coverage.

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

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

The description uses a specific verb 'Append' and names the exact resource 'agent's log.md', with the additional detail 'today's date group'. This clearly distinguishes it from sibling tools like wiki_write_concept or wiki_search, leaving no doubt about its function.

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

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

The description provides no guidance on when to use this tool versus its alternatives. It doesn't mention any conditions, exclusions, or comparisons to sibling tools like wiki_write_concept, so an agent has no explicit basis for choosing this tool over others.

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 behavioral burden. It does disclose the read-only nature, the returned content ('frontmatter + body'), and the concept_id path format. It does not address not-found behavior or how agent_id scopes the read, but for a simple read tool with an output schema this is minimally adequate.

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 a single front-loaded sentence: first the action/resource, then the parameter detail. There is no filler and every clause adds useful 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?

Although the tool is simple and has an output schema, the definition omits the meaning of the required agent_id and offers no usage guidance relative to wiki_search. The concept_id format note helps, but the description is not complete enough for confident correct invocation on its own.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It explains concept_id with the format and example ('projects/x'), but says nothing about agent_id, a required parameter. Half the input contract is left unexplained.

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

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

The description states a specific verb and resource: 'Read one concept (frontmatter + body)'. This clearly distinguishes it from write/search/delete siblings like wiki_write_concept and wiki_search. It does not explicitly name any sibling, so it stops short of a 5.

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

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

There is no guidance on when to use this tool versus wiki_search or wiki_write_concept, and no mention of prerequisites such as having a known concept_id. The phrase 'one concept' implies exact-id reads, but the selection logic is left entirely 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 must carry the behavioral disclosure burden. It communicates that the operation is a search and that it is scoped to one agent's wiki, which implies a read-only action. However, it does not describe result-ranking behavior, matching semantics, or side effects beyond what the name and schema already suggest.

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 a single, front-loaded sentence that states the core purpose without filler. Every word earns its place, and there is no redundant restating 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?

This is a straightforward search tool with an output schema and self-describing parameter names. The one-line description covers the core semantics and scope, though a sentence about when to prefer this over wiki_read or agent_index would make it fully complete. The output schema relieves the description of explaining return values.

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

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

Schema description coverage is 0%, so the description is the only place that could explain parameters, and it does not explicitly do so. The parameter names are self-explanatory enough that agent_id, query, and limit can be inferred, but no additional detail about query format or interpretation is provided.

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 operation, full-text search, and a specific resource, one agent's wiki, which cleanly distinguishes it from sibling tools like wiki_read, wiki_write_concept, and list_agents. There is no ambiguity about what this tool does.

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

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

The phrase 'within one agent's wiki' implies a scope constraint and suggests using this tool when search is needed, but it never states when to prefer wiki_search over alternatives such as wiki_read or agent_index, nor does it mention exclusions. Usage context is only implied rather than explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does state 'Create or update' and mentions extra_json for frontmatter, but it does not explain what OKF means, whether updates overwrite existing content, whether files are created automatically, or any side effects or requirements beyond 'type' being required.

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

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

The description is concise and front-loaded with the primary action. The second sentence adds relevant parameter context, though the unexplained 'OKF' abbreviation slightly weakens clarity. Overall, it is efficient with no wasted content.

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 with 8 parameters, no annotations, and a 0% schema description coverage, the description is incomplete. It does not explain required identifiers, body/tags/title/description semantics, the meaning of OKF, or how the output is structured. The output schema exists, but the input-side gaps are substantial.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It adds meaning only for 'type' (required, OKF) and 'extra_json' (optional JSON object string), while leaving agent_id, concept_id, body, tags, title, and description semantically unexplained.

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

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

The description clearly states the tool creates or updates a concept file in an agent's wiki, which is a specific verb with a clear resource. It does not explicitly differentiate from siblings like wiki_append_log or wiki_read, but the resource and action are unambiguous enough for an agent to understand the core purpose.

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

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

The description gives no guidance on when to use this tool versus alternatives such as wiki_append_log, wiki_search, or wiki_read. It mentions 'type' is required, but does not explain when a concept write is appropriate or how it differs from other wiki operations.

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