Thread Keeper

by po4erk91

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.17.0
Disambiguation2/5
Several tool families blur together: curator_run/curator_review/candidate_review_run/review_candidates, spawn_status/spawn_budget_status/live_status/agent_status, and peers/presence/live_status all overlap in purpose. Descriptions are detailed, but with 127 tools the boundaries between review/status/spawn variants are unclear enough that agents will frequently select the wrong one.
Naming Consistency3/5
The server consistently uses snake_case and many tools follow a domain-prefix-plus-action shape (evolve_*, dialectic_*, skill_*, lesson_*). However word order is mixed—verb_noun tools like accept_candidate sit beside noun_verb tools like core_set and lesson_append—and numerous bare nouns/verbs (brief, context, neighbors, wait, note) break the pattern.
Tool Count1/5
127 tools is far beyond the 25+ threshold and constitutes an extreme MCP surface, even for a broad memory/automation system. The sheer count forces an agent to scan dozens of overlapping review, status, config, and daemon tools before finding the relevant one.
Completeness4/5
The domain is unusually broad—threads, notes, candidates, lessons, skills, dialectic claims, peer messaging, spawning, curator loops, DB maintenance, and sync—and most entities have full CRUD or lifecycle coverage. Minor gaps remain (no explicit list_threads/get_thread, no direct task kill/stop), but these can be worked around via brief/search/pickup_candidates/mp_cleanup.
Average 4/5 across 127 of 127 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 5 community issues answered or closed in the last 6 months
- 151 commits in the last 12 weeks
- Last stable release on August 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description does not contradict, but adds no additional behavioral context (e.g., no mention of data freshness, cost, or side effects). However, with annotations covering the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise (one line) but under-specified. It could be more informative while staying short. Front-loads key info but lacks a clear verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool with output schema present, the description adequately hints at what is returned (config, buffer sizes, capture passes). Could be more explicit but sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema, so description does not need to add parameter details. Schema coverage is 100% vacuously. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description lacks a clear verb, just lists items ('Miner config + buffer sizes + last 5 capture passes'). It implies a status retrieval but does not explicitly state 'returns' or 'retrieves'. Not distinguishing from sibling status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Many sibling tools exist (e.g., dialectic_mine_run, dialectic_claim) but no differentiation provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds no additional behavioral context, such as side effects, error conditions, or authorization needs. It simply restates the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words) and front-loaded with the action. However, the brevity sacrifices needed details, balancing conciseness with adequacy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return value details are not required. However, the description omits any context about edge existence, idempotency guarantees (despite annotation), or post-removal state, making it incomplete for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining the parameter's meaning. The phrase 'by id' hints at edge_id but does not clarify its role or format, leaving the agent to infer from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'an edge by id', making the core action unmistakable. However, it does not differentiate from sibling tools like 'link', which is a natural counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, nor does it mention prerequisites or scenarios to avoid. Context signals show many sibling tools, but no comparative information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds no additional behavioral context. It does not disclose what operations are performed, what happens to resources, or any side effects. For a read-only tool, more transparency about data aggregation or query behavior would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and easy to read. However, it could be slightly restructured to front-load the key action (e.g., 'Get reliability stats...'). As it is, it is very brief but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameter descriptions in the schema and no output schema details provided, the description is insufficient. It does not explain what 'reliability stats' include, how the window is applied, or how the category is specified. For a tool with only 2 parameters, the description should at least clarify the expected inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. It hints at 'one category' and 'over a window' but does not explain the format, allowed values, or meaning of the parameters. The parameter 'window_days' has a default but no explanation of how it affects results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides reliability stats for a category over a window, which distinguishes it from siblings that handle other functions like accept_candidate or agent_status. However, 'stats' is vague and could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, when to use, or when not to use. The sibling list contains many tools with similar operations, but the description offers no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds no further behavioral details (e.g., effect of invalid concept_id, pagination, or performance). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure (e.g., no use cases, prerequisites, or format details). It could be more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and an output schema, the description is minimal. It does not explain return values, edge cases, or prerequisites, though the output schema may partly compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the 'concept_id' parameter beyond its name. The agent receives no additional meaning for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Full description + triangulation_notes for one concept,' indicating the tool retrieves detailed information for a single concept. It is clear but does not differentiate from siblings like 'list_concepts' or 'register_concept'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'list_concepts' or 'concept_manage'. The description only states what it does without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description is the main source of behavioral insight. 'Enqueue heuristic candidates' usefully indicates a write/mutation to some candidate queue, which is more specific than the annotation flags. However, it does not disclose whether repeated runs create duplicates, what side effects the enqueue has, or whether it consumes or only inspects messages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It is efficient and easy to parse, though it is so brief that some needed context is absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0% schema description coverage, no parameter explanations, and no usage context, the description is incomplete for an agent deciding how to invoke the tool. The presence of an output schema reduces the need to describe return values, but the candidate-selection semantics, parameter meanings, and side-effect profile are still under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly explain window_min or max_messages. 'Recent' and 'messages' provide weak contextual hints tying the parameters to a time window and a message limit, but the agent must infer the exact semantics from the parameter names and defaults alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Scan'), a specific resource ('recent dialog_messages'), and a concrete outcome ('enqueue heuristic candidates'). This differentiates it from generic sibling tools like ingest or review_candidates, though 'heuristic candidates' remains somewhat vague about exactly what is selected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, no exclusions, and no mention of related candidate-pipeline siblings such as pickup_candidates, review_candidates, or accept_candidate. The phrase 'recent' implies a timing use case, but the description does not state it explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds one useful behavioral detail — the authorization constraint that only the claimant or its spawned child can release — but it does not explain side effects, what happens to the underlying thread, or the idempotency implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact, front-loads the core action, and contains no filler. It is appropriately sized for a simple one-parameter tool, though some of the omitted semantics limit overall usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one required parameter, an output schema, and safety annotations, so the baseline context is decent. However, the description fails to explain the effect of releasing, what a 'spawned child' means, or how this relates to claim_pickup and pickup_candidates. For an agent choosing among many siblings, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions thread_id. An agent must infer from the tool name that thread_id identifies the claim or thread to release, which is a meaningful gap for a required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('release') on a specific resource ('a claim'), which is clear at a surface level. However, it does not explicitly differentiate this from sibling tools like claim_pickup or pickup_candidates beyond the verb itself, so it stops short of full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, and no mention of the claim lifecycle or conditions that warrant a release. The only contextual hint is who is allowed to release, not when releasing is appropriate or what distinguishes it from related pickup/claim tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's mention of 'search' is consistent. However, the description adds no additional behavioral details beyond what annotations provide, such as rate limits or result size limits. With annotations covering the main point, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It is efficient with no wasted words, though it could benefit from slightly more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose but lacks details on parameter usage and output format. Since an output schema exists, the description does not need to explain return values. However, for a search tool, more context on result scope or ordering would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters 'query' or 'k'. The description only states the purpose without adding any meaning to the input parameters. The agent must infer parameter semantics from names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it performs semantic or full-text search over all notes. The verb 'search' and resource 'all notes' are specific. However, it does not explicitly distinguish from sibling search tools like 'dialog_search' or 'search_via_parent', but the scope 'all notes' provides differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description lacks context on prerequisites, limitations, or typical use cases. The agent receives no hints about when this is preferable to other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by detailing the output format and telemetry information, providing behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes an extensive multi-line format example. It could be more concise by summarizing the format without full example detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter and an output schema, the description covers the output format but omits parameter semantics. For a simple list tool, it is adequate but incomplete in explaining the input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The only parameter, 'include_archived', is not mentioned in the description. The format implies state handling but does not clarify the parameter's purpose or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List skills with telemetry', which specifies a verb and resource. The format details provide additional clarity, though it does not explicitly distinguish from sibling list tools like 'lesson_list' or 'list_concepts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or when not to use it. The description only explains what it does, lacking any contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, which description reinforces with 'list'. Adds minimal behavioral info beyond that. No mention of side effects or data returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Could briefly mention that include_applied controls the filter, but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return value description is not needed. However, lacks context on the purpose of review (e.g., to decide on applying). Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0% means description provides no parameter details. The phrase 'pending (or all)' hints at the include_applied parameter, but not explicitly. Agent must rely on schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists format-evolution suggestions, with a hint of filtering ('pending (or all)'). It distinguishes from siblings like evolve_apply, but could be more specific about what constitutes a suggestion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like evolve_apply, evolve_decide, etc. Agent must infer context from name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond listing. Annotations are non-informative (readOnlyHint=false, etc.), and the description does not mention whether the operation is safe, has side effects, or pagination/limiting (k parameter not explained). The format hint is helpful but insufficient for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one for purpose/ordering, one for output format. It is concise and front-loaded, with no unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is mostly adequate but lacks explanation of the 'k' parameter. Output schema exists, so return format is covered; however, the description could mention limiting behavior or edge cases (e.g., empty list).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the only parameter 'k'. Schema description coverage is 0%, so the description adds no semantic value to the parameter beyond what is in the plain schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a compact listing of materialized lessons, ordered newest first. It uses specific verb and resource ('listing of materialized lessons') and distinguishes from sibling tools like lesson_get, lesson_append, lesson_remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via the purpose and output format, but does not explicitly state when to use this tool versus alternatives (e.g., search, list_concepts). No when-not or exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the tool is non-readonly, non-idempotent, and non-destructive. The description adds meaningful contract context—it is the public MCP surface, parallel by nature, and deliberately excludes retry lineage/config fields—but it does not disclose other behavioral traits such as whether the call blocks on completion or what side effects spawning creates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in a single clear sentence, followed by a brief, relevant note about the public/private contract split. The second paragraph is somewhat esoteric but earns its place by explaining why certain fields are absent; overall it is compact with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters and 0% schema coverage, the description is materially incomplete: it does not define any input semantics and gives no guidance on how the spawned child session behaves or relates to the many spawn/thread siblings. The output schema covers return values, but the input side is largely a black box.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the full burden of explaining 12 parameters, yet it explains none of them. Parameters like slim, write_origin, permission_mode, capture_output, and extra_allowed_tools are opaque, and the only hint—'config fields do not leak'—concerns fields intentionally absent rather than the ones present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Launch a new child session in parallel' gives a specific verb, resource, and distinguishing qualifier. It makes the core action unambiguous, though it does not explicitly differentiate from session/thread siblings like task_thread or idle_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one useful exclusion: watchdog continuation retries should use the private `_spawn_impl`, implying this public tool is for normal interactive launches. However, it gives no guidance on when to choose spawn over related siblings such as spawn_status, spawn_budget_set, or the thread-based session tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that it refreshes liveness and resolves spawned_cid lazily, providing useful behavioral context that the annotation does not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences, front-loading the purpose. It efficiently lists output fields but could benefit from slight restructuring.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately lists return fields. However, it lacks parameter explanations and could be more complete regarding the tool's behavior and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description does not explain the parameters 'k' and 'include_ended'. It only describes output fields, leaving parameter semantics entirely unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists spawned tasks and specifies the fields included (id, pid, status, etc.). It distinguishes from siblings like 'spawn' and 'spawn_status' by focusing on listing rather than spawning or status checking, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'spawn_status' or 'task_logs'. The description only states what it does without when-not conditions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds value by detailing the three search modes (hybrid, semantic, fts) and their underlying mechanisms (RRF, cosine, FTS5). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences. The first sentence clearly states the tool's purpose, and the next two succinctly explain the mode options. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling search tools and the lack of output schema details, the description does not provide enough context for correct tool selection or full understanding. Parameter semantics are incomplete, and return value expectations are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. Only the 'mode' parameter is explained with its options and defaults. The other parameters (k, role, query) are not described beyond their names and types in the schema, leaving their semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search ingested Claude Code transcripts', which is a specific verb+resource. However, it does not differentiate from sibling tools like 'search' or 'search_via_parent', leaving ambiguity about which to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the three modes (hybrid, semantic, fts) but provides no guidance on when to choose this tool over siblings or when not to use it. No context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and non-destructive behavior, which the description does not contradict but also does not elaborate on. The description does not disclose what 'ended' entails (e.g., state changes, cleanup). With annotations present, the description adds minimal behavioral context beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one phrase) and front-loads the core purpose. It is efficient with no wasted words, though it could afford a bit more detail without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description is adequate but lacks context on typical usage scenarios or post-conditions. It does not explain the summary's usage beyond being optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'optional terse summary' which maps to the summary parameter, but does not explain its purpose or format. With 0% schema coverage, the description adds some meaning but not enough to fully compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (mark session ended) and the resource (current session). It includes the optional summary parameter. However, the verb 'Mark' is slightly vague; 'End' would be more direct. It distinguishes from siblings like 'close_thread' by focusing on session termination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as prerequisites or conditions for ending a session. It does not mention alternatives or exclusions, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, so repeated calls are safe. The description adds 'Set' which aligns with the write nature, but does not disclose any additional behavioral traits like conflict resolution or side effects. With annotations covering safety, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—one sentence plus examples. The examples are front-loaded and valuable, showing usage. No unnecessary words, though a tiny bit more structure could improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no nested objects, idempotent) and the presence of an output schema, the description with examples is nearly complete. It covers the primary usage pattern, though it doesn't mention error handling or default values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage). However, the description provides examples (e.g., 'lang=ru') that imply the key-value pattern, partially compensating. This gives the agent a basic understanding but lacks formal definitions of allowed keys or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('stylistic running rule'), with examples that illustrate the pattern. It distinguishes from sibling tools by its specific focus on style rules, which is unique among the many tools listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, contexts, or when not to use it, leaving the agent without usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates read-only behavior; the description adds 'full content' and 'single entry', which is consistent but does not disclose further behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 9 words, front-loaded with verb and object, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief but fails to explain how to use the tool (e.g., what the 'key' is or how to obtain it), leaving a gap despite the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the 'key' parameter, but it only states 'Return the full content of a single core-memory entry', providing no meaning for the required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and resource 'single core-memory entry', distinguishing it from siblings like core_list (list) and core_set (modify).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving a single entry by key, but lacks explicit guidance on when to use vs alternatives like core_list, and no mention of when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral detail beyond the annotations: it explains that restoring a lesson replaces the current same-slug section or re-adds it, and that restoring a skill replaces the primary skill dir and mirrors it to roots. These details align with `destructiveHint: true` and `idempotentHint: true`, adding specificity without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficient: four short sentences, purpose front-loaded, and every sentence adds meaningful information. There is no filler or repetition of schema/annotation content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description effectively explains the core restore behavior and resource-specific effects, which is useful for a destructive tool. However, it omits explanation of the required `pass_id` parameter and does not differentiate from the `lesson_restore` sibling, leaving an agent with incomplete context for safe and correct selection. The presence of an output schema lessens the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden of explaining parameters. It clarifies the roles of `lesson_slug` and `skill_name` and the exactly-one rule, but it never explains the required `pass_id` parameter, which is a significant gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Restore'), resource ('one lesson or skill'), and source ('curator pre-mutation snapshot'). It clearly distinguishes the tool's scope by covering both lessons and skills, but it does not explicitly contrast with the sibling tool `lesson_restore`, so the differentiation is not fully spelled out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a hard constraint ('Pass exactly one of lesson_slug or skill_name') but provides no guidance on when to use this tool versus alternatives like `lesson_restore` or when not to use it. No exclusions, prerequisites, or alternative-conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, making the read-only behavior known. The description adds that results are sorted newest first, which is a useful behavioral detail. However, it does not disclose other behaviors like pagination or the effect of the k parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the most critical information: status filter options and ordering. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 parameters and an existing output schema, the description is somewhat complete but lacks explanation of the k parameter and any pagination or result limits. It sufficiently covers status filtering and ordering but leaves key usage details implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It provides the allowed values for the status parameter (pending, accepted, rejected, all) and implies its usage. However, it does not explain the k parameter, leaving its meaning (likely a limit) undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies that the tool lists candidates filtered by status (pending, accepted, rejected, all) and sorted newest first. This clearly indicates a read operation to view candidates for review, which is distinct from sibling tools like accept_candidate or reject_candidate, though not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as candidate_review_status or accept_candidate. It does not state prerequisites or context, leaving the agent to infer usage from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, not idempotent, and not destructive. The description adds that 'target_kind overrides candidate's kind' and 'thread_id optional,' but does not disclose potential side effects, required permissions, or what happens to the candidate after materialization. This provides minimal additional behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no redundant information. The first sentence states the action, and the second explains key parameter behaviors. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, an output schema, and no nested objects. The description covers the basic purpose and two optional parameters but omits details like prerequisites (e.g., candidate must exist), return format, or error conditions. Given the simplicity, the description is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining that 'target_kind overrides candidate's kind' and noting 'thread_id optional.' This clarifies the purpose of two out of three parameters, though 'id' is implied but not explicitly described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Materialize' and the resource 'candidate into its target table,' indicating the core action. It mentions optional parameters and an override behavior, making the purpose unambiguous. However, it does not explicitly contrast with sibling tools like 'reject_candidate' to differentiate usage contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as 'reject_candidate' or other candidate-related tools. It lacks explicit context, examples, or conditions for use, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that the tool always returns structuredContent with an AgentStatusSnapshot, and explains how the text block changes with json_output. This adds meaningful behavioral context without contradicting the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no filler. The primary purpose is front-loaded, and the only additional sentence explains return behavior and the json_output switch.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the readOnlyHint, presence of an output schema, and only two optional boolean parameters, the description covers most of what an agent needs: purpose, return shape, and output formatting. The undocumented refresh parameter is the main remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for both parameters. It explains json_output well, but refresh is left completely undocumented, leaving an agent to guess whether it triggers a refresh, controls caching, or has side effects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says specifically to 'Show autonomous learning loops' and enumerates the content fields: state, backlog, last pass, and RSS. This is a clear verb+resource statement, though it does not explicitly differentiate from sibling status tools like live_status or spawn_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. The json_output instruction is useful for output formatting but does not help the agent decide between agent_status and sibling status/health tools, and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds the behavioral constraint of a 5-15 word outcome, but does not explain side effects like state changes or what happens after closing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and to the point. It could include more detail without being verbose, but it is efficiently short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 required parameters and an output schema. The description gives the word count constraint for outcome but lacks details on thread_id format, what closing entails, or what the output contains. Adequate for a simple tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to add meaning. The description clarifies that 'outcome' must be a 5-15 word string, but provides no clarification for 'thread_id'. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Close a thread') and resource ('thread'), and adds a specific constraint ('5-15 word outcome'). It effectively distinguishes from sibling tools like open_thread and review_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 compared to siblings like validate_threads or review_thread. It does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description merely restates 'delete' without adding further behavioral context such as irreversibility, permissions, or error conditions. It adds little value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant or missing elements. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 annotations covering destructive and idempotent hints and an output schema, the description is minimally adequate. However, it could mention idempotency or what happens if the key does not exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. It only states 'by key' without explaining what the key is (e.g., format, existence requirement). This is insufficient for a parameter with no schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete', resource 'core-memory entry', and method 'by key'. It effectively distinguishes from siblings like core_get, core_list, and core_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide when to use or when not to use this tool versus alternatives. It implicitly suggests destruction, but lacks guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (idempotentHint=true, destructiveHint=false) are present and not contradicted. The description adds that the reason is appended for heuristic tuning, which is useful context, but does not detail other behavioral effects (e.g., status change, triggers).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two brief clauses with no redundant wording. Every part contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic action and a notable side effect (reason appended for tuning). However, given it's a mutation tool with an output schema and multiple siblings, it lacks context on the overall candidate lifecycle, return values, or any follow-up actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 0%. The description only mentions 'reason' being appended for tuning, but does not clarify the meaning or format of either 'id' (presumably candidate ID) or 'reason' more explicitly. The agent must infer from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Mark rejected', which is a clear verb+resource. The tool name and sibling 'accept_candidate' leave no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool relative to alternatives like 'accept_candidate'. The description does not specify when rejection is appropriate or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the readOnlyHint annotation by stating that setting snapshot_path 'writes a markdown report' as a side effect. This is a serious inconsistency. Furthermore, it does not disclose any other potential side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with extensive technical details (e.g., MATERALIZED-vs-SKIP hit rate, Claude-spawn time) that could be condensed for quicker comprehension. While front-loaded with the core purpose, the additional detail makes it longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. It covers the key capabilities and the optional file write. However, the contradiction with annotations detracts from completeness, and some details about configuration fields might be missing, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name and default value. The description adds meaningful context by explaining that when snapshot_path is set, the tool writes a human-readable markdown report, thereby clarifying its optional side effect beyond what the schema conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows shadow-review config, recent passes, and production telemetry. It specifies the snapshot's contents and contrasts it with alternative tools by mentioning what the production-validation rollup includes (e.g., outcome mix, hit rates), making the purpose specific and distinct from siblings like shadow_review_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sanity-checking daemon health and assessing if the loop earns its execution time. However, it lacks explicit guidance on when not to use this tool or how it compares to alternatives like candidate_review_status or shadow_review_run, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds context by detailing the included signals and optional notes, which is valuable behavioral info beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with key information front-loaded. It is concise but could be more structured by listing parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are covered. However, the description lacks parameter details for 'k', making it incomplete for fully understanding tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It only implicitly addresses 'include_notes' and completely omits 'k', leaving the agent uninformed about this important parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it replays a spawned task as a chronological thread with specific signal and note content. It uses a specific verb and resource, but does not explicitly distinguish from sibling thread tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for viewing task threads, but no explicit when-to-use or when-not-to-use guidance compared to alternatives like open_thread or review_thread.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing no behavioral hints. The description does not elaborate on side effects, required permissions, or what happens to existing quotes. It only states the action without transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences with no wasted words. The main action is front-loaded, and examples are provided efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, output schema exists) the description captures the core purpose. However, it omits any explanation of the thread_id parameter, and while output schema is present, the description doesn't clarify what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter (content or thread_id). It adds no meaning beyond the bare schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a user quote and specifies it's for exact phrasing, distinguishing it from summarizing or paraphrasing tools. The verb 'capture' and resource 'user quote' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the tool when the user's exact phrasing matters and gives examples (sharp reframes, decisions, pushback). However, it does not mention when not to use it or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond annotations (readOnlyHint=true) by detailing the data returned. However, it does not mention side effects, authentication requirements, or other behavioral traits. It is not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence listing all three outputs concisely. No extraneous words; front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description covers the main purpose. It does not explain what the 'configuration' entails or how to interpret queue size, but overall it is adequate for a read-only status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is complete. Baseline of 4 applies, and the description does not need to add per-parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states three specific pieces of information shown (configuration, last 5 passes, pending queue size). It distinguishes from similar tools like candidate_review_run, but does not explicitly differentiate from other review status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as candidate_review_run or curator_review_status. The description only lists what it shows, without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the agent knows it's a safe read. The description adds that the tool returns structuredContent plus legacy text and references the briefing system, but does not disclose other behavioral traits like latency or side effects. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences plus a bullet-like list. Every sentence adds value, front-loading the core information about what context is returned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context signals indicate so), the description does not need to fully detail return values. It provides a high-level list of fields and mentions the legacy text and resource alternative. Sufficient for a simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100% and description cannot add parameter meaning. Baseline for 0 params is 4. The description helpfully lists the output fields (session id, age, etc.), which substitutes for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool returns (runtime context: session id, age, semantic on/off, db path, thread counts). It is a specific verb+resource but does not explicitly distinguish from siblings, though the tool's purpose is unique among the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions an alternative access method (memory://context resource) but does not explain when one should be preferred over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only, not idempotent, not destructive. The description adds that it fires a 'mechanical capture pass' and explains the force parameter's effect. This adds some behavioral context beyond annotations, but does not disclose side effects or rate limits. Adequate given annotation presence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the tool's action and key parameter behavior. No extraneous words; efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one boolean parameter and an output schema (external). The description explains the essential purpose and parameter nuance. It could be more complete by clarifying what happens when force=False or the default behavior, but it's sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the tool description compensates by explaining the 'force' parameter: 'force=True runs even when the miner daemon interval is 0'. This adds meaning beyond the schema's type and default. No other parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fire one mechanical capture pass now', providing a specific verb and resource. It distinguishes from sibling dialectic_mine_status, though the jargon 'mechanical capture pass' may be unclear to some. Overall purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only gives guidance on when to use force=True ('runs even when the miner daemon interval is 0'). It does not mention when to use this tool versus alternatives like dialectic_mine_status or other dialectic tools. No explicit when-not-to-use or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool implements an issue, which implies destructive modifications to code, but annotations set destructiveHint=false. This is a direct contradiction, scoring 1 per evaluation criteria.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, each adding meaningful information. It is front-loaded with the tool's purpose and avoids fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the main workflow and auto-pick logic, it omits details about failure scenarios, prerequisites (e.g., GitHub access), or behavior when no issues are available. The presence of an output schema partially mitigates missing return value info, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter issue_number has 0% schema description coverage. The description explains the special case of issue_number=0 (auto-pick next issue) but does not explicitly state the effect of non-zero values, leaving ambiguity. This partially compensates for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool implements a specific GitHub issue via the evolve_applier role. It distinguishes itself from sibling tools like evolve_apply by specifying roadmap issue auto-picking behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the auto-pick logic when issue_number=0 and outlines the expected workflow (implement, run suite, open PR). However, it does not explicitly state when to use this tool over alternatives like evolve_apply, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool is idempotent ('repeated calls with the same title overwrite the existing section — idempotent'), but the annotation idempotentHint is false, creating a direct contradiction. Additionally, destructiveHint is false, yet overwriting content could be seen as destructive. No other behavioral details are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for parameters and a clear main sentence. It is informative without excessive verbosity, though it could be slightly more compact. Each sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary behavior and parameter semantics but omits details such as success/failure responses or error conditions. Given the presence of an output schema (not shown), return values may be partially covered. However, the contradiction and lack of usage guidelines leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains each parameter: title is sluggified to a key, body goes verbatim, summary is an optional blockquote, source is a provenance tag. This adds essential meaning beyond the schema's simple type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Materialize a class-level lesson into ~/.threadkeeper/lessons.md.' It explains the idempotent overwrite behavior, which distinguishes it from sibling lesson tools like lesson_remove (removal) and lesson_get (retrieval). The verb 'append' is appropriate as it adds a section, but idempotency is highlighted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description (recording lessons), but there is no explicit guidance on when to use this tool versus alternatives like lesson_list or lesson_remove. No exclusions or specific context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are neutral (readOnlyHint=false, destructiveHint=false). Description implies a read operation but doesn't add behavioral traits beyond the basic operation, such as authentication needs or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and an output schema, the description adequately explains purpose and usage. Minor gap: no explanation of output despite having an output schema, but rules state it's not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and only one parameter 'slug'. Description only mentions 'by slug' without explaining format or expected values, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Return the full body of one lesson by slug' with a specific verb and resource, and distinguishes from sibling tool lesson_list by noting when it's useful.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context: 'Useful when lesson_list surfaced something you want to read in full.' No exclusions or alternatives beyond the implied sibling, but guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the annotations: it is bidirectional and returns per-peer (pulled, pushed) counts or an error marker. It does not describe side effects other than reconciliation, but annotations already declare idempotent=true and destructive=false, so the bar is lower.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences: the first states the action and scope, the second states the return shape. Every word earns its place, and the core behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters), the annotations, and the presence of an output schema, the description is sufficiently complete. It covers the action, directionality, scope, and return behavior. It only lacks alternative-tool routing, which is already penalized in usage_guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description does not need to elaborate on parameters. The baseline for a no-parameter tool is 4, and the description correctly avoids inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Reconcile'), a clear resource ('every configured peer'), and a key qualifier ('right now', 'bidirectional'). It is distinct from sibling tools like sync_status and sync_peers, though it does not explicitly name them to draw the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. 'Right now' implies an on-demand trigger, but there is no mention of when to prefer sync_status or sync_peers, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation, so the description does not need to justify non-mutation. It adds useful context—'cross-machine' scope, 'this node id', and 'how many origin nodes this DB has seen'—but it does not disclose traits like freshness, timing, or whether this tool triggers or reflects sync activity. With the annotation covering safety, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the domain and then provides a tight field list. There is no filler, repetition of the title, or unnecessary prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument, read-only status tool with an output schema, the description contains enough context for correct invocation. It could be more complete by distinguishing itself from sync_peers and sync_now, but that gap is already reflected in the usage-guidelines score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no input semantics to document. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on the output fields rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 'Cross-machine sync status' and enumerates the specific fields returned (node id, peer count, listen address, oplog size, origin-node count), which distinguishes it from sync_peers and sync_now. It lacks an explicit verb like 'retrieve' or 'get', so it doess not quite rise to a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for inspecting cross-machine sync state, but it gives no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as sync_peers, sync_now, or live_status. An agent is left to infer the right choice from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that the tool can apply close/idle actions when dry_run=False, implying mutation of thread state. However, annotations set destructiveHint=false, creating a contradiction. Per evaluation rules, score 1 is assigned for contradicting annotations, and annotation_contradiction is flagged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary followed by categorized details. It is front-loaded with the main purpose and then elaborates. While slightly lengthy, every sentence contributes value; no redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, categorization logic) and the presence of an output schema, the description provides sufficient behavioral details. It covers all categories, conditions, and parameter interactions, making it complete for an agent to understand the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains the role of each parameter within the category logic (e.g., no_notes_days, stale_days, shipped_markers). It adds contextual meaning beyond the input schema, clarifying how parameters affect behavior and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs heuristic triage of active threads, proposing or applying close/idle actions per defined categories. It uses specific verbs ('propose', 'apply') and resources ('threads'), and the categories are explicitly listed, making the purpose unmistakable and distinct from sibling tools like close_thread or idle_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, situations where this tool is preferred, or when not to use it. The purpose is implied but no direct comparison with siblings like close_thread or idle_thread is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint=true). The description adds behavioral details: 30-day window, minimum 3 attempts threshold, and inclusion of unknown categories. These go beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action ('list categories ranked...'). It is concise but could be slightly more structured (e.g., listing parameter details).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main logic but lacks parameter documentation. Given the tool has an output schema (so return values are documented elsewhere) and only one parameter, the description is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, top_n (default 5), is not mentioned in the description. With 0% schema description coverage, the description fails to clarify how to control the number of results or any meaning beyond its default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists categories ranked by failure rate with a specific condition (min 3 attempts in 30d) and includes categories with no attempts. This distinct purpose separates it from sibling tools like register_probe or run_probe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for identifying weak spots needing attention but offers no explicit guidance on when to use this tool versus alternatives. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, not idempotent, and not destructive. The description adds that dry_run short-circuits before spawn (no side effects) and force overrides interval. But it doesn't disclose normal spawn behavior or return value, though an output schema exists. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using clear formatting with backticks. Every sentence adds value, no fluff. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to detail returns. However, it doesn't explain what a 'candidate-review pass' entails or the normal behavior without flags. Given the complexity and many siblings, more context about the process would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description explains both parameters: force (bypasses interval) and dry_run (returns inventory/pending count, no spawn). This adds significant meaning beyond the schema's bare type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fire one candidate-review pass', clearly identifying the verb and resource. It distinguishes from siblings like candidate_review_status by specifying a single pass rather than status. However, it doesn't explicitly differentiate from curator_run or shadow_review_run, which are similar action tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use force and dry_run parameters with clear conditions (force for disabled daemon, dry_run for inspection). However, it lacks guidance on when to use this tool versus alternatives like auto_review_trigger or curator_run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (none set), so the description bears the burden. It discloses the return format and optional seeding, but doesn't detail side effects (e.g., state changes, idempotency) beyond what annotations provide. It's adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one well-organized paragraph that front-loads the purpose and then explains optional inputs. It's concise with no wasted words, though a bulleted list might improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 parameters, 1 required) and the presence of an output schema, the description covers essential aspects: creation action, optional evidence, domain guidance, and return format. It lacks constraints (e.g., claim length) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description effectively explains all parameters: claim, evidence, evidence_kind (with default and options), and domain (with recommended values). This adds significant meaning beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Register a new claim about the user') and the optional evidence seeding. While it doesn't explicitly distinguish from siblings like 'dialectic_evidence', the verb+resource combination is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers guidance on optional evidence seeding and recommended domain values, but does not explicitly state when to use this tool vs alternatives (e.g., adding evidence later via 'dialectic_evidence'). The usage context is 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are neutral (no readOnly, idempotent, or destructive hints), but the description adds crucial behavioral info: dry_run only shows pending count and would_spawn, while a real run spawns and advances the cursor. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence states the action, the second explains the key mode. Perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the basic action and dry_run mode, but lacks explanation of the force parameter and return value description (output schema exists but not addressed). With simple parameters, it's adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only explains dry_run implicitly via its behavior. The force parameter is not mentioned at all, leaving its meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fires one validator pass, with a specific dry_run mode that shows pending count and would_spawn without actual spawning. This distinguishes it from status-check tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like dialectic_validate_status or other run tools. The agent gets no context about prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a meaningful behavioral detail beyond annotations: the tool explicitly refuses to overwrite an existing lesson with the same slug. This is useful safety context for an agent. Annotations are not contradicted, and while more side-effect detail could be added, the core guard is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences carry all essential information: the main action is front-loaded and the safety condition is stated separately. There is no redundant filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 the primary action and an important guard. However, it omits behavior when no trashed section exists, whether restoration can fail, and what happens in the overwrite-refusal case, leaving moderate ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, but it only says 'for slug' without defining what the slug refers to, its format, or where to find it. The word 'slug' is repeated back without added semantic depth; a brief clarification of whether this is a lesson slug vs. section slug would help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact action ('Restore the latest trashed lesson section') and the target slug, making the tool's purpose immediately clear. It is distinct from sibling tools like lesson_remove, lesson_append, and curator_restore because it names the restoration of a trashed lesson section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to choose this tool over alternatives such as lesson_append, lesson_patch, or curator_restore. The context is only implied by the word 'restore' and the refusal-to-overwrite guard, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's mention of listing is consistent. It adds the filtering behavior (by minimum confidence), which is useful but does not disclose other behavioral traits like pagination, ordering, or scope (e.g., all users' concepts?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words. It is front-loaded and efficient, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (list with filter) and has an output schema, the description is largely complete. It could briefly mention that it returns a list of concepts or that 'k' limits results, but overall it provides sufficient context for an AI agent to understand basic behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. It explains 'min_confidence' (filtering), but does not mention 'k' (integer with default 10). Thus, it partially adds meaning but leaves one parameter unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists registered concepts with a specific filter (minimum confidence). It uses a specific verb ('List') and resource ('registered concepts'), and distinguishes from sibling tools like 'register_concept' or 'concept_manage' which perform other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention when not to use it, prerequisites, or how it relates to other concept-related tools. The intended context is only implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is not readOnly, idempotent, or destructive, but the description adds no behavioral context beyond stating it proposes a change, leaving unclear if it requires approval or alters state immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, rationale for existence, and illustrative examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameters and existence of an output schema, the description adequately covers what the agent needs to know to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates partially by giving examples for the 'suggestion' parameter, but does not explain 'rationale' or provide full meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Propose a change' and resource 'brief format', with examples that distinguish it from siblings like 'evolve_apply' which likely applies the change.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to adapt the format) but does not provide explicit when-not or alternatives among related tools like 'evolve_apply'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description adds that it defaults to dry-run and can SIGTERM processes when dry_run=False. This clarifies the destructive behavior beyond what annotations provide, though it lacks details on consequences or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with two sentences. The first sentence states the primary action, and the second explains defaults and the destructive option. Every sentence is useful, though the second sentence could be clearer about the conditional execution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and parameters. Since an output schema exists, return value details are not required. However, for a tool with destructive potential, it could mention safety, permissions, or confirmation prompts. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description is crucial. It explains both boolean parameters (notify defaults to false, dry_run defaults to true) and that setting dry_run=False triggers SIGTERM. This adds substantial meaning beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a memory-guard pass. The verb 'run' and resource 'memory-guard pass' are specific. It does not explicitly distinguish from sibling tools like memory_guard_reclaim or memory_guard_status, but the name and context imply a one-time check action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It mentions defaults and an optional destructive behavior, but does not provide context for when to avoid it or which sibling handles related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only. The description adds that it traverses both directions of edges and returns specific fields, providing behavioral context beyond the annotation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded algorithm and return structure. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the core functionality, it omits explanation of 'max_n' and potential performance implications for large depths. With an output schema present, return values are sufficiently described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description explains 'kind' and 'id' as identifying the starting node, and 'depth' as the hop limit, but 'max_n' is not explained. Default values are given in schema but not repeated, which is acceptable. Some parameters lack additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs BFS from a starting node up to a specified depth, returning visited nodes with kind, id, and a content snippet. It distinguishes itself from sibling tools like 'peers' by specifying the breadth-first nature and bidirectional traversal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as 'search' or 'peers'. The description does not mention exclusions or provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'List' matches that read-only safety profile. The description adds one useful context detail, that the peers are configured via THREADKEEPER_SYNC_PEERS, but it does not describe response behavior, error cases, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every part—verb, resource, and configuration source—carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with an output schema, the description is sufficient to invoke correctly. It is less complete on choosing this tool over nearby siblings, but that gap is already captured in usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so no parameter documentation is necessary. The description's mention of THREADKEEPER_SYNC_PEERS is the only relevant context and it is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('configured sync peers') and identifies the configuration source (THREADKEEPER_SYNC_PEERS), so an agent can tell what the tool returns. It does not explicitly name a sibling alternative such as 'peers' or 'sync_status', so sibling differentiation is weaker than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List the configured sync peers' implies the tool is for inspecting configured peers, which gives some contextual cue. However, it provides no explicit when-to-use or when-not-to-use guidance and does not contrast with sibling tools like 'peers' or 'sync_status'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, describes conditional firing and force skip. Missing details on what happens when conditions not met (e.g., no rich thread). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused paragraphs, no wasted words. Could benefit from bulleted param descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main behavior and force use, but leaves focus unexplained. Output schema exists but description gives no output hint, though partially offset by schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains force parameter well but does not describe focus parameter (default 'combined'). With 0% schema coverage, more param detail needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it checks counters and close-thread state then fires review_thread(mode='auto'). Distinguishes use case for skill_nudge/skill_hint from manual thread selection. Could more explicitly differentiate from review_thread sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use after skill_nudge or skill_hint, and describes force=True scenario. No explicit when-not-to-use, but implication is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations (which only indicate non-read-only, non-idempotent, non-destructive). It details weight discounting based on session type, side effects (bumping counts, recomputing confidence/tier, potential events), and how effective weight is computed. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (6 sentences), front-loaded with the core action and parameter definitions. It is well-structured with clear parameter explanations in a list-like format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, parameters, and side effects. However, it does not explain the output schema (returns something), error conditions (e.g., invalid claim_id), or the 'quote' parameter. Given the tool's complexity and lack of schema descriptions, it is adequate but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It clarifies 'kind' (support/contradict), 'source' (with examples), and 'weight' (with discounting logic). 'claim_id' is self-explanatory but not described; 'quote' is not explained at all. Overall, meaningful value added for 3 of 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Attach evidence to a claim.' It specifies the verb (attach) and resource (evidence to a claim), and distinguishes from sibling tools like dialectic_claim (creating a claim) by the action and parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. There are many sibling tools (e.g., dialectic_claim, dialectic_review, dialectic_observation_resolve), but the description does not mention when to choose this one or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (no readOnly, idempotent, destructive hints), and the description does not compensate by clarifying behavioral traits. It implies a write operation but omits safety, idempotency, or side-effect details critical for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—three sentences plus formatted enum lists. Every sentence adds value, front-loading the purpose and contextual information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and the tool's moderate complexity, the description covers purpose, parameter enums, and pipeline connections. It could be improved by mentioning side effects or return value, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by listing allowed values for `kind` and `confidence`, and noting that `source_thread` is optional. It primarily covers 3 of 4 parameters but lacks detail on `content` format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool marks content as worth carrying forward, using a clear verb and resource. It provides specific categories (insight, pattern, etc.) and mentions related tools (vote_distill, export_distillates), establishing its role in a pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description outlines the overall distillation workflow (voting, exporting) but does not explicitly state when to use this tool versus alternatives like compost or when not to use it. It provides context but lacks exclusions or direct comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains mechanism, blocking behavior, and return values, but annotations set readOnlyHint=false while the tool performs a read-only search. This contradiction lowers the score to 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose, mechanism, and parameter details. It is dense but clear, though slightly verbose in the mechanism explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, no schema coverage, output schema exists), the description covers purpose, mechanism, parameters, and return behavior adequately. It lacks detail on output format but is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds full meaning to all parameters: scope, mode, k, query, timeout_s. It provides defaults, valid values, and bounds (e.g., k=1..100).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool delegates semantic search to the parent process, explaining the mechanism and distinguishing from sibling tools like 'search' or 'dialog_search'. It specifies verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when child has THREADKEEPER_NO_EMBEDDINGS=1 to avoid loading PyTorch. It implies usage context but does not explicitly state when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses polling interval (250ms), clamping of timeout_s, and MCP deadline. However, does not mention side effects of mark_read (default true) or that it may mark signals as read, given readOnlyHint is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: describes behavior, then use case, then parameter details. No fluff, but could be slightly more structured with parameter list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior, use case, and two of three parameters. Missing mark_read semantics. Output schema exists, reducing need for return value explanation, but still incomplete for a moderate-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description explains 'kinds' (comma-separated filter with examples) and 'timeout_s' (clamping). Omits explanation of 'mark_read' parameter entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it blocks waiting for signals, with immediate return if unread. Specifies use case for realtime turn-based exchange, distinguishing it from send tools like broadcast/whisper.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for realtime turn-based exchange with peers, implying context. Does not state when not to use or provide alternatives, but the sibling tools make the comparison clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining the side effect of marking claimed by cid and detailing the auto_spawn child spawning behavior. Annotations are minimal (readOnlyHint=false, etc.), so the description provides necessary behavioral context. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 lines), front-loads the main purpose, and every sentence adds value without redundancy. It efficiently covers the core action, the side effect, and the optional spawn behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, one required, and an output schema (not shown), the description provides adequate coverage of the main behavior and key parameters. It lacks details on return values (but output schema likely covers that) and error conditions, but overall it is fairly complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate for all parameters. It explains auto_spawn and spawn_role but does not mention the required thread_id or the plan parameter, leaving them undocumented. This is insufficient for a tool with 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'claim' and the resource 'thread', and specifies 'for self-initiated work', which distinguishes it from other thread tools like open_thread or close_thread. It also notes it marks claimed by cid, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the auto_spawn and spawn_role behavior, which implicitly guides when to use these options, but it does not explicitly state when to use this tool instead of alternatives like release_pickup or other claim tools. No 'when not to use' or comparison to siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, explains pausing behavior, resumption trigger, and lifecycle. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, and trigger. Missing prerequisites but overall adequate given simple tool and presence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No description of thread_id parameter, though schema has title. With 0% schema description coverage, description adds no value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Mark thread idle' with a specific verb and resource, and distinguishes from siblings like close_thread by noting it can resume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage via auto-revival on next note(), but no explicit when-not-to-use or alternative names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, non-destructive, non-idempotent. The description adds key context: reopening threads, making them active, and the safety of auto-close. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence. The description is somewhat lengthy but every sentence adds value. Minor improvement could be more structured separation of usage and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers key behaviors and parameter semantics. The reopening behavior and kind options are explained, making it reasonably complete for a note-adding tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds semantic meaning for the 'kind' parameter by explaining its options and purpose. However, 'thread_id' and 'content' are not described beyond their names in the schema, leaving some gaps despite 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a note to a thread' with a specific verb and resource. It also distinguishes the tool by explaining its reopening behavior, but does not explicitly differentiate from sibling tools like 'brief' or 'respond'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides style guidance ('Write terse, optimized for future-Claude') and explains the kinds of notes. It also clarifies when to use the tool (on idle or closed threads) and the consequence (reopening). However, it lacks explicit alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation (tailing a log), but the annotation readOnlyHint=false contradicts this, suggesting the tool might modify state. No other behavioral traits are disclosed beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and includes necessary details (e.g., the window stays open until closed, like tail -F). Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool with no parameters and a clear purpose. It explains the output (the log contents) and the behavior of the window, leaving no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The description does not need to add parameter information, so a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a terminal window that tails the live cross-session signal log. It specifies the purpose (monitor dialog between sessions), the resource (signal log), and distinguishes it from sibling tools that are more about managing or querying data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to see real-time dialog between sessions) but does not provide explicit guidance on when not to use it or mention alternative tools. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are neutral (readOnlyHint false, destructiveHint false). The description adds that it returns a new ID, but does not elaborate on side effects, permissions, or thread lifecycle. Minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with 'Open a thread', directly state the action and parameter constraints without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with output schema (not shown), the description covers the return value and key parameters. It lacks error handling or prerequisites but is sufficient for a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, yet the description fully explains both parameters: question must be 5-15 words, parent_id is optional with example format. This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a thread, with specific constraints on the question length and optional parent_id for child threads. This distinguishes it from sibling tools like close_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'ask' or 'respond'. The description implies usage for starting threads but does not provide exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds specific filtering behavior (vote_sum >= min_vote, not yet exported) beyond annotations, providing valuable context. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It efficiently conveys the tool's purpose and key conditions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema documenting return values, so the description need not repeat that. However, the description does not mention ordering or the meaning of 'k', which could be inferred but is not explicit. Overall, it is fairly complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. However, only 'min_vote' is partially explained in the description; 'k' (implying result limit) is not mentioned. This is a significant gap, reducing the ability to use the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists distillates with a specific condition (vote_sum >= min_vote) and that they are not yet exported. The verb 'list' and resource 'distillates' are precise, and the condition distinguishes it from siblings like export_distillates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to view pending distillates) but does not explicitly state when not to use it or provide alternatives. Given siblings like vote_distill and export_distillates, the usage context is implied but not formalized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a read-only operation ('list'), but annotations set readOnlyHint to false, creating a contradiction. The tool may have side effects not disclosed, violating the requirement for consistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words; first states action and parameter, second gives usage context. Perfectly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter and an output schema, the description provides sufficient behavioral context, including threshold, self-exclusion, and use case. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'idle_threshold_min' is explained in description as 'heartbeats within threshold (default 5 min)', adding meaning beyond schema, though type constraints are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists concurrent Claude sessions with heartbeats within a threshold, excludes self, and distinguishes from siblings by specifying 'concurrent sessions' and 'excludes self', which differentiates it from tools like 'whoami' or 'peers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for use ('before making changes') but does not explicitly state when not to use or suggest alternatives. Clear enough for an agent to understand typical usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which are minimal—no readOnly, idempotent, or destructive hints), the description adds that the tool 'Updates reliability aggregates', which is a behavioral side effect. The example also shows that the tool accepts a note. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences plus a clear example. The first sentence states purpose, second summarizes usage, third gives a concrete scenario. No wasted words. Slightly more structure could list parameters, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and an output schema, the description covers the core use case but lacks detailed parameter explanations. It is adequate for a simple scenario but incomplete for complex parameter usage. The output schema exists, so return values don't need explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must carry the load. It only explains probe_id and success via the example, and implies category is the first argument. It completely omits note, latency_ms, and category details. This is insufficient for an agent to correctly set all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Record a self-test outcome' with a specific verb and resource. It also notes side effect 'Updates reliability aggregates.' The example differentiates it from sibling tools like register_probe or run_probe by focusing on recording outcomes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly spells out when to use this tool: 'for both registered probes (pass probe_id) and ad-hoc self-observations'. It provides a concrete example. However, it does not mention when not to use it or offer alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, readOnlyHint=false. The description adds context: 'By default this applies the safe cleanup path,' implying a destructive action moderated by a safe mode. It also clarifies that active spawned child agents are not killed, which is critical behavioral information. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the main action. It could be slightly more structured, but it is efficient and provides key information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description can focus on inputs and behavior. It covers the essential context: what the tool does, safe mode, dry run, and what it avoids. For a tool with three boolean parameters and destructive behavior, this is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 boolean parameters with 0% description coverage. The description only explains dry_run ('Set dry_run=True to inspect the plan first'), leaving force and json_output unexplained. Given low schema coverage, the description should compensate by clarifying all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Trim ThreadKeeper memory and clean orphan/over-limit server processes.' It uses specific verbs and targets, distinguishing it from sibling tools like memory_guard_reclaim or mp_cleanup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on usage: safe cleanup by default, with option to inspect using dry_run. It also states what the tool does not do (does not kill active child agents), helping the agent understand when to use it. However, it does not explicitly compare to alternatives like memory_guard_reclaim.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds the randomness and idle filter, which is useful but not extensive behavioral detail beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the action, second gives usage context. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and output schema, the description covers core purpose and usage. Lacks handling of edge cases (e.g., fewer idle threads than N), but output schema may provide additional details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'N' in the description, implying it is the count, but no further details on range, behavior when insufficient idle threads, or output format. Adequate for a single parameter with sensible default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it 'Surfaces N random idle threads', specifying the verb, resource, and parameter. It distinguishes from siblings like 'idle_thread' by mentioning random selection and multiple threads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Call when current threads feel exhausted or you want to shake loose dormant ideas.' Provides clear context but no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds meaningful behavior: it validates file location, naming, marker, and content hash, and explains that replay or swapped reports are rejected—useful context beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose and dense, relevant constraints. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and annotations that cover return and idempotency/safety, and the description covers path/match/marker/hash preconditions. The missing documentation of the required summary parameter and lack of explicit sibling routing leave a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are 0%, so the description carries the burden. It indirectly explains report_path (must live under THREADKEEPER_CURATOR_REPORTS_DIR and match REPORT-*.md) and report_sha256 (must match parent-verified content hash), but it never explains the required summary parameter or the expected formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: mark a Curator report as processed by the evolve_applier child. It is clear about the object and operation, and the nuanced preconditions distinguish it from related evolve_apply/mark siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context that this is called after the evolve_applier child has processed a report, and enumerates acceptance preconditions. It does not explicitly name alternative tools or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true (safe to retry) and destructiveHint=false. The description adds value by specifying the triggering event ('opened a real pull request'), which is behavioral context beyond what annotations provide. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two lines with no unnecessary words. It front-loads the action and context, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (unknown content) and the tool is specialized, the description provides the necessary context about when it is called. However, it does not describe the exact effect on the roadmap issue (e.g., what state change 'handed off' implies), leaving some uncertainty about the tool's impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. However, the description does not mention or explain the parameters (issue_number, pr_url) at all. While the names are somewhat self-explanatory, the description misses an opportunity to clarify their roles, leading to a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark a roadmap issue as handed off') and specifies the caller and precondition ('called by evolve_applier only after it has opened a real pull request'). This distinguishes it from sibling marking tools like 'evolve_mark_applied' which likely cover other cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (only after a real PR is opened) and who calls it (evolve_applier), providing clear context. It does not explicitly mention alternatives, but the condition is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing that dry-run is the default, enumerating the exact stores affected (dialog rows, FTS/vector sidecars, dialectic/verbatim/extract/task records, task spool files), and noting that lessons/skills are listed for manual review rather than silently removed. This substantially clarifies the destructive behavior implied by destructiveHint=true and idempotentHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but compact: three sentences front-load the purpose, then cover the dry-run flow and the full deletion scope. Every sentence contributes meaningful information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and multi-store effects, the description is highly informative: it covers dry-run behavior, what gets deleted, and manual review for citing lessons/skills. The main remaining gap is the undocumented selector_type parameter, but the presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. It does clarify the dry_run parameter well ('Defaults to dry-run', 'Set dry_run=False to delete') and gives meaning to selector by describing it as a session/cid/thread/dialog UUID. However, the selector_type parameter, including its 'auto' default, is left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Forget') and a clear resource ('one session/cid/thread/dialog UUID'), and the deletion scope is further detailed. It does not explicitly differentiate from sibling tools like close_thread or session_end, but the UUID-oriented 'forget' concept is reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the dry-run default and how to invoke actual deletion by setting dry_run=False, which is useful practical guidance. However, it does not provide explicit when-to-use or when-not-to-use guidance relative to alternatives such as unlink, close_thread, or session_end.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds critical behavior: existing edges with same (from, to, relation) are replaced, updating weight/timestamp. This goes beyond annotations to clarify the mutation semantics. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 5 sentences, front-loading the purpose, then listing kinds and relations, and concluding with replacement behavior. Every sentence is informative and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 5 required, and an output schema, the description adequately covers the tool's purpose, entity types, relation suggestions, and replacement behavior. It lacks details on weight and ID parameters, but the presence of an output schema reduces the need to describe return values. Overall fairly complete for a medium-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. It lists allowed values for kinds and suggested relations, which adds meaning beyond the schema. However, it omits details about the weight parameter (default, meaning) and the ID parameters (format, source). The schema has no enums, so the description's coverage is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a typed edge between two entities,' which is a specific verb+resource. It lists the kinds of entities and suggested relations, and distinguishes from sibling tools like 'unlink' by describing the creation behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides suggested relations but lacks explicit guidance on when to use this tool versus alternatives (e.g., unlink or note). There is no mention of prerequisites or when not to use it, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details the output fields (cid, snippet, age, count), self-marking with '*', and behavior when alone. This adds valuable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: purpose, inference method, and output format. Every sentence adds value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, read-only, with output schema), the description covers input meaning, output format, and edge cases (empty if alone). It is fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter window_min has 0% schema description coverage, but the tool description explains it as the time window for activity. This compensates well, though the default value is not repeated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists concurrent Claude conversations active within a specified window. It uses specific verb and resource, but does not explicitly differentiate from potentially similar siblings like 'neighbors' or 'presence'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for monitoring others' activity but does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, idemppotentHint=true, destructiveHint=false), the description discloses concrete side effects: changed constants are republished to every daemon and tool, newly enabled daemons are started, and interval changes apply on the next daemon tick. It also clarifies what does NOT happen (no CLI restart) and shows the return string format. The idemppotentHint is consistent with the described behavior — no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action is front-loaded in the first sentence, and the second paragraph packs only high-value behavioral facts: file paths, no-restart mechanism, republish target, daemon side effect, tick deferral, and a return example. Slightly dense, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-param tool with an output schema and safety annotations already present, the description thoroughly covers scope, mechanism, side effects, and return format. The one material gap is the unexplained 'force' parameter, which an agent must decide whether to pass when invoking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the 'force' parameter, so an agent cannot know whether force=true bypasses change detection, forces a re-read, or something else. The schema title 'Force' and its default of true provide only weak inference; the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource pair ('Re-read the watched config files and hot-apply changed env knobs') and precisely names the affected files, including concrete paths. This specificity lets an agent distinguish it from sibling status tools like config_watch_status without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'hot-apply — no CLI restart' framing gives clear context for when this tool is appropriate: after editing watched configs when changes must take effect in the live process. It does not explicitly name alternatives or state when-not-to-use, so it falls just 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say destructiveHint=true, and description goes far beyond that: it warns dry_run defaults true and reports only, and enumerates six destructive/potential actions with their exact criteria (cosine thresholds, stale days, orphan days, retention bounds). This is valuable behavioral context that annotations alone could not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Frontloaded dry_run warning, then a scannable six-line bullet list, each line one purposeful rule. No filler or repetition of schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values do not need description. The main gaps are minor jargon ('claim mark', 'retention bounds') and no explicit scheduling guidance. Still, an agent can correctly invoke the tool safely and understand what each action will do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description gives real semantics for all five parameters: note_cosine and verbatim_cosine are similarity thresholds, stale_days and orphan_days are age cutoff, and dry_run controls report-only mode. This compensates fully for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
clear resource ('memory') and six concrete sub-operations in bullet list; avoids tautology. It does not explicitly name sibling tools (e.g., compost, forget, db_compact) to distinguish itself from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description labels the tool as 'periodic memory hygiene' and notes dry_run reports only, but gives no explicit when-to-use guidance or alternatives. It leaves it to the agent to infer when to call consolidate versus the many related maintenance/cleanup siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveness (destructiveHint=true). The description adds valuable context: the full lifecycle (active -> stale -> archived), tier-aware adjustments (validated never aged, hypothesis ages faster), and exclusions. Dry_run behavior is also disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and sections, front-loading the main action. It is informative without being overly verbose, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (lifecycle, tiers, exclusions, dry_run) and the presence of an output schema, the description covers most needed context. It explains the behavior fully, though the output is not described (but that's acceptable since output schema exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description does not explicitly describe each parameter. However, it does provide context for 'dry_run' (reports without writing) and indirectly for 'stale_after_days' and 'archive_after_days' through the lifecycle explanation. This adds meaning beyond the schema but could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Move stale agent-created skills to archive'. It uses a specific verb ('move') and resource ('skills') and distinguishes from sibling tools like curator_review by detailing the archiving lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (for archiving stale agent-created skills) and when not to (never touches foreground, pinned, validated, or unknown provenance skills). It also mentions the dry_run default for safe testing. However, it does not explicitly name alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations: it explains the tool prevents re-interpretation and is only called after the child has acted. Annotations already indicate idempotency and non-destructiveness, but the description reinforces these traits and clarifies the workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose and succinctly adding context. Every word serves a clear function with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple flag-setting tool with an output schema, the description covers the key behavioral aspects and workflow context. It could mention return value or error scenarios, but the output schema likely fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description should compensate, but it does not explain the parameters. It only implies that 'id' refers to the buffer row, and 'note' is not described. This is insufficient for a 2-parameter tool with no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool marks a dialectic_observations buffer row as 'processed', specifying the action, resource, and outcome. It also identifies the caller (validator child), differentiating it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates when the tool is used (after writing or skipping observation claims/evidence) and by whom, providing clear context. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it states the tool only changes status ('promoted' or 'dismissed') and never applies edits. This aligns with annotations (not read-only, not destructive) and adds useful detail. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header, bullet points, and code formatting for parameter values. It is concise but informative. Minor redundancy: the statement 'this tool never applies' appears twice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values are covered), the description sufficiently explains the tool's behavior, parameter usage, and side effects. It could mention the life cycle of a suggestion (pending queue) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% coverage, so the description must compensate. It explains the 'decision' parameter values and the 'reason' parameter's purpose (especially for dismiss to note duplicate id). However, the 'evolve_id' parameter is not described at all. Overall, it adds moderate semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Triage a pending format-evolution suggestion.' It explains the two decision options (promote and dismiss) with detailed effects, and distinguishes itself from siblings like evolve_apply by explicitly stating it never applies edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the tool is used by the autonomous evolve reviewer daemon and available manually. It clarifies when to use 'promote' versus 'dismiss' and the role of the 'reason' field. However, it does not explicitly state when not to use this tool or provide direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses meaningful behavior: it checks open/closed GitHub issues, a local ledger, and fingerprints before invoking `gh issue create`, and it records duplicate skips and successful files as events. This gives the agent a concrete picture of side effects, though it does not cover failure modes or auth prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the main purpose appears in the first sentence, with the dedup mechanics in the following two sentences. No sentence is wasted, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, process, and side effects, and an output schema exists to document return values. It does not mention when to prefer alternatives or what credentials/prerequisites are needed, but for a simple three-parameter create operation with dedup behavior, the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 parameter meaning, but it does not explain title, body, or labels. The parameter names are self-explanatory and the roadmap issue context hints at labels, yet no format, constraints, or expected content guidance is provided beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a reviewer roadmap issue through the mechanical dedup gate.' It clearly distinguishes the tool from siblings like evolve_apply_roadmap_issue by emphasizing creation and adds a unique detail (the dedup gate) that makes the tool's role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool is used to create reviewer roadmap issues and is guarded by a dedup mechanism. It does not explicitly name alternatives or give when-not-to-use conditions, but the purpose and workflow are stated plainly enough that an agent can infer the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms this is a read operation. It transparently details the clustering algorithm, scoring mechanism, and error condition without embeddings. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but structured as a clear algorithm with numbered steps and a note about prerequisites. It is front-loaded with purpose and algorithm summary, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, output schema, algorithm), the description covers purpose, algorithm, prerequisites, and return values thoroughly. It is complete for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should add meaning to parameters. It mentions min_cluster_size and response_cohesion in context, but top_n, window_days, and max_messages are only listed with defaults. This leaves gaps for a tool with 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to find recurring assistant-side patterns that survive prompt variance. It uses specific verbs and resources (find patterns, cluster responses) and distinguishes itself from siblings by focusing on invariant detection across conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a step-by-step algorithm and states a prerequisite (semantic embeddings required, else ERR). It implies usage for identifying stable response patterns but does not explicitly mention when not to use or compare to alternatives like distilling or searching. Still, it offers clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds the specific data displayed (thresholds and RSS rows), which aligns with read-only behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, with no wasted words. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status tool with no parameters and an output schema, the description is fully sufficient. It tells exactly what the tool shows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and 100% schema description coverage by default. The description need not add parameter details, and it does not. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Show' and clearly identifies the resource: memory-guard thresholds and thread-keeper RSS rows. It distinguishes itself from sibling tools like memory_guard_check and memory_guard_reclaim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. Given related siblings, explicit usage context would be helpful but is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description is not contradicted. The description adds value by explaining the ranking by oldest last_touched_at and that a one-line summary is added, which is behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences long, with no wasted words. The first sentence states the purpose, and the second adds key details about ranking and summary. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a read-only retrieval with an output schema, so return values are covered externally. The description explains the selection criteria (stale, unclaimed, ranked by oldest) and the summary provided. It lacks explicit parameter guidance but otherwise feels complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (max_n, min_idle_days) with default values but no descriptions. Schema description coverage is 0%, so the description should compensate but does not mention these parameters or explain how to use them. The defaults imply sensible behavior, but the lack of parameter explanation reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool surfaces unresolved threads that are stale and unclaimed, specifying it is for self-initiated pickup when context is free. This distinguishes it from siblings like review_candidates, which likely reviews all candidates without the pickup focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use when context is free and for self-initiated pickup. It implies this is not for reviewing all candidates but for selecting candidates to claim. However, it does not explicitly mention when not to use or list alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds context that the tool is a write operation for registering new concepts. However, it does not detail side effects, idempotency (idempotentHint=false), or data persistence, missing opportunities to fully disclose behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core purpose first. Every sentence adds value—defining the key constraint on description and clarifying optional fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (1 required) and an output schema (not shown), the description covers the purpose and each parameter well. It does not explain return values, but the output schema likely handles that. Overall, it is sufficiently complete for a registration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description compensates fully by explaining each parameter: description should use examples (not labels), triangulation_notes as paraphrase runs, and confidence with enumerated values. This provides essential semantics that the schema alone does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Register a concept that lacks a precise human name,' using a specific verb and resource. It distinguishes from siblings like concept_manage (managing existing concepts) and expand_concept (expanding concepts), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for concepts without a precise human name but does not explicitly state when to use this tool versus alternatives like concept_manage or expand_concept. No contrast or exclusions are provided, leaving it to the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains behavioral effects (bumping counters, emitting events for 'wrong' outcome) beyond annotations. Annotations already indicate non-readOnly, non-idempotent, non-destructive, and the description adds useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear opening purpose statement followed by bullet-like explanations of the two main parameters. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters and their behavioral implications. Given the presence of an output schema, it does not need to explain return values. It could mention error conditions or authentication requirements, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description provides critical parameter details: explains the four kinds and three outcome values, and notes that outcome only applies to 'use' kind. This adds significant meaning absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records usage telemetry for a mirrored skill, specifying it bumps counters and timestamps. It is precise but does not explicitly differentiate from sibling tools like skill_manage or skill_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after skill interactions and provides guidance on marking 'wrong' outcomes, but lacks explicit when-to-use or when-not-to-use compared to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The `readOnlyHint: true` annotation already establishes that this tool does not mutate state. The description adds meaningful behavioral context: the result is deterministic, it enumerates the record contents, and it explicitly warns that semantic candidates are leads, never automatic delete decisions. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, leading with the core purpose, then providing the two usage modes, then adding the important safety-oriented caveat. Every sentence carries meaningful information and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main trigger, output modes, safety behavior, and return contents, and an output schema exists to fill in return shape details. The main gap is the unelaborated `include_archived` parameter, which prevents the definition from being fully self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. It explains the `name` parameter's effect well: with `name`, return a single record; without it, return an inventory. However, the `include_archived` parameter is never explained, and its interaction with the two output modes is left entirely to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's specific purpose: validating ThreadKeeper-managed skills across supported CLI consumers. It distinguishes itself by detailing exactly what is returned with and without `name`, which separates it from sibling tools like `skill_list` and `skill_record`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit trigger: 'Curator must call this after every skill mutation.' It also clearly explains the two usage modes based on whether `name` is supplied. It does not explicitly mention when to prefer alternative sibling tools, so it misses the full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's not read-only, not idempotent, not destructive. Description adds context about manual vs auto-tagging but no additional behavioral traits like side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with action. Highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity and presence of output schema, description covers main use case and differentiates from sibling. Lacks parameter details but overall sufficient for simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and description does not elaborate on what task_id or signal_id represent or how to obtain them. Fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: manually attach a signal to a task. It uses specific verb-noun pair 'attach a signal' and distinguishes from auto-tagging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'useful when retroactively building a task-thread', contrasting with auto-tagging at signal-emit time. Provides clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by detailing the resolution order and potential instability of the mtime fallback. This informs the agent about reliability and edge cases without contradicting the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using bullet points for the resolution order, and front-loads the main purpose. Every sentence is essential and adds clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description fully covers what the tool does and how it determines the conversation_id. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description cannot add meaning beyond the schema. The baseline of 4 is appropriate since no further parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the conversation_id and the detection method, with a specific verb ('Return') and a well-defined outcome. It distinguishes itself from siblings by being the only tool that reveals conversation identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no guidance on when to use it versus alternative tools. No comparison to siblings like 'context' or 'brief' is made, leaving the agent to infer usage context on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which indicate a non-read-only, non-idempotent mutation), the description reveals that the message appears in others' inbox during their next 'brief()' and is accessible via 'inbox()'. This adds valuable behavioral context about message visibility and retrieval. No information about reversibility or limits is provided, but the added context is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with the primary verb and purpose in the first sentence. Every sentence adds value: the first states the action, the second explains visibility mechanics, and the third lists use cases. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers essential behavior: what it does and how peers receive the message. It could mention potential limits (e.g., rate limiting) or persistence, but the provided context is sufficient for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'content' has 0% schema description coverage; the description only implies it is the message text. While the tool is simple and the meaning is clear from the tool name and description, no additional constraints (e.g., max length, format) are given. A baseline of 3 is appropriate given the low coverage but adequate implied semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Post a message visible to ALL concurrent claude conversations,' clearly specifying the verb (Post) and resource (message) with a precise scope. It distinguishes from siblings like 'whisper' or 'note' by emphasizing broadcast to all sessions, and provides concrete use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists appropriate use cases ('shared insights, status updates, work claims, anything you'd want sibling sessions to know'), offering clear context for when the tool is appropriate. However, it does not specify when not to use it or mention alternative tools like 'whisper' for targeted messages, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint; description adds ordering semantics (priority DESC then key). No hidden behaviors omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste. Front-loaded with verb and resource, ordering detail added.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a read-only list tool with no parameters and an output schema; no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline 4 applies. Description adds no parameter info, but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists all core-memory entries, ordered by priority and key. Distinguishes from sibling tools like core_get and core_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear purpose but no explicit guidance on when to use vs alternatives; context from sibling names helps but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explains the marking-read behavior and unread filtering beyond what annotations provide. Annotations give readOnlyHint=false, which is consistent. However, it does not detail what happens to the 'k' parameter or any other 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that effectively convey the tool's purpose and key parameters, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple read tool with an output schema, the description covers essential functionality and parameter usage. It could mention the return format or the meaning of 'signals' but remains adequately complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds meaningful semantics for 'unread_only' and 'mark_read', explaining their defaults and interplay. The 'k' parameter is not mentioned, but the boolean parameters are well-covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Read' and resource 'signals addressed to me (whispers + broadcasts)', which is specific and distinguishes the tool's purpose without needing to reference siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading inbox signals and provides parameter options, but does not explicitly guide when to use this tool instead of sibling tools like whisper or broadcast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses specific behavioral traits: self-identification with is_self=true, the guarantee that self is never flagged as orphan, inclusion of daemon thread liveness in the text view, and the return format (structuredContent plus legacy text block). This is rich, non-obvious context that the annotation alone does not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no filler. It front-loads the core purpose, then adds specific details that are all relevant to understanding behavior and output. Every sentence earns its place, and the length is proportional to the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, a readOnlyHint annotation, and an output schema present, the description covers all necessary invocation knowledge. It explains the key output fields, self-handling logic, and return transport, so an agent can invoke and interpret the call without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameters to document; the schema coverage is trivially 100%. Per the baseline for 0-parameter tools, the description need not add parameter-specific guidance. It appropriately avoids inventing parameter details that don't exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Diagnostic snapshot of every running thread-keeper server process on this machine.' It enumerates the specific fields shown (pid, parent status, RSS, heartbeat age, orphan classification), making the tool's scope concrete. However, it does not explicitly distinguish itself from siblings like mp_dashboard or live_status, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Diagnostic snapshot' implies the tool is for inspecting process health, and the zero-parameter signature makes it low-risk. But the description never explicitly states when to prefer this over alternatives such as mp_dashboard, whoami, or live_status, nor does it give exclusions. Usage is implied rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only. Description adds rich behavioral context: it returns a dense, structural brief not for human reading, explains the format (static memory + live working set + nudges), and details scope control. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded instruction, clear formatting for scope options, and no wasted words. Slightly longer than necessary but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description adequately covers purpose, behavior, and most parameters. The omission of 'k' is a minor gap, but overall the agent can use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains 'query' and 'scope' in detail, but the 'k' parameter (integer, default 6) is completely undocumented. This partial coverage justifies a midpoint score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves a compact memory brief and should be called at the start of every conversation. It distinguishes between first and mid-session calls via scope, but does not explicitly differentiate from sibling tools like 'context'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call at the start of every conversation and provides detailed guidance on when to use 'full' vs 'query' scope, including how to pass the user's first message as query. Offers clear usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description's 'Show' aligns with that. The description adds value by disclosing the exact data reported (last 5 reload passes) and the watched-file resolution behavior in both hybrid and legacy modes. This goes beyond the read-only annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences with the core purpose front-loaded in the first sentence. The subsequent sentences add necessary mode-specific details without repetition or filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument, read-only status tool with an output schema, the description covers the essential behavior, both operation modes, and the relevant environment variable. There are no hidden parameters or destructive actions to warn about, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so the baseline is high. The description adds useful environment-variable context (THREADKEEPER_CONFIG_WATCH_PATH) and explains how watched files are resolved, which helps the agent understand external configuration influence. There is no parameter documentation burden to fulfill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Show hot-config-reload state + the last 5 reload passes.' This precisely identifies what the tool reports and distinguishes it from action-oriented siblings like config_reload. The added mode details further clarify its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only status-inspection use case but never explicitly states when to choose this over alternatives such as config_reload. It provides useful context about hybrid vs legacy modes but lacks direct 'use when' guidance or exclusions. Usage is therefore inferred rather than clearly directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses meaningful behavior: force overrides CURATOR_INTERVAL_S=0 gating, dry_run short-circuits before spawn, avoids cursor advance, and normal execution implies spawn and cursor progression. This adds real side-effect context beyond the basic readOnly/idempotent/destructive flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, and uses short labeled sections for each flag. Every sentence adds value; there is no padding or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two optional parameters and an existing output schema, the description covers the behavior, the daemon-interval interaction, and the dry-run return preview. It only lightly explains what a 'curator pass' actually entails, but that is somewhat implied by the tool name and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both boolean parameters with their exact effects. force and dry_run are both given precise semantics, making the agent able to use them correctly without further inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action 'Fire one curator pass,' which clearly identifies the operation. It explains how the two flags alter behavior, giving an agent a clear sense of what this tool does, though it relies on the slightly jargon-heavy term 'curator pass'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: force=True for one-shot triage or testing when the daemon is disabled, and dry_run=True for inspecting inventory shape before a batched spawn. It does not explicitly compare against sibling tools like curator_run, but the use cases for each flag are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description is fully consistent with a non-mutating status read. It adds value by specifying exactly what is shown, including configuration, queues, running applier, and recent passes, which goes beyond the annotation and helps the agent understand the scope of the read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that leads with the action 'Show' and efficiently lists all status components without filler. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and readOnlyHint annotation covering safety, the description names all four status categories the tool exposes. Given the low complexity and zero parameters, nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to document. The parameterless baseline of 4 applies, and the description makes no misleading parameter claims.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Show', identifies the resource clearly as the evolve-applier, and enumerates exact status components: config, curator/evolve queues, running applier, and last 5 apply/recovery passes. This clearly distinguishes it from action-oriented siblings like evolve_apply or evolve_mark_applied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a diagnostic use case by listing what it displays, but it provides no explicit when-to-use guidance or comparison to the many status-related sibling tools. An agent must infer from the name and content that this is the right tool for checking evolve-applier state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it reveals that the tool sets a field (applied=1) that removes the suggestion from certain views, records a URL, enforces a non-empty pr_url gate, and notes that a human still reviews/merges. This workflow detail helps the agent understand consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concisely written in four sentences, each adding distinct value: purpose, caller, effect, and a critical usage rule. It could be slightly tighter, but overall it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, clear side effects), the description covers the main behavioral aspects and workflow steps. It does not discuss error cases or output schema (which exists), but the core information is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates: it explains pr_url's role as a required gate and its non-empty constraint. However, it does not explain evolve_id, leaving its semantics implicit. This is adequate but not fully helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to mark a format-evolution suggestion as 'APPLIED', with a specific caller context (evolve_applier child) and action (sets applied=1, records PR url). It distinguishes from sibling mark tools by specifying the exact resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool ('after it has opened the PR') and provides a strong usage rule ('never mark a suggestion applied without a real pull request'). It does not explicitly contrast with sibling tools, but the context is clear enough for an AI agent to determine appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly=false, idempotent=false, and destructive=false. The description adds useful operational context: ingestion runs asynchronously in the daemon host and manual calls are for backfill or catching up after a long absence. It does not contradict the annotations, though it could disclose more about duplicate-ingestion consequences given the non-idempotent hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action, then supplies the operational context and manual-call conditions. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter optional tool with an output schema and annotations present, the description covers purpose, normal operational behavior, and when manual invocation is appropriate. The only meaningful gap is the unexplained max_msgs parameter, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, max_msgs, with 0% schema description coverage, and the description never mentions it. While the parameter name and default value give some hint, the description adds no guidance on what max_msgs means, how it affects ingestion, or whether backfill scenarios should adjust it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Ingest new transcripts.' It also distinguishes this tool from the automatic daemon-driven pipeline, and the sibling list contains no similarly named ingestion tool, so an agent can tell what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains that initial and periodic passes run asynchronously in the daemon host, and that manual invocation is intended for backfill or after a long absence. This gives the agent clear conditions for choosing manual invocation over relying on the automated pipeline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reinforces the readOnlyHint annotation by stating 'Read-only; no spawn, no mutate.' Provides additional context on what data is shown and how to interpret it, though no mention of performance or staleness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three sentences covering purpose, safety, and usage examples. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter with default, existence of output schema, and simple read-only nature, the description provides sufficient context and actionable examples for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description references the window_days parameter in context ('in the last `window_days` and 30d'), adding meaning beyond the schema, but does not fully explain its range or effect. With 0% schema description coverage, this compensates somewhat.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a 'one-call rollup' of the entire system, listing specific components like store sizes, loop firing counts, and production metrics. It distinguishes itself from siblings by being a high-level dashboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes read-only and non-mutating behavior, and provides concrete examples of when to use (system health check, spotting unproductive loops, detecting backlogs). Could improve by naming alternative tools for specific tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description aligns by stating it 'surfaces' and 'returns' data. The description adds useful context: the harness doesn't auto-grade because the same model attempts and judges. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, each adding value. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one input and known output (prompt and grader hint). The description covers purpose, return content, and post-action. An output schema exists but isn't shown; however, the description provides sufficient high-level understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (probe_id) with 0% description coverage. The tool description does not explain the parameter's format or constraints, leaving the agent to infer from context. A simple parameter, but the lack of elaboration is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it surfaces a registered probe for self-attempt, returning the prompt and grader hint. This distinguishes it from sibling tools like register_probe and record_attempt, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent to call record_attempt after attempting, and explains the lack of auto-grading due to the model doing both attempting and judging. This provides clear usage context, though it doesn't explicitly exclude alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=false but the description does not fully disclose side effects of a normal run (e.g., does it spawn? advance cursor?). It details dry_run behavior but leaves normal behavior implied. The addition of dry_run details is helpful but not complete for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the main purpose, and each sentence provides essential information. No superfluous text. Perfectly sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two optional parameters and an output schema exists (not shown but noted), the description covers purpose, parameter semantics, and use cases. It lacks a definition of 'shadow-review' but that is likely domain knowledge. Overall, it is adequately complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameter descriptions (0% coverage). The description explains both parameters thoroughly: force bypasses daemon disable, dry_run short-circuits and returns diagnostics. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fires one shadow-review pass. The verb 'fire' and resource 'shadow-review pass' are specific. It distinguishes from sibling 'shadow_review_status' which checks status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage contexts: force is for tests and one-shot triage, dry_run is for inspecting candidate windows before spawning. It does not compare directly with alternatives like candidate_review_run, but provides clear when-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining the adversarial panel mechanism, skeptic presence and its effect on vote weight, fire-and-forget behavior, and that aggregates recompute per vote. This provides rich behavioral context that annotations (all false) do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main purpose. It uses backticks for parameters and explains behavior succinctly. Could be slightly more concise, but overall efficient for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool spawns an adversarial panel and has an output schema, the description covers all necessary aspects: what it does, parameter meanings, behavioral details (skeptic, fire-and-forget), and post-invocation steps (check pending_distillates/dialectic brief). It is complete for an orchestration trigger.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It explains target_kind ('distill' or 'claim'), target_id (Dxxx/UCxxx), and that size/roles override config defaults. However, it lacks specifics on allowed role formats and the meaning of size default 0.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it spawns a panel to vote on a distillate or claim, filling a promotion quorum. It specifies the target types and IDs, and distinguishes from direct voting tools like vote_distill and dialectic_evidence by emphasizing it is a higher-level orchestration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to fill promotion quorum) and provides context on adversarial behavior and fire-and-forget nature. It does not explicitly state alternatives, but indirectly distinguishes from direct voting tools. Lacks explicit 'when not to use' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safety, but the description adds substantial behavior beyond it: retired/superseded claims are omitted by default, as_of returns historically valid superseded claims, 'disputed' is a separate unordered bucket, and include_validity appends fields without altering default output. This is rich, non-obvious 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into short, purposeful sections: core summary, temporal/validity options, confidence semantics, and output format. Every sentence adds useful information, with no repetition of schema defaults or annotation values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the non-obvious temporal filtering, confidence bucket behavior, and output format, while an output schema exists to document return values. The main gap is k/result-count semantics and any pagination or ordering behavior, which are relevant for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden. It thoroughly explains min_confidence values and the special 'disputed' handling, as_of accepted formats and semantics, and include_validity's effect. Domain is only called 'optional', and k is never explained, leaving its meaning (likely result limit) to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb ('List') and resource ('active claims') with clear filter dimensions (confidence floor, optional domain). This distinguishes it from mutation/creation sibling tools like dialectic_claim, dialectic_supersede, and review_candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives detailed conditional behavior for as_of, include_validity, and min_confidence, so an agent knows when those options are relevant. However, it never explicitly names sibling alternatives or states when to choose this tool over the many related dialectic_* and review_* tools, leaving routing mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by detailing what the output contains (config, pending count, last 5 passes), providing behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase that front-loads key information: the output components. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, the presence of an output schema, and low complexity, the description adequately explains the tool's purpose and return value. It does not mention the output schema explicitly, but the content is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%. The description does not need to add parameter details; baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool returns 'Validator config + pending observation count + last 5 passes,' clearly stating the resource and output components. It distinguishes from siblings like 'dialectic_validate_run' (executes validation) and other status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool is for checking validator status. Although no explicit when-not or alternatives are stated, the context and sibling names make its usage obvious for a read-only status retrieval. Slight room for improvement with explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important non-obvious behavior: items are marked exported_at so they won't be re-exported on subsequent calls. This goes beyond the annotations, which only indicate the operation is not read-only, not idempotent, and not destructive, and gives the agent a realistic expectation of state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, each carrying necessary information: the operation, the deduplication behavior, and the default destination. The key action is front-loaded, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two optional parameters and an output schema, the description covers the essential invocation details. Minor gaps remain, such as whether the output file is overwritten or appended, but the description is sufficient for correct selection and basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to both parameters: min_vote is tied to the vote_sum filter, and the default output path is explicitly stated. This complements the schema, where output_path defaults to an empty string and min_vote defaults to 1, by explaining what those defaults actually mean.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Write distillates'), the target format ('jsonl bucket'), the selection criterion ('vote_sum >= min_vote'), and the key side effect (marking exported_at). This clearly distinguishes it from siblings like pending_distillates or distill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear: call this to export qualifying distillates to a JSONL file, and the min_vote threshold defines exactly which items are eligible. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds value by spelling out that heading, summary, provenance, and timestamps are preserved, so the agent understands the blast radius. It leaves failure behavior for non-unique or missing substrings implicit, but the uniqueness statement hints at the contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences; the first states the action and the second adds the constraint and differentiation. There is no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has annotations, an output schema, and a clear sibling contrast, so the description covers the high-risk aspects: destructive edit, scope (unique substring), and metadata preservation. It could be slightly more explicit about empty new_string behavior and non-uniqueness errors, but it is adequate for selection and normal invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for parameter meaning. It explains old_string's uniqueness requirement and implies new_string is the replacement, but it does not explicitly state that an empty new_string deletes the substring or clarify slug scope beyond the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Replace one unique substring in a materialized lesson,' a specific verb plus resource that clearly identifies a surgical edit operation. It also includes a uniqueness constraint and calls out what it preserves, separating it from the sibling lesson_append.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a concrete precondition ('must occur exactly once within the lesson's markdown body') that an agent must verify before calling. It also names the alternative lesson_append and contrasts the patch behavior with wholesale replacement, giving clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which are neutral), the description discloses the side effects: 'Marks the original question as read and inserts an `answer` whisper to the asker.' This informs the agent that the tool modifies state (write operation) and is not idempotent. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste. It front-loads the core action and then explains when to use it and what happens. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (not shown), the description covers purpose, usage context, and side effects. It lacks details like error conditions or prerequisites, but these are less critical for a straightforward answer tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (qid, content) with 0% description coverage. The description adds meaning by linking qid to 'signals.id' from the question, and content to the answer. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Answer a specific question (signals.id) with a directed whisper.' It specifies the resource (a question identified by signals.id) and the action (answering with a whisper). It also distinguishes from siblings like 'ask' (which likely poses a question) and 'whisper' (general whisper), as it specifically targets `+question` entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use after seeing a `+question` entry in inbox()/wait().' This provides clear context for when to use the tool. It implies not to use it arbitrarily, but it does not name alternative tools for other scenarios, which would improve the score further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal info, but the description fully details behavior: it spawns a child Claude process, writes back via memory/skill tools, sets write-origin for curator pruning, and explains both modes ('auto' versus 'inline'). This exceeds 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary sentence, then detailed parameter explanations. Each sentence serves a clear purpose, and there is no redundancy or fluff. It is appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values are handled. The description covers purpose, parameters, modes, and side effects (spawning a process, resource usage). It could explicitly mention the thread_id parameter and prerequisites like thread being closed, but it is already quite complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining the 'focus' and 'mode' parameters in detail with their enumerated values and effects. 'thread_id' is implied by context but not explicitly documented. Overall, the description adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool spawns a background review of a closed thread to extract memory/skills. The verb 'spawn' and resource 'review' are specific, and the description and parameter options distinguish it from sibling tools like 'curator_review' or 'auto_review_trigger'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for extracting memories/skills from a closed thread but does not provide explicit comparisons or exclusions relative to similar reviewing tools among siblings. No 'when not to use' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by detailing data source (budget daemon, ps, polling interval), staleness behavior, and handling of visible spawns. No contradictions; the description enriches understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs: first succinctly states purpose and output; second adds technical details. It is front-loaded and contains no redundant sentences. Slightly dense with acronyms and references, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only status tool with no parameters, the description is exceptionally complete. It covers purpose, output structure (structured content and legacy text), data source, refresh timing, edge cases (just-spawned tasks, visible spawns), and even references relevant constants. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description does not need to add parameter details. Baseline for 0 params is 4, and no additional information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool reports current spawn-budget usage including cap, used, free, and per-task RSS, for deciding whether another spawn() will be admitted. It clearly specifies the verb 'report' and the resource, and distinguishes from siblings like spawn_budget_set and spawn_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use ('to decide whether another spawn() will be admitted') and provides context on timing (daemon refresh, initial estimates for just-spawned tasks). It does not explicitly state when not to use or name alternatives, but the context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses sorting by priority DESC, content cap 1KB, and priority range beyond annotations. Annotations already indicate idempotency and non-destructiveness, so description adds value without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each essential: purpose, usage guidance with sorting, examples, parameter details. Front-loaded with most critical info. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameters, and behavioral traits. Output schema exists, so return value explanation is not needed. Could mention idempotency explicitly, but annotations cover it. Nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining key (implied identifier), content (1KB cap), and priority (0-100, default 50, higher shown first). Adds significant meaning beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Upsert a core-memory entry' with a specific verb and resource. Distinguishes from siblings like core_get, core_list, core_remove by mentioning the ALWAYS shown sorting behavior. Provides examples of good vs bad usage, reinforcing purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to 'use sparingly' and defines the tool as the 'what new-claude must know' surface, not a note store. Gives concrete good/bad examples. Does not explicitly name alternative tools for note storage, but strongly implies usage constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description complements them by explaining what the read-only operation surfaces: config, fingerprints, and report path. It adds context about the sanity-check purpose without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The core 'Show' statement is front-loaded, and the second sentence adds only the essential purpose of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only status tool with an output schema, the description fully covers what the agent needs: what is shown, what it is for, and that it is safe to invoke. No critical behavioral or usage information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema description coverage is 100%, so the description carries no parameter burden. A baseline of 4 is appropriate given the absence of any parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Show') and a precise set of resources: curator config, inventory fingerprints, and the latest REPORT path. This clearly distinguishes it from other status tools like live_status or spawn_status by naming curator-specific content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly frames when to use the tool: as a sanity-check for whether the daemon is alive, advancing the cursor, and producing readable REPORTs. It does not name alternative tools, but the usage context is clear and specific enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful safety context beyond the annotations: rows without a confirmed vec0 mirror retain their BLOBs, the default is a report-only dry run, and pages are only returned to the filesystem after db_compact. This is consistent with idempotentHint=true and does not contradict destructiveHint=false because the operation is gated and preserves fallback data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences in logical order: statement of purpose, gating behavior, and follow-up action. Every sentence adds essential information with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema available, so return-value details do not need to live in the description. The description covers the operation's effect, safety guarantees, default mode, and the required follow-up, which is enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a boolean dry_run with a default and no description, but the tool description explains that the operation defaults to a report-only dry run, giving the parameter practical meaning. It could be even clearer by naming the parameter explicitly, but the single parameter is adequately covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb (Remove), a precise object (base-table embedding BLOBs), and the qualifying condition (already represented in sqlite-vec), so the tool's purpose is immediately distinct from maintenance siblings like db_compact. The description also clarifies what is preserved, avoiding ambiguity about data loss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the operational context: it is coverage-gated, defaults to a report-only dry run, and should be followed by db_compact to reclaim space. It does not explicitly state when to prefer this tool over alternatives, but the sibling list contains no close analog, so the usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description comprehensively explains the tool's behavior: spawns a child, edits a specific file, adds golden test, runs full suite, opens PR, never pushes to main, sets applied via another tool, and single-flight. This far exceeds the minimal annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with a one-line summary. Each sentence adds value, though it could be slightly more concise. It is appropriately detailed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and presence of an output schema, the description covers the core functionality, preconditions, and behavior. It mentions related tools and return format, making it fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `evolve_id` is not described in the schema (0% coverage), but the description provides context: it should be an ID from evolve_review() and must be promoted+unapplied. This adds meaning beyond the type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool action: 'Implement a PROMOTED + not-yet-applied format-evolution suggestion.' It details the whole process, distinguishes from siblings like evolve_review, and specifies the output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives preconditions (ids from evolve_review(), must be promoted and unapplied) and concurrency rules (single-flight). It does not explicitly compare to other evolve_apply_* variants, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses immediate vs queued behavior for peers, adding nuance. Annotations (destructiveHint=false) are not contradicted; unload is not necessarily destructive. Could mention side effects like potential performance impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences plus a focused parameter explanation. No fluff, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema existing, return values are covered. Description explains functionality and parameter. Could mention relationship to sibling memory guard tools for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains the 'scope' parameter with two options ('self' and 'all') and their effects, adding essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Unload thread-keeper model/caches now', specifying the action and resource. It distinguishes from siblings like memory_guard_check and memory_guard_status which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (immediate unload) and scope options, but does not explicitly mention when not to use or compare to alternative memory management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the algorithm step-by-step, detailing how responses are analyzed and missed spawns detected. Adds significant behavioral context beyond the readOnlyHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, algorithm steps, and usage. Though lengthy, it earns its place for a complex tool. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, algorithm, usage, and parameters. Output schema exists so return values need not be described. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Describes most parameters (window_days, min_response_len, min_numbered, min_headers, top_n) within the algorithm, adding meaning. Does not mention max_messages, but overall adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds assistant responses that decomposed into independent blocks but were answered linearly, distinguishing it from siblings like spawn and spawn_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this to calibrate the spawn_hint', providing clear usage context. Does not mention when not to use or alternatives but gives sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool advances the session's cursor by default, which is a mutable side effect not captured by annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description clarifies this behavior and offers a way to avoid it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that cover purpose, usage trigger, and parameter behavior. Information is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in inter-session coordination, the description is largely complete. The presence of an output schema reduces the need to describe return values. However, a brief note on the type of data returned (e.g., 'list of actions') would be helpful for an agent to fully gauge utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'advance_cursor' parameter is well explained in the description, but the 'k' parameter (integer, default 30) is not described. Since schema coverage is 0%, the description should clarify 'k' as a limit on the number of results. The omission limits the agent's understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves activities from other concurrent Claude sessions. It uses specific verbs ('See what OTHER concurrent Claude sessions did') and clearly distinguishes from sibling tools like 'brief' which indicates the presence of live data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use instructions: 'Call when brief() shows live=N where N>0, or proactively when you suspect a parallel instance is working on something relevant.' It also explains the default cursor advancement behavior and how to peek without consuming via 'advance_cursor=False'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects beyond annotations: it stops the brief() skill_hint nudge, appends a move note, and mirrors skill directories on a best-effort basis. This adds significant behavioral context to the idempotentHint and non-readOnly annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured, starting with purpose, then behaviors, then parameter details, then additional mirroring. Every sentence adds value, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers main behaviors and parameters. Given an output schema exists, return values are covered. It could mention prerequisites (e.g., thread must be closed) more explicitly, but overall it is fairly complete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining thread_id (required thread context) and skill_path (optional, behavior when empty vs provided, absolute path requirement). This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it records that a closed thread's insights were materialized into a skill, stops a nudge, appends a note, and optionally mirrors the skill. It uses specific verbs and distinguishes from siblings like skill_record by focusing on the learning loop closure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use it (after a closed thread's insights are written into a skill) and explains the effect of providing or omitting skill_path. It does not explicitly mention when not to use it or alternatives, but context is sufficient for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral trait: manual grader always counts as failure unless confirmed via record_attempt. Adds value beyond annotations by explaining grading logic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise but includes important details; could be more tightly structured but is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers registration purpose, grader types, and categories. Could mention expected output or side effects, but core info is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates fully: explains grader options (regex, exact, manual), expected_pattern optionality for manual, and enumerates valid categories.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool registers a self-test probe with a verifier. It specifies grader types and categories, distinguishing it from run_probe and other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on grader types and behavior (e.g., manual grader default failure unless record_attempt). Does not explicitly compare with sibling tools like run_probe, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, and the description adds substantial behavior beyond it: the exact resolution priority order, the fallback chain, environment variable override patterns, and that it returns both structuredContent and a legacy text block. This is valuable operational context an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then organized into short bullet-like sections for resolution priority, model pinning, and effort. It is longer than minimal but every section carries useful diagnostic context; no fluff. Slightly dense but well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool with an output schema and readOnlyHint, the description is complete. It explains resolution behavior, relevant environment variables, and the return shape, so an agent can invoke it and interpret results without further lookups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema leaves nothing to document. Baseline 4 applies; the description appropriately focuses on behavior rather than inventing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') with a clear resource (which CLI thread-keeper detected as host, and which CLI each spawn role resolves to). It explicitly frames itself as a sanity-check tool for spawn config, distinguishing it from spawn execution and other status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exactly when to use the tool: 'when you want loops to fire through a specific agent' to sanity-check spawn config. It does not explicitly name alternatives or exclusions, but the context and purpose are clear, and the zero-parameter diagnostic nature makes misuse unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description details what each action does, including side effects like consolidation carrying over notes and raising confidence. It also explains that no force escape hatch is needed, providing full behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs and bullet points, but it is somewhat lengthy. Each sentence earns its place, though slight tightening could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameters, complexity, and presence of output schema, the description covers all necessary aspects: actions, parameter details, behavioral implications, and relationship to other tools. It is fully complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: action options, confidence values, merge_ids as comma-separated, and the role of reason. It adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool is for pruning, consolidating, or re-grading concepts. It lists three specific actions and distinguishes itself from sibling tools like lesson_remove by noting that concepts are all system-generated and no force flag is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each action and notes that every concept is fair game. It mentions the guard that target id must exist. However, it does not explicitly contrast with other concept-related tools like register_concept, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing the exclusive VACUUM lock, the full-file copy cost, the transient FTS mis-mapping risk during the vacuum→rebuild gap, and the soft-fail retry behavior. This gives an agent the operational context needed to decide when and how to invoke this mutating but non-destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: the first states the operation; the second gives operational warnings; the third covers failure behavior. The key caution is front-loaded before the timeout/error implications. Every sentence adds value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with annotations and an output schema, the description covers the operation, performance cost, locking requirement, correctness hazard, and failure semantics. Nothing important is missing for an agent to safely select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema already fully describes the input surface. The description correctly spends no space on parameter details. Baseline 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Shrink the DB file: VACUUM + mandatory dialog_fts rebuild.' It states exactly what the tool does and differentiates it from maintenance siblings like db_deduplicate_embeddings or forget by identifying the specific compaction operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Run in a quiet window' due to the exclusive lock and whole-file copy. It explains the cost profile and failure mode ('Fails soft with a retry hint when the DB is busy'). It does not name alternatives, but no alternative is clearly relevant for this maintenance operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds critical behavioral details: single-flight enforcement, child tool permissions (patch/delete memory, no code/git/PR), and default file selection logic. This fully informs the agent of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey purpose, default behavior, and constraints with zero redundancy. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input behavior and operational constraints. Return values are not described, but an output schema exists. It is complete for the tool's complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains the single parameter report_path thoroughly: default behavior (picks latest unapplied report) and the environment variable used. This adds full meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a Curator advisory report using the evolve_applier role. It specifies the resource (Curator advisory report) and action (apply), and distinguishes from sibling tools like evolve_apply or evolve_apply_roadmap_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for curator reports) and provides behavioral constraints (single-flight, no code edits), but does not explicitly compare to alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses critical behaviors: atomic primary write with frontmatter validation, best-effort mirroring to configured skill roots, refusal to delete pinned skills, dangling reference consequences, and restore behavior. It also explains the auto-frontmatter mechanism and the condition for bypassing it, which is exactly the kind of context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but appropriately structured into a summary line followed by a scannable action list. Every major behavior has a stated purpose. Slight redundancy exists ('write a brand-new skill' vs. 'overwrite SKILL.md wholesale'), but the complexity of nine actions justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nine parameters and nine action modes, the description covers all input requirements, edge cases, limitations, and side effects. It explains what happens in deletion, restoration, patching, and file management, and it includes constraints like allowed subdirectories and pinned-skill refusal. Since an output schema exists, the lack of return-value detail is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates. It explains each meaningful parameter in context: content's frontmatter behavior, sub_path allowed prefixes, old_string/new_string as find/replace, force semantics, and replacement_name for repointing wikilinks. The action field is effectively enumerated even though the schema provides no enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line uses a specific verb set ('Create, edit, patch, or delete skills') and names the resource ('under the primary skills root'). The action list further disambiguates each operation, including write_file, remove_file, restore, and delete, which differentiates it from sibling tools like skill_list and skill_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Each action is given explicit requirements ('Requires `name` + `description` + `content`'), which gives clear context on how to invoke the tool correctly. It does not explicitly name sibling alternatives or state when not to use this tool, but the action-specific conditions and examples of when force is needed ('Foreground/unknown-origin skills require force from a foreground writer') provide strong practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds that it returns last tail_lines lines or 'no_log' on missing log/incorrect setup, providing clear behavioral expectations beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second states conditions and return value. No unnecessary words, front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, annotations, and an output schema, the description covers all essential aspects: what it does, when it works, and what it returns. No gaps for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains 'tail_lines' as the number of lines to return and implies 'task_id' is the spawned task identifier. While not exhaustive, it adds sufficient meaning for both parameters given the tool's simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Read tail of a spawned task's captured stdout/stderr log' – specific verb and resource. Distinguishes from siblings like 'spawn' and 'tasks' by focusing on log retrieval for spawned tasks with capture_output=True.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states condition 'Only works for tasks spawned with capture_output=True' and describes fallback 'no_log' for other cases. Does not directly contrast with alternative tools, but the condition is clear enough for an agent to decide when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains the tool's behavior: polling every 2s, timeout, tagged broadcast format, parent matching prefixes, and side effects (children write to thread-keeper). With no contradictory annotations, the agent gets a full picture of what happens during execution, including the warning about multiple terminal windows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear summary and organized into logical sections. While every sentence serves a purpose, the inclusion of technical protocol details (e.g., polling interval, exact broadcast format) adds length. It is efficient but could be slightly trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 1 required, no schema descriptions), the description covers all essential aspects: purpose, roles, interaction protocol, return value, side effects, and visibility. The existence of an output schema allows the description to omit return details, and the provided information is sufficient for proper invocation and understanding of outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates excellently. It explains the 'roles' parameter with predefined list and custom names, clarifies 'visible' default and reasoning, and details 'timeout_s' via polling interval. Parameters like 'cwd', 'model', and 'effort' are less explained but the core ones are well-covered, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear action: 'Spawn N children with different roles on the same prompt, then collect their answers via a tagged broadcast and return a comparison.' This explicitly states the verb and resource, distinguishing it from siblings like 'spawn' and 'broadcast'. It also explains the role mechanism and return type, leaving no ambiguity about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool, including default behavior (visible=False) and the rationale. However, it does not explicitly contrast with alternatives like 'spawn' or 'broadcast', nor does it specify prerequisites or scenarios where the tool is not appropriate. It offers partial guidance (e.g., override per need, inspection via tasks()), but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors beyond annotations: weight range, per-cid restriction, overwrite semantics, and effect on aggregate fields. This adds substantial value over the minimal annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the key action, no redundant information. Every sentence adds necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: action, constraints, side effects. With annotations and output schema present, no further details are needed. It is complete for accurate invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the weight parameter (range) and explains the role of distill_id in the voting logic. However, distill_id is not explicitly described beyond being the identifier, and schema coverage is 0%, so the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Vote on a distillate' with a specific resource and verb. It includes weight range, per-cid constraint, and updates to aggregate fields, distinguishing it from siblings like 'distill' or review tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the overwrite behavior and per-cid rule, providing clear context for when to use the tool. It does not explicitly mention when not to use it or list alternatives, but the given details are sufficient for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that messages from self to self are dropped, adding behavioral context beyond the annotations (readOnlyHint=false, etc.) which already indicate a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: one stating purpose, one providing usage tips. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple messaging tool with annotations and output schema, the description covers essential behavior (posting, CID discovery, self-drop). Complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema description coverage is 0%, the description explains to_cid via peers() and prefix matching, and 'content' is implied by context. This partially compensates but leaves content underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool posts a message visible only to a specific conversation, distinguishing it from broadcasting tools like broadcast or note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use peers() to discover conversation IDs, explains prefix matching, and cautions that self-messages are dropped, providing clear when-to-use and how-to-prepare guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses atomicity, path-safety guarantees for pass_id, batch semantics to prevent child overwrites, replacement behavior on repeated calls, and recording of the final content hash. None of this contradicts readOnlyHint=false, idempotentHint=true, or destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in a clear first sentence, and every sentence adds relevant operational context. The description is dense with domain-specific terminology like 'bounded multi-child pass' and 'parent-authorized spawned Curator,' which is appropriate for the audience but prevents it from being maximally crisp.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a specialized write tool with an output schema and detailed annotations, the description covers purpose, alternative, authorization, safety constraints, batch behavior, idempotent replacement, and downstream hash recording. An agent has enough information to call it correctly without needing the return format explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by explaining pass_id is filename-safe, batch_index/batch_total coordinate multi-child writes, and content is the report being persisted. It stops short of specifying the exact expected content format or the valid range/relationship of batch_index to batch_total, so it is strong but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific action ('Atomically write one Curator report') and the destination ('inside the configured report dir'). The follow-up frames it as a narrow alternative to direct filesystem Write, which separates it from broader curator lifecycle tools like curator_run and curator_review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit selection condition: use this tool instead of filesystem Write when the Codex sandbox cannot write ~/.threadkeeper/curator because the project is elsewhere. It also documents the authorization gate (parent-authorized spawned Curator with matching pass ID) and the intended write/replace workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: old claim becomes superseded with evidence preserved, quote seeds evidence, domain inheritance, and elicitation confirmation on capable hosts. Annotations only indicate mutability, so description adds significant value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: front-loaded with the main action, followed by conditionals and a return format example. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of superseding claims, the description covers mutations, evidence handling, optional parameters, host-dependent behavior, and return format. No gaps remain despite lack of output schema details beyond the return example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by explaining the purpose of all four parameters: old_claim_id, new_claim, quote, and domain, including default behavior when optional parameters are empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retires an old claim and registers a new one that refines or replaces it, distinguishing it from sibling tools like dialectic_claim or dialectic_evidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use (to refine or replace), what happens with quote and domain, and mentions elicitation behavior. Lacks explicit exclusion scenarios but is otherwise thorough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the readOnlyHint annotation: it excludes low/disputed claims, defaults to only active claims, returns at most 12 lines, and explains the tier markers (validated, observed, hypothesis) including the rule that hypotheses are only shown when no stronger claims exist. This gives the agent an accurate model of what the output will contain and how to interpret it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written and front-loaded with the core purpose. The tier-marker table and the final domain note each add necessary operational detail without fluff, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return fields, and it still covers output limits, claim-quality filtering, history behavior, domain filtering, and tier semantics. The parameter set is small and fully explained; no critical calling information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining each parameter: as_of switches to valid-time filtering, include_history adds superseded claims with validity intervals, and domain restricts output and removes group headers. This adds real meaning beyond the bare schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: a terse rendering of accumulated beliefs about the user, grouped by domain. It also positions the tool within the larger system by noting it is 'used as brief() input,' which helps distinguish it from sibling tools like brief or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: it is a compact belief summary feeding brief() input, with explicit controls for time filtering, history inclusion, and domain restriction. It does not name alternative tools to use instead, but the intended integration and parameter-specific behaviors are clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses concrete behavioral details beyond annotations: it picks the oldest conflicated PR by default, validates ownership/state, resolves conflicts, runs the suite, pushes the same branch, and lands into main via protected merge flow. It also explicitly states side-effect negations (no new PR, no roadmap-issue marking). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a concise one-sentence summary, then expands into mode-specific behavior. Every sentence adds useful operational detail; there is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema and adequate annotations, the description covers selection logic, validation behavior, the operational pipeline, and explicit exclusions. Nothing critical is missing for an agent to understand when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for pr_number is 0%, but the description fully explains its semantics: pr_number=0 triggers automatic pick of the oldest eligible conflicted PR, while a numeric value validates and targets a specific PR. This adds essential meaning the schema alone does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Repair an already-open applier PR that currently has merge conflicts.' It also clarifies what the tool does not do (doesn't open a new PR or mark a roadmap issue applied), which distinguishes it from siblings like evolve_apply or evolve_mark_roadmap_issue_applied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when there is an already-open applier PR in a conflicated GitHub merge state, and it explains the two selection modes via pr_number. It does not explicitly name alternative sibling tools or state when-not-to-use, but the scenario is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses meaningful behavioral details: refusal of protected lessons, foreground-writer enforcement, ignoring non-foreground force, wikilink redirection via replacement_slug, and dangling-source reporting. This goes well beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds value: singular purpose, force constraint, attack/misuse vector, and consolidation behavior. It is front-loaded with the primary action and avoids filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and the presence of an output schema, the description fully covers the necessary behavioral context: when removal succeeds, when it refuses, how force works, and what happens with wikilinks. No significant gap remains for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It explains slug (target section), force (foreground writer requirement), and replacement_slug (consolidation redirection and dangling source behavior). All three parameters are semantically covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Remove one materialized lesson section by slug.' This clearly distinguishes the tool from read/restore/patch siblings like lesson_get, lesson_restore, and lesson_patch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: protected lessons require force=True from a foreground writer, and non-foreground force is ignored. It also explains when to pass replacement_slug for consolidations. It does not explicitly name alternative tools, but the usage conditions are strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description details dry-run behavior, signal types (SIGKILL vs SIGTERM), and safety guarantees (never touches current process or alive parents). This is excellent behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: main purpose, defaults and modes, safety guarantee. Every sentence is informative and structured front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two boolean parameters with defaults, destructive annotation, and an output schema (not shown), the description fully covers behavior, safety, and repeatability. No apparent gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both boolean parameters (dry_run, force) are clearly explained with their default values and effects. Schema provides defaults but no semantic context, so description adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it kills orphaned thread-keeper processes with specific conditions (parent gone and heartbeat stale > 5 minutes). It uniquely identifies the tool's function among a large set of sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly describes when to use (orphaned process cleanup) and how to use (dry-run by default, force option). Implicitly states when not to use (never touches current process or living parent processes). Does not explicitly mention alternatives, but no sibling tool appears to serve the same purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the blocking behavior, the mechanics of posting a whisper and waiting, and the timeout effect. Annotations (readOnlyHint=false, etc.) are consistent. The description adds valuable context beyond annotations, such as the kind of whisper and the need for the target to be in a loop.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 5 sentences, clearly front-loaded with the primary purpose. Every sentence adds value: purpose, mechanics, usage hints, and a caution. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and an output schema (implied), the description covers the mechanics, prerequisites, and edge cases (timeout, idle target). It provides sufficient context for correct invocation without needing to inspect the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to `to_cid` (use peers, 8-char prefix) and `timeout_s` (blocks until timeout). However, it doesn't explicitly describe all parameters, though schema coverage is 0%. The parameter `question` is self-explanatory. The description compensates well but could list parameters more explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send a question to a peer and wait synchronously for their answer.' It specifies the verb (send), resource (question to peer), and behavior (synchronous wait). The tool is distinguished from siblings like whisper or broadcast by mentioning it's a whisper with kind='question' that blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use peers() to find available cids; 8-char prefix accepted.' It also warns about prerequisites: 'requires the target to be in a wait() loop or actively calling inbox()+respond(). If they're idle, you'll just timeout.' This helps the agent decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool destructive and idempotent. The description adds crucial detail that only the .venv is deleted while its clone remains intact, that the next Evolve pass rebuilds the environment, and that the tool refuses operator-selected checkout setups, preventing accidental destruction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-loaded with a summary line; every sentence contributes a distinct fact: the action, the effect/preservation/rebuild, and the safety exclusions. No redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one simple parameter, rich annotations, and an output schema, so little extra context is needed. The description covers object, scope, side effect, and refusal conditions, making it safe to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain the confirm flag, and it does: 'Pass confirm=True to delete only that auto-managed virtualenv.' This gives the boolean real semantic weight. It doesn't spell out the no-op when confirm=False, but the schema default and 'after explicit confirmation' make that inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete action: freeing the default managed checkout's .venv, and immediately clarifies with 'delete only that auto-managed virtualenv.' It distinguishes the targeted resource from operator-selected checkouts, giving the tool a clear, specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the trigger condition ('Pass confirm=True') and the situations where the tool refuses to run (THREADKEEPER_EVOLVE_REPO_ROOT and auto-clone-disabled setups). This provides clear when-to-use and when-not-to-use guidance, sufficient because no sibling tool overlaps with this prune operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the override does not persist across restarts, which is beyond the annotations (idempotentHint=true, destructiveHint=false). The description adds behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey core action, persistence behavior, and usage examples. Every sentence earns its place, and key info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers purpose, side effects, and use cases. Output schema exists, so no need to explain return values. Definition is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explicitly explains the single parameter (limit_mb) with units ('in MB') and special value behavior ('Set 0 to disable enforcement'), adding meaning beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Override') and resource ('spawn-budget cap') with units (MB). It clearly distinguishes from siblings like 'spawn_budget_status' (view) and 'spawn' (execute).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (heavy task needing higher temporary ceiling, or dropping cap mid-session) and when not (for persistence, recommending the env var THREADKEEPER_SPAWN_BUDGET_MB).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![thread-keeper MCP server](https://glama.ai/mcp/servers/po4erk91/thread-keeper/badges/card.svg)](https://glama.ai/mcp/servers/po4erk91/thread-keeper)

Score Badge

Copy to your README.md:

[![thread-keeper MCP server](https://glama.ai/mcp/servers/po4erk91/thread-keeper/badges/score.svg)](https://glama.ai/mcp/servers/po4erk91/thread-keeper)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/po4erk91/thread-keeper'

If you have feedback or need assistance with the MCP directory API, please join our Discord server