codecheck

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

With no annotations, the description carries the full burden of behavioral disclosure, and it delivers: it states side effects (writes current.json, report.md, screenshots/), where output goes by default (CODECHECK_REPORTS_DIR), and that a dead criticalSelector counts as critical. It doesn't mention auth, rate limits, or crawling cost, but the core behavioral contract is disclosed.

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

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

Each sentence earns its place: the purpose appears in the first clause, then a compact per-parameter mapping, then a short output summary. No filler, no restatement of schema details, and the most important scoping information is front-loaded.

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

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

For a web-crawling audit tool, the description covers inputs, side effects, defaults, env-dependent output location, and the return summary. It could add the accepted check-category values and note that the tool may make network requests to the target, but it is otherwise self-contained.

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

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

Schema description coverage is 0%, and the description compensates by explaining every parameter with operationally useful detail: maxPages scopes to same-origin pages, viewports are widths with defaults, checks is categories, criticalSelectors has real semantics, and outputDir defines file outputs. Without this, an agent would only have names and types.

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

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

The description leads with a specific verb and resource ('Audit a web project') and frames it within Build → Audit → Fix → Re-audit, which clearly separates it from the sibling testing tools. The rest of the description reinforces the audit scope without ambiguity.

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

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

The phrase 'for an automated fix loop' implies this belongs in a build/audit/fix cycle, but it never explicitly says when to prefer this over siblings such as full_qa or quick_security, nor when not to use it. The use case is clear, but exclusions and alternatives are left to inference.

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

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

With no annotations supplied, the description carries the full burden of behavioral disclosure. It does disclose the output categories (Fixed, New, Unchanged, and findings not rechecked), which is useful. However, it does not mention side effects, permissions, read-only behavior, or any potential state changes. For a comparison tool, this is not critical, but the lack of explicit safety or side-effect disclosure prevents a higher score.

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

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

The description is two sentences, front-loaded with the purpose and then the key output behavior. Every word earns its place, with no redundancy or filler. This is an appropriate size for the tool's simplicity.

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

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

Given the simple input schema (two required strings), an existing output schema, and the tool's read-only nature implied by comparison, the description covers the essential purpose, parameters, and return categories. It could add a note on prerequisites or limitations, but it is largely complete for an agent to correctly invoke the tool.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by explaining that the two parameters are file paths to current.json and previous.json, giving concrete meaning to the otherwise generic string type. This is helpful, though it could specify path format or usage constraints. Still, it clearly adds value beyond the schema.

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

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

The description states a specific verb ('Compare'), a resource ('two audit_project JSON reports'), and a distinguishing mechanism ('by fingerprint'). This clearly differentiates the tool from the sibling audit/test tools (full_qa, test_interactions, audit_project, etc.) by focusing on comparison rather than execution or testing.

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

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

The description implies the use case: when an agent has two audit_project report files and needs to see differences. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or conditions. The sibling names suggest distinct purposes, but no routing guidance is given.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it only lists coverage areas. It does not state what happens during execution, whether it mutates anything, what the output looks like, how pages are traversed, or what 'light security check' actually entails. This is a meaningful gap for a no-annotation tool.

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

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

The description is a compact, front-loaded single line with no filler. It efficiently communicates the tool's scope, though it is somewhat telegram-style and omits critical parameter context while remaining concise.

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

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

For a tool with no annotations and 0% schema coverage, the description is insufficiently complete. It does not define the target input, explain max_pages, or describe expected behavior. The output schema exists but is not shown, so the agent still lacks the information needed to confidently invoke full_qa.

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

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

Schema description coverage is 0% and the description mentions neither 'target' nor 'max_pages'. The required target parameter is completely unexplained, and max_pages is not connected to the stated QA scope. An agent cannot determine what value to pass without external knowledge.

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

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

The description clearly defines the tool's coverage: buttons, layout at 5 screen widths, fonts, images, and light security checks. This goes beyond the tautological title and intuitively reads as a composite QA sweep. It lacks an explicit verb like 'runs' or 'performs', but the scope is still specific and distinguishable.

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

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

The listed domains map directly to the sibling tools (test_interactions, test_layout, test_fonts, test_images, quick_security), making it clear that full_qa is the all-in-one alternative. However, it does not explicitly say when to prefer a single sibling over full_qa, such as for a focused or faster check.

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

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

With no annotations, the description must fully disclose behavior, but it only lists topics. It does not say whether the tool modifies anything, what it returns, how deep it scans, or whether it is read-only. 'Light security' hints at scope but is not a real behavioral disclosure.

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

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

The description is short and free of filler, but it is closer to a tagline than a structured tool definition. It front-loads the security theme yet omits essential operational details.

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

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

Despite the presence of an output schema, the description is incomplete for a 2-parameter tool with undocumented parameters and no annotations. It fails to clarify the target resource or the meaning of max_pages, and it gives no guidance on invocation context.

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

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

The input schema has 0% description coverage and the description does not mention target or max_pages at all. An agent cannot tell what format target should take or what max_pages controls, so the description adds no semantic value for parameters.

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

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

The description names concrete security concerns—secrets in files and git history, .env exposure, headers, cookies, and mixed content—making it recognizable as a security-check tool. It is distinct from the QA-focused siblings, though it lacks an explicit verb such as 'scan' or 'check'.

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

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

The tool's security scope implies it should be used for security checks rather than the layout/font/image/interaction testing done by siblings. However, it never explicitly states when to choose this tool or when to avoid it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to state whether the tool is read-only or performs mutations, what side effects it may have (e.g., does it crawl pages, take screenshots?), or any operational constraints. The description provides no behavioral transparency beyond the topic list, leaving the agent uninformed about the tool's execution characteristics. There is no contradiction, but the lack of information is a severe gap.

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

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

The description is a single sentence with no filler, which is concise. However, it is overly brief to the point of under-specification, but conciseness itself is fine. The topic list is front-loaded, but the lack of elaboration means it sacrifices clarity for brevity, yet it earns a 4 for effective brevity without redundant text.

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

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

Given the existence of an output schema, the description need not explain return values, but it must explain how to invoke the tool. With 0% schema coverage, the parameters are undocumented, the purpose is vague, and there are no usage guidelines. For a tool with two parameters and no annotations, this is completely inadequate. The description leaves critical information about input semantics and tool behavior undisclosed.

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

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

Schema description coverage is 0%, meaning the schema provides no descriptions for 'target' or 'max_pages'. The tool description does not compensate by explaining what 'target' refers to (e.g., URL, page?) or how 'max_pages' limits the test. Neither parameter is documented anywhere, making it impossible for an agent to know what values to supply. The description adds no semantic meaning.

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

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

The description is a vague list of font-related concerns ('uniformity of families and sizes, unloaded web fonts, heading hierarchy') without a clear verb or explicit statement of what the tool does. It implies testing, but does not say 'tests' or 'checks' directly. It does not distinguish itself from sibling tools like test_layout or test_images, which could overlap in visual testing.

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

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

There is no guidance on when to use this tool versus alternatives. The description only lists font issues, but does not explain the context or conditions under which an agent should invoke it (e.g., when checking typography specifically). The sibling names provide some context but are not referenced. No exclusions or alternatives are mentioned.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It lists what is inspected but does not state whether the tool only reads data, how it navigates pages, what limits apply, or whether any side effects occur. There is no contradiction because annotations are absent.

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

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

The description is extremely concise and front-loads the core idea without filler. However, the brevity comes at the cost of omitting parameter semantics and usage guidance, so it is under-specified rather than efficiently complete.

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

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

An output schema exists, so the return structure is likely covered, but the description leaves parameter meanings, invocation context, and selection criteria unexplained. For a QA tool competing with five siblings, this level of detail is insufficient for confident tool selection and use.

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

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

Schema description coverage is 0% and the description never mentions 'target' or 'max_pages'. 'Target' is ambiguous (URL, directory, or selector?), and 'max_pages' is only documented via its schema default, leaving the agent to infer its meaning and relationship to the tool's behavior.

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

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

The description identifies the resource (images) and a specific set of defect categories: broken, distorted, blurry, heavy, and missing alt. The qualifier 'только измеримое' (only measurable) narrows scope and distinguishes it from broader QA siblings, though it lacks an explicit verb like 'test' or 'check'.

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

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

No guidance is given on when to use this tool versus siblings such as test_layout, test_fonts, or test_interactions. The image-domain cue is implicit, but there are no explicit 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.

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 lists what is checked but not how the tool behaves—whether it clicks, submits forms, navigates pages, or produces side effects. No limits or safety characteristics are disclosed.

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

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

The description is a single compact sentence that packs many concrete test categories without filler. It is efficiently sized, though its brevity comes at the cost of needed behavioral and parameter context.

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

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

The output schema may cover return values, but the input contract is opaque and annotations are absent. For a tool that likely drives browser interactions, the description omits target semantics, pagination behavior, and operational side effects, making it incomplete for correct invocation.

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

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

Schema description coverage is 0%, and the description never mentions target or max_pages. An agent cannot infer whether target is a URL, selector, or element ID, nor how max_pages affects crawling. Neither the schema nor the description compensates for this gap.

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

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

The description enumerates concrete interaction targets—buttons, links, forms, and broken anchors—and specific failure modes like dead, disabled-but-reactive, and overlapped elements. This distinguishes it from the layout/font/image sibling tools by domain, though it does not explicitly name any alternative.

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

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

No guidance is given on when to choose test_interactions versus full_qa or quick_security. There are no prerequisites, exclusions, or context signals indicating when this tool is the right fit, so an agent must infer usage entirely.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only lists what areas the tool inspects. It does not state whether the operation is read-only, how results are returned, whether a browser/page must already be open, or any 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.

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

The description is compact and front-loaded: the layout concerns appear first, then the widths parameter details. It is terse to the point of being skeletal, but it wastes no words.

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

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

Despite having an output schema, the description is not complete enough for reliable invocation: the required target parameter is undefined, and the relationship to sibling tools is unstated. An agent would have to guess what to pass as target and when to prefer this over full_qa.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully explains widths (screen widths in px, with defaults), but says nothing about the required target parameter or max_pages, leaving the most important inputs ambiguous.

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

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

The description identifies the resource (layout) and enumerates specific checks it performs: text overlap, truncated text, horizontal scroll, contrast, small tap targets. This gives an agent a concrete sense of what the tool covers, though it never states an explicit verb like 'tests' and doesn't name sibling tools to forestall confusion with full_qa or test_fonts.

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

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

There is no guidance on when to choose this tool over siblings such as full_qa, test_fonts, or test_interactions. The listed layout issues imply a use case, but the description leaves the selection decision entirely to the agent.

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