dayz-agentic-modding-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Every tool has a clearly distinct purpose, from knowledge queries (find/show/overrides/callers) to world manipulation (spawn/delete/set/state) to client controls (move/look/press/type). Even similar-sounding tools like client_verdict vs client_compile_check are explicitly differentiated by scope. No two tools appear to do the same thing.
Naming Consistency4/5Most tool names follow a consistent noun_verb pattern (e.g., knowledge_find, asset_build, world_spawn), but a few are noun_noun (project_status, server_status, job_status) and some are noun_noun_verb (world_time_set, world_weather_set). The style is uniform (lowercase with underscores) but the verb placement is not perfectly consistent.
Tool Count3/5With 55 tools, this is a large surface, but it covers a broad domain: project management, knowledge indexing, mod building, server control, client interaction, world manipulation, UI inspection, and asset pipeline. The count is appropriate for the scope, though it feels heavy and might overwhelm agents; it remains borderline for the size.
Completeness5/5The tool set covers the full lifecycle of modding: knowledge retrieval, building/linting, server and client management, world/UI interaction, and asset conversion/checking. There are no apparent dead ends—each domain has create/read/update/delete or start/stop/status analogues, and even edge cases like asset binarization failures and signature policies are addressed.
Average 3.9/5 across 50 of 55 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 103 commits 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
This repository is licensed under GPL 3.0.
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.
This server has been verified by its author.
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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description hints at underlying logic (process liveness, window state, update flag, joined state) but does so in a metaphorical and unclear manner. It fails to disclose the return value, side effects, or how the four checks are combined, leaving the behavior ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a long, meandering paragraph with unnecessary poetic language and filler (e.g., 'silently broken a run before'). It lacks a clear front-loaded summary and is not concise or well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool appears to be a status check, but the description does not explain what the tool returns (e.g., a boolean, a string, a verdict). It also does not cover error handling, when it might fail, or how the results relate to the mentioned checks. Given the minimal schema and output description, this is highly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there is nothing to describe. The description does not add any meaningful clarification about implicit inputs or configuration, but this is not a significant gap given the empty parameter list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description vaguely states 'everything about the client that decides whether the other tools can work' but does not clearly specify the tool's function, resource, or output. The 'four questions' are cryptic and not directly tied to a concrete action or result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to sibling status-check tools like 'client_verdict' or 'server_status'. The description does not mention any conditions or scenarios where this tool is preferred.
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?
No annotations are present, so the description must carry the burden. It explains that without class_name it reads cached player state (republished every tick) and with class_name it sends a query command and returns a count. This covers some behavior but does not explicitly state whether the command has side effects or if the tool is read-only. The phrasing 'the answer is already on disk' implies a cached read, but side effects are not fully disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and unnecessarily poetic, repeating a rhythmic pattern that obscures core information. It could convey the same functionality in a fraction of the words. The structure is not concise, making it harder to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description explains the two operational modes (with/without class_name) and the caching rationale, it lacks details on return structure (output schema is not shown), error conditions, required parameters (all are optional but their defaults are unclear), and how the tool integrates with the broader workflow. The description is incomplete for a developer to use it confidently without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions, and the description only partially hints at parameters: pos, radius, timeout, and class_name are mentioned, but their precise meanings and defaults are not fully explained. For example, radius is referenced in the context of the class_name query, but pos and timeout are not clarified. Schema coverage is 0%, so the description must compensate, but it does not sufficiently define each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns the current world state (player position, health, items) and optionally a count of objects by class. However, the wording is cryptic and poetic, making the exact purpose less straightforward than it could be. It does differentiate from siblings like world_entities by focusing on player state and optional query counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., world_entities, world_spawn). It explains the caching behavior and query mechanism but provides no guidance on selection criteria or situational 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?
Since no annotations are provided, the description carries the full burden. It does an excellent job explaining the defaulting logic and why the defaults exist ('a single default for both would make one of the two combinations a trap'). However, it doesn't address the purpose of the required timeout parameter or what happens when this tool is called (side effects, return values).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences total: the first states the action, the second details the target/variable combination, and the third justifies the design decision. Every sentence contributes value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, this is mostly complete. The tool's purpose is clear, and the explanation of the trap is valuable for an agent. However, the purpose of a timeout parameter on an apparently instantaneous operation remains a gap, as does what the agent can expect in return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This dimension is where description value matters most with 0% schema coverage. The description adds significant meaning to target ('player' or 'hands') and what (health or quantity), which is necessary. However, timeout is entirely unexplained, and it's unclear if value is absolute or relative. The description partially compensates for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource: 'Set health or quantity.' The description clearly indicates this is a setter tool without ambiguity about what it operates on, and the mention of 'player' and 'held item' provides context. However, it doesn't differentiate itself from more specific sibling tools like world_time_set or world_weather_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains a nuanced defaulting behavior for the target parameter but provides no guidance on when to choose this tool over alternatives. There's no mention of what makes this tool preferable or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully explains the paging/trailing semantics and node fields, but it does not state whether this tool is read-only, whether any side effects occur, whether a timeout is needed for deep trees, or how large a response may be. Some behavior is revealed, but important safety/performance characteristics are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, well-structured, and front-loaded: the core purpose appears first, followed by the root choices, then the node fields, and finally the important trunction/paging semantics. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema gives the fine-grained response shape, so the description does not need to re-list fields. It is missing enough parameter semantics that a caller does not know how `limit` and `depth` control the page, and side effects are unaddressed. The completeness 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schemas provide no descriptions for any of the 4 parameters (0% coverage), so the tool description must compensate. It explains `root` values (`menu`/`screen`) but remains silent on `depth`, `limit`, and `timeout`. Without these semantics, an agent does not know how batching or scan depth affect results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as a getter for the client's widget tree and specifies the distinction between `root: menu` and `root: screen`. It conveys the specific resource (UI widget tree), though it does not explicitly name sibling tools to differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys what the tool is for, and root options imply when to pass `menu` vs `screen`, but it never states when to prefer `ui_tree` over siblings like `ui_find`, `ui_text`, or `ui_menu`. Usage context is implicitly inferred, not explicitly guided.
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?
No annotations are provided, so the description must disclose behavioral traits. It explicitly states that when no player is connected, the mod refuses by name, and that this is a stated reason rather than a silent no-op. This is valuable transparency, though it does not cover other side effects or success behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that immediately convey the core purpose and format. It front-loads the essential information and adds a practical cross-reference to world_state without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers the key parameter and a notable edge case. However, it fails to mention the 'timeout' parameter, which is part of the input schema and could affect invocation. Since an output schema exists, return values are covered, but the missing parameter documentation makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 thoroughly explains the 'pos' parameter and its format, but completely omits the 'timeout' parameter, leaving its purpose and constraints undocumented. This is a significant gap given the schema provides no help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Move' and the resource 'player', and specifies the parameter format. It is unambiguous in what the tool does, but it does not explicitly differentiate from sibling tools such as world_spawn or world_set, relying instead on the generic phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the position format matches world_state, implying it should be used when a position from that tool is available. However, it does not state when to avoid this tool or recommend an alternative, so the usage guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly explains the sentinel behavior (-1 means keep existing value), the engine-defined ranges for each field, and that the response reflects the post-change state. This is valuable and goes beyond what the schema alone provides, though it could be more explicit about potential errors or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but repeats the -1 semantics and range information in a slightly redundant manner across three paragraphs. It could be tightened, but it is not excessively verbose and the structure (purpose, semantics, return) is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, the description covers the key aspects: partial update behavior, value ranges, and response content. Since an output schema exists, the return format need not be detailed, but the description still mentions the post-change snapshot. It lacks edge-case details but is sufficient for most usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the parameters by stating that -1 (the default) means 'keep existing value' and by giving explicit ranges for day, month, hour, and minute. This goes beyond the raw schema, which only shows defaults. It does not explain the 'timeout' parameter, but the core time fields are well clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Move' or set) and resource ('world clock'), making it clear the tool adjusts the world time. It differentiates from read-only siblings like world_state and broader tools like world_set, though it does not explicitly name them. The phrase 'Move the world clock' is slightly unconventional but unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool over alternatives. It focuses on behavioral semantics (partial updates, ranges) but never states 'use this for setting time' or contrasts with world_set or world_weather_set. Agents must infer applicability from the purpose.
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 no annotations, the description carries the full burden. It discloses that the set persists across restarts, that clear resets it, that server_mods does not modify it, and that empty mods array is refused. It also explains that narrowing affects knowledge answers. This is comprehensive, though the repetitive and metaphorical wording ('silent lie') may confuse rather than clarify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively verbose and repetitive. Similar concepts ('narrow', 'silent lie', 'narrowing') are restated multiple times with poetic metaphors. While it has a logical flow (declaration, per-parameter explanations, persistence note), the length and redundancy severely hurt readability and quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers essential behavioral aspects: how the tool behaves with no arguments, with mods, clear, source, persistence across restarts, and its relationship to server_mods. It also mentions edge cases (empty mods list). Since an output schema exists, return values need not be explained. Overall, it is complete despite being over-embellished.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions, so the tool description must compensate. It explains mods (narrows answers, empty array refused), clear (resets to all mods), and source (free text label). Note is not mentioned, but the other three parameters are well described, adding significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear statement of purpose: 'Declare, inspect or clear the active mod set.' This distinguishes it from siblings like knowledge_find or server_mods, though the subsequent verbose metaphors could obscure the core functionality for some agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains behavior under different arguments (no args, mods, clear, source) and contrasts with server_mods, but does not explicitly say 'use this when you need to scope knowledge queries' or provide direct comparison with alternative tools like knowledge_find or world_* tools. Guidance is implied 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?
With no annotations, the description carries the behavioral burden and does disclose a non-obvious trait: logs modified before `since` are 'refused as a reason, not silently judged,' including a Windows file-lock nuance. It does not mention side effects or permissions, but the refusal behavior is genuinely informative beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating purpose in the first sentence and then concentrating all nuance into one focused paragraph about `since`. Every sentence earns its place and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core behavior and the subtle `since` behavior are covered well, and an output schema exists so return-format details are not required. Still, `source` is under-specified and there is no cross-tool guidance, leaving the description slightly incomplete for self-contained agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds real meaning to `since` by tying it to a run and explaining the cutoff behavior, which compensates for 0% schema coverage. However, `source` is only echoed as a placeholder and never given semantic meaning or expected values, so the description only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Judge the newest log for `source`.' It is clear that this tool evaluates a log, but it does not differentiate itself from siblings such as log_tail or client_verdict, and the exact meaning of 'judge' is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful workflow context for `since`, noting it is 'typically the value `server_start` returned,' and explains the consequence of a too-old log. However, it never explicitly says when to call this tool instead of alternatives like log_tail or client_verdict; usage is implied 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?
With no annotations provided, the description carries the behavioral disclosure burden. It does well by revealing that the tool samples the newest log's size twice pulse_seconds apart and reports recency of the last log change, adding meaningful behavior beyond a simple 'is it alive' check. It doesn't claim any side effects, and 'health read' implies a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with a clear summary in the first sentence. The following sentences add useful rationale and behavioral detail about why two samples are taken. The brief historical note about a post-compile hang is slightly extra, but it supports the tool's purpose without bloating the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter read-only tool, and an output schema exists, so the description doesn't need to explain return values. The description covers the tool's purpose, input parameter, and core behavior, leaving no critical gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain pulse_seconds. It does so by stating the tool samples the log's size twice 'pulse_seconds apart,' which defines the parameter as the sampling interval. However, it doesn't elaborate on units, acceptable ranges, or the effect of choosing a larger or smaller value beyond the obvious.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a health read: checking if the server process is alive and if its log is actually growing. This distinguishes it from sibling status tools like project_status, bridge_status, and client_status, though it doesn't 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: as a quick health read, especially when a hung boot and a slow boot look similar from the outside. However, it does not explicitly state when not to use it or which sibling tool to prefer in other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that the engine continues simulating weather, so set values drift—a key non-obvious behavior. It also clarifies the meaning of seconds (change time) and duration (hold time). However, it doesn't mention potential error conditions, permission requirements, or side effects beyond drift. The main quirk is well documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence adds value: it defines the phenomena, value ranges, the meaning of seconds and duration, and the nudge behavior. It front-loads the purpose and then adds necessary detail. It's not overly verbose; the drift warning is repeated for emphasis, which is somewhat redundant but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, multiple weather types, timing semantics), the description covers most essential aspects. It explains the operational behavior and the main parameters. The output schema exists, so return value details aren't needed. The missing timeout explanation is a gap, and it doesn't mention prerequisites (e.g., world must be loaded), but overall it's fairly complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'what' (the five phenomena), 'value' (range per phenomenon), 'seconds' (transition time), and 'duration' (hold time). However, 'timeout' is completely unexplained, leaving one of five parameters semantically undocumented. Since the description covers most but not all parameters, it's a partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves a weather phenomenon toward a value, listing the specific weather types and their value ranges. It distinguishes itself implicitly from other world_* tools by focusing on weather, but doesn't explicitly name alternatives or contrast with them. The purpose is specific and understandable, but lacks explicit 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a critical usage warning: this is a nudge, not a lock, and values drift afterward. This is valuable context for when to use the tool (expect drift) but it does not state when to use this tool over alternatives like world_time_set or world_set. There's no explicit 'when-not' guidance or comparison to siblings, so it's a clear but implicit usage note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses that the original declaration is not an answer, that both method and class readings are returned together, that results name the layer and layer age, and that searches over unbuilt layers are refused rather than returning empty results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every paragraph adds meaningful behavioral detail. The opening sentence front-loads the core purpose, and the subsequent paragraphs clarify method/class semantics and output behavior. It is somewhat verbose but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core semantics well, including method versus class handling, layer behavior, and refusal on unbuilt layers. However, with no annotations and 0% schema coverage, the unexplained 'limit' and 'owner' parameters leave gaps that an agent would need to resolve before calling the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 meaning to 'name' by explaining it can refer to a class or method, and it implies the 'layer' parameter through the discussion of built versus unbuilt layers. However, 'limit' and 'owner' are never explained, and no explicit parameter mapping is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool answers 'who overrides this class or this method' and distinguishes between method and class semantics. It is specific about the resource and behavior, but it does not explicitly differentiate from sibling tools like knowledge_callers or knowledge_scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when a caller needs to know overrides for a method or class, and it explains that both readings are answered at once. It does not mention alternatives or exclusions, but the intended use case is well conveyed.
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 no annotations, the description carries the behavioral burden and it does so well: it discloses refusal behavior for non-editable widgets and verifies writes by reading the value back before answering. It doesn't cover failure/timeout behavior or focus side effects, but it explains the important semantic guarantees of the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The summary action is front-loaded, and both follow-up paragraphs earn their place by explaining a refusal guard and why the read-back is necessary. There is no filler, and the rationale is tightly tied to correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and zero schema description coverage, and the description only covers the write/read behavior. It omits how `root`, `timeout`, `expect_name`, and `expect_class` shape the lookup or verification, leaving an agent with significant unknowns for correct invocation despite the output schema covering returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only weakly illuminates the parameters: 'text' is implied as the value written and read back, and 'path' as the target widget. 'root', 'timeout', 'expect_name', and 'expect_class' are not explained at all, so an agent cannot infer their meaning from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific action and resource ('Write into an edit box, and read it back'), and the later constraint makes clear it targets only player-editable fields. It doesn't explicitly name a sibling tool as an alternative, 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use ('Only a field the player could type into may be written') and an explicit when-not-to-use (writing a mod's label would create a lie on screen and is refused). It also points at the alternative naive approach (TextWidget.SetText) and explains why it is not acceptable, so an agent has clear selection criteria.
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?
No annotations exist, so the description carries the full burden. It discloses critical behavioral traits: ground spawns are created with ECE_PLACE_ON_SURFACE and ECE_NOLIFETIME, explaining why an item persists and why the flag matters. It also describes the fallback when neither position nor player is given (the mod says so in words) and the consequence of omitting the lifetime flag. This is substantial transparency for a mutation tool, though it does not cover every hypothetical side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-ordered paragraph: purpose first, then parameter details, then flag rationale. It is dense but each sentence contributes value; no filler. The front-loading makes the primary function immediately clear. It is slightly long but justified by the technical context needed for correct use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main placement and flag behavior, which is crucial for correct invocation. However, it omits the semantics of `timeout` and `quantity`, both of which could significantly affect results. An output schema exists, so return values may be documented there, but the parameter omissions leave gaps. Given the 5-parameter complexity and 0% schema coverage, the description needs to explain all parameters; it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must clarify parameters. It fully explains `where` (enumerating options and default) and `pos` (format and fallback), adding real meaning. However, it does not address `class_name` (the required parameter), `timeout`, or `quantity`, which remain opaque despite their presence in the schema. The description partially compensates but leaves key parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb–resource pair, 'Create an item,' and specifies three distinct placement contexts (ground, hands, inventory). This is specific enough to distinguish it from sibling world_* tools like world_set or world_exec, which target different actions (state changes, commands). No ambiguity remains about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context for the `where` parameter (ground, hands, inventory) and the behavior of `pos` (including fallback), which helps an agent decide placement. However, it never frames this tool against alternatives or states exclusions, e.g., 'use world_exec for commands instead.' The guidance is implicit rather than explicit, but the parameter-level detail does inform usage choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors, such as ignoring script logs because they may not exist in certain builds, and that old reports (before 'since') are refused rather than silently judged. It does not mention any side effects or detailed file-handling logic, but the core decision-making is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively verbose and repetitive, circling around the script log vs. RPT distinction multiple times. A more concise structure would improve readability without losing key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and parameter semantics, but it does not describe the output/verdict format or possible values. Given the output schema is not shown, the user is left guessing what the tool actually returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema provides no description for 'since', the tool text thoroughly explains its meaning and how to use it (pass the timestamp from client_start). This compensates for the schema gap, though the explanation could be more concise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool judges the running or last client based on its .RPT file, and it differentiates itself from log_verdict for compile checks. However, it gets bogged down in caveats about script logs, making the primary purpose slightly less immediate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly contrasts with log_verdict(source='client') and explains when to use this tool (for the live client) versus the alternative. It also gives concrete guidance on the 'since' parameter by instructing to pass the value returned from client_start, making the intended usage 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?
With no annotations, the description takes on the behavioral disclosure burden and does a good job: it defines coordinate orientation, clamps inputs to [-1, 1], and promises that inputs are released on every exit path. It does not explain the effect of seconds or error behavior, but the stated guarantees are concrete and useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and every sentence provides distinct information: the action, the precondition, the coordinate/unit conventions, and the exit guarantee. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-number tool with an output schema, the description covers most of what an agent needs: target behavior, coordinate frame, clamping, and release behavior. The only substantial omission is the role of 'seconds', which prevents full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions and 0% coverage, so the description must compensate. It explains x and y conventions and their ranges, but says nothing about the required 'seconds' parameter, leaving a meaningful gap in how to invoke the tool with the correct semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Turn the camera') with the input mechanism ('right stick') and a clear precondition ('NO FOCUS NEEDED'). It also distinguishes the tool from sibling client_move by clarifying that this is a camera-look operation, not a movement operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives helpful context ('NO FOCUS NEEDED') and references client_move for units, but it never explicitly states when to choose client_look over client_move or another input tool. The reader must infer that this tool is for camera control rather than character movement.
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 no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It explains matching semantics (exact for name/class_name, substring for text), the requirement that at least one criterion be supplied, and that filtering occurs client-side, not here. This goes beyond the input schema and gives the agent realistic expectations about performance and result scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose and is efficiently written across three short paragraphs. The first sentence delivers the core action, and subsequent paragraphs add necessary context without fluff. The only slight waste is the longer explanation of why substring matching is used, but it justifies a non-obvious decision, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and an output schema, the description covers the key behavioral aspects and the main alternative, but leaves several parameters undefined. The output schema presumably documents the return structure, so that gap is mitigated. Still, an agent may not know how `root`, `depth`, `limit`, and `timeout` affect results without deeper inspection. Given the complexity, the description is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the meaning of `name`, `class_name`, and `text`—the three search parameters—including exact vs. substring matching and the implicit requirement that at least one be provided. However, it does not describe `root`, `depth`, `limit`, or `timeout`, leaving those to be inferred from their names. Given that 4 of 7 parameters are undocumented in both schema and description, this is only partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence 'Find widgets by name, class or text, without fetching the whole tree' states a specific verb, resource, and explicit scoping constraint. It also explicitly contrasts itself with ui_tree, making it clear which sibling it is not, so an agent can distinguish it without consulting other schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names ui_tree as the alternative when no search criteria are provided ('with none of them this would be ui_tree'), giving a clear when-not-to-use condition. It also clarifies that filtering is client-side, implying this is the right tool when you want filtered results rather than the full tree. It doesn't discuss all siblings, but the primary alternative is well addressed.
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 no annotations provided, the description carries the full behavioral disclosure burden. It discloses the cost profile (free, no round trip), the update mechanism (client republishes every tick), and the specific status fields included. It does not explicitly state there are no side effects or describe staleness semantics, but the wording strongly implies a passive read-only query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: the main idea is front-loaded, and the cost explanation follows in a compact second sentence. The 'same bargain world_state makes' analogy is slightly jargon-heavy but efficient because it anchors the behavior to a known sibling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter query with an output schema, the description covers the essential operational facts: what state is reported, how often it is updated, and what it costs. It could strengthen routing by naming explicit sibling alternatives like ui_tree or ui_find, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the input schema already documents this completely. The description adds context by explaining that no arguments are needed and that the answer costs no round trip, but since parameter coverage is already 100%, the baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening line identifies the resource (the client's interface) and its current state, and the second sentence enumerates concrete data points: open menu class, cursor visibility, and modal dialog state. It is clear what the tool reports, but it lacks an explicit imperative verb like 'return' or 'get' and does not directly differentiate itself from sibling UI tools such as ui_tree or ui_find.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: this is a free query, already on disk, updated every tick, and requiring no command round trip. It does not explicitly state when to prefer ui_menu over ui_tree or ui_find, nor does it list exclusions, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details behavior such as reading source from the index, handling archives and binarised configs, returning layer information, and reporting which layers were searched when nothing is found. It does not mention side effects but covers key edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with multiple paragraphs, each adding useful context but resulting in a dense block of text. The structure is clear but not concise; it could be trimmed to essential information without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It explains the tool's behavior well and references an output schema separately. However, it does not clarify the meaning of parameters like limit and owner, nor does it specify behavior when multiple declarations match the given name. This leaves some gaps for a tool with 7 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It explicitly covers body, max_lines, and layer, but omits limit, owner, kind, and name. While name is self-explanatory, the others are left undefined, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool shows everything the index holds about one declaration, distinguishing it from knowledge_find which lists matches. It specifies the verbose/resource combo: retrieving full details of a single declaration from a knowledge index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly contrasts with knowledge_find: 'where knowledge_find lists matches, this expands them,' indicating to use this tool when full details of a specific declaration are needed. It also provides a concrete usage hint with layer='core' to target the game's own declaration.
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 reveals that the tool works without focus and drives the UI, and it explicitly states it cannot type. It also notes that no mouse or window messages are used, making the behavior transparent. However, some details like the mention of a third-party application are not essential and slightly obscure the transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is unnecessarily verbose and repetitive. Phrases like 'Measured with a third-party application holding the foreground the whole time' and 'window messages were measured to do nothing at all' add little value and are redundant. The structure could be much more concise and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides good context about the tool's capabilities and limitations (no typing, works without focus, lists buttons). However, it does not mention the output or return value, even though an output schema exists. This leaves a gap in understanding what the tool returns, but given the simplicity of the tool, it is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description enumerates all valid button names (a, b, x, y, back, start, left_shoulder, right_shoulder, dpad_up, dpad_down, dpad_left, dpad_right), which is crucial for the `button` parameter. It does not explain the `seconds` parameter explicitly, but the default (0.1) and context imply it is press duration. Overall, parameter meaning is well-addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Press one gamepad button.' It also specifies the resource (gamepad) and distinguishes it from other input tools by noting it works without focus. The verb 'Press' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool versus alternatives: it mentions that text input should go through `client_chat` and `client_type`, and clarifies that this tool is for button presses without focus. This provides clear guidance on usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, it discloses the key behavioral trait: it blocks and that the timeout will be clamped to at most 600s. It does not mention behavior for missing or failed jobs, but the core blocking-and-timeout contract is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the complete contract: wait until finished, or wait until timeout, and timeout is capped. There is no redundant information and the most important semantics are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for an agent to invoke the tool correctly, especially because an output schema is present. It could still state what happens if the job ID is invalid or whether job failure is treated as a terminal state, but these are not severe gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description partially compensates by specifying timeout in seconds and explaining the 600s cap. job_id is not detailed in words, but its purpose is clear from the tool name and the natural reading of the sentence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action, wait, and its resource, a job, with a well-specified termination condition: job completion or timeout. This distinguishes it from sibling tools like job_status and job_artifacts, which check or use jobs without blocking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The wait and timeout behavior implies that this is for callers that need to block until a job reaches a terminal state. However, the description never explicitly says when to prefer this tool over job_status or other non-blocking status checks, leaving that routing decision mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description openly states what the tool returns ('Each hit names the class and method it was made from, the file and line, and the layer') and explicitly discloses blind spots: 'What it does NOT see... a call reached through a variable whose type the index does not track...' This is thorough transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and repetitive, using parallel poetic structures that restate the same ideas across three paragraphs (e.g., 'before changing a signature, before removing something' mirrors 'before changing a signature, before removing something'). It could be significantly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context to understand the tool's core behavior, output, and use cases. It lacks details on parameters like `layer` and `limit`, but the overall context is sufficient for typical usage, especially with an output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains `kind` ('narrows to call or new') and `owner` ('narrows to calls made from one class'), but does not explain `name`, `layer`, or `limit`. Since schema coverage is 0% and only 2 of 5 parameters are clarified, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Who CALLS this -- every place a method is invoked or a class is built.' It explicitly distinguishes this from knowledge_overrides, making the resource and verb unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage context: 'A different question from knowledge_overrides' and advises using it 'before changing a signature, before removing something, and when working out how a piece of the game is actually used.' It also highlights limitations, guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It details case-insensitive matching, prefix behavior, layer ordering (nearest-first), staleness measurement on every call, the distinction between 'not found' and 'not looked', narrowing with `elsewhere` fallback, and hard time/result limits. This is exceptionally thorough and leaves no major behavioral surprises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence contributes meaning. It leads with purpose, then dives into matching semantics, kind distinctions, output behavior, and edge cases in a logical order. It could be tightened (e.g., the config explanation is lengthy), but for a tool with this complexity, the density is appropriate and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 0% schema coverage, no annotations), the description covers most critical aspects: matching rules, kind semantics, layer ordering, staleness, empty-result behavior, and limits. It also describes output contents. However, it fails to mention the `owner` parameter entirely and does not fully specify acceptable values for `layer`, leaving those aspects incomplete for an agent to use the tool correctly in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains `kind` in depth (with rationale for separation), `prefix` explicitly, and touches on `layer` via the layering concept and `limit` via the hard ceiling. However, the `owner` parameter is entirely unmentioned, and `layer` is not clearly defined as a parameter (e.g., what values it accepts). The description adds substantial meaning for some parameters but misses others, leaving gaps for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Find declarations by name' and enumerates the kinds (classes, methods, constants, enums, configs). This clearly distinguishes it from sibling tools like knowledge_show, knowledge_callers, and knowledge_scope, which have different scopes. The purpose is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use different `kind` values, including a concrete example ('does the game have an item class called X'). It explains the layer ordering and prefix behavior, and warns about situations where a search is refused due to missing index layers. However, it does not explicitly state when NOT to use this tool or name alternative tools as fallbacks, leaving some room for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals that the tool CLEARS THE BRIDGE TRANSPORT before spawning, reports but never fails on left-behind files, never auto-stops a process it did not start, refuses certain reserved arguments, and resolves readiness from two independent signals while reporting which one answered. This is precisely the hidden behavior an agent needs to predict the side effects of a server boot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is structured and dense: bolded signal words ('CLEARS THE BRIDGE TRANSPORT first', 'REFUSES if the game port is already held') front-load the critical warnings, and each paragraph earns its content. Minor asides like the measured 'bound 16.9s after spawn' provide a useful real-world anchor but could be trimmed if brevity were a priority.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A complex tool with no annotations and only 0% schema description coverage — the description compensates well: cleanup semantics, port-conflict refusal, extra argument rules, log-record behavior, and the dual-signal readiness logic are all covered. The only meaningful gap is the timeout parameter's role and what its expiry implies, which is left entirely to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The extra_args parameter is exceptionally well described: it must be a list of strings, is appended after fixed arguments, is an explicit one-run opt-in, refuses the tool's own flags, and is recorded in the boot job's summary. However, the timeout parameter (default 420) is never mentioned at all, and schema description coverage is 0%, so the description must compensate — the omission is not covered anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence is explicit and compact: 'Start the test server and wait for it to be ready. Returns a job id.' It names the specific verb, the resource, the behavior, and the return contract in one breath. It also clearly distinguishes this tool from its siblings like server_status, server_stop, and world_ready — this is the lifecycle-start action, not an observer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides real decision points: it 'REFUSES if the game port is already held,' names the pids holding it, and explicitly routes the caller to server_stop when the holder is a server this session started. It also gives the when-not-to-invent pattern for extra_args ('never one string to re-split') and explains that profile surgery belongs elsewhere, not here. It stops short of listing alternatives for every scenario, but the guidance given is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure, and it excels. It reveals that the tool checks the widget identity via expect_name/expect_class, that script delivery reaches only the open scripted menu (HUD widgets are unreachable), that cursor delivery steals foreground, and that a handler returning false is reported as a fact about the mod rather than a failure. These are significant behavioral traits beyond the schema, and they are clearly articulated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds value. It fronts the core purpose and the safety rationale, then clearly distinguishes the two via tracts with examples, and finally explains the handler-false behavior. The formatting with headers and code formatting aids scanning. No filler or unnecessary repetition – it is appropriately concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 7 parameters and no schema descriptions, the description covers behavior thoroughly but omits parameter semantics for root, button, and timeout. The output schema exists, so return format is not a burden, and the description does mention that the answer indicates which tract was used and how handler-false is reported. Still, the missing parameter details leave the tool incompletely specified, especially for an agent that must supply or adjust these defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameter descriptions, so the description must compensate. It explains the purpose of path (the widget path), via (delivery mechanism), expect_name and expect_class (identity checks). However, it does not explain root (default 'menu'), button (default 0), or timeout (default 45). With 7 parameters and 0% schema coverage, partial coverage leaves a meaningful gap for agents trying to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise statement of what the tool does: 'Press a widget, by path, having checked it is still the one meant.' This names the specific verb, resource, and a key safety verification. It clearly distinguishes itself from generic click tools (like client_press) by focusing on path-based UI interaction with expectation checks. The two via modes (script vs cursor) further clarify its scope, making it unambiguous versus siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the two via modes: 'via="script"' for open scripted menus (works in background, no focus) and 'via="cursor"' for anything the player could click (takes foreground). It also explains the expectation checks as a way to avoid pressing the wrong widget. However, it does not directly mention alternative tools like client_press or when to prefer this over them, leaving the broader selection context implicit.
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?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: the build is unsigned (no signing key used), the output folder is kept free of signatures/keys, and building does not load the mod. It also explains the rationale for not auto-attaching it. This is good behavioral disclosure for a build 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded. The first sentence states the core purpose, followed by concise paragraphs explaining the bridge's nature, the unsigned build, and the non-loading behavior. Every sentence adds value, and the structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema details are provided (though output schema exists), the description covers the essential context: what the bridge is, how it's built, and what happens after building. It could mention the output location or how to check the result, but the description is fairly complete for a zero-parameter build tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (vacuously, since there are no properties). The description doesn't need to explain parameters, but it does explain the build context and output behavior, which is useful. With no parameters, the baseline is 4, and the description adds relevant context about the build process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Pack the bridge mod from this repository's own sources.' It specifies the verb (pack/build), the resource (the bridge mod), and the source (this repository's own sources). It also distinguishes the bridge from the project's own mod, which helps differentiate it from sibling tools like mod_build.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: to build the bridge mod, which is the server's own mod shared across projects. It clarifies that building does not load it, and attaching it remains a profile decision. However, it doesn't explicitly name alternative tools or state when NOT to use it, though the context implies it's for the bridge specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It fully discloses the measurement mechanism (comparing size and modification time against disk), the semantics of 'sources' vs 'empty_sources', and the subtle distinction between 'skipped' and 'outstanding', including why 'outstanding' exists after incremental builds. This goes far beyond typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than strictly necessary, but it is structured logically—first the overall purpose, then the staleness measurement, then the detailed explanation of the two counts. The front-loaded purpose is clear, and every sentence adds substantive information, though it could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the staleness semantics and the presence of an output schema, the description is entirely complete. It covers what each layer holds, how staleness is computed, and the meaning of both counts, including edge cases like incremental builds. No necessary information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the baseline is 4. The description adds valuable meaning to the return values by explaining the meaning of the counts and their relationship, which compensates for the lack of an output schema in the given context (though an output schema exists per signals). No params are left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('holds', 'how old', 'matches') for the knowledge layers, and explains the core concept of staleness as a measurement. It clearly distinguishes the purpose from other knowledge tools (e.g., searching or showing) by focusing on status and integrity, though it does not name a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting layer status and staleness, but it does not explicitly contrast with alternatives like knowledge_find or knowledge_show, nor does it state conditions for when to prefer this tool. The context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it reveals that 'Accepted' is not success, the engine may drop an action, the mod holds the command until release, failure paths release too, and there is a 20s watchdog. This gives an agent a precise mental model of the asynchronous behavior and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place, covering purpose, parameter semantics, behavioral nuances, and failure handling in a logical, front-loaded structure. There is no fluff or repetition; the density is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and missing parameter explanations, the description is highly informative for the core semantics but incomplete for three parameters. The output schema exists, so return values needn't be described, but the undocumented pos/radius/timeout leave a gap in complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains action_class, target_class, and subject in detail, but provides no meaning for pos, radius, or timeout. These three parameters are entirely undocumented, leaving an agent guessing about their purpose and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb-resource pair: 'Run a mod's own action through the engine's gate, on the server.' It distinguishes itself from siblings like world_spawn or world_exec by focusing exclusively on invoking mod-defined actions, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it explains how applicability is determined by the action's own Can() method, that no verb dictionary exists, and when target_class and subject may be omitted. It doesn't explicitly name alternative tools or state when NOT to use this tool, but the context makes it obvious this is the only bridge for mod actions.
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 no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the class is required, radius is clamped, and players are never deleted—critical safety information for a destructive operation. It doesn't mention timeout behavior or what happens to the objects (e.g., permanent deletion), but the core destructive nature and safety guardrails are well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, then adds critical constraints in a second sentence. Every sentence earns its place—no fluff, no repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive, multi-parameter) and the lack of annotations, the description covers the essential usage and safety aspects. It doesn't explain the 'timeout' parameter or the output schema, but the output schema exists and the description covers the most critical behavioral aspects. A small gap remains on timeout semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the meaning of 'pos' (defaults to player position when omitted) and 'radius' (clamped), and clarifies that 'class_name' is required. It doesn't explain 'timeout', but the description adds significant value beyond the bare schema for the other three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes objects of a specific class within a radius, with a clear verb ('Delete'), resource ('every object of class_name'), and scope ('within radius of pos or player'). It distinguishes itself from siblings like world_set or world_action by specifying a destructive, class-filtered deletion operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (to delete objects of a class) and provides important exclusions: the class is required, radius is clamped, and players are never deleted. It doesn't explicitly name alternative tools for non-destructive world manipulation, but the context is clear enough for an agent to infer when this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the tool blocks, has a ceiling, why waiting is necessary, the measured delay window, and the failure mode of sending commands during that window. This is far richer than a generic 'waits until ready' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Longer than average, but every paragraph earns its place: the operational instruction is front-loaded, followed by timing evidence and a rationale for blocking. There is no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers when, why, and blocking behavior, and an output schema exists so return values need not be explained. The only gap is the timeout parameter's units and expiry behavior, which is a small completeness hole for a tool whose only knob is that parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional timeout parameter with 0% description coverage, so the description must document it. It only indirectly references a 'ceiling' and never names the parameter, states its units, or explains what happens when it expires. The agent can infer seconds from context but not explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete action—'Wait until the bridge inside the game is actually ticking'—and clearly identifies the resource and readiness condition. It also gives explicit sequencing relative to server_start and world commands, distinguishing it from siblings without merely restating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exactly when to call: after server_start's boot job finishes and before the first world command. It explains why this matters (the 18-38 s gap) and even contrasts with a polling alternative, so an agent knows when this tool is the intended choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is highly transparent: it explains the internal steps (running binarize, checking artifact, copying models), side effects (deploy or not), failure modes (refusal for invalid source or ambiguous candidates), and non-deterministic rebuilds. It also notes the return behavior (job_id) and that Model.cfg is not copied. With no annotations, it fully carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and repetitive, with duplicated statements about the process (e.g., 'Build...and put them' vs. 'copy the models into the mod') and an anecdotal timing example that adds length without essential value. While well-paragraphed, it is not concise; it could be streamlined by removing redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main context: parameters, return behavior, refusal conditions, artifact handling, and structural comparison. It references job_wait for polling and mentions the artifact but does not describe the output schema or exact job_id format. Given no output schema is provided, it is reasonably complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are explained with meaningful detail beyond the schema: mod ('names one of build.mods...'), deploy ('deploy=False builds and judges without writing'), and source ('model directory relative to the mod's own folder...'). It covers defaults, exclusions, and edge cases (e.g., two candidates cause refusal). Schema coverage is 0%, so the description compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Build a mod's models from their MLOD sources and put them in the mod.' It specifies the resource (mod models) and the source (MLOD sources), distinguishing it from siblings like asset_export or asset_convert. The verb 'build' is specific and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description details the behavior and conditions for use (e.g., default source selection, refusal cases), but it does not explicitly state when to use this tool over alternatives like asset_export or mod_build. The guidance is implicit through detailed process explanation, but lacks a clear 'use this when...' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers exceptionally. It discloses failure modes ('four of them refuse, and this call fails when one does'), specific warnings (C7, animation to artifact, fingerprint mismatches), edge cases ('build.exclude' files not judged), and the PNG comparison logic. Nothing about this tool's behavior is hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The main purpose is front-loaded and every sentence earns its place for a tool of this complexity. The twelve-check enumeration, however, is delivered as a dense paragraph where a more scannable list format would improve parseability. The description is rich but could be condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and substantial complexity, the description is remarkably complete: purpose, performance, side effects, failure modes, edge cases, and parameter hints are all addressed. The output schema covers return values. The lone gap is the 'mod' parameter semantics and explicit sibling differentiation, keeping it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description had to compensate, and it does meaningfully for 'model' — 'narrows it to one file, relative to the mod's directory' — adding real semantic value. However, the 'mod' parameter is never explicitly described, either in the schema or the tool description, leaving the agent to infer its purpose from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Judge the models and textures a mod already ships' pairs a specific verb with a clear resource, and 'Builds nothing' cleanly separates it from build/convert siblings. The enumeration of twelve distinct checks (C1-C12) with concrete examples (DXT1 transparency, ODOL references, rvmat pointers) leaves zero ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear when this is appropriate: when validating an existing mod's files without building, needing no DayZ Tools, and expecting millisecond responses. However, no sibling alternatives are explicitly named (e.g., mod_lint for code-level linting), so the exclusion logic is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels. It discloses that the client launches windowed (with a rationale), refuses connection without a stand, reads and warns about pauseMode, defines readiness by player count rather than a timer, and explains failure reporting. It also reveals the extra_args opt-in behavior and refusal of computed arguments. This is exceptional transparency beyond basic 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though lengthy, every sentence adds essential context. The structure uses clear headings ('IT LAUNCHES WINDOWED...', 'READINESS IS...') to front-load critical knowledge. No redundant filler; each paragraph addresses a distinct aspect of behavior. Despite its length, it is efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites, return value (job id), failure modes, behavioral quirks, and parameter restrictions. It even explains how to interpret readiness. The output schema is present, so return format is assumed. This is a model of completeness for a complex tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 thoroughly explains extra_args, including its append-only nature and protected arguments. However, timeout is left entirely undocumented in both schema and description; an agent must infer its role (likely a wait limit). This is a notable gap for a parameter that controls the tool's blocking behavior. Overall, partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: 'Start the game client and connect it to the test stand. Returns a job id.' This identifies the verb, resource, and outcome. It distinguishes the tool from siblings like client_status and client_stop by its unique launch role. No ambiguity about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive contextual guidance on when to call it: it requires a stand to join, explains the readiness condition (player count, not timer), and warns about windowed mode. It implies the appropriate timing and prerequisites. However, it does not explicitly state when NOT to use it or name alternative tools, though the conditions make that clear. Slight gap in explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and does so exceptionally well. It explicitly states 'Nothing is applied,' explains matching is by Workshop id and never by name, and discloses three categories of things the tool cannot see. This goes far beyond a typical description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and uses bold labels, bullets, and clear separations. The empirical detail about six live servers and 252 distinct offsets is useful but somewhat heavy; it earns its place for port guidance but makes the description denser than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key contextual needs: non-mutating behavior, port semantics, result buckets, and known limitations. It does not clarify whether address is effectively required despite having zero required parameters, nor what timeout means precisely. The output schema reduces the need to explain return values in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds real meaning for address ('host' or 'host:port') and for query_port (overrides embedded port and must be the QUERY port). The timeout parameter is left without explicit units or behavior, which prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, actionable statement: 'Ask a running server which mods it runs, and PROPOSE an active set.' It clearly identifies the resource (a running server's mods) and the unique contribution (proposing an active set), distinguishing it from siblings like server_status or mod_build.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong operational guidance: use the QUERY port, not the game port, and explains with evidence why the game port will fail. It also clarifies how results are bucketed and that nothing is applied. However, it does not explicitly name alternative tools or state when to prefer them, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses behavioral traits: the server does not know the verb, does not validate arguments beyond stringifying them, marks all responses as 'non_standard', and returns a failure listing known verbs for unknown ones. It also details the verb format constraints (lowercase ASCII, up to 41 chars). This fully covers the tool's behavior given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely verbose and repetitive. The same contrast with world_action is stated multiple times, and the language is overly poetic ('silence this product exists to remove'). It could be condensed into a few clear sentences without loss of meaning. The structure is not efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's generic nature (arbitrary verb bridge), the description covers all necessary context: purpose, constraints, failure modes, and relationship to world_action. It is complete enough for an agent to decide when to use it and what to expect. However, the verbose style makes it less accessible, though not incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to the 'verb' parameter (format and constraints) and 'args' (stringified without validation). It does not explain the 'timeout' parameter, but that is a common parameter with a default value. Overall, it enriches understanding of the schema beyond its bare types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Send an arbitrary verb through the bridge' and positions it as a 'debugging escape hatch'. It distinguishes itself from world_action, which is for normal actions. The core function is unambiguous despite the flowery language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use this tool versus alternatives: 'Anything a mod's behaviour can express as an ACTION should go through `world_action` instead'. It also notes it's for debugging and that unknown verbs return a failure listing valid verbs. This gives clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so impressively. It discloses that the capture is 'measured rather than assumed,' explains the minimized state refusal instead of an empty result, and reveals a critical failure mode: what appears to be a successful capture can be a black image, so 'lit_fraction' is returned to disambiguate. This goes far beyond the schema and gives an agent real insight into what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured, starting with the core action in the first sentence and then adding behavioral nuances in tight paragraphs. Some phrases, such as 'the honest half' or 'dark frame is never dark' arguably are stylistic, but they still convey important expectations without unnecessary bulk. More precise language could trim a few words, hence not a full 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and available output schema, the description provides complete coverage of the client's screen semantics. It addresses the main failure mode (minimized), the edge case of black frames, the meaning of 'lit_fraction', and the default output location. An agent has enough detail to call the tool correctly and interpret its results without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the sole 'path' parameter only by type and default, with 0% description coverage inside the schema. The description compensates by explaining what happens when path is omitted: 'the file lands in this project's own .dayz-mcp/shots.' This adds meaning beyond the schema, though it does not fully specify the semantics of an explicitly provided path (e.g., whether it is a directory, full filename, or expected extension).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Capture the client's window to a PNG.' This clearly distinguishes client_shot from sibling tools like client_press, client_chat, or client_move, none of which involve visual capture. The bold 'NO FOCUS NEEDED' additionally clarifies the operational constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides meaningful usage context: it explicitly states the tool works with the client both at the bottom of the z-order and in front, and warns that the only unusable state is MINIMIZED, where 'the client area collapses to 0x0 and there is nothing to copy.' This gives clear when-to-use and when-not-to-use guidance, though it does not compare against alternative sibling tools because none exist for this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does this thoroughly. It discloses that compression is decided by source filename, that alpha loss may occur, that warnings are issued before and after conversion, that output cannot be repaired, and that verdicts are read from the written file rather than the exit code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than typical but every paragraph carries essential operational detail: conversion behavior, compression quirk, path rules, and verdict source. It is front-loaded with the core action and remains coherent, though the alpha-loss narrative could be tightened slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a conversion tool with subtle behavior. It covers path resolution, defaults, output placement, compression selection, alpha-loss limitation, and result interpretation. Even though an output schema exists, the description adds necessary behavioral context beyond structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters—and it does. It defines source path resolution relative to absolute, repository, or build.project_root, and explains output defaults and placement behavior. This gives an agent everything needed to pass meaningful values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: converting one texture between .png and .paa and judging the result. It clearly distinguishes this from the sibling tools by focusing on a single texture conversion plus quality verdict, making it easy for an agent to recognize when this tool is relevant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when this tool is applicable—when converting textures between PNG and PAA formats and needing alpha-loss awareness. It does not explicitly name alternatives or exclusions, but the scenario is specific enough that an agent can infer appropriate use without confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it excels: it discloses that focus is unnecessary, messages are server-side, go to all connected players, color values are validated by the mod with refusal for invalid ones, long lines are refused, success means engine acceptance rather than visibility, and client profile options may drop channels. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose but structured into clarifying paragraphs that each add meaningful detail: purpose, distinction from typing, recipient semantics, color validation, success meaning, and prerequisites. Every section earns its place given the tool's nuance, though it could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and schema descriptions, the description covers all critical aspects: prerequisites, behavior (all players), validation (color, length), semantics of success, and response meaning (count of recipients). The only notable omissions are the exact behavior of timeout and the precise response format, both of which are partially implied but not fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 'text' as the chat line and 'color' with explicit allowed values and validation/refusal behavior. However, 'timeout' is never mentioned—neither its purpose nor behavior. While this is a common parameter, it is completely undocumented in both schema and description, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Put a line in the connected player's chat.' It explicitly distinguishes itself from typing (server-side) and from client_type, which is for mod's own input fields. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use the tool (to send a line to all connected players) and when NOT to use it (for client-only input fields like PDA/terminal, pointing to client_type). It also includes prerequisites (bridge loaded and ticking, bridge build knows the verb) and explains focus is not needed, covering both context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses async behavior (returns job_id immediately), the non-blocking nature (wait with job_wait), the meaning of layers, and the nuanced semantics of 'only' (does NOT notice unlisted changes). Very thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Long but well-structured with layer breakdowns and examples. Every sentence contributes value (measurements, staleness triggers). Slightly verbose but justifiable given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a multi-layer async tool. It covers all parameters, behavior, output (job_id, artifact), and integration with job_wait. The existing output schema (though not provided) handles return specifics, so the description adds the necessary behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain every parameter. It does: layer is explained with each possible value, 'only' gets a detailed semantics explanation (including edge cases like deleted paths), and 'full' is explicitly described as forcing a whole-layer re-read. Nothing is left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource ('Build or refresh a knowledge layer') and distinguishes from siblings like knowledge_find (querying) and knowledge_status (status). The description explicitly enumerates the layer types and their staleness conditions, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context on when each layer is stale (e.g., 'rebuild it whenever you want to ask about code you just wrote') and explains the 'only' fast route for project layer. It doesn't explicitly name alternatives to not use, but the guidance is strong enough to route the agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility and excels: it discloses non-destructive behavior (no packing/booting), defines refusal and warning categories, and details the knowledge-index dependency and its fallback to warning rather than accusing. This is comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a bit long but each sentence adds value: core purpose, parameter semantics, refusal conditions, warning conditions, and a behavioral caveat. It is well-structured with bullets-ish paragraphs and front-loads the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all critical aspects: what the tool does, parameter effects, edge cases (self-extension, exceptions, unresolved modded class), and the dependency on the knowledge index. Since an output schema exists, not explaining return format is acceptable, making this complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, but the description fully explains both parameters: mod (restrict to one mod or default to all) and strict (treat warnings as failures, default off). It adds meaning that the schema alone lacks, fully compensating for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks a mod's Enforce Script without packing or booting, distinguishing it from build operations. It specifies the scope (one mod or all) and the strict flag, making the purpose concrete and distinct from siblings like mod_build or client_compile_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains parameter behavior (mod empty = all, strict defaults to false) and the conditions for refusals vs warnings. It doesn't explicitly name alternatives or say when to prefer this over building, but the 'without packing or booting' phrasing implies it's for quick validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it goes above and beyond: it reveals the async contract (returns job_id, wait with `job_wait`, seconds-to-minutes latency), a subtle corruption failure mode (wrong root strips drive letters, looks valid, resolves to nothing, reports success), the exact verdict logic (must be an MLOD, this run must have written it, no outgoing references), and guarantees that nothing else is touched and Blender preferences are never written back. That is unusually deep transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long (six paragraphs) but nearly every sentence carries decision-relevant facts: purpose, timing, failure mode, verdict criteria, side-effect guarantees, parameter semantics. It is front-loaded with the core behavior and only slightly verbose in the measured-example details (the 2-of-5 LODs / 169-line log anecdote), which explains a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex asynchronous pipeline tool with a known silent failure mode and zero annotations, the definition covers everything an agent needs to invoke it correctly: parameters and defaults, the job-waiting protocol, timing bounds, verdict conditions, and non-destructive guarantees. Since an output schema exists, the description need not enumerate return fields, and it still mentions the `job_id` return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the weight. It compensates well for three parameters: `blend` gets three path-resolution modes, `source` gets its meaning and the single-directory omission rule, and `name` gets its default (source file name with `.p3d` extension). The `mod` parameter, however, is never explicitly explained; an agent must infer it from the 'mod's own folder' phrase.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb and resource: Export a model out of a `.blend` into the project's model root. It also explicitly differentiates itself from the sibling `asset_build` by explaining the export produces the MLOD while the binarized game model is a separate call, so an agent can distinguish it from the other 50+ build assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states positioning explicitly: 'This is the pipeline's OPTIONAL first step' and names the natural next step (`asset_build`) as 'a separate call on purpose.' It also gives a concrete exclusion rule for when to skip the tools: a mod whose `.p3d` came from somewhere else. An agent can decide when to call this tool versus its pipeline neighbor without further inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations are absent, the description goes beyond a simple call to action. It discloses that it runs mod_lint first, that failure to lint blocks the build, that running lint is cheap, and that skipping lint can mask real defects (the example of a modded class that loads and reports success). This is rich behavioral context that an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly verbose with the runtime-cost rationale, but the first sentence is sharp and the extra lines about skip_lint earn their place by explaining a non-obvious parameter. It is well-structured with the main purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single boolean parameter and an output schema, the description covers what the tool does, what it returns, when to skip lint, and the safety/correctness rationale. It's complete for an agent to decide when to call it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a boolean with a default and title, but 0% description coverage means the description must explain it. It does: skip_lint is introduced and its purpose/rationale are clearly described. Could add a touch more about consequences (e.g., potential build failure), but the current explanation is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Pack this project's mods') and states the return value ('Returns a job_id'). It clearly distinguishes this from sibling tools by describing the lint-first behavior, which no other tool describes. The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use skip_lint and why: skip_lint packs anyway, and the rationale ('a refusal that cannot be overridden is a refusal that gets worked around') provides clear guidance on when to override. It also implies normal usage (use without skip_lint) and the alternative of fixing lint errors first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It discloses the read vs. write behavior, the safety check about editing exactly one file within the root, refusal while a server is running, and the output semantics ('says which way in words'). This is exemplary for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Text is clear and well-organized with headers, but slightly verbose. Some redundancy (e.g., 'has already cost one session a long hunt') adds color but could be trimmed. Still, every paragraph earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, behavior, safety constraints, failure modes, and output semantics. Even with an output schema, the description's narrative provides richer context. It's complete for an agent to decide when and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one nullable integer parameter with a default of null meaning no argument; description explains that `value` writes and no argument reads. It doesn't constrain valid integers beyond 0/1/2 implied, but that's fine. Schema coverage is 0% so description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads or writes the `verifySignatures` setting in a server config, and explicitly positions it as a distinct tool with rationale. It distinguishes itself from siblings like server_start/stop by focusing on policy editing rather than lifecycle management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (no argument = read; with value = write), and provides a strong 'WHY THIS IS ITS OWN TOOL' section explaining the failure mode and why using this tool is preferred over manual edits. It doesn't explicitly name an alternative, but the rationale implies it's the right tool for signature-check toggling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full disclosure burden and excels: it reveals the 200-entry cap with a separately reported true total, explains that distance is HORIZONTAL because the engine's radius test ignores height (with a concrete Chernarus example that proves why a straight-line reading would be misleading), and discloses that players are deliberately excluded, including the safety rationale. This anticipates exactly the behavioral traps an agent would stumble into.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense paragraphs, each earning its place: purpose/contrast, pagination, distance semantics, player exclusion. The core message is front-loaded in the opening line. The Chernarus example is lengthy but necessary to make the horizontal-distance warning concrete and credible; nothing feels padded or repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and 0% schema coverage, this is a complex tool to document, and the description covers every major trap: what it returns vs world_state, empty-class_name semantics, pagination interpretation, horizontal distance, and player exclusion. An output schema exists, so return-value explanation is rightly omitted. Minor omissions are timeout semantics and an explicit pos format specification, though both are partially inferable from the example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does substantially: the empty-class_name meaning ('lists everything found rather than nothing') is critical and non-obvious, the pagination note directly explains the limit parameter's cap behavior, and the radius/distance discussion clarifies how the radius filter is actually applied. The only gap is timeout, which receives no added meaning, and pos format is conveyed only by example ('7500 0 7500').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a precise contrast: 'WHICH objects are nearby, not how many,' then names the sibling it is not ('world_state counts; this one names them'). It states the exact resource, the verb (name/list nearby objects), and the returned fields (class, position, distance, health). An agent can distinguish it from world_state without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names the alternative tool and the selection condition: 'world_state(class_name=...) counts; this one names them.' It also gives concrete usage guidance for edge behavior (empty class_name lists everything rather than nothing) and for interpreting pagination (total > count means more results exist). The player-exclusion note additionally frames when this tool is safe to pair with bulk deletes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and handles it exceptionally. It discloses the deletion semantics (claiming IS deleting the file), the safety refusal logic (won't act if the bridge may be alive), the probing preconditions, and that force=True overrides everything. It also contrasts its behavior with server_start and explains what would happen outside these tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is substantial but every sentence earns its place. It front-loads the core purpose in the first line, then builds context in tight, meaningful paragraphs without fluff. The structure flows from purpose → context → safety behavior → parameters, and no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the complexity — a 2-param tool with an output schema, no annotations, and embedded 'own name references' in the description — the description explains what the tool does, why the problem exists, when to use it, what safety checks apply, and what force does. The only tiny gap is that probe_window units aren't specified, but the output schema presumably covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate — and it does. It explains force=True ('overrides all of it') and probe_window ('probes for probe_window seconds'), which adds real meaning beyond the bare schema fields. The only minor gap is not specifying units or boundary behavior for probe_window, but the essential semantics are there.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states 'Discard whatever command is sitting in the mailbox' — a specific verb, resource, and action. It clearly distinguishes itself from related tools like bridge_status and server_start by explaining the wedge problem and naming the sibling that also clears it. The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use it ('the remedy for bridge_status's stale_command') and when not to ('Refuses when anything suggests the bridge is alive'), and names the alternative (server_start) that also clears the transport. It states that throwing away a queued command is a decision, never a side effect of status checks — strong guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels: it explains blocking behavior, the cost of window=0, the no-state-file penalty, and the order of answer checks, including why no_server is checked on process not file to avoid stale snapshots. It discloses the multiple return values and their meanings, which is rare and high-value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely informative, with a clear front-loaded opening question, then structured sections for answers. Every sentence adds value, though it could tighten some phrasing. The length is justified by the complexity of the tool's semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, one optional parameter, and high-quality schema/output schema coverage, the description is complete: it explains all return states, the reason for ordering, and the cost trade-offs. An agent has everything needed to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter `window` has 0% schema description coverageible> but the description thoroughly explains its semantics: default, clamping, unit (seconds), and the behavioral impact of different values (window=0 returns immediately and reports unknown vs larger windows detect movement). This is far more than the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if the bridge is 'still ticking' in the running game, with a specific verb and resource. It distinguishes itself from siblings like server_status and bridge_build by focusing on the bridge's live tick status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use window=0 for quick 'is it publishing' checks vs a larger window for movement detection Menu>implied usage is not present; it gives concrete guidance on block timing and trade-offs, and warns about the cost of no state file. It also implicitly differentiates from siblings like server_status (server-level) and bridge_build (build action).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior. It details that the tool runs a diagnostic client for wait_seconds, stops it, and judges its output, requiring the specific 'Module: Mission' line to accept the log. It also notes the use of a throwaway profiles directory, that it does not read/write the test stand, and that it joins no session. This is comprehensive behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and structured logically, starting with the core function, then nuance, then exclusions, then parameters. While slightly long, every sentence contributes value. It could be tightened, but it remains efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with this complexity—compile logic, judgment criteria, exclusions, parameters—the description covers all necessary aspects: what it compiles, how it judges, what it doesn't do, alternatives, and parameter behavior. It even states the return type ('Returns a job id'). Nothing essential for an agent to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description explains both parameters: 'runs the diagnostic client for wait_seconds' and 'extra_mods appends to the -mod list for this run only.' This fully compensates for the lack of schema documentation, adding meaning beyond the raw property definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource pair: 'Compile the CLIENT half of the scripts and judge the result.' It explicitly distinguishes itself from live-client tools by stating 'this is a compile pass, not a session' and names alternatives like client_start. This leaves no ambiguity about what the tool does relative to its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives. It explains that for the live client, one should use client_start and siblings, and it clarifies that log_verdict(source='client') reads this job's log while client_verdict reads the live client's. It also warns that a server boot never compiles the client-only guard, implying this tool is needed for client-side validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses axis directions, coordinate ranges, clamping behavior, a concrete calibration example (client_move(0,1,6) = 24m walk), stick-rest-on-return semantics including failure paths, and the side effect of attaching a virtual controller visible to the game. This is exemplary behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then packs essential behavioral details, units, side effects, and failure safety into a compact text. Every sentence adds substantive information; none are filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a movement tool with no annotations and an output schema present, the description covers everything an agent needs: effect, coordinate semantics, calibration, device state on return, failure behavior, and integration with client_stop. No critical operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must define all three parameters. It does: x positive to the right, y positive forward, both clamped to [-1,1], and the example implies seconds is a duration. All parameters are meaningfully explained beyond their bare names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Walk the character with the left stick') and resource (character), and explicitly distinguishes itself as the only tract that moves the character and the only analog movement option among many siblings. Clear verb, resource, and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: this is the only tool that moves the character at all, and the only analog one, so 'walking rather than sprinting' is testable here and nowhere else. It also mentions `client_stop` as the companion to unplug the virtual controller, giving clear context on related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and succeeds. It discloses the side effects: stopping the client, unplugging the virtual controller, and intentionally discarding the pad. It also explains the consequence of leaving a controller attached, including a concrete example with DayZ switching on-screen hints to controller mode.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately detailed and well-structured, front-loading the core action before explaining side effects and the deliberate absence of a pid parameter. Every sentence earns its place, including the DayZ example, which concretely justifies why the controller must be unplugged.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema exists, the description need not explain return values. It fully covers what the tool does, when to use it, why it has no parameters, and the behavioral consequences of not using it. Nothing necessary for an agent to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty, which gives a baseline of 4. The description goes further by explaining why there is no pid parameter: the client and server share the same executable, so a pid argument could not be safely validated and would turn the tool into a generic process killer. This adds meaningful rationale beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Stop the client this session started' and 'unplug the virtual controller.' It also explicitly distinguishes itself from server_stop by explaining that client_stop takes no pid because the client shares an executable with the server, preventing it from becoming a general process killer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly defines when to use the tool: 'Stopping the client is the end of the input session, so it is where the device is given back.' It also states that 'Nothing else in this tool set closes it,' ruling out alternatives, and explains why the pid-based approach of server_stop does not apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the tool takes the foreground, verifies it obtained focus before typing, refuses keystrokes if Windows denies focus, uses US-layout scancodes, rejects characters without scancodes by name before taking the screen, and exactly what submit/empty-text combinations do. It even explains the historical accident that made verification non-optional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but every sentence adds essential behavioral or safety information for a tool that can steal focus from a human user. The core purpose is front-loaded, and the length is justified by the tool's risk profile and the need to prevent the exact failure mode described.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations, the description fully covers prerequisites (active window), side effects (foreground taken), safety checks, keyboard layout concerns, refusal behavior, submit semantics, and empty-text edge cases. An output schema exists, so the description need not explain return values. An agent has enough context to invoke the tool correctly and avoid the documented accident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain both parameters. It specifies that text is typed as US-layout scancodes and that unscancodeable characters are refused by name. It also details submit ('presses Enter afterwards'), including the special case of submit=True with empty text sending only Enter, and the refusal of empty text without submit. This goes far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Type into a CLIENT-SIDE INPUT FIELD -- a mod's PDA, terminal or form.' It clearly distinguishes itself from client_chat by explaining that chat is server-side and delivered without focus, while this tool exists for client-only fields that must be typed into like a person would.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when not to use it: 'This is not chat. Chat is a server-side message and client_chat delivers it with no focus at all; use that unless the point of the test IS the typing.' It also explains the submit behavior to avoid needing a second foreground-taking tool, giving clear context for when submit is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the safety check against the recorded image name before invoking stop(), and explains the rationale (recycled Windows pids could target unrelated processes). It also mentions that stop() calls taskkill, providing concrete behavioral transparency beyond the simple 'stop' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though the description is a few paragraphs, every sentence contributes critical information: main action, two modes, eligibility rules, orphaned access, and safety rationale. It is front-loaded with the primary action and uses structured paragraphs for edge cases, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and a minimal schema, the description is exceptionally complete. It covers what the tool does, when to use it vs. not, the exact conditions for pid acceptance, the safety mechanism, and the underlying implementation (taskkill). An agent has all necessary context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a pid integer with default 0 and no description, so schema coverage is 0%. The description compensates fully by explaining the semantics of pid: absence stops the session's own server, presence stops a specific pid only if it meets eligibility criteria (started by session or orphaned), and any other pid is refused. This adds deep meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb + resource combination: 'Stop a server this session is responsible for.' It distinguishes two modes (own tracked server vs. specific pid) and explicitly differentiates from siblings like server_start and server_status by defining scope ('this session is responsible for').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides precise when-to-use guidance: no pid stops the session's own server, while a pid stops that specific process only if it was started by the session or reported as orphaned_server_pid. It explicitly refuses any other pid, and states that this is the only way to reach an orphaned server, preventing misuse as a general process killer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/covalschi/dayz-agentic-modding-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server