wardogs-mcp

Server Quality Checklist

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

Latest release: v0.2.3
Disambiguation4/5
Most tools target distinct resource+action pairs, and the detailed descriptions make even similar pairs (move vs set_pose as relative vs absolute, plan_pieces vs plan_status) easy to separate. A few pairs could trip up an agent though: plan_load_code vs plan_load (site string vs saved file), hub_import vs plan_load_code (both replace the plan from an external source), and browser_push vs browser_readback.
Naming Consistency3/5
Snake_case is used throughout and the plan_, browser_, and hub_ prefixes create strong group predictability. However, the word after the prefix alternates between noun (plan_status, plan_code, browser_readback) and verb (plan_save, plan_load, browser_push), and the bare tools mix verb-first (list_buildables, set_pose), noun-verb (data_refresh, wall_run), and imperative (undo, stack) styles.
Tool Count3/5
33 tools is heavy and exceeds the typical comfortable band, but the server genuinely spans several sub-domains: buildables catalog, plan lifecycle, geometry editing, persistence, hub sharing, and browser automation. Some fragmentation exists (wall_run and ring could be one pattern generator; the seven browser_* tools could be consolidated into fewer parameterized tools), so the count earns a middling score rather than a poor one.
Completeness5/5
The tool surface covers the full base-planning workflow with no dead ends: rules and buildable data, plan creation/query/serialization, every placement and transformation primitive, validation (plan_status, perimeter_check), persistence (plan_save/load/list), sharing (plan_code, hub_import/hub_save), and full browser interactivity including readback and screenshots. Every save has a corresponding load and every import has an export.
Average 3.6/5 across 33 of 33 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- Last stable release on September 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It conveys that the operation mutates a piece's pose and that units are metres and degrees, but it does not explain coordinate frames, side effects, required key semantics, reversibility, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. It front-loads the action and the core delta concept, though brevity comes at the cost of needed detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with five parameters, no output schema, and no annotations, the description is too sparse. It omits essential context such as what 'piece' refers to, how the key parameter selects it, coordinate system conventions, and any constraints or results of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It only hints that dx/dy/dz are in metres and dyaw in degrees via 'metres and degrees', but it does not clarify the role of 'key' or precisely map each parameter to the delta.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('move'), a resource ('a piece'), and the manner of movement ('by a delta in metres and degrees'). The word 'delta' distinguishes it from absolute positioning tools like set_pose, though sibling tools are not explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as set_pose, place, or undo. The delta wording implies incremental adjustment, but there are no explicit use conditions, exclusions, or alternative recommendations.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'load,' but does not disclose whether loading replaces the current plan, requires an exact saved name, or produces any side effects or error conditions. For a state-changing load operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundancy. It is concise and easy to parse, though it achieves brevity at the expense of behavioral and usage detail that is penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool this is near-minimal, but with no annotations, no output schema, and no statement of post-load behavior, error handling, or relationship to plan_load_code, an agent cannot fully judge side effects or reliably select this tool over alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'name' parameter beyond the vague implication that the plan was saved under a name. It adds no details about format, uniqueness, or how the name relates to plan_save.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('load') and a clear resource ('a plan saved with plan_save'), which identifies this as the inverse operation of plan_save. It is not a tautology and gives enough context to recognize the core function, though it does not explicitly contrast with the sibling plan_load_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or alternatives are provided. The phrase 'saved with plan_save' implies a save-then-load workflow, but the description never states when to choose this tool over plan_load_code, plan_list, or plan_status.
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?
With no annotations, the description carries full responsibility for disclosing behavior. It clearly indicates a destructive action by saying 'Replace the current plan,' but it does not explain whether unsaved changes are lost, whether validation occurs, or what happens after replacement. This is thin for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The core action is front-loaded, and the source clarification is compact. It earns its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive replacement tool with no annotations and no output schema, yet the description omits return behavior, error handling, success indication, and important safety context. An agent can guess the input but not fully understand the consequences or how to verify the operation succeeded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'code' as a string, and schema coverage is 0%. The description adds that the code is a site plan string and can originate from plan_code, hub_import, or the browser, which gives basic meaning. However, it leaves the exact format, syntax, and expected representation of the plan string unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—'Replace the current plan'—with a clear object and input type. It also notes the string can come from plan_code, hub_import, or the browser, which helps distinguish it from tools like plan_load or plan_new, though it does not explicitly name siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives such as plan_load, plan_new, or plan_code. The mention of sources implies some use cases, but there are no conditions, exclusions, or comparative context.
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?
With no annotations, the description carries the burden of explaining side effects, but it does not say whether starting an empty plan discards the current plan, overwrites anything, or interacts with undo/redo or persistence. It only discloses that world must be null.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the main action and adds only a relevant parameter qualification. Every word contributes value; there is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations and no output schema, the description is too thin. It omits side effects on the current plan and how plan_new relates to sibling plan_* tools. A few additional words about what happens to existing plan state would make it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the world parameter (0% coverage), so the description compensates by stating that world is null for the open pad and that v1 only supports the open pad. This gives some meaning, but it does not explain what the open pad is or what other world values might exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Start') and resource ('an empty plan'), making the core purpose clear. It doesn't explicitly distinguish itself from sibling plan tools like plan_load or plan_list, but the 'empty' qualifier helps establish that it creates a fresh plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to choose plan_new over alternatives such as plan_load, plan_list, or plan_save. The only usage hint is the world parameter constraint, which is more about parameter semantics than about when to use the tool.
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?
No annotations are provided, so the description carries the full burden. It discloses the output's form ('share string') but does not state whether the tool returns a string, copies it, prints it, or has any side effects. The behavioral contract is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the core idea, with no redundant information. The grammar is slightly awkward ('The plan as...'), but the two fragments together are efficient and easily scanned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should make both the invocation effect and return behavior explicit. It names the output and a use case, but it does not clarify how the agent receives the string or what happens on invocation. The zero-parameter surface keeps this gap moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is complete, so there are no parameter semantics that the description needs to clarify. The 0-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource and result: the plan as the site's share string, and it is clearly paste-able. However, it lacks an explicit verb such as 'get' or 'export', so the tool's action is implied rather than stated. It also does not distinguish plan_code from the closely related sibling plan_load_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Paste-able into the builder's draft or another tool' gives a concrete use case, so an agent can infer when to call it. However, it does not name alternatives, state when not to use it, or explain how plan_code differs from plan_load_code or plan_save.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that pieces are removed, but does not mention irreversibility, error behavior for invalid keys, whether the operation is atomic, or what happens to related pieces.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or repetition. It is front-loaded and easy to parse, though it could have used additional sentences to improve clarity without being wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this description is too sparse. It does not explain side effects, reversibility, required context, or how this relates to sibling tools, leaving an agent without enough information to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema shows only an array of strings named 'keys' with 0% description coverage. The description adds the important semantic that these strings are keys identifying pieces to remove, but it does not clarify key format, uniqueness, or handling of missing keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it removes pieces, and does so by key. It is clear enough to distinguish from broader operations like remove_all, though it does not explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by key' implies this tool is for removing specific pieces identified by their keys, which gives some usage context. However, there is no explicit guidance about when to prefer this over remove_all, undo, or other removal-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully explains coordinate directions, the half-size meaning, and the gap/gate placement behavior that the schema alone does not convey. However, it does not state whether this mutates existing blocks, what y defaults to, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the core shape and center/half specification before adding optional gap details. The parenthetical coordinate mapping is compact but slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no annotations, and no output schema, this description is insufficient for reliable invocation. The required piece parameter is undefined, vertical positioning via y is absent, and return/error behavior is not mentioned. Build side effects like overwriting existing walls are also not covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains cx, cz, half, gapSide with direction mapping, gapWidth, and mentions gate, but it leaves the required piece parameter and the y parameter undocumented. This is meaningful but partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies a square ring of walls centered on (cx, cz), with half-size semantics and optional gap behavior. It is distinct from siblings like wall_run or perimeter_check in shape, though it does not explicitly name which sibling it competes with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided; the agent is not told when to prefer ring over wall_run, perimeter_check, stack, or other building tools. The only usage cue is the implied geometry, with no exclusions or alternative routing.
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?
No annotations exist, so the description carries the full disclosure burden. It does disclose that adoption is the default behavior and that adopt=false suppresses it, but it fails to reveal the likely destructive consequence — adopting a new plan presumably replaces the current working plan. It also says nothing about remote fetching, sharing requirements, or what a non-adopting import actually does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One tightly packed sentence with no filler. The example URL earns its place by pinning down the accepted input format precisely, and the primary action plus the parameter exception are both front-loaded. Every part contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the missing details are material: what happens to the current working plan when adopting (overwrite vs replace), what adopt=false actually accomplishes, and any prerequisites such as the base being public/shared. An agent can invoke the tool but cannot predict its side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It documents idOrUrl well by giving a concrete example URL, and it states adopt's default (true) plus its exception behavior. However, the meaning of adopt=false remains ambiguous — whether the base is still opened for inspection and what effect that has — leaving a real semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Open') and resource ('another player's hub base') and spells out the outcome ('adopt it as the working plan unless adopt=false'). The 'another player's' qualifier hints at how this differs from the plan_* siblings, but no sibling is named or explicitly contrasted, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied — call this when you have another player's hub id/URL and want it as your plan — but there is no explicit when-to-use vs when-not-to-use guidance or comparison to siblings like plan_new, plan_load, or plan_save. The adopt flag hints at a behavioral fork but doesn't say when one would want adopt=false.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Undo the last edit.' It does not disclose whether the operation is destructive, whether it can be reversed with redo, what counts as an 'edit', how undo history behaves, or what happens when there is nothing to undo.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler or redundancy. It is immediately readable and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description provides the essential idea, but it leaves important operational context unstated: undo history depth, reversibility, behavior when no edit exists, and its relationship to the sibling 'redo' tool. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the input schema is empty, so the baseline is 4. There are no parameter details for the description to clarify, and nothing here is missing or misleading in terms of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Undo') and the target ('the last edit'), making the core purpose immediately understandable. However, it does not differentiate from sibling tools such as 'redo' or 'remove', so an agent must infer the boundary from the tool name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention 'redo' as the inverse operation, nor does it state any prerequisites, limits, or conditions under which undo is appropriate.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It identifies the action and some effects ('toggles,' 'cycle'), but does not specify return values, whether the builder must be open/focused, whether key presses are asynchronous, or whether toggles persist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with parenthetical examples and no filler. Every word contributes to defining the action and key inputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema, no parameter descriptions, and no annotations, the description should provide more detail. It covers common key examples but does not enumerate all valid keys or state preconditions like having the builder open and focused.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema gives only a 'key' string with no description or enums (0% coverage), so the description must compensate. It adds useful examples such as camera 1-4, F, Tab, Z/V, but these are illustrative rather than an exact or exhaustive list, leaving ambiguity about accepted syntax and case sensitivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Press a key in the builder.' The parenthetical examples (camera 1-4, F frame, Tab cycle, Z/V toggles) make the tool's scope concrete and distinguish it from sibling browser_* tools like browser_open, browser_screenshot, or browser_readback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, nor any exclusions or prerequisites. The only context is 'in the builder,' which is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It lists what the tool returns, which implies a read-only status query, but it does not explicitly state that it has no side effects or what happens when no current plan exists. This is acceptable for a simple no-parameter status tool but not fully 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and the key content categories are front-loaded. It is slightly fragmentary as a bare noun phrase, but it remains appropriately sized for a simple status tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has no parameters, and no output schema, yet the description still leaves some gaps: it does not clarify how 'current plan' is determined or whether a plan must be loaded first. It is minimally sufficient for an agent to invoke, but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters and 100% schema description coverage, so the description is not required to document parameters. The baseline of 4 for zero-parameter tools applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('the current plan') and the specific categories of information returned: summary, supply cost, breakdown, and validation issues. It is distinguishable from sibling tools like plan_list and plan_new, though it lacks an explicit verb like 'get' or 'view'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as plan_list, plan_load, or plan_pieces. The phrase 'for the current plan' implies context but there are no explicit prerequisites, exclusions, or routing cues.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the operation sets absolute position/yaw and supports partial specification, but it does not explain the coordinate frame, units for yaw, whether omitted values are preserved or reset, prerequisites, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the core action and the optionality of position/yaw efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no output schema, and no annotations, this description is too thin. An agent lacks essential context such as coordinate system, yaw units, required key semantics, expected response, and error behavior, making correct invocation uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only loosely maps x/y/z to position and yaw to yaw. It does not clarify the meaning of the required 'key' parameter, numeric ranges, units, defaults, or how partial updates behave when some position fields are omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('a piece'), and specifies the exact properties being modified: absolute position and yaw. The word 'absolute' differentiates it from relative movement tools such as 'move', making the tool's purpose clear without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The term 'absolute position' implies this tool is for setting exact coordinates rather than moving relative to the current pose, and the 'and/or' suggests partial updates are allowed. However, it does not explicitly state when to prefer this tool over sibling tools like 'move', nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does provide useful behavioral context: the stack is placed on the top socket and respects the stack limit. However, it does not say what happens when the limit is reached, whether a negative count is allowed, or what occurs if the key is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and resource, with the placement detail and stack-limit behavior in a parenthetical. Every clause earns its place and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and no annotations, the description covers the happy path but leaves important gaps: default count behavior, limit-violation behavior, and error semantics. It is adequate for basic invocation but not fully complete for robust agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does: 'piece key' identifies the target and 'count more copies' suggests count is the number of copies to add. But it does not clarify the default when 'count' is omitted, nor whether negative values are meaningful, leaving ambiguity despite the schema's numeric bounds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Stack'), the target resource ('piece key'), and the manner ('using its top socket'). It is specific enough that an agent can distinguish it from generic placement tools like 'place' or 'move', though it does not explicitly name any sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as 'place', 'remove', or 'set_pose'. The description implies the intended use case (stacking onto an existing piece) but provides no explicit exclusions or conditions for choosing this tool over a sibling.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does convey the core behavior of adopting the builder's plan and capturing hand edits, but it does not state whether this overwrites the current working plan, whether it is destructive, what it returns, or whether it affects the builder's state. For a state-synchronizing operation, these are material gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence delivers the core meaning, with the clarifying parenthetical adding the crucial context about hand edits. There is no filler or redundancy, and the primary action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema and no annotations, the description adequately states the main operation and rationale. However, it leaves undefined terms like 'builder' and 'window', and it does not clarify the relationship to sibling tools such as browser_push or browser_readback, so an agent may still be unsure about exact behavior and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter details. The baseline of 4 applies because there is no parameter documentation burden to satisfy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Adopt') and resource ('the working plan') and identifies the source (what the builder currently holds). It also adds the key purpose 'captures hand edits made in the window', which differentiates this pull-style tool from push-style siblings. The jargon 'builder' and 'window' is somewhat undefined, but the direction and intent are discernible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you want to bring the builder's current plan into the working plan, especially after manual window edits. However, it provides no explicit guidance about when not to use it or how it compares to siblings like browser_push or browser_readback.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool renders and reads back, but it does not disclose side effects, whether this changes builder state, whether it requires an already-open browser, or what happens on failure. The term 'push' suggests some state change, but the description does not clarify its impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the main action and conveys both the input mode and the output purpose. There is no redundant or filler wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no annotations or output schema, the description covers the basic call intent and parameter meaning. However, it lacks important context about return value shape, preconditions, browser state requirements, and how this differs from nearby browser_* siblings, leaving notable gaps for an agent deciding when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema offers no description for the optional 'code' parameter, and schema description coverage is 0%. The description compensates by explaining that code is an alternative to the current plan, which is the key semantic needed to use the parameter correctly. It does not specify format or accepted values, but for a single optional string this is largely sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: render the current plan or a given code in the builder and read back the site's manifest. It identifies the resource (builder manifest) and the verb ('render'), making the core purpose understandable. However, it does not explicitly differentiate this tool from sibling browser tools like browser_readback or browser_pull, which may also involve reading back site data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you want to render either the current plan or supplied code and obtain the resulting manifest. It gives context by mentioning the builder and the two input modes, but it does not provide explicit guidance on when to choose this tool over alternatives such as browser_readback or browser_screenshot.
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 provided, the description carries the full burden of behavioral disclosure. It does state the destructive scope clearly: either all pieces or all pieces of one id. However, it does not disclose side effects such as irreversibility, whether the operation can be undone, or whether it affects the current plan versus a broader workspace.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the primary behavior and uses the 'or' structure to efficiently convey both invocation modes. The phrasing is slightly awkward, but every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description is minimally adequate. It explains the core behavior and the optional parameter semantics, but it leaves ambiguity about the containing context (e.g., current plan vs. entire workspace) and about edge cases such as invalid or unknown piece ids.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single undocumented string parameter 'piece' with 0% coverage, so the description must compensate. The phrase 'every piece of one id' clarifies that 'piece' is an identifier and that omitting it likely means all pieces. It does not provide the expected format of the id or examples, but for a single optional parameter this is reasonable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Remove') and a clear resource ('every piece') with an explicit scope qualifier ('or every piece of one id'). It distinguishes itself from the sibling tool 'remove' by emphasizing removal of multiple/all pieces rather than one. It could be stronger by naming the sibling or stating the containing context, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'or' phrasing implies two distinct usage modes: one for removing everything and one for removing all pieces matching an id. However, it does not explicitly state when to prefer remove_all over the sibling 'remove' tool, nor does it mention any exclusions or prerequisites. Usage guidance is therefore present but mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It usefully discloses the 60 m spatial constraint and the default-to-origin behavior. However, it does not state whether placing the FOB overwrites an existing one, how coordinates relate to the world, or what response/effect to expect, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loads the core action, and every sentence adds useful information. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple placement tool, the description conveys the essential placement action, the 60 m constraint, and the default origin. However, the lack of parameter semantics and mutation consequences means an agent still has to infer important details like yaw orientation and whether repeated calls replace the existing FOB. No output schema further increases the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only says 'Defaults to the origin.' It does not explain what x, z, and yaw individually mean, their units, or how they interact with the 60 m square. This is a significant gap for a 3-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Place the Forward Operating Base.' It also adds a distinguishing constraint (the 60 m square) and the default origin behavior. It does not explicitly differentiate itself from the generic 'place' sibling, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sentence 'Everything else must sit inside its 60 m square' gives clear contextual guidance: the FOB must be placed before other items and positioned so that the rest of the build fits. It does not explicitly name alternatives or exclusion conditions, but the intended usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'List' implies a read-only operation, which is transparent, but the description does not disclose ordering, error behavior, return format, or whether it includes details beyond names. Adequate for a simple list, but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence with no wasted words. It is front-loaded with the action ('List') and directly communicates the operation and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no nested objects, no output schema), the description covers the essential invocation need. It could be improved by stating the output shape, but for a zero-argument list operation the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description is not required to explain parameters. The baseline for no parameters is 4, and the description does not conflict with or misrepresent the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List saved plans in plans/' provides a specific verb ('List'), a clear resource ('saved plans'), and a location ('plans/'). It conveys the core operation and distinguishes it from mutation tools like plan_new or plan_save, though it does not explicitly name alternative siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus siblings like plan_status, plan_pieces, or plan_load. There are no conditions, exclusions, or alternative recommendations, leaving the decision entirely to inference.
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?
With no annotations, the description carries full behavioral burden. It only names the operation and its target; it does not disclose side effects, failure modes when the redo stack is empty, or whether state is persisted. This is a notable gap for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word contributes meaning, and the length is appropriate for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a very simple zero-parameter tool, the core behavior is fully described. Minor omissions such as redo-stack edge cases mean it is not perfect, but no critical invocation detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so there is no parameter information for the description to add. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Redo') applied to a specific resource ('the last undone edit'). It is unambiguous and distinct from siblings like undo, though it does not explicitly name or contrast the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'last undone edit' implies the tool should be used after an undo operation, but the description never explicitly says when to choose redo over undo or what happens if there is nothing to redo. Usage context 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 burden and it does disclose important behaviors: default socket snapping, snapRadius for choosing a socket, snap=false for free placement, and parent limiting snapping to one piece key. It doesn't state return values or confirm that the action mutates state, but the core placement mechanics are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-load the core action and then add only the snapping behavior that changes how the tool should be called. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no annotations and no output schema, the description covers the main mechanics but omits useful context such as valid piece keys, default snapRadius, coordinate conventions, return/result information, and how this differs from nearby placement tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate; it explains x, z, yaw (degrees), optional y, snap, snapRadius, and parent. 'piece' is only implied by 'one piece' and parent's phrasing is cryptic, keeping this just below a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('Place one piece at (x,z)') and the resource being acted on, and it covers the core placement parameters. It doesn't explicitly contrast with placement-related siblings such as place_fob or stack, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how snapping works and that snap=false enables free placement, but it gives no explicit guidance on when to use this tool versus alternatives like place_fob, stack, or move. There are no exclusions or conditions that route the agent to the right sibling.
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?
No annotations are provided, so the description must carry the full behavioral burden. It states the action but does not disclose whether closing the window destroys session state, whether the operation is idempotent, or what happens if no browser window is open.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single seven-word sentence with no filler, and it leads directly with the action verb and target. Every word earns its place for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema close operation, the description captures the essential operational meaning: what the tool does and what it acts on. Minor gaps such as edge-case behavior when no browser is open or return-value details would be helpful but are not critical at this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is complete, so there is no parameter surface requiring extra documentation. The description correctly avoids inventing parameter details that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('close') and identifies a distinct resource ('the MCP's browser window'), clearly distinguishing it from browser_* siblings that open, push, pull, readback, screenshot, or send keys. There is no ambiguity about what action this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: use this when you want to close the MCP's browser window. However, the description gives no explicit guidance about preconditions, when not to use it, or relationships to alternatives like browser_open.
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 provided, the description carries the full behavioral burden. It discloses the file output path and camera preset behavior, which is helpful. However, it does not explain whether the screenshot is saved automatically, whether the file is overwritten, or what happens if no name/camera is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The primary action and output location are front-loaded, and the camera parameter behavior is explained efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with two optional parameters and no output schema, the description covers the core action, output location, and parameter meanings. Minor gaps remain around preconditions and default camera behavior, but the tool is sufficiently described for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does explain 'camera' as 1..4 presets or 'f' to frame the base, and it shows that 'name' is used in the output filename. This adds meaningful semantic context beyond the bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Screenshot the builder window', plus an exact output destination ('plans/<name>-<time>.png'). This clearly distinguishes it from sibling browser tools such as browser_open, browser_close, and browser_readback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly say when to use this tool versus alternatives, nor does it mention any preconditions (e.g., browser open or builder loaded). The behavior is implied by the name, but there is no guidance about when a screenshot is appropriate or when another browser tool should be used.
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 full burden of behavioral disclosure. It implies a read-only, informational tool via 'read this' and 'standing ruleset', and it lists what content is covered. It does not explicitly state side-effect-free behavior or the output format, but it gives enough context for a zero-parameter reference 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one that front-loads the resource type and lists its contents, and one that tells the reader when to use it. The long enumerative list is somewhat dense but each item adds useful information; no redundant or filler sentences are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description adequately covers what the tool contains and when to use it. It does not explicitly state the return format or that it is a non-mutating read, but for a simple reference tool this is a minor omission and unlikely to confound an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain any parameter semantics and appropriately focuses on content and usage instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 'the standing WARDOGS base-building ruleset' and enumerates its specific topics, making its purpose evident. However, it lacks an explicit action verb like 'retrieve' or 'display', relying on 'Read this' to imply the tool returns the rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Read this before planning a base' explicitly tells the agent when to use this tool, providing clear context for its primary use case. It does not mention exclusions or alternatives, but for a foundational reference tool this guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it explains the placement geometry, socket-pitch spacing, count override, and skip behavior. It does not disclose side effects such as interaction with existing walls or the default y-level, but the core construction behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry all of the essential placement geometry and parameter nuance with no filler. The core operation is front-loaded and the override/gap behavior is provided as a clearly separated second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a straightforward construction command but omits some context an agent might need: the default y/height, whether existing pieces are affected, how the default count is derived, and what happens after the run is created. These gaps are not covered by annotations or an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does for the most important parameters: x1/z1/x2/z2 form endpoints, piece is the 'one piece type', count overrides computed count, and skip leaves gaps. The optional y parameter is not explained, which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a straight run of one piece type between coordinate endpoints at socket pitch with the long axis along the run, which is a specific and meaningful operation. It is clear, but it stops short of explicitly naming alternatives such as ring or stack, so differentiation from siblings is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used for straight runs ('Straight run... long axis along the run') and hints that skip creates gaps, but it gives no explicit when-to-use vs when-not-to-use guidance and does not route the agent to alternatives. Usage context must be inferred from the operation described.
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 full burden of behavior disclosure. It does disclose the returned content areas and the acceptance of flexible identifiers, which adds useful behavioral context. However, it does not explicitly state that the operation is read-only or describe behavior for unknown or ambiguous inputs, so coverage is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the purpose and return contents, then covers input flexibility, which is an efficient and well-ordered structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter query tool with no output schema, the description covers the main things an agent needs: what the tool returns and what to pass in. It could be more complete by noting not-found behavior or confirming read-only semantics, but the low complexity makes this a minor gap rather than a serious one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the required 'piece' parameter, and schema description coverage is 0%, so the description must fully compensate. It does so by explaining that 'piece' accepts an id, label, or loose name and gives a concrete example ('hesco small'), making the parameter semantics clear and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns full data for one piece and enumerates the contained information: boxes, socket positions and kinds. It does not explicitly name a sibling or contrast itself with list_buildables, but 'one piece' versus listing all buildables is a meaningful implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this tool is for retrieving full data about a single buildable and that the identifier can be an id, label, or loose name. It does not explicitly state when to prefer this over sibling tools like list_buildables, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It openly states that the tool requires a Discord sign-in, opens a dialog, and depends on the user to complete a captcha and click Save — making the interactive, non-deterministic nature clear. It does not mention failure modes or what happens on cancel, but the main behavioral traits are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The primary action is front-loaded, and the important user-interaction requirement follows immediately in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the essential context: the target action, the required user authentication, and the interactive final step. It does not describe timeout or cancellation behavior, but those are minor gaps given the simplicity and the clear interactive caveat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining parameter semantics. It only says 'name and notes filled,' which maps the two params to dialog fields but adds little beyond their names. It does not clarify that name is required while notes are optional, and the phrasing could even imply both are mandatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it pushes the current plan and opens the site's save dialog with prefilled fields. It is clearly distinguishable from sibling tools like plan_save or hub_import because it names the exact interaction with the hub site's save UI.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when you want to push the current plan to the site and save it. However, it does not explicitly contrast this with alternatives like plan_save, and it does not state when not to use it or what prerequisites must hold beyond the Discord sign-in requirement.
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 provided, so the description must carry the transparency burden. It discloses the external network source and the 7-day cache policy, adding useful behavioral context. However, it does not mention potential latency, failure modes, or the effect on the local dataset, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no filler. The action and resource are front-loaded, and the cache qualification is kept as an effective parenthetical. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter refresh tool with no output schema, the description provides the essential context: what is refreshed, from where, and cache duration. It does not describe return values or errors, but for a simple refresh operation this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to document. The description correctly focuses on tool behavior rather than input syntax, meeting the baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action 'Re-extract' on a specific resource, the 'buildables dataset', with a clear source ('wardogs.zone'). This distinguishes it from sibling read tools like list_buildables and describe_buildable, which consume the dataset rather than refresh it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The cache note ('cached 7 days otherwise') implies this tool is for refreshing stale data, but the description does not explicitly say when to use it instead of list_buildables or describe_buildable. No alternatives are named, so usage guidance is inferred rather than explicit.
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 provided, so the description carries the behavioral disclosure burden. It does communicate that this is a read-only listing operation and specifies returned fields, but it omits details like pagination, ordering, case sensitivity, or what 'pieces' refers to in the broader plan context. Some meaningful behavior is disclosed, but significant details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, purposeful sentences. The main purpose is front-loaded, and the optional filter behavior is stated immediately after, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional string parameter and no output schema, the description is mostly sufficient. It covers the returned fields and filtering semantics. However, it does not explicitly state what 'pieces' are or whether the listing is scoped to the current plan, which an agent may need to infer from the tool name and siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a bare 'filter' string with 0% description coverage. The tool description compensates by explaining that the filter performs substring matching on id or label, which gives the agent the essential semantic meaning needed to invoke it correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('pieces'), and the exact fields returned ('key, position and yaw'). It also distinguishes itself from siblings like plan_list and list_buildables by focusing on pieces rather than plans or buildables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this tool to list pieces, optionally filtered by id or label substring. However, it does not explicitly mention when to choose this over alternatives, nor does it state exclusions or prerequisites. Guidance is adequate but mostly implied.
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 clearly guarantees 'without changing anything', which is a significant behavioral disclosure for a read tool, and it names the exact data areas returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. The verb is front-loaded and every element in the list earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with no output schema, the description names all relevant state categories and the side-effect guarantee. A return-format note would be nice, but it is not essential for invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics for the schema to provide. The description correctly focuses on the read payload rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and enumerates exact resources: manifest, totals, status line, and sign-in state. The 'without changing anything' clause makes its read-only nature explicit and distinguishes it from mutating siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when the agent needs to inspect builder state without side effects, but it does not explicitly state when to choose this tool over sibling read tools like browser_screenshot or data_refresh. No alternatives or exclusions are mentioned.
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?
There are no annotations, so the description must carry behavioral disclosuresn. It does so by explicitly warning that an existingplan of the same name will be overwritten, and by specifying the destination as the writable home folder. Missing return behavior is a minor gap; the destructive side effect is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The primary action is front-loaded, and the overwrite warning earns its place as a crucial behavioral note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter save tool, the description is mostly complete: action, path, and overwrite behavior are all covered. The main omissions are the meaning of notes and the shape of the response, but neither prevents a correct invocation with the required parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description conveys that the required name parameter becomes the filename in plans/<name>.json. However, the optional notes parameter is not described at all, and since the schema has zero property descriptions, the agent gets no guidance about whether notes are saved, appended, or merely metadata.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action, resource, and destination: save the current plan to plans/<name>.json. It clearly differentiates plan_save from siblings like plan_load, plan_new, and plan_list by focusing on the persistence behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you want to persist the current plan to a named file. It does not explicitly mention alternatives or when not to use it, but the save-versus-load role is implied well enough for most use cases.
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 and does well by explaining what the count means and the threshold for a hole/loose end. The verb 'Count' implies a read-only operation, though it does not explicitly state absence of side effects or describe the exact return shape. The description provides more behavioral context than most tool definitions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The action is front-loaded, the result interpretation is given immediately after, and the optional filter is the final sentence. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter diagnostic tool with no output schema, the description provides the essential semantics: what is counted, how to interpret counts, and the optional filter. It does not specify what happens when no pieces match or how results are ordered, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare 'piece' string property with 0% coverage, so the description must compensate. It does so by stating 'Optional filter by piece id,' giving the parameter meaning and usage. It leaves some ambiguity about id format or multiple ids, but the core semantics are clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Count open side sockets per wall piece.' It then defines the meaning of the result (2 = sealed, 3+ = hole/loose end), which makes the tool's diagnostic purpose unmistakable. It clearly distinguishes itself from building/placing siblings like wall_run or ring by focusing on checking, not creating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys when this tool is useful: to verify a wall is sealed by checking socket counts. It explains the interpretation of values (2 vs 3+), so an agent knows what outcome indicates a problem. It does not explicitly name alternatives or exclusions, but the use case is strongly implied.
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 discloses a significant side effect (a few hundred MB download on first use) and an authentication prerequisite (Discord sign-in for hub_save). It does not detail all possible behaviors, but for a 0-parameter browser open action it is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences. The first front-loads the action and resource; the second packs two important behavioral caveats. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, zero-parameter tool with no output schema, the description is complete. It explains what the tool does, its side effects, and an authentication prerequisite connected to a sibling tool. Nothing essential for an agent to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter semantics, but none are needed; the schema already fully covers an empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Open (or focus)') and a specific resource ('the builder in the MCP's own Chromium window'). The verb-plus-resource pairing clearly distinguishes it from sibling browser_close and other browser operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when it matters: the first use downloads Chromium, and a one-time Discord sign-in enables hub_save. It does not explicitly list exclusions or alternatives, but the zero-parameter scope and 'or focus' phrasing make the intended usage context reasonably 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 carries the full burden of behavioral disclosure. It states the output content (id, cost, hp, c4, stack limit, footprint) and the filter options, so an agent knows what to expect. It does not mention edge behaviors like exact-match filtering or ordering, but 'List' clearly conveys a non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and output fields, followed by filter instructions. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter and no output schema, the description fully covers what is returned and what filter options exist. It names the return fields and the valid kinds, making the tool callable without further research.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only declares 'kind' as a string with no description, so schema coverage is 0%. The description compensates fully by enumerating the allowed kind values, making the parameter's meaning and options explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'List placeable pieces with id, cost, hp, c4, stack limit and footprint.' It clearly differentiates from the sibling describe_buildable by indicating a plural listing of pieces with specific fields, versus a singular detailed inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for use: listing all buildables or filtering by a kind value. It names valid kinds ('core, fortification, defence, support, vehicle, structure'), enabling selection. It does not explicitly mention alternatives, which prevents a 5, but the context is unambiguous.
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:

[![wardogs-mcp MCP server](https://glama.ai/mcp/servers/MudcrabWarrior/wardogs-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MudcrabWarrior/wardogs-mcp)

Score Badge

Copy to your README.md:

[![wardogs-mcp MCP server](https://glama.ai/mcp/servers/MudcrabWarrior/wardogs-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MudcrabWarrior/wardogs-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MudcrabWarrior/wardogs-mcp'

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