harness-manager

by x380kkm

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
Multiple tools have overlapping boundaries: host_inspect vs host_preview both return diffs, codex_list vs codex_groups both enumerate Codex content, and content_read/content_open/content_snapshot/content_continue cover similar read/snapshot behavior. The domain prefixes help, but with 44 tools an agent will often be unsure which variant is the right one.
Naming Consistency4/5
Most tools follow a consistent [resource]_[action] snake_case pattern with clear prefixes like host_preview, document_apply, and context_preview. A few names are result-oriented rather than action-oriented (catalog_graph, card_relations, host_status, agent_capabilities) and statistics_reads is an odd variant, but the overall style is predictable.
Tool Count2/5
44 tools is well beyond the 25+ threshold for a practical MCP surface, even though the server spans multiple subsystems. Many tools are fine-grained lifecycle variants of preview/apply/read that could be consolidated into fewer, clearer entry points.
Completeness3/5
The set covers host management, card relations, catalog/document reads, content snapshots, and code/x import with mostly consistent preview/apply flows. However, some lifecycles are asymmetric: usage has no direct remove/apply counterpart to context_preview_remove/context_apply, and module_apply has no explicit removal path visible, so coverage is not uniformly complete.
Average 3.2/5 across 44 of 44 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true and openWorldHint=false, so the safety profile is covered; but the description adds only internal detail and the word '保存' (save) muddies the read-only semantics. The note that the use switch is controlled by bindings is the only genuine behavioral context, and it is too terse to be useful. Not a hard contradiction since '保存' describes members data rather than the tool's 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but it is under-specified rather than concise: it front-loads dense jargon about member references and switches instead of leading with the tool's purpose, and every clause requires inference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with zero parameter descriptions, a full output schema, and a long list of ambiguous siblings, the description explains none of the inputs, no invocation semantics, and no differentiation from module_describe, module_apply, or the other preview tools. The output schema covers return values, but everything else an agent needs is missing.
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 must compensate, but it only hints at members sub-fields (itemId, role) that don't even appear in the schema. None of the six parameters (id, name, scope, members, baseline, description) are explained, so an agent cannot construct a valid call.
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?
The description never states what the tool does — no verb+resource such as 'preview a module' — and instead describes internal member data mechanics ('members 使用 itemId 和 role, 保存独立来源版本引用'). It reads like an implementation note and gives an agent no way to know this tool produces a module preview or how it differs from module_describe or module_apply.
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 when-to-use guidance, no conditions, and no mention of alternatives among the many sibling preview/describe/apply tools. The only context is a cryptic note that the usage switch is controlled by bindings, which does not help an agent choose this tool over module_describe or host_preview.
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 signal read-only and non-destructive behavior. The description adds the nuance that the read is scoped by skill references and selector scope, and that settings are interpreted via context_describe's settingsSchema. This is useful but cryptic and does not cover further behavioral aspects like response shape or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is short, but brevity replaces clarity. It is dense and jargon-heavy, with the internal schema reference front-loaded and the actual purpose absent. It is under-specified rather than appropriately concise.
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?
Even though annotations and an output schema reduce some burden, the description fails to establish the tool's purpose, selection criteria, or enough parameter semantics for a 4-parameter call. An agent would have to guess what context_preview returns and how settings/scope/baseline interact.
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 alludes to 'settings' and possibly 'plugin'/'scope' via 'skill refs' and 'selector scope', but it never explains baseline or the required plugin/settings values, formats, or defaults. This is insufficient for relilable invocation.
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?
The description never clearly states what the tool does; it mentions 'settings' and 'reading' but has no explicit action like 'preview' or 'render'. It also does not distinguish context_preview from siblings like context_describe, context_apply, or context_preview_remove.
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?
There is no guidance about when to use this tool versus alternatives. The only reference to context_describe is as a schema source, not as a competing or complementing tool. An agent cannot determine when context_preview should be selected.
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 provide almost no behavioral context (only openWorldHint=false), so the description carries the burden. It does disclose a concrete side effect: '双端均共享的关系及正文写入项目文件' indicates that relationships and content are written to the project file. However, it remains ambiguous about what '双端均共享' means and does not mention reversibility, permissions, or failure behavior.
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 dense sentence, which is concise. However, the wording is awkward and packs multiple concepts (baseline, dual-sided sharing, project file writing) into a way that reduces clarity. It earns credit for brevity but not for effective structure.
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 parameter coverage and minimal annotations, the description leaves the agent without enough information to call the tool correctly. The output schema exists, so return values are covered, but the meaning of parameters, the precise action, and the expected side effects remain underspecified. For a tool that writes to project files, this is inadequate.
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 undocumented parameters. It references 'sharingBaseline', which loosely maps to the baseline parameter, but gives no explanation of id, shared, or how baseline should be structured. The boolean 'shared' is the core parameter, yet the description never explicitly states its role.
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?
The description states a verb ('adjust') and a resource ('project sharing'), but the phrasing is convoluted and references card_describe's sharingBaseline without clearly explaining what the tool actually does. It does not adequately distinguish itself from siblings like card_set_relation or card_configure, which also deal with card/project modifications.
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 is given about when to use this tool versus alternatives. The mention of card_describe hints at a prerequisite, but there is no when-to-use, when-not-to-use, or explicit alternative routing. An agent would have to infer the correct invocation context.
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 only include openWorldHint=false, so the description carries the burden of behavioral disclosure. It does add meaningful info: calling it once saves the original config and subsequent calls do not overwrite that restore point, implying idempotent behavior. However, it does not state whether the tool mutates state, what permissions are required, or what the output represents.
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 just two short sentences with the key behavior front-loaded. It is efficient, though 'save once' and 'maintain the restore point on later calls' are slightly redundant. Still, there is no filler or irrelevant 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?
The description does not connect the tool to the host-management workflow, explain the unusual 'restore point' concept, or clarify the scope parameter. The sibling list shows many host_* tools, so omitting when and how to use this one leaves an agent under-informed. The output schema exists but the description still fails to explain the tool's place in a sequence.
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 schema defines one optional 'scope' parameter with default 'user' but no description, and the description provides zero explanation of what scope means or how it affects behavior. With 0% schema description coverage and no compensation in the description, the agent cannot determine valid values or the impact of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action—save the original configuration once and preserve the restore point on subsequent calls—so it goes beyond a tautology. However, it does not explicitly say this initializes a host, and the relationship to sibling host_* tools is absent. It conveys intent but leaves important scope ambiguity.
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 guidance about when to call this tool versus alternatives like host_preview, host_apply, or host_status. The only hint is the phrase 'original configuration', which implies it should run before modifications, but this is never stated. An agent must guess the intended workflow.
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=true, so the read-only nature is covered. The description adds a deduplication behavior ('同一关系保留一份 Adapter 文本'), which is useful beyond the annotations, but it does not explain error behavior, scoping effects, or what 'Adapter 文本' means.
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 short and front-loaded with the primary return purpose, but the second clause is cryptic and the overall phrasing is too abbreviated to be fully useful. It is concise, but the ambiguity of 'Adapter 文本' prevents a higher score.
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?
While the output schema covers return values and annotations cover read-only safety, the description fails to explain the required 'id' parameter, the optional 'scope' parameter, or what counts as 'candidate tools'. For a two-parameter tool with 0% schema coverage, this is a significant completeness gap.
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 clarify the meaning of 'id' or 'scope' beyond the schema field names. Since the schema provides no descriptions and the description does not compensate, the agent has insufficient parameter semantics to reliably invoke the tool.
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 ('返回' / returns) and resource: outgoing, incoming, and candidate tools for a card relation. This distinguishes the tool's role from mutation-focused siblings like card_set_relation and card_remove_relation, though it does not explicitly name an alternative.
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 given about when to use this tool versus alternatives such as catalog_graph, card_describe, or card_set_relation. The description simply states what is returned, leaving the agent to infer appropriate usage from the tool name and sibling context.
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 provide only openWorldHint=false, so the description carries most of the behavioral burden. It adds the useful disclosure that '用户层内容保持独立' (user-layer content remains independent), implying the operation is scoped to the adapter layer. However, it does not disclose whether the removal is destructive, reversible, permission-gated, or how it affects other layers or baselines.
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 compact sentence with no redundant filler, and the key action is front-loaded. Its brevity is efficient, though it sacrifices clarity by relying on unexplained jargon like 'Adapter' and '关系基线'.
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 four parameters and minimal annotations, the description is not complete enough for an agent to confidently invoke it. The meaning of Adapter, baseline, from_id, to_id, and scope are all under-specified, and the output schema cannot compensate for missing input semantics.
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 the four parameters, but it only hints at 'baseline' and gives no meaning for from_id, to_id, or scope. The directionality of from_id and to_id is not explained, and the baseline object's structure and role remain undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('移出' / remove) applied to '本层 Adapter' based on a '关系基线' (relationship baseline), which is more than a tautology. However, the term 'Adapter' is unexplained and it is unclear whether the tool removes a relation, an adapter entity, or a layer's relation mapping, so the purpose remains somewhat ambiguous.
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 guidance on when to use this tool versus its siblings such as card_set_relation, card_relations, or card_set_shared. It does not state prerequisites, whether this is the inverse of card_set_relation, or what distinguishes it from other relation-modifying 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 (readOnlyHint=false) already signal that writes occur; the description adds context by revealing that snapshots and completion statistics are saved and read, which is consistent and non-contradictory. But it does not disclose side effects in detail such as whether existing snapshots are overwritten, when persistence is triggered, or what state changes occur.
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 short sentences with no filler or redundant restatement of the tool name. The core behavior is front-loaded, and the secondary readiness concept is separated cleanly, making the text efficient even though its content is under-specified.
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?
Even though an output schema exists and annotations are present, the description remains incomplete for a 6-parameter tool with 0% schema parameter coverage. It omits any explanation of the six parameters, gives no usage context, and provides no guidance relative to its many siblings, leaving an agent unable to construct a correct call confidently.
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% while the tool has 6 parameters (ref, scope, budget, context, version, resources), so the description carries the full burden of explaining them and fails to do so. The 'readiness' sentence offers a domain hint about Skill completeness, which may relate to an output field, but it provides no meaning for any individual parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a domain and action ('固定配置和正文, 保存读取快照与完成统计' – fixed config and body, persisting/reading snapshots and completion stats), which is more than a tautology. However, it never explains what the 'open' operation itself does and provides no differentiation from siblings like content_read, content_continue, or content_snapshot, leaving the core purpose vague.
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 given about when to use this tool versus alternatives. The siblings include content_read, content_continue, content_snapshot, and content_apply, yet the description names none of them and gives no conditions, prerequisites, or exclusions that would help an agent route to this tool correctly.
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 covers the safety profile. The description adds useful behavioral context by explaining that unit_status reflects transfer status and expected_revision compares against the current body of the same source entry. Still, it leaves other behavioral aspects such as versioning, budget limits, and scope handling unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and contains no filler, but it is under-specified rather than concise. It lacks structure, examples, or parameter context, making it less useful than its brevity suggests.
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 six parameters, no schema parameter descriptions, and many sibling content/document tools, this description is incomplete. It does not clarify the notion of a unit, explain the other parameters, or situate the tool among its siblings. The readOnly annotation and output schema reduce but do not eliminate the need for more context.
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 schema description coverage at 0%, the description needed to explain the six parameters. It only touches expected_revision and leaves ref, scope, budget, version, and resource without meaningful explanation. This is insufficient compensation for the schema gap.
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 clear verb and resource: read a complete unit. It also introduces two relevant concepts, unit_status and expected_revision. However, it does not define what a 'unit' is or differentiate this tool from siblings like content_continue or content_snapshot.
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 on when to use this tool, when not to use it, or which sibling tool might be a better alternative. The expected_revision hint suggests a conditional use case, but it is not framed as usage 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the output includes the full declaration and baseline, which is useful context, but it does not disclose any other behavioral traits such as scope handling or failure modes. 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 a single concise sentence with no filler. However, it is under-specified, so brevity is achieved at the cost of clarity.
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?
Despite having an output schema and read-only annotations, the description is incomplete for tool selection and invocation. It lacks parameter semantics and sibling differentiation, making it inadequate for an agent to confidently decide when and how to call this tool.
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 compensate for the missing parameter details. It never explains what 'id' or 'scope' mean, how they interact, or what values are expected. The vague reference to '存储身份' is not sufficient for an agent to populate the parameters correctly.
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 uses a specific verb ('读取', read) and a resource ('存储身份对应的完整声明与 baseline'), making the core operation clear. It is distinguishable from sibling tools like document_apply or document_import because it is explicitly a read operation, though '存储身份' is somewhat ambiguous.
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 such as document_preview or content_read. The description does not state conditions, exclusions, or context for selecting this tool, leaving the agent to infer usage.
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 establishes that this is a safe read operation, and the description's '查询' is consistent with that. The description adds a vague note that the body/content is stored in a local backup, which hints at data locality but does not clearly explain tool behavior, auth needs, or response characteristics. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and starts with the action, which is good. However, the clause '正文保存在本机备份中' is cryptic and does not clearly earn its place; it may confuse more than it clarifies.
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 many host_* sibling tools and one undocumented optional parameter, the description is not complete enough for an agent to confidently select and correctly invoke the tool. The output schema and readOnly annotation reduce some burden, but missing parameter semantics and usage guidance leave significant gaps.
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 never mentions the 'scope' parameter, its default value, or possible values. The agent receives no semantic guidance for the only parameter the tool accepts.
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 a specific verb '查询' (query) and names the resources being queried: '接管开关和固定原始恢复点' (takeover switch and fixed original recovery point). This gives a reasonably clear purpose, though it does not distinguish the tool from sibling tools such as host_preview or host_inspect, and the trailing clause about local backup is ambiguous.
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 never mentions sibling tools like host_preview, host_inspect, or host_set_enabled, and it gives no exclusions or decision criteria for selecting host_status.
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 '读取' (read) is consistent with that. The description adds that the tool returns fixed config plus complete unit descriptions, which is useful context, but it does not disclose error behavior or what happens when the snapshot is unavailable. 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 a single sentence with no filler and the key subject is front-loaded. It is concise, though it sacrifices parameter and usage clarification for brevity.
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 simple one-parameter schema, output schema, and read-only annotations, the definition is not heavily burdened, but it still omits id semantics and use-case selection. An agent can only call this tool correctly if it already knows what identifier to supply and when this snapshot read is appropriate.
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 required string 'id' with no description and 0% schema description coverage. The tool description does not explicitly define what id refers to or how to obtain it, although the phrase ContentReadResult.snapshot indirectly suggests it is a snapshot identifier. This is insufficient for reliable invocation without prior domain knowledge.
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 operation: reading the fixed configuration and complete unit description associated with ContentReadResult.snapshot. This is more informative than a tautology, though it does not explicitly differentiate from sibling tools like content_read or content_continue.
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 such as content_read, content_open, or content_continue, and no stated prerequisites or exclusion conditions. The reference to ContentReadResult.snapshot hints at context, but the trigger for selecting this tool is left implicit.
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 and openWorldHint annotations already establish the read-only, closed-world safety profile. The description adds that the result contains '独立正文' and a bound read baseline, but does not explain what that baseline is, how it is derived, or whether any state is assumed. 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 a single compact sentence and front-loads the primary operation. However, the trailing jargon about '独立正文' and '读取基线' is not defined, so those parts are concise but not fully self-explanatory.
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?
Although an output schema exists and may document return shape, the description omits parameter semantics, usage context, and sibling routing. For a tool with two parameters and a 0% schema coverage, this is a meaningful completeness 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 must compensate. It only indirectly references the plugin parameter and says nothing about the scope parameter, its default value, or valid inputs. An agent cannot confidently determine what values to supply for scope.
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 action ('列出' / list) against a specific resource ('选定 Plugin 的 Skill 与配套说明') and states that it returns text plus a read baseline. However, the phrases '独立正文' and '绑定的读取基线' are domain jargon that weaken clarity, and it does not explicitly distinguish itself from sibling context 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?
There is no guidance on when to use context_describe versus context_preview, context_apply, or context_preview_remove. The description gives no conditions, exclusions, or selection criteria, so the agent must infer usage from the tool name and annotations 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 provide readOnlyHint=true, and the description does not contradict that; preparing a draft can be interpreted as read-only. The description adds the workflow context of draft preparation before preview/apply, which is useful, but it does not clarify side effects, output behavior, or constraints beyond that.
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 compact sentence with no filler, and the core purpose is front-loaded. It is concise, though it sacrifices enough detail that other dimensions suffer.
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 3 parameters, 0% schema coverage, and an output schema, the description is too thin. It gives the general workflow but omits parameter semantics, valid input kinds, required path meaning, and any guidance around sibling alternatives.
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 `path`, `kind`, or `scope` directly. An agent cannot infer what the required `path` refers to, what valid `kind` values are, or what the `scope` default means. The description fails to compensate for the schema's 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 states a specific action: prepare approved-path Skill/说明/JSON content into a declaration draft, and it signals that this is a staging step before preview/apply. This distinguishes it from document_apply, though it never explicitly names sibling tools or alternative routes.
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?
It provides useful sequential context ('之后使用预览与应用入口'), implying this tool should be used before preview/apply. However, it does not explicitly state when not to use it, what kind of content qualifies, or how it differs from alternatives like document_read, document_preview, or document_apply.
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 openWorldHint=false, covering the safety profile. The description adds that the tool returns pending/unchanged/blocking status and diffs, which is useful behavioral context, but it does not describe any edge cases, limitations, or interpretation rules. No contradiction exists.
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 short and front-loaded with the main return behavior, but the second clause is awkwardly worded and ambiguous. It is not verbose, yet it sacrifices clarity in an attempt to be concise.
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?
An output schema exists, so return-value explanation is less critical, but the sole input parameter remains completely undocumented. The agent cannot know what values to pass for scope, making the definition incomplete for correct invocation despite the tool's low complexity.
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, scope, has no description and no enums. The tool description does not mention the scope parameter at all, leaving the agent without any clue about accepted values or what 'user' default means. The description entirely fails to compensate for the undocumented 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 states a specific verb ('返回' / returns) and the result kinds: pending, unchanged, or blocking status and differences. It clearly identifies the tool as an inspection rather than a mutation, and the mention of a separate host preview distinguishes it from the preview/apply siblings, though not by name.
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 that confirmation or applying happens through a separate host preview, which hints that this tool is for inspection rather than action. However, it does not explicitly say when to use host_inspect versus host_preview or host_apply, and the phrasing '应用通过独立的宿主预览确认' is ambiguous.
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 behavior is partly captured by metadata. The description adds useful context by saying the source content stays unchanged, but it does not explain what 'registered differences' means operationally or what the preview output will look like.
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 compact, free of filler, and front-loads the core behavior before the 'source remains in place' caveat. It earns its place, though its brevity is part of why the tool remains underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a required nested baseline object, a required id, a scope parameter, and 0% schema description coverage, a single terse sentence is not enough for an agent to construct a correct call. The existence of an output schema helps with return values, but the input semantics—especially what baseline must contain and how 'registered differences' are expressed—are essentially missing.
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 the unexplained parameters, but it never names id, baseline, or scope. The phrase 'registered differences' glances toward baseline's purpose, but id and scope remain completely unexplained and the baseline object shape is opaque.
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 identifies a specific action (移出/remove) on a specific resource (登记的差异/registered differences) and adds a key constraint that the source content remains in place. This clearly conveys a non-destructive preview intent and distinguishes it from apply-style tools, even though it does not explicitly name a sibling.
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 mention alternatives or exclusion conditions, but the phrase 'source content remains in place' strongly implies this is the preview/non-destructive variant. The usage context is therefore implied rather than explicitly articulated.
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 covers the safety profile. The description adds that this queries members via a plugin registration ID and returns layer binding/current candidate, which is useful behavioral context. However, it does not elaborate on response semantics or how the optional scope/context affect behavior. There is 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 a single compact sentence with no filler. However, '本层绑定和当前候选' is unclear and would benefit from more precise wording, so it is not a perfect example of concise clarity.
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, so return values do not need to be described. With only one required parameter and a readable plugin explanation, a minimal call is possible. Still, optional scope/context semantics are left unexplained, making the description only minimally 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?
Schema description coverage is 0%, so the description must compensate. It only clarifies that 'plugin' is a registration ID; 'scope' and 'context' are not explained at all. This leaves the agent guessing about important optional parameters.
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 ('查询' / query) and a resource ('成员' / members keyed by a Plugin registration ID). It also gives partial result scope with '本层绑定和当前候选', though that phrase is cryptic. Overall it is distinguishable from a preview tool like usage_preview.
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 on when to use this tool instead of alternatives such as usage_preview, context_describe, or module_describe. The read-only annotations imply a safe query context, but the description itself provides no selection criteria 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 already declare readOnlyHint=true, and the description does not contradict this. It adds some context about scope composition ('project-local 合成用户, 共享项目和个人覆盖'), but the wording is cryptic and adds limited actionable 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and the main verb-resource pair is front-loaded. The second clause is grammatically awkward, but there is no redundant filler or repetition of schema fields.
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?
Despite having an output schema and read-only annotation, the description leaves the meaning of 'composite user' and the exact role of scope unresolved, and it gives no guidance on what values id/scope take. This is not enough for an agent to invoke the tool reliably.
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 needed to explain id and scope. It never names id, and scope is only obliquely hinted at through the phrase about project-local, shared project, and personal overrides. This is insufficient to compensate for the empty schema descriptions.
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 clear verb ('读取' / read) and a specific resource: the enablement and sharing baseline of Skill, Rule, or Hook cards. This distinguishes it from mutation siblings like card_configure and card_set_shared, though the trailing phrase 'project-local 合成用户...' weakens clarity.
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 read verb implies the tool is for inspecting baseline settings rather than modifying them, but it never explicitly says when to prefer this over card_configure or card_set_shared, nor does it state exclusions or prerequisites.
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 read-only and closed-world behavior; the description adds that results are gated by enabled PluginBinding and that context controls scope matching. It does not contradict the annotations, and it surfaces the non-obvious PluginBinding dependency.
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 no filler, and the main action ('returns bounded candidates') is placed near the front. It is concise but slightly cryptic; some structure or examples would improve comprehension.
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 five parameters, one of which accepts arbitrary object properties, and no parameter descriptions, this short description is insufficient for an agent to construct a correct call. The output schema may define the result shape, but invocation semantics such as query filtering, pagination via cursor/limit, and the expected shape of context are missing.
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 needed to document the five parameters, but only context (and indirectly PluginBinding) is addressed. limit, query, scope, and cursor receive no semantic explanation.
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 behavior: returning bounded candidates based on enabled PluginBinding, and assigns context a role in matching scope. This goes beyond the tool name, but it lacks a plain-language definition and does not distinguish catalog_discover from siblings such as catalog_list or catalog_effective.
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 given about when to use this tool instead of catalog_graph, catalog_list, or catalog_effective, and no exclusions or prerequisites are stated. The only usage hint is that context determines matching scope, which is implicit rather than explicit direction.
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 show the tool is not read-only, not open-world, and not destructive. The description adds that it saves observations and requires re-checking source authorization each call, which is useful behavioral context beyond the annotations. It does not, however, explain the side effects of saving or what happens across multiple continuations.
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 brief and front-loaded with the core mechanism. It is one sentence with no filler, though the phrase 'save observation' is vague enough that brevity comes at some cost.
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 two parameters, zero schema descriptions, and non-read-only annotations, this description is too thin. It doesn't explain how a continuation token is obtained, what saving observations entails, or what budget controls. The output schema exists, so return-value detail is not required, but operational context is still insufficient.
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 carry parameter meaning. It gives some context for 'continuation' by saying continuation is used to continue reading, but it says nothing about 'budget', its default, or how it interacts with the continuation process. An agent would be guessing about important semantics for budget.
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 concrete action: use a continuation to continue reading a snapshot and save observations. It identifies the key resource (snapshot) and mechanism (continuation), which adds specificity beyond the tool name alone, though it does not explicitly contrast itself with siblings like content_read or content_snapshot.
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 instruction to use a continuation implies that this tool is for resuming a prior snapshot read, and the auth re-check note gives a concrete operational rule for repeated use. However, it does not state when to prefer this tool over alternatives or provide any exclusion conditions.
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 annotation readOnlyHint=true is consistent with the description's claim that only the preview is affected and '上游 Skill 保持原位' (the upstream Skill remains in place). This adds useful non-destructive context beyond the annotation and clarifies that the removal does not propagate upstream.
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 compact sentence with no filler and places the core action first. Its brevity is a strength, although it may be too terse to cover all necessary semantics.
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 nested baseline object, a required plugin, and zero schema description coverage, the description is incomplete for confident invocation. It lacks parameter guidance, usage context, and clarity about what '配套说明' refers to, despite having an 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?
Schema description coverage is 0%, so the description must compensate. It references the 'baseline' concept ('原始读取基线') and indirectly the plugin/Skill relationship, but it does not explain the scope parameter or the structure/role of the nested baseline object.
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, '移出配套说明' (remove companion explanation) applied to a preview context, and clarifies that the upstream Skill is left in place. This gives a recognizable resource and effect, though '配套说明' is somewhat vague and not explicitly contrasted with sibling preview 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?
The description implies a preview-removal scenario but offers no explicit guidance on when to use this tool versus context_preview, context_apply, or document_preview_remove. No alternatives or exclusion 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 description discloses meaningful side-effect behavior: enabling applies application configuration, while disabling retains files. It also states that execution is handled directly by the host. However, it does not elaborate on other potential side effects, permissions, reversibility, or what happens to existing configuration beyond the enabled toggle, and annotations provide only openWorldHint=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 description is short and every clause carries meaning related to behavior or parameters. The phrasing is somewhat fragmented, especially '使用由宿主直接完成', but it does not waste words and front-loads the core baseline/takeover concept.
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?
While an output schema exists, the description still leaves key invocation questions unanswered: what baseline properties are expected, what scope values are valid, when this tool should be used instead of host_apply, and what 'takeover' fully implies. The reference to host_status helps but does not make the tool safely invocable without additional investigation.
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 provides no descriptions for enabled, baseline, or scope, and description coverage is 0%. The description does add meaning for enabled ('enable applies config, disable retains files') and baseline ('use host_status's baseline'), but it does not explain the structure of the baseline object or the meaning of scope, leaving one parameter semantically uncovered.
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 clarifies the effect of the enabled flag: enabling applies configuration and disabling retains files, tied to a baseline from host_status. This gives a specific behavior rather than only restating the tool name, though it does not explicitly differentiate itself from sibling tools like host_apply or host_preview.
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 on when to use this tool versus alternatives such as host_apply, host_preview, or host_preview_restore. It references host_status as the source of the baseline, but does not state when a user should choose host_set_enabled over other host-related operations.
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?
There are no readOnly or destructive annotations, and the only behavioral note is '原文保持原位' (original text stays in place). The description does not disclose whether existing configuration is overwritten, whether the operation is reversible, or what side effects may occur, which is insufficient for a mutating configuration 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?
The description is a single dense sentence with no filler. It packs in the action, the state values, the data source, and a key behavioral guarantee, which makes it highly efficient and front-loaded.
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 4 parameters, no annotations, and no schema parameter descriptions, the description is too thin. It does not explain scope, the shape of baseline, preconditions, or effects beyond preserving the original text. The presence of an output schema reduces the need to document return values, but not the need for parameter and mutation context.
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, but the description compensates partially by enumerating the state values and referencing card_describe's configBaseline for the baseline parameter. It leaves id and scope unexplained, though those are relatively self-evident or have defaults; overall it is adequate but not complete.
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 identifies a clear action — setting a card's state to enabled, disabled, or inherit — which is a specific verb plus resource. It does not explicitly distinguish itself from sibling tools like card_set_relation or card_set_shared, but the state-configuration focus is clear enough to separate it.
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?
It implies an ordering dependency by instructing the agent to use card_describe's configBaseline, which gives useful context for when to call this tool. However, it does not explicitly state when not to use it or mention alternatives, leaving the usage guidance mostly inferred rather than 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?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context: unregistered references are not dropped but preserved through diagnostics, which is useful and goes beyond the structured 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 very short and front-loaded, with the primary behavior stated first. The second clause adds useful diagnostic behavior without padding, though it is terse enough that some meaning is left implicit.
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 is simple, read-only, and has an output schema, so the description does not need to explain return values. However, it leaves important context unclear: what 'scope' means, what the diagnostics are, and how this compares to other catalog tools. It is adequate but has clear gaps.
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?
There is one parameter, scope, with a default and zero schema documentation. The description provides no information about valid scope values or how scope affects the returned graph, so it does not compensate for the 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 states a specific verb and resource: it 'returns declaration and reference relationships', which clearly indicates the core function of the graph tool. It also adds a distinguishing behavior about unregistered references being preserved through diagnostics, though it does not explicitly differentiate from sibling catalog 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?
There is no guidance on when to use this tool versus siblings like catalog_list, catalog_effective, or catalog_discover. The diagnostic-preservation note hints at a particular behavior, but the description never states use cases, 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 declare readOnlyHint=true, and the description adds useful context: the actual write into the user library happens through document_preview and document_apply, not through codex_import itself. This clarifies the side-effect boundary and does not contradict 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the main action and the downstream workflow, though it is a bit telegraphic.
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 workflow context and output schema help, but the missing meaning of the sole required parameter leaves the agent unable to invoke the tool correctly. For a one-parameter tool, omitting any explanation of that parameter is a critical completeness gap.
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, id, has no schema description and the tool description never explains what id refers to. With 0% schema description coverage, the description needed to compensate, but it provides no semantic guidance for the sole required input.
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: prepare a complete Skill or description as a standalone declaration. It gives the tool an identifiable role in the preview/apply workflow, though it does not explicitly differentiate it from siblings like document_import or document_preview.
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 context by naming document_preview and document_apply as the downstream tools that write the draft into the user library. However, it does not explicitly state when to choose codex_import over alternative tools or what conditions make it the right choice.
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?
Annotation readOnlyHint true already marks read-only; the description adds that the plan is saved via document_apply after previewing, implying usage_preview itself does not persist. It does not contradict annotations, and the workflow note is behavioral context beyond the boolean hint.
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 with no filler and the most important constraint (settings schema source) is front-loaded. It is concise, though somewhat under-specified; still 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?
The output schema and readOnly annotation lower the burden, and referencing usage_describe/document_apply gives workflow context. But it lacks parameter semantics for most fields and no explicit guidance for choosing this tool over sibling preview tools, leaving it only partially 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?
Schema description coverage is 0%, so the description must carry parameter meaning; it only explains settings by pointing to usage_describe's settingsSchema and ignores plugin, scope, and baseline. It provides one useful link, but three of four parameters remain semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says settings must comply with usage_describe's settingsSchema and that after previewing a plan should be saved via document_apply, but it never directly states what usage_preview returns or what action it performs. The verb 'preview' is implied by the name and workflow, not by a clear definition.
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?
It embeds a workflow: settings schema comes from usage_describe and the preview result is ultimately persisted through document_apply, so an agent can infer use before applying. It does not state when not to use usage_preview or how it compares with other preview/apply siblings, leaving selection partly to inference.
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 and openWorldHint=false. The description adds useful behavioral context about default grouping and origin switching, but does not explain pagination, cursor, or limit behavior. It does not contradict 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the main purpose, followed by the most important parameter behavior. It is appropriately sized, though the itemIds mention is slightly cryptic and could be clearer with minimal extra wording.
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 an output schema present, return values need not be described, but the tool still leaves three of four parameters semantically unexplained and lacks explicit guidance on when to prefer this over sibling list tools like codex_list. The description is not sufficient for correct non-default calls involving query or cursor.
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 all four parameters. It explains origin values (user default, official) but says nothing about limit, query, or cursor semantics. This is a meaningful gap for a tool with no parameter descriptions in 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 uses a specific verb + resource ('按来源聚合本机内容') and clarifies that it returns itemIds that can be handed to codex_read, which helps distinguish it from read tools. It is somewhat terse but conveys the core purpose and default 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?
It clearly states the default query targets personal groups and that origin=official reads official groups. It also points the agent to codex_read as the destination for resulting itemIds, giving useful downstream routing context, though it doesn't explicitly list when-not-to-use 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 indicate readOnlyHint=true, and the description adds useful behavioral context: it returns file differences and the service-valid planId, while keeping configuration secret fields local. This extra information helps the agent understand what to expect 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 a single, front-loaded sentence that communicates the main output first and then the key privacy behavior. There is no filler or redundant 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 tool is simple with one optional parameter, an output schema, and read-only annotations, so the description covers the core return values and a key behavioral detail. However, it omits scope semantics and usage context, which leaves a noticeable gap for an agent deciding how to invoke 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?
The input schema has 0% description coverage and the only parameter 'scope' is not explained in the description. The default value 'user' provides a weak hint, but the agent is left without information about valid scope values or how scope affects the result.
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 ('returns') and resource ('static file differences' and the effective planId), making the tool's purpose clear. It does not explicitly compare itself to sibling preview tools, but the host-specific wording provides a reasonable distinction.
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 given about when to use this tool versus alternatives such as host_apply, host_preview_restore, or other preview tools. The only implied usage is that it is a preview operation, but no explicit conditions or exclusions 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 only include openWorldHint, so the description must carry behavioral weight. It discloses two behaviors: default-prompt fallback when text is omitted, and storage-location selection for project relations based on both endpoints' shared state. However, it does not mention side effects, permissions, or reversibility of the update.
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 compact and front-loaded with the core action. The additional clauses add meaningful behavioral information without wasted words, though the storage-location phrasing is somewhat dense and ambiguous.
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 six parameters, no parameter descriptions in the schema, and minimal annotations, this description leaves major gaps. The behavior of enabled, baseline, scope, and the exact storage-selection rule are unclear, so an agent would likely need to guess or inspect other tools to use this 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?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It only clarifies text and vaguely alludes to the two endpoints (from_id/to_id). Parameters like enabled, baseline, and scope remain entirely 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 uses a specific verb (更新/update) and a specific resource (参考关系/reference relation), clearly distinguishing it from sibling tools like card_relations and card_remove_relation. The main purpose is immediately understandable.
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 state when to use this tool versus alternatives, but the update verb makes the general use case clear. It does provide a conditional usage hint about omitting text to use the default prompt, which gives partial 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?
The annotations already declare readOnlyHint=true, and the description aligns by describing a 'preview' rather than an actual restore. It additionally adds context about original configuration and the protected copy being stored separately, which is useful behavioral information 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 two short sentences with the primary behavior front-loaded. It is compact and contains no filler, though the second sentence could be clearer about why the separate storage matters.
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, readOnlyHint, and only two simple parameters, the description is reasonably complete. However, the unexplained 'scope' parameter and the lack of explicit guidance about the difference between previewing and applying a restore leave some contextual gaps.
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 indirectly relates the 'id' parameter to the backup identity from host_status, but it does not explain the 'scope' parameter or its default. This leaves the agent without adequate parameter-level guidance.
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 ('preview restore') on a specific resource ('the backup identity returned by host_status'), which clearly distinguishes it from host_apply. It is less explicit about how it differs from the sibling host_preview, but the mention of 'restore' provides enough differentiation.
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 the tool should be used after host_status returns a backup identity, so there is some contextual guidance. However, it does not explicitly state when not to use it, nor does it name alternatives like host_apply or host_preview.
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 covers the safety profile, and the description adds useful context about local scope and returning summary/identity rather than full content. It does not disclose pagination behavior, how query/cursor influence results, or behavior on empty/no-match results, which are relevant for a listing 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?
Two short sentences front-load the core behavior and then add the essential kind enum. There is no filler or 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?
The output schema covers return structure and annotations cover the read-only nature, but the description leaves query/cursor behavior and alternative-tool routing unspecified. It is adequate for simple default-limit calls, but not fully complete for non-trivial 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?
Schema description coverage is 0%, so the description must compensate. It explicitly enumerates valid kind values, which is valuable, but it does not explain limit, query, or cursor semantics beyond their names and defaults; the parameter documentation remains incomplete.
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 identifies a specific action (只读盘点/read-only inventory) on a specific resource (本机 Codex 来源) and the return shape (摘要与原文身份). It is clear, but it does not explicitly contrast itself with sibling tools such as codex_read or codex_groups, so it stops short of full sibling differentiation.
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 intended usage—read-only inventorying of local Codex sources—is implied clearly, and the kind list defines the categories. However, the description never states when to choose this over alternatives like codex_read, codex_import, or codex_groups, nor mentions any 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?
The description discloses that the tool re-validates, applies, and writes to a fixed directory, which adds meaningful behavioral context beyond the sparse openWorldHint annotation. However, it does not mention whether the operation overwrites existing data, whether it is reversible, or what happens on validation failure—important for a write/apply 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?
The description is a single compact sentence with no filler. The action and object are front-loaded, followed by the destination. Every phrase earns its place, and the description is appropriately concise for the tool's complexity.
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?
An output schema exists, so return-value documentation is not required. Still, the description leaves gaps around prerequisites, such as whether the plan must come from document_preview, how re-validation failures are handled, and how this tool relates to document_import or document_preview_remove. Given minimal annotations, this is only partially 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 schema provides no description for the required 'plan' object and has 0% schema description coverage. The description adds some meaning by identifying the parameter as a preview plan and noting that it fixes the target user or project registration directory, but it does not explain the plan's structure, required fields, or expected provenance.
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 ('重新校验并应用预览计划' = re-validate and apply preview plan) and a destination ('写入计划固定的用户或项目登记目录' = write to the plan-fixed user or project registration directory). This clearly identifies what the tool does, though it does not explicitly contrast with sibling tools like document_preview or document_import.
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 wording implies this tool is used after a preview plan has been created, since it applies and re-validates a preview plan. However, it does not explicitly state when to use document_apply versus related siblings such as document_preview, document_import, or other apply tools, nor does it mention 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?
注释仅有 openWorldHint=false，未提供 readOnlyHint 或 destructiveHint，因此描述需承担行为披露责任。描述确实披露了"恢复原配置后关闭接管"这一行为特征，超出名称本身的信息量。但未说明更改是否可逆、应用失败时的后果、对现有配置的影响范围，且该工具本质是变更操作却无任何破坏性提示。
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?
描述为两个短句，第一句前置核心动作和参数来源，第二句补充行为结果，无冗余词。对于单参数、低复杂度的工具，这个篇幅和结构恰到好处，每句话都有信息量。
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?
已有输出 schema，故返回值无需描述，降低了对完整性的要求。描述覆盖了用途、参数来源和副作用，但由于复杂度低，整体接近完整。主要缺口是"接管"概念未解释、未区分 host_preview 与 host_preview_restore 两种 plan 的差异，也未说明失败语义。
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 描述覆盖率为 0%，schema 中 plan_id 仅有 title"Plan Id"，无任何语义说明。描述中用"host_preview 或 host_preview_restore 的 planId"补充了参数来源，为代理提供了关键的出处语义，这是超出 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?
描述以具体动词"应用"明确指向 planId 这个资源，并点名其来源工具 host_preview 和 host_preview_restore，功能意图清晰。补充的"恢复原配置后关闭接管"进一步说明了操作的连带结果。唯一不足是"接管"一词本身未定义，略显术语化，但整体足以与同名工具区分。
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?
通过点名 host_preview 和 host_preview_restore，隐含说明了使用时机：在 preview 生成 planId 之后执行 apply。但未显式说明何时不用本工具、与 module_apply/document_apply/context_apply 等其他 apply 系列的区别，也未见排除性说明，属于 implied usage 而非明确指引。
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 establish readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral context: this tool returns summaries, not full documents, and full content is intentionally delegated to document_read. Pagination or cursor behavior is not disclosed, but this is less critical for a read-only lookup.
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 compact sentence with no filler. The summary-vs-body distinction is front-loaded and immediately actionable, though the terseness leaves some parameter semantics unaddressed.
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 adequately conveys the main purpose and the document_read handoff, and an output schema exists so return values need not be described. However, with five undeclared parameters and zero schema descriptions, the meaning of scope, cursor, and limit remains unclear for an agent that needs to invoke the tool beyond defaults.
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 clarifies that 'query' maps to name and that 'kind' is a filter, but it leaves limit, cursor, and scope unexplained, even though these affect result size, pagination, and filtering scope.
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 ('查询') and resource ('声明摘要'), with clear filtering axes: name and kind. It stops short of explicitly distinguishing itself from catalog siblings like catalog_graph or catalog_effective, though it does separate itself from document_read.
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 routes full-body reading to document_read ('正文通过 document_read 读取'), giving the agent a clear condition for using an alternative. It does not mention when to prefer catalog_list over other catalog-related siblings, but the provided handoff is useful.
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 a meaningful behavioral guardrail: when the source changes, the tool retains the current file and requires a re-preview. This goes beyond the sparse annotations, which only contain openWorldHint: false. However, it does not disclose whether the operation is destructive, reversible, or what happens on a normal successful apply.
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 efficient sentence that front-loads the primary action and then adds the key conditional behavior. No word is wasted, and the most important usage detail appears immediately.
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 one opaque input parameter and an output schema present, the description covers the essential workflow constraint and the re-preview condition. It is concise but sufficient for an agent to select and invoke it in the module preview/apply cycle, though it leaves out error scenarios and exact effect 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?
The single 'plan' parameter has no schema description, and overall schema description coverage is 0%. The description compensates partially by stating the plan must come from module_preview, which constrains its provenance and expected structure. It still does not describe the plan's internal shape or required fields, leaving the agent with limited semantic guidance.
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 an apply/submit action on the plan produced by module_preview, which distinguishes it from module_preview itself and other apply-like siblings. It names the specific resource ('module_preview 的 plan') and implies a concrete workflow step. However, it does not explicitly state what applying the plan ultimately changes in the system.
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 the tool should be used after module_preview, since it takes that tool's plan as input. It does not provide explicit when-not-to-use guidance or compare with other apply variants like host_apply, document_apply, or context_apply. The usage context is inferable but not clearly delimited.
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 does not contradict this. It adds that the tool performs validation and previews a diff, and that the baseline should come from document_read, which is useful behavioral context beyond the schema. It does not detail failure modes or exact diff semantics, but those are less critical given 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?
One compact sentence, purpose first and usage note second, with no filler or repeated schema information. This is a model of concise, front-loaded description.
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 invocation pattern (pass a document, optionally carry a baseline from document_read), and the output schema reduces the need to describe return values. However, it leaves the meaning of '声明' vague and omits any guidance on the scope parameter, so an agent could misjudge what counts as a valid document. It is minimally complete rather than fully self-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 needed to explain all three parameters, but it only meaningfully clarifies baseline ('携带 document_read 返回的 baseline'). The core document parameter is only implicit in '声明', and scope is never mentioned. This leaves a significant 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?
Description uses specific verbs '校验' and '预览差异' with the document/declaration resource, so an agent can tell this is a validation/preview tool. However, it does not explicitly distinguish itself from related preview siblings like host_preview or document_preview_remove, and the term '声明' is left undefined.
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 instruction '编辑时携带 document_read 返回的 baseline' gives explicit context and a concrete prerequisite: when editing, pass the baseline returned by document_read. It does not state when not to use this tool or point to alternatives such as document_apply, so it is clear but not fully exclusive.
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's '读取' (read) aligns with that. The description adds useful behavioral detail beyond annotations: omitted id returns new-module candidate content. 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 sentence with no filler, front-loading the core action and then adding the key conditional detail. Every part 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?
With an output schema present and readOnlyHint=true, the description doesn't need to explain return format or safety. However, the scope parameter is undocumented, and there is no guidance on when to use module_describe vs module_preview, leaving some contextual gaps.
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 partially explains the id parameter's omission behavior but says nothing about the scope parameter. This leaves one of the two parameters semantically 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 clearly states the action ('读取模块表单与基线', read module form and baseline) and the conditional behavior when id is omitted. It is specific about the resource but does not explicitly differentiate from sibling tools like module_preview.
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 it to read module form/baseline, and if id is omitted, it returns candidate content for creating a new module. It does not mention exclusions or alternative tools, but the conditional guidance is explicit enough.
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?
With `readOnlyHint: true` and `openWorldHint: false` already covering the safety profile, the description adds pagination behavior and the fact that it exposes side-effect information for a given method. No contradiction with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the main purpose before detailing behavior. It is efficient and without filler, though the semicolon-based structure is somewhat terse.
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 is adequate for basic selection and invocation, especially with an output schema and read-only annotations, but the ambiguous `group` parameter and the vague 'side effects and next-step help' phrasing leave gaps an agent may need to resolve.
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 clarifies `method` and implies `limit`/`cursor` through '分页查询', but leaves `group` entirely 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 identifies a specific action: paginated querying of methods, and states that specifying `method` returns the actual input schema, side effects, and next-step help. This is clear enough, though it does not explicitly differentiate it from sibling tools like `agent_help`.
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 usage context: use pagination by default, or specify `method` to get detailed schema/side-effect/help information. It does not mention alternatives or when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with readOnlyHint=true and adds a small amount of context by saying the read is on-demand and concerns topics returned by overview. It does not disclose additional behavior such as error handling or what happens for invalid topics, but the annotations already cover the read-only safety profile.
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 conveys the action, the input source, and the likely topic content with no wasted words. It is appropriately concise for a simple one-parameter tool.
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 optional-parameter read tool with an output schema and read-only annotations, the description covers the essential usage context. It could be slightly stronger by explicitly stating that 'overview' is the default topic or by giving an example invocation, but nothing critical is missing.
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 provides only a default value and no description for 'topic', and schema coverage is 0%. The description partially compensates by listing example topic areas (rules, modules, host, content), but it does not give an exact enumeration or clarify whether these are the only valid values.
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 uses a specific verb ('读取' / read) and identifies the resource as a single help topic returned by overview. It hints at the topic categories (rules, modules, host, content), but it does not explicitly distinguish itself from sibling tools such as content_read or module_describe.
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 phrase '按需读取 overview 返回的单个帮助主题' gives clear context: this tool is meant for reading one help topic after an overview has listed available topics. However, it does not state exclusions or explicitly name alternative tools for 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 mark this as read-only and not open-world; the description adds extra behavioral context by stating that the returned body is limited to Skill/说明载体 and that a configured mode returns a safe summary. No contradiction exists between the description and 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?
One dense sentence packs the primary action, the resource, and the key constraints without wasted words. The slight deduction is due to unexplained domain terms that force an agent to decode meaning rather than absorb it immediately.
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-parameter readonly tool with an output schema, the description is mostly complete: it identifies the source of the id, the read-only nature, and body constraints. It falls short only because 'Skill', '说明载体', and '安全摘要' are not expanded, so a cross-domain agent may still be unsure what exactly will be returned.
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 coverage, the description must explain the single 'id' paramter. It does so by identifying the id as an observation identity returned by codex_list, which gives an agent a way to obtain the value. It is not a 5 because it fails to define what an observation identity looks like or how it is formatted.
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 uses a specific verb ('读取') and names a concrete resource ('codex_list 返回的观察身份'), which helps distinguish it from list/import siblings. It is not a 5 because phrases like '正文限于 Skill 和说明载体' are jargon-heavy and leave the exact read target somewhat ambiguous for an agent unfamiliar with the domain.
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 the intended workflow: first call codex_list, then read one of the observation identities it returns. However, it does not explicitly state when to choose this tool over codex_groups, module_describe, document_read, or other read-style siblings, nor does it give any '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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: if any baseline changes, the entire group commit is rejected, which warns the agent about a potential failure mode. However, it does not specify side effects, whether the operation is destructive, or what a successful commit entails. With annotations limited to openWorldHint=false, the description carries the burden but only partially.
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?
One concise sentence that front-loads the action and then adds the critical rejection condition. No filler words; every clause adds information.
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 explains the input source and a key failure condition, and an output schema exists to cover return values. But for a mutating apply-style tool with minimal annotations, it lacks detail on what changes are actually made, whether they are reversible, and what the agent should do if the commit is rejected (e.g., re-run preview). This leaves the tool usable but not fully self-contained.
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 'plan' parameter has no description in the schema and additionalProperties is true, so the schema conveys almost nothing about its structure. The description compensates by telling the agent exactly where the plan comes from: the return value of context_preview or context_preview_remove. This gives meaning to the parameter that the schema lacks.
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 ('保存' = save/commit) on a specific resource (the plan returned by context_preview or context_preview_remove), and the rejection condition further clarifies its role. It is clear enough to distinguish from sibling apply tools like module_apply or host_apply, though '保存' is slightly ambiguous versus the tool name 'apply'.
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 names context_preview and context_preview_remove as the sources of the plan, telling an agent this tool should be invoked after those preview tools produce a plan. It does not explicitly list exclusions or alternatives, but the workflow is clear from the source references.
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 annotations do not include readOnlyHint or destructiveHint, so the description carries the burden. It clearly discloses persistent side effects and an authorization precondition. It could be more specific about reversibility and scope, but the essential warning is present.
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 purposeful sentences with the core side-effect trait front-loaded, followed by the required precondition and input content. No filler or redundant repetition.
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 generic action dispatcher with no parameter docs, the description sensibly routes to agent_capabilities and warns about persistent side effects. It lacks concrete examples and explicit exclusions, but an output schema exists so return-value detail is not a major gap.
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 adds that params should contain a complete baseline or confirmed plan and that method/input details come from agent_capabilities, but it does not enumerate valid methods or the params shape.
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 clear action: execute methods that have persistent side effects, which distinguishes it from sibling query/preview tools. The exact set of methods is left vague, but the core purpose is identifiable.
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 explicitly instructs the agent to first read agent_capabilities to understand inputs and authorization boundaries, then pass a complete baseline or confirmed plan. It does not name exclusions or alternatives, but the usage context 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 adds behavioral detail beyond the readOnlyHint annotation: each snapshot is counted only once, and native Codex direct use is marked as not collected. These are exactly the interpretation-relevant caveats an agent needs. The annotation is consistent, so no contradiction exists.
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 counting rule comes first, followed immediately by the snapshot dedup and exclusion caveats. There is no filler or repetition; every clause adds information.
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 read-only tool with one optional parameter and an output schema present, the description covers the essential semantics: what is counted, the grouping key, the dedup rule, and the data availability limitation. The main remaining gap is the unspecified meaning of days, which keeps it from being fully self-contained.
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 only parameter, days, has 0% schema description coverage and is not mentioned in the description at all. The name 'days' plus default 7 weakly implies a time window, but the description does not explain what days controls, how it bounds the statistics, or its accepted range. The description fails to compensate for the low schema coverage.
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: it 统计 Manager 完整读取, grouped 按原始Skill, and gives an explicit counting rule and data exclusion (原生Codex直接使用列为未采集). This makes it clearly an aggregate read-statistics tool, distinct from raw read/list siblings like codex_read or content_read.
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 context is implied: it is for Manager complete-read stats, not for raw Codex direct-use data. But there is no explicit when-to-use/when-not-to-use guidance and no named alternative tool for the excluded data, so the agent must infer routing from scope rather than being told.
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 annotations already declare readOnlyHint=true, and the description does not contradict that. It adds genuinely useful behavioral context by revealing that this is a dynamic dispatcher: the actual operation depends on the selected method from agent_capabilities, and params are validated against that method's schema. This is meaningful beyond the static 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 one compact sentence with no filler. The readOnly constraint and the parameter schema rule are both front-loaded, and every phrase contributes to correct usage.
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 dynamic dispatcher, the description tells the agent where to find valid methods and how to validate params; an output schema exists, so return-value documentation is less critical. It could be more explicit about invalid methods or the relationship to manager_action, but the core calling contract is reasonably 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?
Schema description coverage is 0%, and the params property is just a generic object, so the description carries the burden. It explains that method is a readOnly method name sourced from agent_capabilities and that params must follow that method's inputSchema. This is actionable, though it does not provide concrete examples or enumerate possible methods.
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 (execute) and identifies the resource as methods that agent_capabilities marks as readOnly. It is clear, but it does not explicitly name the sibling alternative manager_action or other specialized tools, so differentiation is only implicit through the readOnly qualifier.
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 selection context: use this tool for methods that agent_capabilities labels readOnly, and shape params according to that method's inputSchema. It does not explicitly state when not to use it or point to manager_action as the mutation counterpart, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only behavior is already declared in annotations, so the description's added value is its disclosure that the tool also performs conflict diagnostics and reports original input positions. This goes beyond the schema and annotations, though it does not elaborate on any side effects or formatting, which is acceptable for a read-only, zero-parameter 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?
One compact sentence that places the verb and primary object upfront, then appends the two additional behaviors (conflict diagnostics, source positions). Every phrase earns its place and there is no 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?
For a zero-parameter, read-only tool with an output schema, the description is sufficient: it defines what the effective catalog consists of, what diagnostics it includes, and where the data originates. Return format is covered by the output schema, so no more detail is needed.
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 no parameters, so the description carries no parameter semantics burden. The conceptual inputs (defaults and explicit declarations) are briefly identified, which adds enough context without needing to document argument details.
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 operation (reads the effective combination) and a specific resource (user defaults plus explicit project declarations), and clarifies it includes conflict diagnostics and original input locations. This distinguishes it from sibling catalog tools like catalog_list or catalog_graph, which would focus on enumeration or graph structure.
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 usage context is implied: use this when you need the effective merged view of defaults and explicit declarations, especially with conflict diagnostics. However, it does not explicitly state when to prefer it over alternatives or mention any exclusions, so the agent must infer the appropriate selection from the description alone.
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

harness-manager MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![harness-manager MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/x380kkm/harness-manager/badges/card.svg)](https://glama.ai/mcp/servers/x380kkm/harness-manager)

Score Badge

Copy to your README.md:

[![harness-manager MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/x380kkm/harness-manager/badges/score.svg)](https://glama.ai/mcp/servers/x380kkm/harness-manager)

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/x380kkm/harness-manager'

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