MeWeApps Deep-Tech Scanners

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds the useful detail of which compliance areas are audited. However it never says what the result looks like (per-field findings, pass/fail, severity) and never explains that a URL mode performs a remote fetch, which sits in mild tension with openWorldHint=false. Adds value, but leaves the agent guessing about output behavior.

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?

Two sentences, front-loaded with the action and followed by the regulatory context that justifies it; there is no filler. The second sentence is borderline but earns its place by telling the agent who is in scope and from when, which supports the required 'category' argument.

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?

With no output schema and 5 parameters at 40% coverage, the description should carry more weight than it does: it never describes the response shape of a 'check' or clarifies the optional 'model' field. It is adequate for choosing the tool but thin for interpreting results, so a 3 is appropriate.

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 coverage is only 40%, so the description must compensate; it does so for 'json', 'url' and implicitly 'mode' by naming the two input styles, and for 'category' via the EV/LMT/industrial scope sentence. The 'model' parameter is left completely unexplained in both schema and description, so the compensation is partial rather than complete.

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?

States a specific verb and resource ('Check an EU battery passport') and anchors it to a named regulation, Regulation (EU) 2023/1542. It then enumerates the exact dimensions checked (scope, unique identifier, Annex XIII public fields, restricted-data exposure, state-of-health, carbon footprint), which is far more specific than any sibling tool and makes selection unambiguous.

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 gives clear input-shape guidance ('pasted JSON or a passport/QR resolver URL') and a scoping cue in the deadline sentence, which implies the check matters for EV, LMT and >2 kWh industrial batteries. It stops short of explicit when-not-to-use guidance or naming an alternative path (e.g. what to do for portable or SLI passports), so it falls just under a 5.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real substance by enumerating the exact evidence classes (security.txt directives, CVD policy, CSAF, SBOM, support period) that define a "readiness" result. It does not explain what happens when a domain exposes none of these (empty result vs. failed checks), nor what the response shape looks like. The declared openWorldHint=false also sits in mild tension with a tool that inspects arbitrary external domains, though the description itself is not the cause of that inconsistency.

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?

One sentence, purpose front-loaded before the colon, and every item in the list is a distinct check the agent can reason about. Nothing is padded or repeated from the title.

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 single-parameter, read-only scan with no output schema, the description covers what is inspected and against which two regulations, which is what an agent needs to select the tool. The remaining gap is that it never indicates the shape or granularity of findings (pass/fail per artifact vs. raw extracted records), so output must be discovered at call time.

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?

There is a single required parameter and schema description coverage is 100%, so the schema already carries the burden. The description adds only the framing that the domain is a *vendor* domain under regulatory assessment, not any format, normalization, or subdomain-handling guidance. Baseline 3 is appropriate.

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?

Names a specific verb ("Scan") and resource ("vendor domain") and scopes it to two named regulatory regimes (EU CRA, UK PSTI), then enumerates the concrete artifacts examined (RFC 9116 security.txt fields, CVD policy, CSAF provider metadata, SBOM, support-period statements). None of the sibling tools overlap, so no disambiguation is needed and an agent can tell exactly what this returns evidence about.

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 "vendor domain" implies the intended scenario (assessing a supplier's disclosure readiness), but there is no explicit when-to-use, when-not-to-use, or routing to an alternative tool. It also doesn't state prerequisites such as the domain needing to be publicly reachable. Usage is inferable but not guided.

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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real substance: what signals are extracted (SBTi, ISO 14001, B Corp, reports), what site-level measurements are taken (green hosting, carbon.txt, page weight, CO2 per view), and the regulatory basis with an effective date. It stops short of disclosing scan depth limits (e.g., JS-rendered pages, crawl scope, caching) — a notable gap for a web-reading tool — and the 'read a website' framing sits somewhat uneasily with openWorldHint=false, though this does not rise to a direct contradiction.

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?

One front-loaded sentence that opens with the action and resource before layering on legal frameworks and measurement details. It is dense with parentheticals but every clause carries distinct information, with no filler or restatement of the tool name.

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?

With no output schema, the description usefully sketches the three result categories an agent should expect, which is the main thing it must supply. For a read-only, single-parameter tool this is close to complete; only the response shape and scan-coverage limits are left implicit.

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 100% for the single parameter ('Domain, e.g. example.com'), so the schema carries the semantics and baseline 3 applies. The description adds only the implicit notion that the domain is a company website; it does not clarify whether to pass a bare domain vs URL, or how subdomains/paths are handled.

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?

States a specific verb and resource ('Read a company website for environmental claims and greenwashing risk') and names the exact regulatory lenses (EU Directive 2024/825, UK CMA Green Claims Code) plus the three output classes: claims, evidence/credentials, and site footprint. No sibling tool (cra_disclosure_scan, battery_passport_check, etc.) overlaps this scope, so an agent can select it unambiguously.

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?

Usage is implied by the regulatory framing and the single required domain argument, so the agent can infer it is for greenwashing/sustainability due-diligence on a company site. However, there is no explicit when-to-use/when-not-to-use statement, no mention of prerequisites (e.g., public site accessibility), and no routing to any alternative tool for adjacent regulatory scans.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds that the assessment is benchmarked against fixed published standards, implying deterministic rule-based evaluation rather than open-ended judgement. It does not disclose what the check produces (pass/fail per criterion, gaps list, severity) which matters because there is no output schema.

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?

Two dense sentences with no filler, front-loaded with the tool's purpose and followed by the accepted inputs. The regulatory citations are long but each carries real selection value; only the input list feels slightly tacked on rather than integrated.

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 nine-parameter domain tool with no output schema and thin schema descriptions, the definition covers the regulatory scope and the main numeric inputs but leaves the preset mechanism, shape semantics, and the shape of the returned assessment unexplained. An agent could invoke it, but not predict or interpret the result confidently.

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 only 33%, so the description must compensate, and it partly does: it clarifies that d10/d50/d90 are particle size in nm, that ssa is BET surface area, and that sdsText is optional. It adds nothing about the 'preset' enum (seven material presets that presumably fill defaults), 'shape', or how materialName drives the lookup, leaving several parameters undocumented in both places.

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 a specific verb ("Check") and a precisely scoped resource: a nanomaterial against three named regimes (2022/C 229/01 EU definition, REACH Annex II / Regulation 2020/878 SDS nanoform requirements, ISO/TR 13014 characterisation coverage). That is far more specific than the sibling '*_check' tools, although it never explicitly distinguishes itself from regulatory neighbours like cra_disclosure_scan or battery_passport_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?

There is no when-to-use / when-not-to-use guidance, no statement of prerequisites (e.g. that materialName alone yields a partial result, or that SDS text is needed for the SDS section to be meaningful), and no mention of alternatives or downstream steps. Only the closing clause about accepted inputs implies the intended calling context.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true; the description adds useful context by confirming URL input (consistent with open-world network access) and disclosing that output includes a readiness score and Article 50 transparency notes. It does not cover failure behavior for malformed specs or fetch errors, which keeps it below a 5.

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?

One dense sentence with the action, accepted inputs, and outputs front-loaded; no filler or redundancy.

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 one-parameter tool with no output schema, the description covers input forms and the nature of the returned artifacts adequately. It leaves the exact output structure and error handling unspecified, which is a modest gap given the tool's simplicity.

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 coverage is 0% and the single parameter is an undescribed string, so the description carries the full burden — and it does, enumerating the accepted forms (JSON/YAML text, URL, or cURL command). It stops short of stating format detection rules or size constraints.

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 a specific verb (Convert) and precise resources (OpenAPI/Swagger spec, cURL command) and states the produced artifacts (MCP tool definitions, readiness score, EU AI Act Article 50 notes). Sibling tools are unrelated compliance/validation utilities, so no differentiation is needed.

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?

Usage is implied by the accepted input types (spec text, URL, or cURL), but there is no explicit when-to-use or when-not-to-use guidance, nor any stated prerequisites such as spec size limits or validity requirements. With no competing sibling, the gap is minor but real.

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?

The annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description is consistent with them by calling this a "live" handshake test. Beyond that, it discloses that the tool returns a 0-100 readiness score, Harvest-Now-Decrypt-Later risk, and findings, which an agent could not infer from the structured fields. It does not mention timeouts, rate limits, or whether redirects/SNI mismatches are followed, which leaves a modest 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?

One dense but disciplined sentence: verb and resource first, then the checks performed, then the return values. Every clause maps to either a check the tool runs or an output it produces, with no filler.

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?

With no output schema, the description carries the burden of describing returns, and it does so adequately by naming the score, risk rating, and findings. For a one-parameter read-only scan this is close to complete; only minor operational details (timeouts, handling of non-resolving hosts) are absent.

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 coverage is 100% for the single parameter, so the schema already documents the domain/host:port format. The description adds meaning beyond the schema by constraining the target to a public domain, implying resolvability and external reachability requirements. That is a genuine semantic constraint not encoded in 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 gives a specific verb and resource ("Live TLS handshake test of a public domain") and then enumerates the concrete checks (X25519MLKEM768/SecP256r1MLKEM768 hybrid key exchange, TLS 1.3/1.2, legacy downgrade, certificate key, HSTS). This is unmistakable against the sibling tools, none of which touch TLS at all.

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 "of a public domain" implicitly conveys the precondition that the target must be publicly reachable, which is real usage guidance. However, there is no explicit when-to-use/when-not guidance, no statement about internal or unresolvable hosts, and no named alternative. The 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and locality are covered structurally. The description adds real value beyond that by flagging the analysis as 'heuristic' and bounding its claims (no genome-wide off-target search), which sets expectations about false negatives. It does not disclose what the result looks like, whether findings are pass/fail or scored, or how the input format is detected, so the behavioral picture remains partial.

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?

One dense sentence plus a one-clause caveat, front-loaded with the operative phrase 'Heuristic QC'. The parenthetical groupings map cleanly onto the three input families and earn their space. Slightly over-packed — three domains and six checks in a single sentence demands a second read.

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 two parameters, no output schema, and a readOnly annotation, the description covers what is checked for each input type and one important scope limit. It is still silent on output shape, severity thresholds, and input auto-detection, all of which matter for a tool that accepts four different formats through one string field. Adequate but with clear gaps.

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 coverage is 50%: 'input' is documented in the schema, but 'nuclease' is a bare enum. The description partially compensates by naming SpCas9/SaCas9/Cas12a in the PAM-check parenthetical, which implies the parameter selects which PAM rule set is applied. It still does not state the default when 'nuclease' is omitted, nor how the tool decides which of the four input formats it received — the most consequential ambiguity for a single free-text 'input' field.

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?

Uses a specific verb-plus-resource framing ('Heuristic QC for CRISPR guide RNAs... FASTA sequences... HL7 v2 headers or sample manifests') and enumerates the concrete checks (GC%, PAM, poly-T, homopolymers, seed checks). The scope is unambiguous, though the multi-modal grab-bag of three unrelated input families makes the tool's single purpose slightly diffuse. No sibling differentiation is offered, but the siblings listed (battery_passport_check, pqc_tls_scan, urdf_validate, etc.) share no domain, so disambiguation is not needed here.

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 one explicit when-not ('Not a substitute for genome-wide off-target search'), which is genuinely useful for routing. However, there is no positive when-to-use guidance, no statement of what the tool assumes about input, and no explanation of how to choose between the guide/FASTA/HL7 modes. Usage is implied by the input listing rather than stated.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description usefully adds what is actually checked (structure, joint limits, inertia plausibility, collision geometry), which tells the agent how thorough the validation is. It still omits behavior beyond that: how findings are reported, whether validation is strict or heuristic, and whether generation produces a full URDF versus a skeleton. Generation under readOnlyHint is not a contradiction, since it does not mutate external state.

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?

One sentence, front-loaded with the primary verb, and the parenthetical list of check categories earns its space by conveying validation depth. No filler or restated title.

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?

There is no output schema, so the description carries the burden of explaining what comes back from a validation call — a pass/fail flag, a list of diagnostics with locations, severity levels — and it says nothing about this. It also leaves the mutual exclusivity and required-ness of the two zero-required parameters unexplained. For a tool with two distinct modes and no output schema, these are material gaps.

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 100%, so both parameters are already documented as 'Natural-language robot spec' and 'URDF XML to validate'. The description adds only the mode mapping between the two, and it does so implicitly through the example spec rather than stating that exactly one parameter should be provided. Baseline 3 is appropriate.

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 a specific verb+resource (validate a URDF robot description) and enumerates concrete check categories — structure, joint limits, inertia plausibility, collision geometry — plus a second generation mode. It is clear what the tool does, though the dual purpose sits awkwardly against the tool name 'urdf_validate', which suggests validation only; an agent scanning names might miss the generation capability.

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?

Usage is only implied: the description pairs validation with a URDF and generation with a natural-language spec ('6-DOF arm with parallel gripper'), which hints at which parameter drives which mode. It never states that the two parameters are alternatives, what happens if both or neither are supplied, or any prerequisites. The sibling tools are unrelated domains, so no alternative-routing guidance is needed.

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