clear-line-ops

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

With no annotations, the description carries the full burden; it usefully discloses the cost ('1 credit per call') and the statistical method, which are real behavioral facts. However, it says nothing about validation behavior, error handling, or what a valid call looks like given that zero parameters are required.

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 tight sentences, front-loaded with the primary capability and closing with the cost. Nothing is padded or redundant.

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 6-parameter, zero-required-parameter statistical tool with no output schema and no annotations, the description leaves critical gaps: it never explains which parameter combination triggers the significance test vs the sample-size calculation, so an agent could easily make a nonsensical call.

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%: a_visitors, b_visitors, a_conversions, and b_conversions have no descriptions in either the schema or the description. The text hints at 'visitors per variant' and 'a given lift', but does not explain the conversion counts or how the two modes map onto the six 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 two specific capabilities with the underlying method ('two-proportion z-test') for comparing ad or page variants, and sample-size calculation for a target lift. No sibling tool overlaps this statistical domain, so an agent can identify it instantly.

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?

It implies two usage modes ('compare two variants' vs 'calculate how many visitors...') but never states which parameters select which mode, nor any prerequisites or exclusions. Usage is inferable but not explicit.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses the cost (1 credit per call) and enumerates the policy checks performed, but says nothing about the result shape, whether it is read-only, or what happens when limits are exceeded.

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?

A single front-loaded sentence covering platforms, checks, and cost with almost no waste. The stray 'body text' mention is minor noise but does not bloat the description.

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 check tool with no annotations and no output schema, the description should say what the result looks like (pass/fail, flagged issues per field) and clarify whether all three text types are inputs. What it provides is adequate but leaves the agent guessing about output.

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%, so the description must compensate. It does name the supported platforms (mapping to the enum) and identifies headlines and descriptions as the checked fields, but it omits per-field character limits, the maxItems caps, and even references 'body text' which is not an actual parameter.

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 (check) and resource (headlines, descriptions, body text) plus the full scope: character limits across six named platforms and policy problems. An agent can tell this apart from siblings like ad_metrics or keyword_formatter 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.

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

Usage is implied (validate ad copy before publishing) and the credit cost gives a budgeting cue, but there is no explicit when-to-use, when-not-to-use, or named alternative. Nothing routes the agent away from this tool when it is the wrong choice.

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 and does so richly: it discloses automatic ducking, looping to fit, end fade-out, credit cost (1 per minute of main file), job_id polling via get_job for long jobs, and a 1-hour link expiry. These are exactly the behavioral traits an agent cannot get from structured fields.

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?

Four short sentences, purpose front-loaded, then behavior, cost, and job/expiry handling in that order. Each sentence delivers distinct, necessary information with no padding.

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 six parameters and no output schema, the description supplies everything needed to invoke and follow up correctly: cost model, async job_id path with get_job, and result-link lifetime. Nothing material is missing.

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 already 83% (a 3 baseline), but the description adds effect-level semantics not in the schema: what ducking actually does to the music while speech is present and that the track loops and fades. It does not touch music_volume_db, so it is not a full 5.

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 ('lay a music track under a video or voice recording') with the effect it produces, so the operation is unambiguous. However, it never distinguishes itself from media siblings like merge_media or process_audio, which the rubric reserves for a 5.

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 from 'under a video or voice recording'; the description gives no explicit when-to-use, when-not-to-use, or named alternative among the many media tools. Adequate but leaves routing 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, the description carries the full burden and does well: it discloses permanent burning (destructive to the source framing), credit cost per minute for both modes, asynchronous job behavior with job_id + get_job polling, and 1-hour result-link expiry. It omits auth/permission requirements and what happens to the original video.

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?

Five tight sentences, front-loaded with the core action, then modes, then cost, then async/expiry behavior. No filler; every sentence conveys actionable information.

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 7-param media job with no output schema and no annotations, the description covers cost, async polling and link expiry, which are the main things an agent needs. It stops short of describing the returned artifact or permission needs, but is close to complete.

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 71% and the schema already documents srt, language, color, position and font_size. The description adds only a loose mapping ('style, size and position are adjustable') that largely restates what the schema already conveys, so it adds marginal value.

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 (add/burn) and resource (subtitles/captions into a video) with the key qualifier 'permanently shown on screen'. This clearly distinguishes it from siblings like subtitle_convert (format conversion) and transcribe_media (transcript output).

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?

Explains the two operating modes (auto from speech vs. supply your own SRT) and gives the cost implication of each, plus routing to get_job for polling. However it never explicitly says when to pick this over alternatives like subtitle_convert or edit_video, so there is no when-not guidance.

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 and does well: it discloses cost (1 credit per minute), asynchronous execution with a job_id, the polling tool, and that result links expire in 1 hour. It does not mention auth requirements or what happens if both text and watermark_url are omitted, which keeps it short of 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?

Four short sentences, front-loaded with what the tool does, followed by cost, async handling, and link expiry. Every sentence earns its place with no 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 10-parameter media-mutation tool with no annotations and no output schema, the description covers cost, async behavior, retrieval path, and result longevity. It leaves unstated the edge case of supplying neither text nor watermark_url, a minor gap in an otherwise complete definition.

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 70% and the schema documents most parameters with descriptions, defaults, and ranges. The description only alludes to position/size/opacity at a high level and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 ('Put a logo image and/or a line of text on a video') and enumerates the controllable dimensions (position, size, opacity). This is clearly distinguishable from siblings like add_captions, edit_video, or video_color_grade without opening any schema.

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 explains operational flow (long jobs return a job_id, poll with get_job) but never says when to choose this tool over alternatives such as edit_video or add_captions. Usage is implied by the resource rather than explicitly scoped.

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. It usefully discloses a cost constraint (1 credit per call) and the computed outputs, but says nothing about statelessness, behavior when no inputs are supplied (all 7 params are optional), or error handling. The credit disclosure is genuine added value beyond structured fields.

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 tight sentences, front-loaded with the core compute capability and followed by the projection feature and cost. No filler; every clause carries information.

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 7-parameter calculator with no output schema and no annotations, the description covers the output metric set and the projection behavior well. Remaining gaps are the unmentioned profit_margin_percent input and the all-optional-input edge case, which are modest given the tool's simple deterministic nature.

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 14% (only new_budget is documented), so the description must compensate. It names five of the seven inputs and conveys an important semantic the schema cannot express ('any mix' — all params optional and combinable), but it never mentions profit_margin_percent or which input combinations yield which metrics.

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 computation verb and enumerates the exact metric set (CTR, CPC, CPM, conversion rate, CPA, ROAS, ROI, break-even), plus the projection capability. This clearly separates it from sibling calculators like ab_test_calc or tempo_calculator without needing schema inspection.

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 usage by listing accepted inputs ('from any mix of spend, impressions, clicks, conversions and revenue') and the projection feature, but gives no explicit when-to-use, when-not-to-use, or alternative-tool routing. Usage must be inferred from the metric list.

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. It usefully discloses a per-call cost (1 credit) and the effect of extra payments, but omits return format, validation behavior, and idempotency. Cost is valuable but not complete behavioral transparency.

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

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

Two sentences, front-loaded with the core purpose, then optional feature, then cost. Every element earns its place with zero waste.

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 simple calculator with no output schema, the description should describe return values and parameter details. It only vaguely mentions 'full amortization schedule' and leaves parameter semantics unexplained, though the cost note helps.

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%, so the description must explain parameters. It only implies that extra_monthly affects interest saved and payoff date, but gives no meaning for principal, annual_rate_percent, or years (units, constraints, or expected formats).

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 ('Calculate') and resource ('loan's monthly payment and full amortization schedule'), and includes the optional extra payment feature. No direct sibling tool competes, so the 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.

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 description only says what it does and its cost, leaving the agent to infer that it should be used for any loan amortization request without any exclusion or 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?

With no annotations, the description carries the full burden and does so well: it discloses per-minute cost (1 credit/min), async behavior via job_id, the get_job polling path, and a 1-hour link expiry. These are exactly the non-obvious traits an agent needs before invoking.

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?

Three tight sentences, front-loaded with purpose before cost and job handling. Every sentence adds distinct information 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?

Since there is no output schema, the description usefully sketches the return shape (silence/scene locations, LUFS loudness) and the job lifecycle. It is nearly complete, missing only guidance on the threshold parameters that shape the results.

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 should compensate, and it partially does by clarifying the LUFS unit and the three analysis types mapping to the 'analyses' param. It says nothing about min_silence_seconds or silence_threshold_db, leaving half the 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?

States a specific verb+resource ('Analyse a file') and enumerates the three concrete outputs (silence locations, scene changes, loudness in LUFS). This clearly distinguishes it from siblings like get_media_info (metadata only) and transcribe_media (transcription).

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?

Gives clear intent context ('to cut dead air', 'to chapter or clip a video') and explicitly routes the agent to get_job for polling long jobs. However, it never states when to prefer this over adjacent tools like get_media_info, so the when-not side is absent.

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 and delivers real behavioral detail: output is plain editable HTML/CSS/JS, pages run sandboxed with settings kept in memory only, runs on sample data out of the box, and cost is 2 credits per call. It stops short of documenting permissions, persistence, or return/publish 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?

A single dense paragraph that is front-loaded with the core action and hosting outcome, then layers layouts, themes, features, and integration details. It is information-rich for such a complex tool, though mildly run-on.

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 14-param, nested-object tool with no annotations and no output schema, the description covers purpose, layout/theme options, API wiring, output format, sandbox limitations, and cost. It is nearly complete for correct invocation, with the main gap being semantics for the less-prominent configuration parameters and no clear routing away from siblings.

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 low (36%) across 14 parameters, so the description must compensate. It explains the meaning of the key integration params (api_base_url, data_url, chat_endpoint) and their expected payloads, but leaves accent, nav_items, publish, site_id, default_mode, and the nested dashboard/crud/chat objects to the bare 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?

States a specific verb and resource – 'Build a polished, responsive front end for an app and host it instantly' – and enumerates the three layouts and four themes it produces. An agent can distinguish it from adjacent siblings like site_create or site_deploy, which do not generate themed app UIs.

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?

Gives clear context: layout-specific wiring (crud via api_base_url, dashboard via data_url, chat via chat_endpoint) and names site_files for editing the output. It also flags cost and sandboxed hosting. However it never explicitly states when to prefer this over site_create/site_deploy, so no true exclusions are provided.

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 and does well: it discloses the artifacts produced, the interactive studio, live material pricing, downloadable formats, and an explicit cost ('1 credit per call'). It omits persistence/latency or limits on regenerating, so it is strong but not exhaustive.

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?

Front-loaded with what it does and what it returns, then optionals, then the cost note. Dense but every clause maps to a real capability or parameter; the output-format enumeration (IFC/CSV/DXF/STL) is slightly listy but still earns its place as an integration signal.

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?

No output schema and 15 params with one nested object, so the description must do heavy lifting; it covers the return artifacts, cost, and the high-value inputs well. The gap is the unexplained region/site_lat/site_lon/title params and no statement on error or fallback behavior, so an agent could still call it correctly but not optimally.

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 7% (just brief), so the description must compensate and does for most inputs: it explains budget_usd semantics (live material prices), layout provenance (plan.json from the studio), rooms syntax ({bedroom:3,...}), roof enum values, structure enum values, and area/floor/height params. It leaves title, region, site_lat, and site_lon unexplained, so it falls short of fully covering 15 params.

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 concrete verb+resource ('describe a building... generates a laid-out floor plan per storey, 3D model, room schedule, energy/budget numbers, build guide'). The specific artifact list (DXF/SVG, STL, IFC, CSV) clearly separates it from siblings like arch_review or cad_build without opening any schema.

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?

Explicitly routes between two modes: give budget_usd to size to a budget, or layout (plan.json exported from the studio) to rebuild an edited design. This is clear 'when-to-use-which-input' guidance, but it never names when to prefer arch_design over adjacent siblings like arch_review or cad_* tools, so it stops short of a full 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?

With no annotations, the description carries the full burden and does well: it discloses the return shape (score, prioritised findings with fixes, improvement ideas), the screening-not-certified limitation, and a per-call cost of 1 credit. It does not state runtime or failure behavior, but coverage of the key behavioral traits is strong.

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?

Front-loads the purpose, then packs the input list densely, and closes with return description, disclaimer, and cost. The parameter enumeration is a long run-on block, but every clause carries information given the 21-parameter surface.

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 21-param, no-annotation, no-output-schema compute tool, the description supplies purpose, input semantics, return contents, scope limitation, and cost. Only gaps are the two undocumented fields and absent guidance on partial-input behavior nuances.

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%, so the description must compensate, and it does: it enumerates and explains nearly all 21 inputs with structure, units, and per-field meaning (tributary_width_m, egress_window, ventilation, zone enums). It omits shear_walls and aspect_ratio, so it is not fully 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: screening an existing building design for weaknesses and improvements, plus a 'stress-test' title. It implicitly separates itself from the design-oriented sibling arch_design via 'existing project', but never names an alternative explicitly.

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?

Gives useful invocation context ('provide whatever you have', all inputs optional) and a scope caveat ('screening only, not a stamped engineering check'). However, it offers no explicit when-to-use-vs-alternatives routing against arch_design or other siblings.

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 and does disclose a lot: per-minute credit cost, that long jobs are asynchronous and return a job_id to poll with get_job, and that result links expire in one hour. It omits permission/auth requirements and any note on output format or failure modes, keeping it short of 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?

Three tight sentences with zero filler: capability first, then cost, then async/expiry mechanics. Everything an agent needs is front-loaded and each sentence earns its place.

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 4-parameter tool with no annotations and no output schema, the description covers capability, cost, async polling and result expiry — enough to invoke and follow up correctly. The undocumented 'format' enum and absence of auth/permission notes are the only remaining 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 75% and already documents tempo and semitones (including ranges and the '+12 is one octave' note), so the description's pitch/tempo wording is largely redundant. The 'format' enum has no description in either place, so the description does not compensate for the remaining 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?

States a specific verb and resource: shift pitch in semitones and/or change tempo independently. The word 'independently' communicates the key capability (decoupled pitch/tempo) that separates it from a simple speed changer. It does not explicitly name or contrast a sibling, so it stops short of a 5 in this crowded audio-tool family.

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?

Gives concrete use cases ('remixes, practice tracks and key matching') that tell the agent when this tool is appropriate. It offers no explicit exclusions or named alternatives (e.g., tempo_calculator for pure tempo math), so it is clear context without routing guidance.

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 and does so well: it discloses credit cost (1 credit per minute), asynchronous behavior for long jobs, the get_job polling path, and 1-hour result link expiry. It omits auth/permission requirements and any failure/rate-limit behavior, so it stops short of 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?

Three tight sentences with the capability front-loaded, then cost, then async/expiry mechanics. No filler, though the sentences are somewhat telegraphic rather than optimally organized.

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 annotations and no output schema, the description must cover the operational contract, and it does: output format (PNG), cost, async flow, and link lifetime. Missing details are limited to authentication and the shape of the returned link, both minor for calling the tool correctly.

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 40% (url and color documented, type/width/height bare). The description restates the waveform/spectrogram choice matching the enum but adds nothing about the sizing or color parameters, so it fails to compensate for the documentation 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?

States a specific verb+resource+output: renders an audio or video file's sound as a waveform or spectrogram PNG. No sibling tool (process_audio, analyze_media, extract_audio) does the same thing, so an agent can distinguish it immediately.

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 capability statement and the async note (poll job_id with get_job) routes the agent onward for that case. However, there is no explicit when-to-use guidance versus alternatives like analyze_media or process_audio, and no statement of when this tool is the wrong choice.

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 behavioral burden. It does add real context — the weekend-skipping rule, optional holidays, and a cost of 1 credit per call — but omits error behaviour, how negative or out-of-range add_days is handled, and the fact that only 'start' is required.

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 tight sentences: capability first, cost second. No filler, no restatement of the tool name, and the most important information is front-loaded.

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

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

There is no output schema and no annotations, so the description is the only source of truth. It explains the two modes and the holiday/weekend behaviour but never says what is returned (a count versus a shifted date) or how the competing 'end'/'add_days' inputs resolve, which is a notable gap for a calculator.

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 conceptually maps all four parameters (two dates, add_days, optional holidays), but adds no format detail (the YYYY-MM-DD pattern), no sign semantics for add_days, and no mutual-exclusivity rule, leaving meaningful gaps for a four-parameter tool.

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 and resource ('Count working days between two dates or add working days to a date') and clarifies the core rule of skipping weekends and optional holidays. It is unambiguous on its own, though it never names or contrasts itself with adjacent calculator siblings such as tempo_calculator or timecode_calculator.

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?

Two operating modes are implied ('between two dates' vs 'add working days to a date'), which suggests when each branch applies, but there is no explicit statement that 'end' and 'add_days' are alternatives or mutually exclusive, nor any prerequisites beyond the implicit start date. Usage is inferable but not spelled out.

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 behavioral burden and does well: it discloses the return payload (model, DXF, SVG, cut list, BOM, build report), the cost ('1 credit per call'), and content policy limits. It does not mention regeneration/determinism or any failure/limitation behavior, so it is strong but not exhaustive.

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?

A single dense paragraph with the core promise front-loaded, then examples, supported kinds, optional inputs, exclusions, and cost. Every sentence adds distinct information and nothing is redundant, despite the length.

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?

Complete for a 7-param generation tool with no output schema and no annotations: the description substitutes for the missing output schema by enumerating every returned artifact, and it covers inputs, enums, exclusions, and cost. Only minor gaps (title param, dimension ranges) remain, which the schema itself supplies.

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 for most fields: 'brief' is richly shown via examples, 'kind' and 'wood' enum values are restated, and dimensions are shown in mm units through examples. However, the 'title' parameter is never mentioned and the min/max dimension bounds are left entirely to 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?

States a specific action and resource: turn a plain-language brief into a complete design package, enumerating the concrete artifacts produced (STL/viewer, DXF cut layout, SVG, cut list, BOM with cost, fastener count, weight, build report). That level of output specificity separates it from generic CAD siblings like cad_part or cad_calc, though it never explicitly names or contrasts those siblings.

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?

Gives concrete invocation examples ('a 6 ft workbench', 'bookshelf 800 x 300 x 1800 mm'), an explicit supported-type list, and clear exclusions ('Does not design weapons, firearms, ammunition or explosives') plus a cost note. It stops short of stating when to prefer this over sibling tools such as arch_design or cad_part.

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 behavioral burden. It does add two genuinely useful facts beyond the schema: the accepted material set and the cost model ('1 credit per call'). It omits what happens on invalid material/kind, which fields are required per mode, and the result format, so disclosure is 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?

The purpose sentence is front-loaded, followed by a dense, notation-style per-kind spec with no filler sentences. It is cryptic in style but every clause carries parameter information.

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 six-mode calculator with no output schema, no annotations, and a nested schema with zero description coverage, the input side is well covered but the description says nothing about the returned results, output units, or validation errors. Cost is the only operational detail supplied, leaving a real gap on the output side.

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 'values' is an untyped nested object, so the description does heavy lifting by listing the exact keys per kind (length_mm, load_N, torque_Nm, etc.), the support/mode enums, and the valid material strings. It still does not state types, defaults, or whether every listed key is mandatory, so it compensates well but not completely.

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 concrete verb+resource ('engineering checks') and then enumerates the six calculation modes (beam, torsion, bolt, motor, spring, belt) with their inputs, so an agent knows exactly what this tool computes. It is distinguishable from CAD-construction siblings like cad_part or cad_build, though it never explicitly contrasts itself with them.

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 mode enumeration implies when each calculation applies (beam bending, bolt loading, motor sizing), which is implicit usage guidance. However, there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling calculators and CAD tools, so the agent must infer 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?

With no annotations, the description carries the full behavioral burden. It discloses key traits: credit cost per call, the conceptual scaling-law nature, ITER-like defaults, and a concrete list of outputs including 3D models, DXF, and a component list. It does not mention permissions or side effects, but for a computational design tool this is a strong 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 front-loaded with the main purpose and is dense with relevant details. It is somewhat run-on—one long sentence plus two fragments—but every clause contributes useful information for selection and invocation.

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 complex design domain, absence of annotations, and no output schema, the description does a good job of covering what the tool computes, what artifacts it returns, and its cost and limitations. It lacks specifics about return formats or error behavior, but an agent has enough to decide and invoke it correctly.

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 lists ten parameter names with units (e.g., major_radius_m, toroidal_field_T, density_1e20_m3) inside the nested 'params' object, adding substantial meaning beyond the bare schema. It stops short of explaining ranges or defaults for each parameter, so a 5 is not given.

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 and resource: 'Scope a tokamak fusion reactor concept' with detailed params and outputs. It is immediately clear what the tool does, but it does not explicitly distinguish itself from sibling CAD tools such as cad_build or cad_calc, so the top score of 5 is not warranted.

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 phrases 'Concept-level, scaling-law based' and 'Defaults approximate ITER', which signal this is for early-stage conceptual design. However, the description never says when to use this tool versus alternatives, nor does it provide explicit when-not conditions.

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 and does disclose two non-obvious traits: a content policy exclusion ('Does not design weapons, firearms, ammunition or explosives') and a per-call cost ('Cost: 1 credit per call'). It also describes the return behavior (tool recommendation + extracted parameters). It does not cover failure modes for vague or unparseable ideas, which keeps it short of 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?

Four short sentences, front-loaded with the action and an example, followed by the return shape, the exclusion, and the cost. No filler; each sentence carries distinct information the agent needs.

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 routing tool with no output schema and no annotations, the description covers input form, expected output, cost, and content limits. It leaves the ambiguity-handling path (what happens when the idea is too vague to map to a tool) unspecified, but otherwise an agent has enough to call it correctly.

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% — the 'idea' property has no description, only minLength/maxLength constraints. The description compensates by explaining what belongs in the field (plain-language machine/mechanism/product description) and giving worked examples ('40 kg lift arm', 'a 30:1 gear reducer for a winch'), which tells the agent that numeric quantities should be embedded in the text so parameters can be pre-filled.

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 and resource ('Describe a machine, mechanism or product idea in plain language') and pins down its distinct role among the cad_* siblings by stating it 'Returns which CAD tool to run and pre-filled parameters' — i.e. it is the router, not the builder (cad_build), calculator (cad_calc), or part/fusion tools. An agent can tell it apart from cad_machine/cad_part without opening either schema.

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

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

Usage is only implied: because it 'returns which CAD tool to run', the agent can infer this is the entry point before cad_build/cad_machine. There is no explicit when-to-use/when-not statement and no sibling named as an alternative, so the routing guidance must be inferred.

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 and discloses substantial behavior: it produces a 3D model, 2D DXF, bill of materials, and engineering checks, and it details the calculations performed for each machine type. It also states the per-call credit cost. It does not cover permissions, rate limits, or error behavior, but for a design-generation tool this is a strong 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 front-loaded with the tool's purpose and outputs, then efficiently enumerates machine-specific parameters in a dense but readable format. It is appropriately sized for a complex multi-mode design tool, though the semicolon-heavy list format could be slightly clearer.

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 absence of annotations, output schema, and schema parameter descriptions, the description supplies the essential context: outputs generated, calculations performed per machine type, and required nested parameters. It omits the role of the 'material' enum and any error or prerequisite behavior, but is otherwise complete enough 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%, so the description must explain parameters. It provides detailed nested parameter meanings and expected values for all three machine modes (e.g., input_rpm, input_torque_nm, ratio for gearbox; ground, crank, coupler, rocker for four_bar). It does not explain the top-level 'material' or 'title' parameters, leaving a small 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 states a specific design verb and resource: 'Design a working mechanism with 3D model, 2D layout DXF, bill of materials and engineering checks.' It also enumerates three machine types and their outputs, making the tool's scope clear. However, it does not explicitly differentiate itself from sibling CAD tools such as cad_build, cad_part, or cad_calc.

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 usage by listing supported machine types and their parameter sets, and notes the cost of '1 credit per call.' It does not state when to choose this tool over siblings like cad_build or cad_part, nor does it provide when-not-to-use guidance.

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

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

There are no annotations, so the description carries full behavioral burden. It does add genuine value by disclosing the billable cost ('1 credit per call'), the unit convention (mm), and the artifact set produced (DXF, STL, SVG, 3D viewer, mass/specs). However it is silent on what 'host it' concretely means — persistence, returned URLs, artifact lifetime, or failure modes for invalid parameter combinations.

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 long but front-loaded with the core verb and outputs, then organizes the bulk into a single dense part-to-parameter mapping that is genuinely necessary given nine disjoint part schemas. Every clause carries information; it only loses a point for the run-on enumeration being harder to scan than a structured list.

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 4-parameter tool with 0% schema coverage, nested free-form params, and no annotations, the description covers generation well but leaves real gaps: how the hosted artifacts are retrieved, whether `title` matters, how `material` affects output, and when this differs from the other cad_* tools. It is adequate to invoke the tool, but not to invoke it confidently in a crowded tool family.

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 `params` is a free-form object, so the description does the heavy lifting by documenting the expected keys for every enum value of `part` (e.g. gear {module, teeth, thickness, bore}, flange {outer_diameter, bore, bolt_circle, bolts, bolt_diameter, thickness}). It does not mark which per-part keys are required versus optional or supply defaults, which would have earned a 5.

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+resource ('Generate a precise parametric part') and then enumerates all nine part types with their parameter sets, so an agent knows exactly what family of geometry this tool produces. It is clearly distinguishable from siblings like cad_calc (computation only) or cad_reverse (reverse engineering) even without opening any other schema.

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 never states when to pick this tool over cad_build, cad_fusion, cad_machine, cad_ideas, or arch_design — a dense sibling cluster where routing matters most. It only implies usage through the enumeration of part types, with no prerequisites, alternatives, or exclusions 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, the description carries the full burden and does well: it discloses the complete output set, accepted file formats, a units contract, a content restriction (no weapons/firearms/ammunition/explosives), and even the cost (1 credit per call). It still omits permission/auth requirements and any input-size or processing-limit caveats, so it stops short of 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?

A single dense paragraph that front-loads the core action, then the return artifacts, then units, restrictions and cost — every clause carries information. It is long, but the length is justified by six undocumented parameters and a missing output schema; a bulleted split of inputs vs outputs would read better than the run-on list.

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 no output schema, the description covers inputs, the full set of return artifacts (dimensions, volume, mass, weight by material, cross-sections, hulls, DXF, re-exported STL, viewer), units, refusal policy and cost. Nothing an agent needs in order to call it correctly is missing, aside from the minor param gaps noted above.

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, and it does for most parameters: it explains unit ("unit: mm|cm|m|in ... default mm"), the format enum via the listed file types (STL binary/ASCII, OBJ, ASCII PLY), and the two data channels (data_base64 vs data_text). It does not explain the material enum values or what title is used for, leaving two of six 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?

States a specific verb+resource (reverse engineer a part from a 3D scan/mesh) and enumerates the concrete artifacts produced, which cleanly separates it from the cad_build/cad_part/cad_fusion siblings that generate rather than reconstruct CAD. An agent can identify the tool's purpose 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.

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

The description implies when to use it (you have a scan/mesh and need CAD drawings, specs or measurements) and names the accepted input formats, so the trigger condition is reasonably clear. However, it never names an alternative sibling or states when NOT to use it, and it doesn't mention that data_base64 or data_text must actually be supplied for the call to do anything.

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. It usefully discloses the cost (2 credits per call) and what is returned, but omits auth requirements, timeouts, redirect-following depth, or rate limits that matter for an unattended checker.

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 compact sentence-cluster, front-loaded with the action and results, then the use case, then cost. Every clause earns its place 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?

For a single-parameter read tool with no output schema or annotations, the description covers purpose, return contents, quantity limit, and cost. It only lacks an explicit read-only/permission statement, a minor gap.

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%, but the single parameter is a self-evident array of URI strings. The description adds that up to 20 URLs are checked and what each yields, though "up to 20" duplicates the schema's maxItems and no format details are added.

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 URLs) and enumerates exactly what is returned: HTTP status, final URL after redirects, content type. It does not name or differentiate itself from relevant siblings like redirect_chain, phishing_url_check, or security_headers, so an agent must infer the distinction.

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?

"Good for finding broken links" implies the use case but offers no explicit when-to-use/when-not or routing to alternatives (e.g. redirect_chain for deeper redirect inspection, phishing_url_check for safety). Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden — and it does disclose two things the schema cannot: the operation is a deterministic generator (not a query/mutation) and it costs 1 credit per call. It also states the return content (hex and HSL values). It does not say how many colours are produced or whether the base must include the '#', which keeps it short of 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?

Two sentences, zero filler, with the capability front-loaded and the cost constraint trailing. Every clause earns its place.

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 two-parameter pure function with no output schema and no annotations, the description covers purpose, output format and cost, which is close to adequate. However it omits the default harmony, the palette size, and the exact meaning of each harmony rule, so an agent cannot fully predict the result without experimentation.

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 enumerate the five harmony modes, giving semantic meaning beyond the raw enum tokens, though it writes 'split-complementary' while the enum value is 'split'. It never documents the 'analogous' default nor the accepted base-colour format, so the compensation is partial.

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 ('Build') and resource ('palette') with the input ('from one base colour') and output format ('hex and HSL values'). Among the sibling list there is no other palette-generation tool, and the closest neighbours (video_color_grade, pixel_art) operate on entirely different inputs, so disambiguation is trivially satisfied.

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 'game or brand palette' implies the intended use case but never states when to pick this over another tool, nor what happens with the default harmony. With no annotations or output schema, the description could carry more routing guidance, so usage remains 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.

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

With no annotations, the description carries the full burden and does it well: it discloses that bitrate is chosen automatically, that a second re-encode may occur, the credit cost per output minute, async job_id behavior with polling via get_job, and that result links expire in 1 hour. These are exactly the operational traits (cost, latency, result lifetime) an agent cannot infer from the schema.

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

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

Four tight sentences with zero filler; the core purpose is front-loaded and the operational details (cost, polling, expiry) follow in descending order of importance.

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 and no annotations, yet the description covers the return path (job_id polling), the result lifetime, and the cost model. Nothing an agent needs to invoke this tool correctly is missing.

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 the baseline is 3. The description adds the useful fact that bitrate is auto-selected (no such parameter exists), but says nothing about max_height, start_seconds, or duration_seconds semantics beyond what the schema already documents.

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 ('Shrink a video or audio file') plus the distinguishing goal ('to fit a size limit'), which separates it functionally from conversion (convert_media) and trimming (trim_media) siblings. An agent can tell what this tool produces without reading the schema.

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?

Gives concrete triggering contexts ('8 MB for Discord or 25 MB for email'), which makes the when-to-use condition clear. It never names or excludes competing siblings such as convert_media or edit_video, so the routing guidance is implicit rather than explicit.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose two useful traits: no network calls and a cost of 1 credit per call. However, it omits failure behavior for malformed input, output format, and the 1,000,000-char input limit, which matters for a mutation-free but size-constrained 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?

Three short sentences, each earning its place: purpose first, then a behavioral note, then cost. Nothing is padded or repeated.

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 two-parameter tool with no annotations and no output schema, the description covers purpose, cost, and environment but never states what the tool returns (converted text vs. an object), nor how oversized or malformed input is handled. Enough to call it, not enough to predict its behavior.

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%: 'data' is documented in the schema while the 'direction' enum carries no description. The description's phrasing ('between CSV and JSON text') only obliquely implies the two direction values and adds no format or limit detail beyond the schema, so 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 gives a specific verb and resource ('Convert between CSV and JSON text'), and the word 'text' implicitly separates it from media-conversion siblings like convert_media and subtitle_convert. It stops short of explicitly naming any alternative tool, so it is clear but not fully sibling-differentiating.

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?

'Useful for cleaning scraped data' hints at a context of use but gives no when-to-use/when-not guidance and does not route the agent to or away from alternatives such as csv_profile or extract_tables. Usage is only implied.

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 behavioral burden and does well: it discloses cost (1 credit per minute of output), async behavior (long jobs return a job_id, poll with get_job), and result expiry (links expire in 1 hour). It omits permission/auth requirements and any input size or duration limits, which are the remaining gaps.

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?

Four compact sentences, front-loaded with the core action and format list, followed by cost and async/expiry mechanics. Every sentence carries information an agent needs; nothing is redundant with 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 7-parameter tool with no output schema, the description covers the important call-time mechanics (async job_id, polling tool, expiring links) and the format domain. It could go slightly further on what the immediate response contains versus the polled result, but nothing essential is missing.

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 the baseline is 3, but the description adds real value beyond the schema by grouping the flat format enum into video outputs and audio outputs and by framing trimming/downscaling as the intent behind the timing and height 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?

States a specific verb+resource (convert video or audio files between formats) and enumerates the exact output formats, which lets an agent distinguish it from siblings like compress_media, extract_audio, and trim_media 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.

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

Clearly signals the scope of the operation ('convert to another format, with optional trimming and downscaling') and tells the agent what to do for long jobs (poll with get_job). It never explicitly names when to prefer a sibling such as extract_audio or compress_media instead, so routing is left partly 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, the description carries the burden and does disclose genuine operational traits: breadth-first order, same-domain confinement, the text return format, and a per-call cost of 5 credits. It stops short of rate limits, timeout behavior on large sites, or robots/politeness handling, but the cost and scope disclosures are exactly the kind of context annotations would otherwise provide.

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?

Three tight sentences, front-loaded with the core action and followed by use case and cost. No filler, though the use-case sentence could be traded for parameter or limit guidance.

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?

No output schema and no annotations, so the description must fully specify behavior. It covers purpose, scope, return content, and cost, but omits how max_pages/max_chars_per_page shape results and what the returned structure looks like across multiple pages.

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%: url is documented in the schema, but max_pages and max_chars_per_page have no schema descriptions and are never mentioned in the description. The description does not compensate for the coverage gap on these two controls, leaving their effect on output size unexplained.

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 (crawl), resource (site), traversal strategy (breadth-first from a starting URL, same domain), and return content (clean text of each page). This is clearly distinct from the single-page sibling scrape_page in spirit, but it never names that sibling, so the differentiation is left implicit.

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

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

Gives a use case ('building a knowledge base or RAG corpus') but no when-to-use/when-not guidance and no alternatives. Given strong sibling overlap with scrape_page, extract_content, and sitemap_urls, the definition should route the agent but does not.

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 and does so well: it discloses cost (2 credits per minute), async behavior and the polling pattern, that result links expire in 1 hour, and where segments are served from. It stops short of stating auth/permission requirements or rate limits.

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?

Four short sentences, front-loaded with purpose and output, then operational facts (cost, async, expiry). Nothing is redundant or padded.

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 no-annotation, no-output-schema tool, the description covers the return value, async polling contract, cost, and link expiry, which is nearly everything an agent needs. Minor gaps remain: no guidance on choosing heights/segment_seconds values and no permission requirements.

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 67%: url and heights are documented in the schema, but segment_seconds has no description anywhere. The description only loosely gestures at parameters ('several quality levels') without adding format, range, or default meaning beyond the schema, so 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?

States a specific verb and resource ('package a video ... as HLS') plus the defining characteristic of the output (several quality levels, master playlist) which separates it from generic converters like convert_media or compress_media in the sibling list. An agent can tell what it produces 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.

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

Gives clear context for use (adapting to slow connections for web playback) and routes follow-up work explicitly: 'Long jobs return a job_id; poll it with get_job.' It does not, however, state when not to use it or contrast it with nearby siblings such as extract_audio, trim_media, or compress_media.

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 behavioral burden and does reasonably well: it discloses the returned report structure, the temporal coverage limit, the data provenance/ethics caveat ('public data: no victim or suspect identities, not evidence of guilt'), and the per-call cost of 5 credits. It omits whether the call is strictly read-only, auth requirements, and what happens when no match is found.

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 core lookup action is front-loaded in the first sentence, followed by three tightly packed sentences covering output, coverage limits, disclaimers and cost. Every sentence carries information; nothing is restated from the schema or 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, and the description does describe the returned report well enough (pinpointed location, public details, candidate matches, ranked similar incidents, area pattern summary). For a 12-parameter tool with zero required fields it still leaves the 'at least one selector required' rule and the no-result behavior unspecified.

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%, so several parameters (similar_limit, similar_radius_m, search_radius_m, lat/lon) have no inline documentation. The description compensates by naming the accepted search selectors and by explaining that the date is used 'plus or minus a window' and that similarity ranking draws on same offence, location type, time of day, block and proximity – which effectively explains the similar_* and radius 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?

Specific verb+resource: pinpoint a past Chicago crime incident by case number, date, block, type, keyword or coordinates, then rank similar incidents. It is plainly distinguishable from siblings like crime_map_data and crime_stats because it is incident-level lookup rather than aggregate or map data, and the title reinforces the 'exact case + similar cases' scope.

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 context on what selectors are accepted and bounds the data range ('2001 to about a week ago'), which is real usage guidance. It does not name alternatives or state when NOT to use it, and with 0 required parameters it never says that at least one locator (case, date, block, keyword, coords) must be supplied – a meaningful omission for a 12-param tool.

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 and does well: it discloses the hourly cache vs live re-pull, the 3-credit cost, that data is public and may lag, and the important caveat that results show reported incidents, not guilt. It omits auth/rate-limit details but covers the operationally relevant traits.

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?

A single dense paragraph that front-loads the core purpose and layer list before filters and cost. The long layer enumeration is necessary for discovery, though it makes the sentence heavy. Little waste overall.

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 15-parameter tool with no output schema and no annotations, the description covers purpose, filters, caching, cost, and return shape ('points plus ranked hotspots'). It leaves a few parameters (limit, radius_miles, state, year) unexplained, which is the main residual gap.

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 47% across 15 parameters. The description compensates for some (layer vs layers, date range, keyword, map box, refresh) but says nothing about limit, radius_miles, year, state, or near, leaving those to a sparse schema. Partial compensation justifies a 3.

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 ('Query public open data') and enumerates the exact resources/layers available. An agent can immediately distinguish this from siblings like crime_stats or crime_case_report because it specifies the layer-based query model and lists the datasets.

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?

It clearly explains when to use `layer` (one dataset) vs `layers` (several at once) and outlines filter mechanics (date range, keyword, map box) plus when to set refresh=true. It lacks explicit guidance distinguishing it from the sibling crime tools, so it stops short of a 5.

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

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: it discloses that only reported crime is present, that non-reporting agencies are absent, how rate is computed (sum of monthly per-100k rates), and the cost (1 credit per call). It stops short of stating read-only behavior or describing the response payload, but the coverage caveats and cost are genuinely useful.

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?

A tight, front-loaded paragraph where every sentence adds information: purpose, level semantics, filter list, coverage probe, data caveats, and cost. No filler or repetition of the schema.

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 7-parameter, zero-required tool with no output schema and no annotations, the description supplies the level routing, filter guidance, coverage discovery path, data-quality caveats, and pricing. An agent can call it correctly without opening the schema.

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 29%, so the description must compensate, and it does for the important axes: it names the four level values, the state/offense/year-range filters, and that town is a city-or-agency name lookup. The county parameter is only indirectly explained via level=county, leaving a small 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?

States a specific verb and resource ('Query the local Crime Radar statistics database') and pins down the data provenance (FBI Crime Data Explorer, annual counts and rates by offense). This clearly distinguishes it from siblings like crime_case_report and crime_map_data.

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?

Explains what each level value selects (state totals, county roll-up of reporting agencies, town name lookup) and explicitly tells the agent to call level=coverage to discover what data is loaded. It gives strong in-tool routing but never contrasts itself against sibling crime tools, so no explicit exclusion.

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 behavioral burden, and it does disclose two useful traits: the fixed cost (1 credit per call) and the expected output shape (English translation plus next run times), which matters since there is no output schema. It is silent on error behavior for malformed or 6-field expressions and on any validation rules, so the disclosure 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.

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

Two sentences, zero filler. The purpose is front-loaded and the cost caveat follows it, which is the right order for an agent deciding whether to call.

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 two-parameter tool with no annotations and no output schema, the description should cover return format, the second parameter, and failure behavior. It covers the return format and cost, but leaves `runs` unexplained and says nothing about how invalid expressions are handled, so it is adequate rather than complete.

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%: the `expression` parameter has an example but the `runs` parameter has no description at all, only schema constraints (default 5, max 20). The description contributes the meaningful constraint that the input is a 5-field expression, but it never explains what `runs` controls beyond the vague phrase 'list the next run times'.

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 specific verbs (translate, list) against a specific resource (a 5-field cron expression), and names the concrete output (plain English plus next run times). No sibling tool in the list overlaps with cron parsing, so there is nothing to disambiguate against; an agent can select this with confidence from the title and first sentence alone.

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 purpose statement (call it when you need a cron expression explained), and the cost note gives a reason to weigh the call. However, there is no explicit when-to-use/when-not guidance, no mention of how it relates to any alternative, and no prerequisites such as expression validation expectations.

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, and it does disclose a genuinely useful behavioral trait: cost of 2 credits per call. However it says nothing about latency, rate limits, or that this is a strictly read-only lookup with no side effects, so the safety/behavior profile is only partly covered.

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?

A single front-loaded sentence: resource first, then the metric list, then cost. The metric enumeration is dense but each item earns its place since no output schema exists to communicate the return shape. 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?

Because there is no output schema, the enumerated metrics are important and usefully present, and cost is covered. But the days parameter's meaning remains unexplained and no sibling routing is given, leaving gaps for a tool whose whole value is the parameterized lookback window.

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%: id is well documented with an example and a pointer to crypto_search, but days (default 180, range 30–365) has no description and the tool description never mentions it or that it controls the lookback window. The description therefore fails to compensate for the documented 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?

States a specific resource ('one coin') and enumerates the exact analytics returned (price history, RSI, MAs, trend, volume, volatility, drawdown, headlines), which is far more concrete than a bare 'get coin data'. It implicitly separates itself from the multi-coin crypto_markets and news-only crypto_news, but never names a sibling to make the boundary explicit.

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 statement of when to use this versus crypto_markets, crypto_signals, or crypto_news, and no prerequisites. The only guidance ('use crypto_search if unsure') lives in the input schema's id description, not here. The cost line is the sole decision-relevant 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?

No annotations are provided, so the description carries the full behavioral burden, and it does disclose a real operational trait: cost of 1 credit per call. Combined with 'Live' (real-time data) and a full field inventory, the agent knows what it gets. It still omits auth requirements, rate limits, and error/fallback behavior for unknown coin ids, so it is not complete.

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?

A single sentence that front-loads the scope ('Live market snapshot') and then enumerates the return payload and cost. No filler, every clause carries information.

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 field enumeration usefully compensates for a missing return spec, and cost is covered. But the 33% schema coverage on sort/limit is not offset, and for a 3-param tool with zero annotations the definition leaves gaps in how to control sorting and pagination.

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 33%: only 'ids' is documented in the schema. The description restates the ids path and its override behavior but says nothing about the 'sort' enum values or the 'limit' range/default, leaving two undocumented parameters for the agent to guess at from constraints alone.

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 the resource (crypto market data) and the exact payload: top coins by market cap or explicit ids, with price, multi-period change, volume, market cap, ATH distance, plus global cap, BTC dominance and Fear & Greed. That is far more specific than the title. It does not, however, explicitly distinguish itself from siblings like crypto_coin or crypto_signals, which likely overlap on per-coin data.

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?

It mentions the two retrieval modes (top-by-cap vs explicit ids) but gives no when-to-use guidance versus crypto_coin, crypto_signals, or crypto_search, no exclusions, and no prerequisites. The agent must infer routing from the payload list alone.

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 zero annotations the description carries the full burden, and it discloses meaningful traits: the sentiment is computed 'by keyword' (a real limitation), the return shape (per-headline tags plus an overall mood score), and the cost of 1 credit per call. It stops short of freshness/pagination or error behavior, so not 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?

Three tight sentences that front-load the core purpose, then add filtering scope and cost. Every sentence earns its place 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?

For a no-output-schema, no-annotation tool the description covers purpose, return content (tagged headlines + mood score), sentiment method and cost. It leaves the limit parameter and data freshness unaddressed, which keeps it just short of complete.

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% (coin documented, limit not). The description's 'filter by coin name or symbol' merely restates the schema's own coin description and adds no syntax or format detail, and the limit parameter goes unexplained in both places. Baseline 3 for partial coverage with no compensating value.

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+resource (latest crypto headlines) and names the exact sources (CoinDesk, Cointelegraph, Decrypt, The Block) plus the sentiment tagging behavior and mood score. This is unmistakably a news-aggregation tool, clearly distinct from siblings like crypto_markets, crypto_coin and crypto_signals.

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 when-to-use guidance and no alternatives named. 'Filter by coin name or symbol' is parameter guidance, not usage routing, and the cost note, while useful, does not help an agent decide between this and related crypto siblings. Usage is only faintly implied.

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?

No annotations are provided, so the description carries the full behavioral burden. It does add genuinely useful context — a cost of 1 credit per call and the fact that the returned id feeds other crypto tools — but says nothing about auth requirements, error/empty-result behavior, or whether results are ranked.

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 short sentences with no filler: purpose and output first, cost last. Every clause earns its place.

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-optional-parameter lookup with no output schema, the description covers what the tool returns, an alternate mode, and its cost. It stops short of describing result shape (ranked list, exact vs fuzzy match) or failure behavior, but nothing critical is missing.

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% and there is only one parameter, so the baseline is 3. The description goes beyond the schema text by specifying that the query accepts a name or a symbol (the schema only documents the empty-query case), adding real semantic value for how to populate it.

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+resource ('Search coins by name or symbol') and clarifies the output's role ('the id used by the other crypto tools'), which helps separate it from crypto_markets or crypto_coin. It never names a sibling tool explicitly, so the differentiation is functional rather than direct.

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 'Leave empty to see trending coins' behavior is only in the schema, and the description hints at it with 'plus the trending coins right now.' There is no explicit when-to-use-this-vs-crypto_coin/crypto_markets guidance or prerequisite statement; usage must be inferred.

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 and does well: it discloses the data sources combined (price action, news sentiment, Fear & Greed), the shape of the result (two ranked lists with scores and reasons), and an explicit cost of 3 credits per call. It omits read-only status and any auth/rate-limit context, which slightly limits the 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?

Four tight sentences, front-loaded with the purpose, then data sources, return shape, parameter behavior, and cost. Every sentence adds distinct information; nothing is redundant.

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 no-output-schema, no-annotation tool, the description covers return shape, data provenance, defaults, and cost, which is enough for an agent to call it correctly. The gap is the unexplained deep/universe parameters, but these are optional knobs with schema-level hints.

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 67%, above the half-way mark, so the baseline of 3 applies. The description only illuminates the ids parameter ('scan the top coins or pass your own list') and says nothing about deep or universe, whose meaning is left entirely to 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?

States a specific verb and resource: scans the market for coins likely to run vs. showing warning signs, and names the two output lists. It is clearly distinguishable from data-lookup siblings like crypto_markets or crypto_coin, though it never names an alternative directly.

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?

Gives implied usage (scan top coins by default, or pass your own list) but no explicit when-to-use vs. when-not, and no routing against the many crypto_* siblings. An agent must infer that this is the analysis/signal tool rather than the raw-data tools.

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 and discharges it well: it declares READ-ONLY by design, states it cannot move funds, that it refuses private keys or seed phrases, and quantifies cost at 2 credits per call. These are exactly the behavioral traits an agent needs before invoking a wallet 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?

Three sentences, front-loaded with the capability and scope, followed by the safety constraint and then the cost. Every clause earns its place; nothing is repeated from the schema or annotations.

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 3-parameter read-only tool with no output schema and no annotations, the description covers the return fields, chain scope, safety posture and cost, which is nearly everything an agent needs. It stops short of describing address formats per chain or error behavior for invalid/empty wallets.

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 33%, so the description must compensate, and it does: it enumerates the chain enum values (Bitcoin, Ethereum, Solana), explains address as a public wallet address, and describes include_signals as a risk check on the biggest holdings. Minor gap: the schema frames include_signals as a scan on the native coin while the description says 'biggest holdings', a slight mismatch, and address length limits are unmentioned.

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 (look up) and resource (public wallet address) plus the exact chains supported and the fields returned: balance, USD value, token holdings, transaction count, optional risk check. This clearly distinguishes it from siblings like crypto_markets, crypto_search, crypto_coin and get_balance.

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?

Gives clear context for when it applies: a public wallet address on one of three named chains, with an optional risk-check flag. It does not name an alternative or state when NOT to use it (e.g., vs. crypto_signals for the standalone signal scan), so it falls short of the explicit when/when-not/alternatives bar.

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. It does add real value by disclosing the cost (1 credit per call) and the fact that it returns a report rather than mutating data. But it omits the schema's 2MB input ceiling, any auth or rate-limit context, and error behavior on malformed CSV.

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 covering the action and its full output contract, followed by a short cost sentence. Front-loaded, no filler, and every clause maps to information an agent needs.

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 no annotations, the description steps in admirably by enumerating the report contents, so an agent can anticipate the return shape. It is only incomplete on input constraints and failure modes, which are minor for a stateless read-style 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 coverage is 0% for the single 'csv' parameter, so the description must compensate. "Paste CSV text" usefully clarifies that the value is raw CSV content, not a file path or URL, but it does not surface the minLength/maxLength bounds (3 to 2,000,000 characters) that the schema only encodes structurally.

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?

Specific verb+resource: it profiles pasted CSV text and enumerates the exact report contents (row count, per-column type, blanks, distinct values, numeric stats, top values, duplicate rows). An agent knows exactly what the tool produces. It never explicitly names a distinguishing sibling (e.g., convert_data, extract_tables), so it falls just 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.

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

"Paste CSV text" implies the usage mode and the input shape, which is the single most important usage fact for a one-parameter tool. However, it gives no when-to-use guidance, no exclusions, and never points to an alternative among the many data-handling siblings.

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 and does add real context: rates are 'current' (not historical), sourced from ECB, and each call costs 1 credit. However, it says nothing about rate freshness/refresh cadence, precision or rounding of the returned value, or error behavior for unsupported currency codes.

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 short sentences with the core operation front-loaded and the cost disclosure appended; nothing is wasted or buried.

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, no output schema, and 0% parameter documentation, the description leaves too much unstated: the expected format of the result, rounding behavior, and currency-code format. The credit-cost disclosure is a positive, but the definition is not self-sufficient.

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% for all three required parameters. The phrase 'convert an amount between currencies' loosely maps to amount/from/to, but the description never clarifies that from/to are 3-letter ISO currency codes, nor does it explain the amount bounds or direction of conversion. It fails to compensate for the coverage 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?

States a specific verb ('Convert') and resource ('an amount between currencies') with the data source (ECB reference rates) named, which cleanly separates it from siblings like convert_data, subtitle_convert, and convert_media. An agent can identify the tool's function 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.

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

The description explains what the tool does but offers no when-to-use guidance, no prerequisites, and no alternatives or exclusions (e.g., historical vs. current rates, unsupported currencies). Usage is only implied by the tool's obvious domain.

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 and does reasonably well: it discloses the data source, the return content (CVSS severity, description, affected products, references), and a per-call cost of 1 credit. It omits auth/permission needs and error behavior for invalid IDs, but the cost and output disclosure are genuinely useful.

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 tightly packed sentences, front-loaded with the action and modes, followed by return values and cost. No filler; every clause adds information.

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?

No output schema or annotations exist, and the description compensates by describing return fields and cost. It is nearly complete, though it leaves the 'limit' parameter and any optionality rules (0 required params) unexplained.

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%, so the description must compensate. It explains the semantics of cve_id and keyword (the two ways to query), but never mentions the 'limit' parameter or the required CVE-ID format, leaving one of three params undocumented in both schema and description.

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 (look up / search) and resource (CVE vulnerabilities), names the authoritative data source (NVD), and distinguishes the two operating modes (ID lookup vs keyword search). An agent can immediately tell what the tool does.

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

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

The description implies how to choose between the two modes ('look up a CVE ID, or search recent vulnerabilities by keyword'), but gives no explicit when-to-use guidance or exclusions relative to other security tools like web_search or ioc_extract. Usage is implied rather than stated.

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

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 does disclose two valuable behaviors the schema cannot express: seed-based reproducibility and a per-call cost of 1 credit. However, it says nothing about determinism guarantees, batching behavior for multiple rolls, or failure modes for malformed notation.

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?

A single front-loaded sentence that opens with the core action and notation formats, with the pricing caveat tacked on at the end where it is easy to find. Slightly overloaded by bundling the probability-distribution capability into the same clause, but no wasted 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?

With no annotations and no output schema, the description should describe what comes back. It names the probability distribution as an output but not the shape of a repeated-roll result or how multiple rolls are returned, and the batching parameter is left ambiguous.

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% (only notation is documented in-schema), so the description must compensate. It clarifies that seeds give repeatable results, which adds real meaning beyond the bare 'seed' field, but it leaves 'times' (number of rolls, default 1, max 100) entirely unexplained in either place.

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 (Roll) and resource (tabletop dice) and pins down the notation grammar with concrete examples (2d6+3, 4d6kh3) plus the extra probability-distribution output. It is unambiguously about dice math, but it never distinguishes itself from the nearest sibling, loot_table, which an agent could plausibly confuse for tabletop randomness.

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 notation examples and the mention of repeatable seeds hint at how to call it, but there is no explicit when-to-use or when-not-to-use guidance, and no routing to alternatives such as loot_table for item generation.

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?

No annotations are provided, so the description carries the full behavioral burden. It does add one genuinely useful non-schema fact — 'Cost: 1 credit per call' — which tells the agent this is a metered operation worth using deliberately. It does not disclose whether the lookup is read-only, how failures (NXDOMAIN, timeouts) are surfaced, or any rate limits, leaving meaningful gaps for an unannotated 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?

Two short sentences with zero filler. The functional scope is front-loaded and the cost constraint follows immediately. Every clause earns its place.

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 no annotations, the description should ideally describe the shape of the result, error behavior, and safe usage. It partially compensates by listing the record types returned, but omits any return-format or failure-mode detail for a tool whose structured metadata offers nothing.

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 parameter, 'domain', and the schema description coverage is 0%, so the description must compensate. Saying 'a domain's ... records' implies the parameter is a domain name, but it adds no format guidance (e.g., whether a bare domain, subdomain, or URL is accepted) despite the schema imposing a pattern, minLength, and maxLength.

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 ('look up') and resource ('a domain's ... records') and enumerates exactly which record types are returned (A, AAAA, MX, TXT, NS, CNAME), so an agent knows precisely what the tool does. It does not, however, distinguish itself from adjacent siblings such as domain_info, subdomain_enum, or reverse_dns, which also operate on domains.

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 domain_info, subdomain_enum, or reverse_dns, and no stated prerequisites or exclusions. The only usage-adjacent information is the cost line, which is not a selection criterion. The agent must infer applicability entirely from the tool name.

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?

No annotations are present, so the description carries the full behavioral burden. It does disclose cost ('1 credit per call'), which is genuinely useful non-schema context, but says nothing about read-only/non-destructive nature, authentication needs, behavior for unregistered domains, rate limits, or failure modes.

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

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

Two compact sentences with zero filler; the core capability is front-loaded and the cost caveat follows in a short clause. Every word earns its place.

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 simple one-parameter lookup with no output schema, the description adequately enumerates the returned data fields and the credit cost. It is missing only edge-case behavior (unregistered domains, invalid TLDs) and input format guidance, which keeps it from a 5.

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 single parameter is undocumented in the schema beyond a regex pattern and length bounds. The description references 'a domain's' but never clarifies the expected format (bare registrable domain vs. hostname/subdomain) or whether IDN/internationalized input is accepted, so it only partially compensates.

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 (look up) and resource (a domain's registrar, registration/expiry dates, nameservers) plus the data source (RDAP), which is enough to separate it from generic web or DNS tools. It stops short of naming the adjacent siblings it must not be confused with, such as dns_lookup, reverse_dns and ip_whois, so a 5 is not warranted.

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 agent can infer it is for registration metadata, and 'via RDAP' scopes it to registry data. There is no explicit when-to-use or when-not, and with siblings like dns_lookup, ip_whois, reverse_dns and domain-adjacent site_audit tools in the list, the lack of routing guidance is a real gap.

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 and does well: it discloses that streams are copied without re-encoding (quality untouched), a flat cost of 1 credit, async behavior via job_id polled with get_job, and 1-hour link expiry. It omits any auth/permission requirements or confirmation that stripping is irreversible, hence not 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?

The purpose is front-loaded in the first sentence, followed by operational facts (encoding, cost, async, expiry). Four tight sentences with little waste, though the cost/expiry details could be grouped more cohesively.

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?

No output schema and no annotations, so the description must cover the operational surface: it explains async job handling and result-link expiry, which is exactly what an agent needs to complete the call. Missing auth prerequisites and per-parameter format detail keep it just short of 5.

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 29% (url and strip_all documented), so the description must compensate. It lists the editable tags (title, artist, album, comment, year) and clarifies what 'strip' removes (location, device, software), but adds no format guidance (e.g. year as a string) beyond the field names.

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+resource: setting named tags (title, artist, album, comment, year) or stripping all metadata, with the explicit goal 'before sharing'. An agent can distinguish it from compress_media or edit_video, though it does not name a sibling to route against.

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 'before sharing' implies the primary use case, giving implied context. However there is no explicit when-to-use/when-not guidance and no named alternative (e.g. vs. convert_media or process_audio), leaving selection 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, the description carries the full burden and does well: it discloses billing rate, asynchronous job semantics with a named polling tool, and a 1-hour expiry window for output links. It still omits whether the source video is modified or preserved, which is the main unresolved behavioral question for a transform 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?

Four front-loaded sentences: purpose first, then cost, async handling, and expiry. The long enumeration in sentence one is dense but scannable; nothing is redundant or wasted.

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 13-parameter, no-annotation, no-output-schema tool, the description covers the critical gaps: how long-running work is retrieved and how long links live. It is nearly complete, missing only an explicit statement about what the call returns and whether the input asset is left untouched.

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 already 100%, so the baseline is 3, but the description adds genuine meaning: the aspect_ratio use case (9:16 for Shorts/Reels), the crop-to-fill vs pad-with-bars choice corresponding to the fit enum, and the note that speed changes preserve audio pitch. These go beyond the schema text and justify a 4.

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 opens with a specific verb+resource and enumerates concrete operations (aspect ratio, downscale, rotate, flip, speed, frame rate, mute), so an agent knows exactly what the tool transforms. It does not, however, differentiate itself from overlapping siblings like compress_media (downscaling) or convert_media (format), which is why it falls 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.

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

It gives clear operational context: cost is 1 credit per minute of output, long jobs return a job_id that must be polled with get_job, and result links expire in 1 hour. What's missing is any explicit when-not/to-use-alternative guidance versus trim_media, convert_media, or compress_media.

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 and does disclose meaningful behavioral traits beyond the name: it performs DNS/MX lookups (implying network I/O and latency) and it charges 1 credit per call. That cost disclosure is genuinely useful and not derivable from any structured field. It still omits failure behavior and response shape, keeping it short of 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?

Two sentences plus a cost clause, all front-loaded: what is checked first, then the cost. No wasted words and nothing buried.

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, no-annotation, no-output-schema tool, the description covers what is validated and the cost. The remaining gap is what the result looks like (boolean vs. structured flags), but with no output schema and a trivial input this is close to sufficient.

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% for the single 'email' parameter, and the description only implies the input is an email string without adding format, normalization, or edge-case detail beyond the 254-char maxLength already in the schema. Minimum-viable for a trivially simple single-param tool.

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 (check) and resource (email address), and enumerates the exact sub-checks performed: syntax, MX record deliverability, and disposable-domain flagging. An agent knows precisely what the tool returns conceptually 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.

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

The use case (validating an email before relying on it) is implied by the checks described, but there is no explicit when-to-use guidance. It does not state whether this is the right call versus related siblings like dns_lookup or domain_info, nor any exclusions.

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 whole burden and does so well: cost per minute of output, async job_id with a named polling tool, and a 1-hour link expiry. It omits auth requirements and error behavior, so it falls short of 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?

Four short sentences, each carrying a distinct fact (purpose, track selection, cost, async/expiry), with the primary purpose front-loaded. Nothing is redundant.

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?

No output schema exists, but the description explains the return path (job_id, poll via get_job, expiring links) and the cost model, which is exactly what an agent needs to plan a call to this 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 coverage is 100%, so the schema already documents all six parameters with enums, bounds, and defaults; baseline is 3. The description only adds the notion that audio_track matters when a file has several tracks, which is marginal 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?

States a specific verb+resource ('pull the audio track out of a video') and expands scope to a second case ('or re-encode an audio file'). This clearly distinguishes it from nearby siblings like process_audio, trim_media, and compress_media.

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?

Gives useful context — choose the track when multiple exist, and poll with get_job for long jobs — but never states when to prefer this over alternatives such as process_audio or trim_media. Usage is implied rather than routed.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses a concrete cost ('1 credit per call'), which is real information beyond the schema, but omits permission/auth needs, whether JS-rendered pages are handled, rate limits, and failure behavior on non-HTML responses.

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 tight sentences with zero filler; the extraction scope is front-loaded and the cost caveat follows. Nothing is redundant with the title or 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?

For a simple one-parameter read tool with no annotations and no output schema, the description covers what is extracted and the cost, but leaves the return shape (flat list vs. grouped per type), empty-result behavior, and page-fetch constraints unaddressed. 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 description coverage is 100% for the single 'url' parameter, so the schema already documents it as a public http(s) URL. The description adds no syntax, format, or constraint detail beyond the schema, which is the expected baseline for full-coverage schemas.

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 ('Scan a page') and resource, and enumerates exactly what it extracts (emails, phones, social profiles), which separates it from generic siblings like extract_links and extract_tables. It never names a sibling explicitly, so differentiation is achieved through the field list rather than routing.

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 guidance, no statement of prerequisites, and no mention of alternatives such as extract_links, extract_content, or scrape_page, despite several overlapping siblings. Usage must be inferred entirely from the field enumeration.

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. It usefully discloses parallel execution, per-URL error reporting, and a cost of 3 credits per call, but says nothing about auth requirements, rate limits, retries, or how non-HTML/JS-rendered pages are handled.

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?

Three short sentences with zero filler; the core capability and its scale limit are front-loaded, followed by failure behavior and cost. Every sentence carries information an agent needs.

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 annotations and no output schema, the description does a fair job covering return shape and error behavior, but the undocumented max_chars_per_page parameter is a real gap for a 2-param tool. Adequate but not complete.

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% for both parameters. The description conveys the URL count limit (10, mirroring maxItems) but never explains max_chars_per_page, its 8000 default, or its 500-30000 bounds, leaving one of two parameters undocumented anywhere.

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 (fetch URLs, return clean readable text) plus concrete scope: up to 10 in parallel, with the return shape (title, text). It does not name or distinguish itself from close siblings like scrape_page, crawl_site, or fetch_json, so an agent must infer the boundary.

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 parallel batch of up to 10 URLs and 'clean readable text' output suggest bulk article/page extraction, distinct from extract_links or fetch_json. No explicit when-to-use, when-not, or named alternative 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?

No annotations are provided, so the description carries the full disclosure burden. It does add real value by specifying the return shape ('each field returns the text of every match') and a cost signal ('1 credit per call'), both absent from structured fields. However, it omits operationally important traits such as JS-rendering support, no-match/error behavior, and rate limits.

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?

Three tightly written sentences, front-loaded with the core action, then the input format, then the attribute trick and cost. No filler or redundancy; every sentence carries information.

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 covers the return semantics and the per-call cost, and the schema fully covers inputs. It is nearly complete for a scraping tool, falling short only on failure/pagination behavior that an agent might reasonably want.

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 the schema already documents url, limit, and the selectors map, including the '@href' example. The description reiterates the field-to-selector mapping and @attr syntax, adding little beyond the schema, and it never mentions the limit parameter. 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 gives a specific verb and resource: 'Scrape specific elements from a page,' and the CSS-selector mechanism makes it distinguishable from nearby siblings like extract_links and extract_tables. It does not, however, explicitly differentiate itself from scrape_page or extract_content, so an agent still has to infer which is right.

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 explicit when-to-use or when-not-to-use guidance, and no alternative tools are named despite several overlapping siblings (scrape_page, extract_content, extract_links, extract_tables, crawl_site). The text explains how to format the input, not when this tool is the correct choice.

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, and it does disclose a real behavioral trait not present in the schema: cost of 1 credit per call. It is silent on other relevant traits such as whether the page must be statically fetchable, whether redirects are followed, and any rate limits.

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?

Three short sentences with no filler: what it returns, the optional filter, and the cost. The core purpose is front-loaded and each sentence earns its place.

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 simple 2-parameter read tool with no output schema, the description states the return shape (links plus anchor text) and the cost. Minor gaps remain around output volume/pagination and static-vs-JS rendering behavior, but nothing blocking 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 coverage is only 50% — url is documented but same_domain_only has no schema description. The description compensates by explaining that flag ('Optionally keep only links on the same domain'), so the semantics of the undocumented parameter are recoverable from the text.

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 ('List every link on a page with its anchor text'), which cleanly separates it from neighbors like extract_content, scrape_page, and sitemap_urls. It stops short of naming any sibling, so sibling differentiation is implicit rather than explicit.

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 guidance, no prerequisites, and no reference to alternatives such as crawl_site (multi-page) or check_urls (validate links). The only usage flavor is the inline note that same-domain filtering is optional, which describes a parameter rather than when to pick this tool.

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 behavioral burden. It usefully discloses the cost (1 credit per call) and a header heuristic, but omits important traits like what happens on pages with no tables, how max_tables affects results, and whether the extraction is static or rendered.

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 tightly written sentences with no filler, front-loading the core action and output shape before the cost note. Every sentence earns its place.

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 simple extraction tool with no output schema, the description covers purpose, output shape, and cost, but leaves key gaps around max_tables behavior and empty-result handling. It is adequate but 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 coverage is 50%: url is documented, but max_tables has no description in either schema or description. The description says 'every table' while the schema defaults max_tables to 10, which is potentially misleading and does not compensate for the missing parameter semantics.

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 and resource ('Pull every table on a page') and clarifies the output shape ('rows of cells'), which distinguishes it from general siblings like extract_content or extract_data. It does not explicitly name or contrast with those alternatives, 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.

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 scrape_page, extract_content, extract_data, or extract_links, and no prerequisites or exclusions are stated. The only conditional information is a cost note, which is not usage guidance.

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 behavioral burden. It usefully discloses a cost ('1 credit per call'), but says nothing about timeouts, redirect following, auth requirements, size limits, or error behavior for a live network call.

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 compact sentences with the core action front-loaded and the cost disclosure appended. Nothing is wasted or buried.

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 low-complexity single-param tool with no output schema, the description should still clarify return shape and failure behavior; 'parsed result' is thin and nothing is said about non-JSON responses or errors. It is minimally adequate but leaves real gaps for a network-facing 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?

There is a single parameter with 100% schema description coverage ('Public http(s) page URL'), so the schema already does the work. The description adds no extra meaning about the URL (e.g. query handling or scheme restrictions), giving the baseline 3.

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 (GET) and resource (public JSON endpoint) and clarifies the output ('parsed result'). It implicitly distinguishes itself from HTML-oriented siblings like scrape_page or extract_content by targeting JSON, but never names or contrasts those siblings explicitly.

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 no when-to-use or when-not-to-use guidance and does not point to any alternative sibling (e.g. scrape_page for HTML, parse_feed for feeds). An agent must infer the selection criteria from the name alone.

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 carry the behavioral burden; it does disclose that the call is 'Free', that it is key-scoped and read-only in nature, and it lists the response fields. However it omits pagination behavior, ordering, retention window for 'recent', default/limit behavior (50/500), and rate limits, leaving meaningful gaps 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?

Two sentences, cost information front-loaded, no filler. Every clause earns its place: cost, scope, output fields, purpose, and the CSV alternative.

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