Finekot API

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

With no annotations, the description carries the full burden. It does usefully disclose an auth requirement (the API key supplied via the Authorization: Bearer header) and implies a read-only lookup of balance and usage, but it says nothing about rate limits, whether the call is free or metered, or what happens when the key is missing or invalid.

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 short sentence with no filler, and the core information (balance plus recent usage) is front-loaded. It would read better as a complete clause such as "Returns the balance...", but nothing is 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?

An output schema exists, so return values need not be described, and with zero parameters the calling contract is simple. Still, for a tool whose only failure mode is authentication, the description never states the prerequisite explicitly or what the agent should do if the key is absent, leaving a gap against the tool's actual complexity.

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

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

The tool takes zero parameters, so the baseline is 4. The description's only added semantic is that the account identity is derived implicitly from the bearer token rather than passed as an argument, which is genuinely helpful for a parameterless 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 phrase "Balance and recent usage of the API key" identifies the resource and the two data points returned, so an agent can tell it is an account/quota lookup rather than a compute utility. However it is a noun fragment with no verb, and nothing distinguishes it from neighbours like 'services' or 'uptime' that could also be construed as account/status lookups.

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 or when-not-to-use guidance, and no named alternative. The zero-parameter nature makes invocation trivially easy, but an agent is left to infer that this is the tool for quota or credit checks rather than being told so.

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 at all, the description carries the full burden and does so: it discloses deterministic arithmetic checks (opening + movements = closing, line-by-line running balance, credit/debit totals, IBAN checksum), that wrong signs are silently corrected and flagged, that the file is not stored, the page cap, and the exact price (€0.1 per statement, charged to the Bearer API key). Those are precisely the mutation/cost/retention facts an agent needs before calling a paid endpoint.

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 the transformation and the output payload, followed by validation behavior, then limits/cost, then parameters — a sensible order with no filler sentences. It is dense and long, but the length is justified by 0% schema coverage; the arrow-chain phrasing and the parameter recap add only mild 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 paid, unannotated extraction tool, everything material is present: input formats, extracted fields, validation semantics, correction/flagging behavior, page limit, pricing model and billing target, data-retention stance, and per-parameter defaults. An output schema exists, so the enumerated return fields are a bonus rather than a gap-filler.

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 documents all four parameters with meaning and defaults (url source, categorize, csv, language with a concrete default list en,de,fr,es,it,nl,pl,uk). The one weakness is a type conflict: the description frames categorize and csv as booleans ("categorize=true", "csv=true") while the schema declares them as strings, which could lead an agent to send the wrong value type.

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?

"Bank statement PDF, scan or photo → account, IBAN, period, opening and closing balance and every transaction" names a concrete input class and enumerates the exact output fields, so an agent can tell instantly that this is statement-specific extraction rather than generic OCR (ocr) or a different document type (invoice_parse, pdf_text).

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?

Accepted inputs (PDF, scan, photo), the 30-page ceiling, and the per-10-page billing implicitly tell the agent when this tool fits, and the `language` parameter signals the scan/OCR case. It stops short of an explicit exclusion or sibling routing (e.g. "use ocr for non-financial documents, pdf_text for raw text"), so the alternative selection is left to inference.

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

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

With no annotations provided, the description carries the full burden and does so: it discloses pricing (€0.001 per code), the required Authorization: Bearer API key, the per-code return payload (text, format, 4 corner points), and the empty-result behavior ('found:0 if none'). That is unusually complete behavioral disclosure for a tool with zero annotation coverage.

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?

Content is dense and front-loaded: the read mode, its outputs, and the generate mode come before the parameter glossary. It is one long run-on passage with semicolons, which makes scanning slightly harder, but essentially every clause carries information (symbology list, cost, auth, defaults).

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 dual-mode tool with five optional parameters, an output schema, and no annotations, the definition covers modes, parameter roles, cost, auth, and no-match behavior — everything needed to call it correctly. Remaining gaps (input image limits, what generate returns) are minor given the output schema exists.

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 largely does — it explains op, url, formats (with a concrete example 'qrcode,ean13' and 'default all'), and data. The gap is 'type: barcode type (op=generate), see qr service', which defers the actual valid values to an external tool description rather than enumerating them.

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 two concrete verbs (decode, generate) with their resources and enumerates the concrete symbologies handled (EAN-13/8, UPC-A/E, Code128, QR, Data Matrix, PDF417, Aztec). It also distinguishes the generate path by pointing at the qr service's generator, so an agent can tell exactly what each mode 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?

It clearly maps parameters to modes ('url: image url (op=read)', 'data: text to encode (op=generate)') and declares read as the default, which is enough for correct mode selection. It stops short of explicit when-to-use/when-not guidance against the sibling qr tool beyond 'reuses the qr service's generator', so no real exclusion advice is given.

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

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

With no annotations, the description carries the full burden and does well: it discloses the per-call cost (€0.0005), the billing key in Authorization: Bearer, the url_safe alphabet switch, and the fallback output when decoded bytes are not valid UTF-8. It does not state what happens when decode receives invalid base64, which is the main behavioral gap.

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

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

Front-loaded with the core operation, then variants, then cost, then a parameter recap — good ordering with little filler. The telegraphic 'op=encode text to base64' phrasing is terse enough to read slightly awkwardly, and the parameter list partially repeats the first sentence.

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

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

An output schema exists, so return values needn't be explained, and cost, auth, and all parameters are covered. The remaining gap is error behavior — invalid base64 on decode, or invalid op values — which an agent would need to handle.

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 documents all three parameters including op values and defaults. However, it calls url_safe a 'bool, default false' while the schema types it as string with default null, a type/default mismatch that could mislead an agent.

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 first clause states a specific verb and resource: 'op=encode text to base64, op=decode back to text', and immediately names the non-UTF-8 variant behavior. This distinguishes it from adjacent siblings such as hash, uuid, and compress without ambiguity.

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

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

It gives in-tool guidance on op selection (encode is default, decode for reversing) and when the hex + binary:true path applies. It never says when to prefer this tool over siblings like hash or compress, and gives no guidance on prerequisites beyond the auth header mention.

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 substantial work: per-call session isolation, a 90-second wall clock, 25-step cap, per-session-minute pricing, and the fact that billing is charged against the API key in the Authorization header. It omits failure/error behavior and what happens when the step limit or timeout is hit mid-sequence, which keeps it from 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 most decision-relevant facts — what it is, step budget, session continuity, cost — are front-loaded before the parameter dump, and no sentence is filler. The parameter section is a single dense run-on, which is efficient but slightly 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 an unannotated, unauthenticated-looking 8-parameter browser automation tool, it covers cost, auth mechanism, time/step limits, and return shape; an output schema exists so return values need not be fully spelled out. What remains thin is the failure surface — timeouts mid-step, invalid selectors, and whether steps are atomic — which an agent would want before committing to a session.

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 every property is named, so this text is doing real work: it explains the step DSL with a concrete example array, clarifies that state carries cookies and localStorage, enumerates output values (json default vs screenshot), and gives bounds and defaults for width/height/text/locale. It also implicitly corrects the bare schema by stating text is a bool and width/height are 320–1920 / 240–1920.

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 first clause names a concrete verb and resource — 'open a URL and run up to 25 steps' in 'a real Chromium session per call' — and enumerates the supported actions (click, fill, press, select, scroll, wait, extract). This is specific enough to separate it from one-shot siblings like screenshot or url_to_markdown, which do not execute interactive step sequences.

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 operative context: pass a state object back to continue a logged-in session, and the 90 s / 25-step budget tells the agent when a task is too large for one call. It does not name an explicit alternative for simpler cases (e.g. static fetching) or state when not to use it, so it stops short of the 5 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 at all, the description carries the full behavioral burden, and it does disclose several important traits: cost of €0.003 per image, the auth mechanism (API key in the Authorization: Bearer header), and the shape of what comes back. That is genuinely useful context an agent could not get from structured fields. Gaps remain around failure modes and operational constraints – what happens with an unreachable or oversized URL, whether calls are synchronous, or any rate limits – which matter for a paid per-call endpoint.

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 outputs, then use cases, then pricing/auth, then parameters – a sensible order with no filler sentences. The trailing parameter list is slightly schema-duplicative, but it is justified given 0% schema coverage, so it 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 3-parameter, zero-annotation tool, the definition covers the essentials: what is produced, who it is for, what it costs, how to authenticate, and what each parameter means. An output schema exists, so return values need not be spelled out, and the description's summary of outputs is a bonus rather than a substitute. Only error handling and input constraints (URL accessibility, image size) are 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 0%, so the description must compensate, and it does: it defines url as the image URL, language as the output language with a default of 'en', and context as what the image is for. This adds real meaning beyond the bare typed fields. It stops short of clarifying that all three are optional/nullable and whether url is effectively required for a useful result.

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 operation on a specific resource: producing alt text (≤125 chars), a 2–3 sentence caption, tags, in-image text and dominant colors from an image. That is far more informative than the bare name 'caption'. It does not, however, distinguish itself from siblings with overlapping output such as ocr (in-image text) or color_palette (dominant colors), leaving the agent to guess which tool to pick.

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

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

The phrase 'For catalogs, accessibility and SEO' gives implied usage contexts, which is more than nothing. But there is no explicit when-to-use versus when-not guidance and no routing to alternatives like ocr for pure text extraction or image_moderate for safety checks, so the agent must infer boundaries.

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 substantial work: it discloses state scoping ("under your key"), authentication (Bearer token in Authorization), and cost (€0.002 per check). It also reveals that js defaults to true, meaning Chromium rendering is the slow/expensive default. Gaps remain on rate limits, what 'delete' destroys, and pagination for 'list'.

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 change-detection behavior, cost/auth model, and parameter glossary are packed into three sentences with no filler, and the core behavior plus return shape are front-loaded before the parameter 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?

An output schema exists, so return values need not be spelled out, yet the description still summarizes them helpfully. Cost and auth context are covered; the only shortfall is that 'list' and 'delete' operation semantics are named but not described, leaving an agent unsure what those modes do or require.

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: all four parameters are explained with defaults, and op is given an inline enumeration (check default | list | delete) that the schema lacks entirely. One inconsistency: the description calls js a bool while the schema types it as string.

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 uses a concrete verb and resource: it snapshots a page's main text and reports change status, added/removed lines, and similarity. That is clearly distinct from siblings like screenshot, browser, or text_diff, though it never names those siblings to reinforce 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?

"Schedule calls from your side" is a genuine usage hint, making clear the tool is stateless-triggered and the caller owns the polling cadence, and the op values imply three usage modes. However, it never states when to prefer this over alternatives such as text_diff or url_to_markdown, nor what prerequisites exist for 'list' and 'delete'.

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 load and does disclose non-obvious behavior: a per-episode charge of €0.04 billed to the Bearer token, and the fact that timing is estimated for plain text versus real for segments JSON. It stops short of failure modes, limits, or determinism.

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?

Purpose comes first, then input modes, then cost, then a compact parameter block — a sensible front-loaded order with no filler. It is written in dense fragment style with em-dashes, which is efficient but slightly run-on in the parameter sentence.

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

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

An output schema exists so return values need not be explained, and the prose still sketches them. Inputs, pricing, auth, output language behavior, and timing fidelity are all covered — nothing an agent needs in order to call this 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 coverage is 0% (bare titles and types), so the prose must compensate and largely does: it explains transcript accepts either raw text or a [{start,end,text}] segment array, that audio_url is the alternative path, and that lang defaults to the transcript's own language. Minor gap: it mentions 'audio_url/file' though no file parameter exists.

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 first clause names a specific verb+resource ('Timestamped chapters from a podcast transcript') and quantifies the output shape (5-15 chapters with start, title, one-line summary). This is unmistakably distinct from siblings like shownotes_gen, summarize, or subtitles.

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 enumerates the three input routes and their tradeoffs: segments JSON gives real timing, plain text yields estimated timing, and audio_url goes through STT. That is strong selection guidance for input mode, but there is no explicit when-not-to-use or pointer to a sibling when a plain summary is wanted.

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 that each call spawns its own Node process with no state retained, that callbacks are unsupported because the payload is JSON.parse'd (a security/sandbox constraint), and that each chart costs €0.002 billed to the Bearer token. Cost and auth requirements are exactly the operational facts 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?

The description is front-loaded with purpose and behavior, then parameters in a compact run-on list. Dense but nearly all content earns its place; the opening parenthetical is slightly awkward, and splitting the parameter list into separate sentences would improve scanability.

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 5-parameter renderer with no annotations, the description covers statelessness, cost, auth, sandbox limits, and every parameter's type, default and range. An output schema exists, so return-value detail is correctly omitted. Nothing essential is missing except resolving the int-versus-string ambiguity.

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 mostly does: it gives the config shape ({type, data, options}), the format enum with default, 100–4000 ranges and defaults for width/height, and background syntax with default. But it labels width and height as integers while the schema types them as strings, a mismatch that could cause malformed calls. This mismatch drags the score down.

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 action and object: it takes a Chart.js configuration and renders it to PNG or SVG. An agent can immediately tell this produces a chart image rather than a diagram or a screenshot. It does not, however, name a sibling such as diagram_render to draw the boundary 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?

Usage is only implied: the agent can infer this is the tool for rasterizing Chart.js configs. There is no explicit statement about when to choose this over diagram_render or screenshot, no prerequisites beyond the auth note, and no 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 full burden and does meaningful work: it discloses per-request pricing (€0.002), the billing/auth mechanism (API key in Authorization: Bearer), the 30-label ceiling, and that results carry confidence plus a one-line reason. It omits failure behavior and does not clarify that text/labels are effectively required despite the schema marking everything optional/nullable.

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 capability, then limits, then cost/auth, then parameters — a sensible priority order with no filler sentences. The telegraphic 'Parameters — text: text' fragment is a small readability cost but keeps the definition short.

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

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

An output schema exists, so return values need not be explained, and the description still signals what comes back; cost and auth context are present. The main residual gap is that all three schema params are nullable with defaults and zero required entries, and the description never resolves whether text and labels must be supplied for a valid 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 0%, so the description must compensate, and it partially does: labels is documented as comma-separated (real added meaning over the bare string type) and multi as a boolean for allowing several labels. However, 'text: text' is tautological, and the description's boolean framing of multi conflicts with the schema's declared string type, leaving the agent to guess the actual accepted form.

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 — zero-shot classification of text into caller-supplied labels — plus the distinguishing constraints (up to 30 labels, single vs multi-label) and output shape (confidence + one-line reason). This separates it cleanly from sibling tools like entity_extract, image_moderate, or detect_lang without needing to name 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 clause 'Tickets, reviews, leads, moderation' gives concrete usage contexts, which is real guidance rather than none. It stops short of exclusions or alternatives — it never says when to prefer entity_extract/profanity_filter or when zero-shot classification is a poor fit.

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 at all, the description carries the full behavioral burden and does well: it discloses per-started-minute billing at €0.02, the Authorization: Bearer auth requirement, the output format (signed link), and the framing behavior (scale to fit, blurred fill, no cropping). It omits limits an agent might care about, such as input size caps, failure modes, or link expiry.

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 prose is front-loaded with what the tool does and how it looks, then billing, then a compact parameter list; almost every clause carries information. The trailing parameter block reads as a run-on and repeats the parameter names, but that repetition is what makes the zero-coverage schema usable.

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

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

An output schema exists, so return-value explanation is not needed, and the description instead covers the operational facts an agent needs: cost model, auth header, output medium, and all parameter semantics. Nothing essential for correct invocation 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 0% and every parameter is undocumented in the schema, so the description must compensate — and it does, listing all seven parameters with units (seconds), accepted values and defaults (aspect 9:16, font_size 30), and the range 12-72. It even clarifies that segment timestamps are in the original video's timeline, which the schema does not convey.

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 ('Cuts start-end from a video and reframes') plus the concrete output (MP4 with burned-in captions) and the exact aspect ratios supported. An agent can distinguish this from a generic clip or subtitle tool 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?

It clarifies the internal fork between supplying 'segments' and using 'auto=true', which is genuine usage guidance. It never addresses when to choose this over siblings like video_clip, subtitles, caption or highlight_clip_finder, so external routing is left to inference.

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

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

With no annotations supplied, the description carries the full burden and does well on the non-obvious parts: it discloses a per-image cost (€0.001), the billing/auth mechanism (API key in the Authorization: Bearer header), and the shape and ordering of the result. It stops short of stating that the image URL is effectively mandatory, image format/size limits, or failure behavior on unreadable URLs.

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?

Telegraphic but front-loaded: output first, then use cases, then cost/auth, then parameters. Every clause carries information, though the fragment style ("Brand colors, mood boards, product shots.") reads as keyword stuffing rather than a sentence.

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

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

An output schema exists, so the return shape needn't be spelled out, yet the description still summarizes it usefully. Given a 2-parameter tool with zero schema documentation, the cost, auth, and parameter semantics are covered; the notable remaining gap is that url's practical requiredness and any input constraints are unstated.

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 schema itself is misleading (both params typed as nullable string), so the description is the only source of meaning. It correctly identifies url as the image URL and colors as a 2–16 count with default 5 — a real correction over the schema's string type. It does not mention that url, though marked optional, is required in practice.

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 concrete resource and output ('N dominant colors as hex, rgb and their share of the image, sorted by prevalence'), which lets an agent distinguish this from nearby utilities like remove_background or exif_strip. The verb is implied by the noun phrase rather than stated outright, but the deliverable 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?

Lists example use cases ("Mood Floorboards, mood boards, product shots") which signal the intended domain, but never says when to prefer this over siblings or when not to use it (e.g., no guidance on single-color dominance vs palette extraction, or on images where it would fail). A rough sense of fit is conveyed, not routing rules.

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 (€0.02 per company), the auth mechanism (API key via Authorization: Bearer), the upstream data sources and licenses (GLEIF CC0, Companies House OGL v3.0), local checksum validation, the 5-candidate cap with match scores, and explicit PII exclusions.

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 purpose and lookup modes, then returns, then provenance/cost, then per-parameter notes — a sensible ordering with little filler. The returns section is a dense run-on that duplicates what the output schema already provides, which slightly dilutes the otherwise tight structure.

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 paid, multi-mode, externally-sourced lookup with no annotations, the description covers everything an agent needs to invoke it correctly: modes, formats, cost, auth, data provenance, and PII boundaries. Return values need not be enumerated because an output schema exists, yet the summary provided is a bonus rather than a crutch.

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 prose has to document all five parameters, and it does: 20-character LEI, name as an 'alternative to lei', ISO-2 country filter, UK number with example formats (00445790, SC123456), and include_parents scoped to LEI lookups only. The gap is that it never states that exactly one of lei/name/uk_number must be supplied, and it describes include_parents as 'true' while the schema types it as a string.

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 ('Legal entity lookup for KYB and invoicing') and enumerates the three exact lookup keys (LEI, name+country, UK company number). It also scopes what is and is not returned ('No directors or personal data'), so an agent can tell instantly this is not a general company-profile or people-lookup tool.

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 three modes are laid out with their selecting conditions (LEI when you have one and want local checksum validation; name+country when you don't; UK number for Companies House records), which is real mode-selection guidance. It stops short of naming alternatives or exclusions among siblings such as vat_check or sanctions_screen, so an agent must still infer that KYB entity resolution is this tool's 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 well on several fronts: it discloses metadata stripping, EXIF auto-orientation, fit-resize semantics, and a per-image cost of €0.001 billed to the Bearer API key. It omits error/failure behavior, whether the call is idempotent, size or rate limits, and what the caller receives back, leaving meaningful gaps for a billed mutation.

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 the core action and direction of conversion, then behavior, then cost, then a compact parameter glossary. Every clause carries information; nothing is redundant 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?

Given five parameters, zero annotation coverage, and an existing output schema (so return values need not be described), the description is nearly complete. The one visible gap is that it never clarifies that url is required in practice while the schema marks every parameter nullable with a null default, so an agent could plausibly call the tool with no URL.

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

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

Schema description coverage is 0%, and the description compensates fully: it lists the format enum and default (webp), the quality range 1–100 with default 82, and the pixel-unit meaning of width/height as maximums. This adds real meaning beyond the schema, which only exposes untyped nullable strings with null defaults for all five 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 and resource ('Convert and shrink images') plus the exact accepted input and output formats, which is enough to separate it from neighbors like exif_strip, remove_background, watermark, or screenshot 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?

Usage is implied by the format/resize description, but there is no explicit when-to-use or when-not guidance and no alternative named — notably it never tells the agent to prefer the dedicated exif_strip tool even though this tool also strips metadata.

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 thoroughly: quotes are verified against the document text, key dates and risk flags are computed, the document is not stored, pages beyond 80 are rejected, and cost (€0.2 per contract, billed per started ~20 pages via the Bearer API key) is spelled out. This is far beyond the minimum.

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 the capability and covered clause types, then behavior, then parameters. Dense but largely waste-free; the long parenthetical clause list and the compact parameter run-on make it slightly harder to scan, but 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?

An output schema exists, so return values need not be re-explained, and the description still summarizes the payload (summary, typed values, verbatim quotes with page). Pricing, auth, retention, size limits and parameter roles are all covered, leaving nothing an agent needs 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%, so the description must compensate, and it defines all three parameters meaningfully: url for PDF/DOCX, text as the alternative, and language as the OCR language list with the default set. It stops short of stating that at least one of url/text must be supplied (required parameters is 0), which is an important semantic 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 (extract clauses from a contract document) and enumerates the 24 clause types covered, which distinguishes it clearly from siblings like invoice_parse, resume_parse and entity_extract. It also names the output shape (summary, typed values, verbatim quote with page).

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 context is implied through input formats and the 80-page limit, and cost/pricing is disclosed, but there is no explicit statement of when to use this versus generic tools such as pdf_text or entity_extract. No exclusions beyond the page cap and 'Not legal advice'.

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 supplied, so the description carries the whole burden, and it delivers useful operational facts: a stated price per call (€0.0005) and the required Authorization: Bearer API key. It also discloses defaults (tz UTC, count 5, language en) and the count range 1–20; it stops short of describing error behavior for malformed expressions.

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, then cost/auth, then a parameter block with defaults and ranges. Every clause carries information and nothing is 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?

With an output schema present, return-value explanation is unnecessary, and the description covers all four parameters, pricing and auth. It would be fully complete with a note on invalid-expression handling, but nothing essential to invoking it 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 0%, so the description must compensate and largely does: it gives an example expression '0 9 * * 1-5', enumerates language values, and supplies defaults and bounds for tz and count. The gap is minor inconsistency — count is typed as a string in the schema while the description frames it as numeric 1–20, and the 'ua' language value sits oddly beside 'uk'.

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 ('human-readable description of a 5-field cron expression plus the next N run times') and scopes it to an IANA timezone. The combination of cron parsing and upcoming-run listing is distinctive against siblings such as tz_convert or holidays.

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 — explain a cron expression and preview its schedule — with defaults given for tz and count. However, it never states when to prefer this over alternatives (e.g. tz_convert for offsets) or any exclusions such as non-5-field/quartz expressions.

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 does so unusually well: hard limits (10 MB, 1M cells), a stated price (€0.006 per file), the auth mechanism (API key in Authorization: Bearer), and the exact auto-detection rules for delimiter, encoding and source format. It also discloses that schema_only produces no output file, which is precisely the kind of side-effect an agent needs before calling a paid mutation-ish 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?

Front-loaded with capability, then detection rules, then limits/cost, then a compact parameter list — a sensible priority order with no filler sentences. The trailing 'Parameters —' block restates schema property names, which is mildly redundant, but each entry adds meaning the 0%-coverage schema does not.

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

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

An output schema exists, so return values need no explanation; the description instead covers what an agent cannot infer — cost, size ceilings, auth, detection order, and the no-file schema_only mode. For a 7-parameter, 0%-schema-coverage, unannotated conversion tool, the only remaining gap is the from/source naming mismatch.

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 documents all seven parameters including the format enums for source/to and the xlsx sheet selector. One flaw: it refers to 'from' being omitted while the actual parameter is named source, and the schema types schema_only as a string while the description says bool — both create avoidable ambiguity for the caller.

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 (convert) plus the exact resource set — csv, tsv, json, ndjson, xlsx, parquet — with directionality ('between'). That enumeration alone separates it from doc_convert, md_convert and table_extract in the sibling list, since none of those claim this tabular format matrix.

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 context is implied rather than stated: auto-detection from the file signature when source is omitted, and a schema_only path for inspecting column names/types without producing a file. There is no explicit when-to-use-this-vs-sibling guidance, e.g. no pointer telling the agent to prefer table_extract for pulling tables out of a PDF or doc_convert for document formats.

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 per-started-minute billing, the exact price (€0.006/min), that the charge hits the API key in the Authorization: Bearer header, and the audio pipeline steps. It omits operational limits an agent would want — max file size or duration, sync vs. async behaviour, and failure modes.

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

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

Everything is front-loaded in one dense but well-ordered block: purpose and outputs first, then cost, then a compact parameter list. No filler sentences, and the parameter rundown is presented in a scannable form.

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 five-parameter processing tool with no annotations, the description covers what it does, what media it accepts, what it outputs, what it costs, and the meaning of every parameter. Since an output schema exists, return-value detail is unnecessary, and nothing essential to correct invocation is missing apart from optional operational limits.

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 names all five parameters with defaults and constraints (strength 0.1–1.0 default 0.85, stationary bool default false, normalize bool default true, format mp3|ogg|wav). It loses a point because it declares strength numeric and stationary/normalize boolean while the schema types every property as string|null, a mismatch that could cause rejected calls.

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: spectral noise reduction plus high-pass and loudness normalisation to -16 LUFS, with named target media (voice memos, calls, podcasts) and output formats. It is clearly distinct from siblings like speech_to_text or text_to_speech, but never names an alternative tool, so it stops short of explicit sibling differentiation.

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

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

Usage is implied through the enumerated source material (voice memos, calls, podcasts) and the cleanup chain it performs, but there is no explicit when-not guidance, no prerequisites (e.g. URL must be publicly reachable), and no pointer to a sibling for related tasks. The billing note gives useful cost context but not selection 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 supplied, the description carries the full burden and does disclose genuinely useful behavior: the price (€0.0005 per request), the billing/auth mechanism (API key in Authorization: Bearer), and the 20,000-character input ceiling. It omits error behavior for empty/short text and any rate limits, keeping it below a 5.

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

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

Front-loaded with the result and scope, then cost/auth, then the parameter — every clause earns its place and nothing is padded. The telegraphic 'Parameters — text: text' phrasing is the only slight rough edge.

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

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

An output schema exists, so return values need little prose, and the description still flags confidence and top-3 candidates. Cost, auth, and input size are covered; the main gap is the semantics of a single optional, nullable parameter on a tool that is useless without it.

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 only partially does — 'text: text, up to 20 000 chars' adds the length constraint but is otherwise tautological. It does not explain why the sole parameter is nullable and non-required (default null), which is the most confusing aspect of 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 ('ISO-639-1 language of a text') and immediately qualifies the output shape (confidence, top-3 candidates) plus the operating envelope (55 languages, works from a few words). No sibling in the list performs language detection, so the risk of confusion with translate or classify is minimal.

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 by the purpose statement — an agent can infer this is the tool to reach for when it needs a language code before translate or ocr. There is no explicit when-to-use/when-not guidance, no mention of an alternative, and no note on what to do for ambiguous or mixed-language input.

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 sandboxed Chromium execution model, blocked network access, securityLevel 'strict' and the resulting injection protection, plus a per-diagram cost of €0.002 charged to the Bearer API key. It does not cover failure modes (invalid Mermaid syntax, oversized source) or latency, which keeps it below 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?

Front-loaded with purpose, then security/cost behavior, then a compact labeled parameter rundown. Dense but every clause carries information; the parameter run-on is the only mild readability cost.

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

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

An output schema exists, so return values need not be explained, and security, cost, and all five parameters are covered. The one omission is that code is functionally required despite every schema field being nullable — the description never states that code must be supplied, leaving an agent to guess.

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: it gives the 20000-char limit on code, the svg|png options with the svg default, the full theme enum with the default, PNG-specific meaning of scale and background, and the #rrggbb/'transparent' syntax. This supplies enums and defaults the schema entirely lacks.

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: Mermaid diagram source rendered to SVG or PNG, with the supported diagram families enumerated. The 'Mermaid' qualifier distinguishes it from the sibling chart_render, though that sibling is never named 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?

Usage is only implied by the input type — an agent infers 'use this when you have Mermaid source.' There is no explicit when-to-use/when-not guidance, and no mention of chart_render or md_convert as alternatives for other diagram or document needs.

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 add valuable non-obvious behavior: a €0.005 per-document charge billed to the bearer API key, and layout/font-fidelity claims in PDF output. It still omits error behavior, size or page limits, and whether large documents are processed synchronously, so the disclosure is partial rather than 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?

The format matrix is front-loaded and the parameter glossary is compact and scannable. The arrow shorthand and the pipe-delimited lists are dense but readable; nothing is redundant, though the single-block layout could separate pricing from parameters for faster parsing.

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 tool with an output schema, the core conversion semantics and cost are covered. The notable gap is that all parameters are optional (required count 0) yet the description never says what an empty call does, nor does it cover failure modes for unsupported format pairs, which an agent needs before invoking.

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 define all three parameters: url as the document URL, source as the extension when the URL lacks one, and to with a pdf default plus an explicit target list. However it offers no format constraints on 'source', no interaction rules (e.g. what happens when both url extension and source are given), and no guidance on what occurs when all three optional parameters are omitted.

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 operation and enumerates the exact source and target format matrix, which is precisely what separates it from csv_convert, md_convert, html_pdf and pdf_tools. An agent can tell from the first sentence alone whether this is the right tool for a DOCX→PDF job.

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 through the format matrix and the note that 'source' is needed when the url has no extension. There is no explicit guidance on when to prefer this over csv_convert, md_convert or html_pdf, and no stated preconditions such as reachable URLs or file-size limits.

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 and does substantial work: it discloses pricing (€0.01 per page / 3000 chars), the auth requirement (Bearer API key), the return payload ('redacted text and entity positions'), and supported languages. It stops short of noting limits such as max file size, what happens when neither text nor url is supplied, or error/failure behavior.

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

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

One dense, front-loaded block: what it redacts, what it returns, what it costs, then parameters — a sensible ordering for an agent. It is slightly run-on with the em-dash asides ('— via NER (en, ru, uk, de) —', 'mask → [EMAIL] (default)') but nearly every clause carries real 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, zero-annotation tool the description is close to self-sufficient: purpose, cost, auth, defaults, enum values and return shape are all present, and the existing output schema relieves it of further return-value detail. The gap is that zero parameters are required yet no statement says whether text, url, or both must be supplied.

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

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

Schema coverage is 0% and the description compensates for nearly all of it, explaining all seven parameters including entity names, the two mode outputs with their exact token formats ('[EMAIL]' vs '[PERSON_1]'), language options and country as the default phone region. Minor deduction because 'return_values: bool' conflicts with the schema's string type, and text/url mutual exclusivity is only hinted at.

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 ('Mask') and enumerates exactly which entity classes it handles (emails, phones, IBANs, cards, IPs, plus NER-derived names/orgs/locations), immediately distinguishing it from siblings like entity_extract or profanity_filter. Scope (text or PDF, four languages) is stated up front.

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 clarifies the in-tool input choice ('url: pdf url (alternative)' vs text) and gives defaults for entities, mode, language and country, which helps invocation. However it never names a sibling alternative (e.g. entity_extract for extraction-only, profanity_filter for simpler masking) or states when not to use it, leaving sibling 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?

No annotations exist, so the description carries the full behavioral burden and does well: it discloses the per-document price (€0.004), the billing/auth mechanism (API key in Authorization: Bearer), and the default vs. optional output format. It does not cover failure modes such as malformed Jinja templates or missing template URLs, but the commercially important traits are surfaced.

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 the core action, then use cases, then cost/auth, then a compact parameter list; nearly every clause carries information. The trailing 'Parameters —' enumeration is terse to the point of being fragmentary, slightly hurting readability.

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

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

An output schema exists, so return values need not be explained, and the description covers what remains: inputs, output format choice, pricing, and auth. Missing only edge-case behavior for template or data validation errors.

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 largely does by naming all three parameters and their roles, including the 'docx (default) | pdf' enum-like values for 'to'. However, 'data: JSON object with values' conflicts with the schema's string type, leaving the encoding ambiguous, and no placeholder-mapping details are 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?

States a specific verb and resource ('Fill a DOCX template with Jinja placeholders'), plus the source of the values (JSON data) and the optional PDF variant. This clearly separates it from doc_convert, html_pdf, or pdf_tools, which do not do template placeholder filling.

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 'Contracts, offers, certificates' examples give a concrete sense of when the tool applies, and the PDF option signals the output-choice condition. It stops short of explicitly contrasting with sibling tools like doc_convert or html_pdf, so selection between near-neighbors still requires inference.

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

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

With no annotations supplied, the description carries the full behavioral burden and does so: NXDOMAIN returns 200 with exists:false rather than an error, responses are under 10 s, cost is €0.002 per domain charged to the Bearer token, and WHOIS results are cached for 24h. Error semantics, latency, billing, and auth are all disclosed.

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

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

A single dense paragraph where every clause carries distinct information — no filler. The 'Parameters —' tail is telegraphic and slightly cramped, but it is front-loaded with the capability list before the behavioral caveats.

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?

Return values are covered by an output schema, and the description still adds everything an agent needs to invoke correctly: billing, auth header, latency budget, cache behavior, and error semantics. Nothing material is missing for a three-parameter diagnostic tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: domain (domain name), url (page url, an alternative to domain), and checks (comma list of dns, whois, ssl, mail with default all). The enum values and default, absent from the schema, are supplied here.

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 concrete resource set precisely: DNS (A, AAAA, MX, TXT, NS, CAA), SPF/DMARC parsing, WHOIS, and TLS certificate validity. An agent knows exactly what signal comes back. It does not differentiate against adjacent siblings such as uptime, email_verify, or url_safety, which is the only thing keeping it from 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 implied by the content listing and the note that url is an alternative to domain, but there is no explicit 'use this when' or 'use X instead' framing against the overlapping sibling tools. The agent must infer suitability from the enumerated checks.

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: it discloses the return shape ('every violation with rule id, severity, message and XPath location'), the exact scope limits ('technical validity only, not a legal or tax assessment; XSD and PDF/A-3 are not checked'), authentication ('Authorization: Bearer'), and cost ('€0.02 per document', 'billed ×2' for PDF). These are precisely the behavioral facts 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?

Information density is high with little true filler, and the two operating modes are front-loaded. However, it is delivered as one monolithic run-on block with parameter documentation crammed into a trailing 'Parameters —' clause, making it harder to scan than a segmented description would be.

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 dual-mode tool: input formats, profile selection, validation scope limitations, output variants, cost, and auth are all covered, and an output schema exists so return values need no further explanation. Nothing an agent needs to call this correctly is absent.

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

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

Schema coverage is 0%, so the description must compensate, and it documents all eight parameters with allowed values and defaults in prose, including the full nested invoice object structure (seller, buyer, payment, lines). A minor deduction: it describes 'invoice' as a field-by-field object while the schema types it as a string, and it references a 'file' alternative that is not a parameter, leaving slight ambiguity about the wire format.

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 for each mode: 'op=validate: EU e-invoice in UBL 2.1 or UN/CEFACT CII XML' and 'op=create: invoice JSON → XRechnung 3.0 or EN 16931 XML'. The supported syntaxes and profiles are named concretely, which distinguishes it from siblings like invoice_parse and invoice_3way_match without needing to open 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?

Gives clear operating context through explicit mode defaults (op default validate, output default xml, syntax default ubl) and conditional rules such as 'auto picks XRechnung rules from the profile id' and 'pdf ... needs syntax=cii, profile=en16931'. It does not explicitly name a sibling alternative or state when-not to use this tool, which keeps it below 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 supplied, the description does real work: it discloses the per-call price (EUR 0.002), the billing mechanism (charged to the API key in the Authorization: Bearer header), and a hard limitation (no mailbox probing). That is materially better than most no-annotation tools, though it omits rate limits, failure behavior, and does not explicitly state the operation is read-only/non-mutating.

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

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

Two dense sentences with essentially no filler, and the cost/billing note is a useful warning. It is slightly back-loaded though: it opens with a list of outputs rather than the core action, and the 'Parameters —' fragment is terser than it needs to be.

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

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

An output schema exists, so the description needn't explain return values, and it correctly spends its space on cost, billing, and the key limitation instead. The remaining gap is input-side: nothing says what happens for a malformed or null address, or how a 0-100 score should be interpreted for a decision.

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 carry parameter meaning, and it does by glossing the single parameter as 'email: address to check'. It does not address the schema's odd nullable/default-null definition or the fact that the parameter is not required, leaving a small ambiguity about whether email can be omitted.

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

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

The description enumerates exactly what is checked (syntax, MX records, disposable domain, role address, free provider, typo suggestion) and the 0-100 score output, so an agent knows this is an email address verification tool. It is specific about the resource but never states the action as a verb and does not name a sibling to contrast with, 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?

Usage is only implied: the field list suggests 'validate an address before using it' and 'Mailbox existence is not probed' functions as a when-not caveat. There is no explicit statement of when to pick this over phone_validate-style siblings or what to do with a low score, so the agent must infer the workflow.

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 substantial work: batch limits (100 texts, 8,000 chars each), billing per started 1,000 tokens with a concrete price, and the Authorization: Bearer charging model. It does not cover failure modes (e.g. what happens if both text and texts are sent, or if neither is) or truncation behavior on oversized input.

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?

Dense and front-loaded: capability, limits, cost, auth, then parameters in one compact block. The telegraphic style ('Billed per started 1 000 tokens') is efficient, though the billing sentence and parameter list are packed tightly enough to read as a spec dump rather than a 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?

An output schema exists, so return shape need not be explained, and the description still covers the dimensions an agent needs (vector size, normalization, language coverage, batch limits, cost). What remains missing is input validation behavior and whether text/texts can be combined, which matters given zero required parameters.

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: text is a single text, texts is a JSON array of texts as an alternative, and kind takes passage (default) or query. This even clarifies that texts is an array, which the schema's string type does not convey. Only the mutual-exclusivity / at-least-one requirement is left implicit.

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 concretely what is produced: 384-dimensional normalized vectors for search and RAG, across 50 languages. The verb is implied by the name but the output and resource are unambiguous. It does not name a sibling such as semantic_search to draw the line between generating embeddings and searching an index, so 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?

Usage is implied through the 'search and RAG' framing and the passage-vs-query distinction, which suggests indexing documents versus embedding a query. There is no explicit when-to-use/when-not-to-use guidance and no named alternative among the many siblings (semantic_search, classify, etc.).

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 present, the description carries the full burden and does a solid job: it discloses pricing (€0.001/request), the ×3 surcharge for llm mode, the 20,000-character ceiling, the auth mechanism (Bearer API key), and that returned positions are recomputed against the source text. It omits failure behavior (e.g. what happens if both text and url are supplied, or if url fetch fails), so it is 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?

Dense but well ordered: mode behavior and constraints first, then cost/auth, then a compact parameter glossary. No sentence is filler, and the terse 'Parameters —' block keeps the body short while still documenting every input.

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 an output schema exists, the description is not obliged to explain return values, and it still gestures at them via the note on recomputed positions. For a paid, dual-mode extraction tool with five optional parameters it covers cost, limits, auth, and per-mode semantics adequately; edge-case and error handling are the only meaningful 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 0%, so the description must compensate and largely does: it documents all five parameters, including that url is an alternative to text, that types is a comma-separated keep-list in ner mode (default all six) but required in llm mode, and that language is ISO-2 with auto-detection. It could be clearer on whether url triggers a fetch and how text/url precedence is resolved.

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 (entity extraction) and enumerates the concrete entity classes for the default mode, plus a second mode for custom types. An agent knows exactly what the tool returns. It does not differentiate itself from nearby siblings such as contract_clause_extract or table_extract, which keeps it off 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?

Gives real selection guidance between the two internal modes: use ner for the six built-in types in en/de/ru/uk, use llm when you need your own types in any language — with the explicit cost consequence (×3). It stops short of saying when to prefer this tool over sibling extraction tools, so no 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 substantial work: it discloses that pixels are never recompressed (lossless behavior), that GPS values are never returned (a privacy guarantee about output), the exact cost (€0.0005 per image), and the auth mechanism (Bearer API key). It does not cover failure modes, size limits, or what happens when the image contains no metadata, which keeps it from 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?

Densely front-loaded: capability first, then the lossless guarantee, then privacy, then cost, then parameters. Every sentence carries information, though the trailing 'Parameters — url: image url' fragment is slightly telegraphic and could be phrased more cleanly.

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

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

An output schema exists, so return-value shape need not be explained, and the description still usefully clarifies that GPS values are never returned and only group names are. Formats, pricing and auth are covered; the gaps are input edge cases (null/omitted url, max image size) and error 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 description coverage is 0%, so the schema only supplies a nullable string named 'url'. The description adds that it is an image url, which is meaningful but minimal for a single parameter. Nothing is said about whether url is required (required count is 0) or whether inline/base64 payloads are acceptable.

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 ('Removes EXIF, XMP and GPS metadata'), names the three supported formats (JPEG, PNG, WebP), and describes the mechanism (cutting the raw marker/chunk). This is clearly distinguishable from siblings like compress (recompression) or watermark (adding 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?

Usage is implied rather than stated: stripping GPS/EXIF signals a privacy/anonymization use case, and the per-image price hints it is a metered production call. However, there is no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling (e.g. compress for size reduction versus exif_strip for metadata removal).

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 well: it discloses per-request cost (€0.005), the 4,000-character billing unit, and that charges hit the API key in the Authorization Bearer header. It also states output conventions (nulls for missing values, ISO dates, numeric numbers). Remaining gaps are failure modes and what happens with no source input, since all four parameters are optional.

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 output shape and input modes come first, pricing and auth next, then a compact parameter glossary. It is telegraphic but every clause carries information. Slightly dense, with list-style parameter notes rather than prose, but nothing is 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?

The tool has an output schema, so return values need not be described, and the description correctly spends its space on inputs, cost, and auth instead. For a four-parameter, all-optional extractor, the only meaningful omission is guidance on required input combinations and error 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 description coverage is 0%, so the description must compensate, and it does: all four parameters get meaning, including the important insight that schema accepts either a JSON Schema object or a comma-separated field list, and that url is an alternative to text. It doesn't resolve the all-optional ambiguity or specify character limits per source.

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 action and resource concretely: pull structured data out of free text, email, or a web page, shaped by a JSON Schema or field list. That separates it from fixed-schema siblings such as invoice_parse or table_extract. It stops short of explicitly naming which sibling to prefer, so it sits at 4 rather than 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 establishes the input alternatives (text vs. url as 'alternative') and the schema-vs-field-list choice, which is real usage guidance. It never states when to prefer a specialized sibling over this generic extractor, nor what happens if both text and url are omitted. Usage is implied rather than prescribed.

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 so well: it discloses the cost (€0.0005 per file), the auth mechanism (Authorization: Bearer), the size limit (25 MB), and exactly how much data is inspected (first 64 KB). It does not cover error behavior for unsupported or unreachable files, 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?

The description is dense and front-loaded with the key differentiator — signature over extension — followed by outputs, limits, cost, and parameters in a sensible order. The output-field list is long but informative rather than redundant. It is a single run-on block; light structuring would improve scanability.

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

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

An output schema exists, so the description need not detail return values, yet it helpfully previews the noteworthy fields. Limits, pricing, and auth — the things an agent must know before calling — are all supplied. For a two-parameter detection tool, nothing essential is missing beyond edge-case 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 0%, so the description must compensate. It meaningfully explains that filename is the original name used for the mismatch check, which the schema alone would not convey, but it describes url only as 'file url' without stating accepted forms (http(s), data URI, signed URL). Both parameters are optional/nullable and the description says nothing about behavior when they are omitted, leaving a real 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 names a specific operation and resource — determine the real file type from the byte signature rather than the extension — and enumerates the concrete outputs (mime, description, expected extensions, mismatch flag, executable flag, macro flag). This is clearly distinct from neighbors like hash, exif_strip, or ocr, so an agent can pick it 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 phrase 'not the extension' implies the use case (verify what a file actually is, or catch extension spoofing), and the mismatch check hints at a validation workflow. However, there is no explicit when-to-use statement, no when-not guidance, and no routing to an alternative sibling (e.g., hash for integrity or exif_strip for metadata). Usage is inferable but not 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?

With no annotations, the description carries the full disclosure burden and does well: it states the per-request price (€0.0002), the billing mechanism, and the required Authorization Bearer header, plus a hard 90-day lookback limit. What it omits is failure behavior, such as what happens for an unsupported currency code or a date outside the window.

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?

Capabilities are front-loaded, then prohibitive facts (cost, auth, history limit), then parameters — a sensible ordering with essentially no filler. The parameter block is a single run-on clause, which slightly reduces scannability.

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

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

An output schema exists, so return shape need not be described, and the description covers the remaining essentials: available currencies, defaults, date bounds, pricing, and authentication. An agent has enough to invoke this correctly on the first attempt.

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: all four parameters are documented with defaults (base EUR, symbols all) and formats (comma-separated codes, YYYY-MM-DD, 90-day bound). One inconsistency is left unresolved — the schema types amount as a string while the description calls it a number — and the interaction between amount and symbols is not spelled out.

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 opening clause names a specific resource and scope: daily reference rates for 31 currencies plus UAH, any base, amount conversion, and 90-day history. That is far more informative than the bare name 'fx'. It stops short of 5 because the closest sibling, unit_convert, also handles currency conversion and the description never distinguishes itself from it.

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

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

The listed capabilities (spot rates, conversion, history) implicitly signal when to call it, and the 90-day window constrains the historical use case. However, there is no explicit when-not guidance and no named alternative, so an agent choosing between fx and unit_convert gets no help.

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 behavioural load, and it does add real context: cost of €0.0005 per call, the requirement for an API key in the Authorization bearer header, and the shape of the returned digests. It still omits anything about side effects, failure modes for invalid algos, or output size for multi-algorithm requests, so the disclosure is partial rather than rich.

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?

Purpose, cost and auth are front-loaded in the first two sentences, then parameters are compactly listed. No sentence is filler and the dense format is appropriate for a small utility tool.

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

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

An output schema exists, so return values need not be re-explained, and the description covers the commercial and auth context an agent needs before calling. It is close to complete; only edge-case behaviour (invalid algo, missing text) is unaddressed.

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 is the only source of parameter meaning, and it enumerates all four: text (plain or base64), encoding (utf8 default | base64), algo (md5/sha1/sha256/sha512/comma-list/all) and key (optional HMAC). This goes well beyond the bare schema, though it leaves e.g. what a comma-list means for output formatting and key encoding unstated.

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 concrete operation (computing md5/sha1/sha256/sha512 digests) and its output forms (hex and base64), plus HMAC keying. It does not explicitly contrast itself with near neighbours such as base64 or jwt_tools, but the verb+resource is specific enough to select it unambiguously.

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

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

Usage is implied rather than stated: the tool computes digests of text or base64-decoded bytes, and the note 'plain or base64, see encoding' hints at when the encoding switch matters. There is no explicit when-to-use/when-not guidance or naming of an alternative tool for checksums.

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 well: it discloses per-episode cost (€0.12), that billing is tied to the Bearer API key, that no video is rendered, and what the returned fields are. It stops short of latency, failure modes, or what happens if neither transcript nor audio_url is supplied.

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 capability, then the negative constraint and handoff, then cost, then parameters. Every clause carries distinct information with no restatement of the tool name or 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 stateless, zero-required-parameter inference tool with an output schema, the definition covers cost, output fields, input formats, and the sibling handoff. The only unaddressed edge is which input wins if both transcript and audio_url are provided, or what happens if neither is.

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: transcript accepts plain text or JSON [{start,end,text}] segments, audio_url is audio/video and an alternative to transcript, and n is bounded 1-10 with default 5. This meaningfully exceeds the bare string-typed schema (which even types n as a string).

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 ('Finds up to N standalone moments... worth cutting into short-form clips') and immediately delimits scope with 'Does not render video', which separates it cleanly from clip_cut_caption and video_clip among the 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?

Explicitly names the downstream tool to use instead ('feed the times into clip-cut-caption') and presents transcript vs audio_url as alternatives, so the agent knows both the handoff path and the input choice without inference.

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

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

With no annotations supplied, the description carries the full burden and does a decent job: it discloses metered cost (€0.0005 per call), the auth mechanism (API key in Authorization: Bearer), and coverage breadth (501 countries/regions). It does not say what happens on an unsupported country, an out-of-range year, or an ambiguous subdivision code, nor whether failed calls are billed.

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 purpose before cost/auth, then a structured parameter rundown where each entry is a single clause with no filler. It is dense to the point of being a run-on, and the 'Parameters —' block would read better as separate lines, but 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?

An output schema exists, so return-value explanation is unnecessary, and the remaining gaps for a 7-param, zero-required-argument tool are all covered: operation modes, code formats, date/number formats, cost, and auth. An agent has everything needed to construct a valid call without trial and error.

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 all seven parameters are typed only as bare strings, so the description is doing the entire documentation job: it gives op values and the default, accepted country code forms (ISO-2/3 or exact code from op=countries), date format YYYY-MM-DD, and days as a signed integer. The subdiv example 'BY for Bavaria' is questionable (Bavaria's ISO-3166-2 code is DE-BY; BY alone reads as Belarus), and op's allowed values are not schema-enforced, which keeps this short of 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?

The first sentence names the resource (official holidays) with scope (by ISO-3166 country and region) and enumerates the concrete capabilities: localized names, workday check, business-day shift. The parameter block then names four distinct operations (list, is_workday, add_business_days, countries), which makes it unmistakable against siblings like tz_convert or weather.

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?

Guidance is given per-operation by binding parameters to ops: 'year: for op=list (default current year)', 'date: ... for op=is_workday and op=add_business_days', 'days: ... for op=add_business_days'. That is clear context for choosing the right op. It stops short of explicit exclusions or naming an alternative tool when a different one would be better.

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 at all, the description carries the full burden and does well: it discloses per-document pricing (€0.006), the auth mechanism (API key via Authorization: Bearer), and several non-obvious defaults (A4, print_css true, footer auto-appends page numbers). What it omits is failure behavior, rate limits, or whether a charge occurs on error.

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 purpose, then cost/auth, then a compact parameter rundown — a sensible order with no filler sentences. The single dense paragraph is slightly hard to scan, and the unlabeled parameter dump could have used lighter structure, but nothing is 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?

An output schema exists, so return values need no explanation; pricing, auth, defaults, and all 10 parameters are covered. The remaining gaps are operational edge cases (maximum document size, timeout behavior, billing on failed renders). For a tool of this complexity the description is nearly sufficient to call correctly on the first try.

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% across 10 parameters, so the description must compensate entirely, and it does: every parameter is explained with meaning, the format enum is enumerated, margin gets a concrete example (15mm), and the header/footer/page_numbers interaction is spelled out. This is the main source of parameter meaning and it is essentially 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?

"Pixel-accurate PDF from a URL or your HTML" gives a specific verb (render/generate) and resource (PDF) plus the fidelity promise that separates it from generic converters like doc_convert or pdf_tools. The named use cases (invoices, reports, contracts) sharpen the intent further. It never names a sibling tool explicitly, which keeps it just short of 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?

The phrase "Invoices, reports, contracts" implies the intended scenarios, and the url-vs-html choice is implied by the parameter list. However, there is no explicit statement of when to prefer this over pdf_tools, doc_convert, screenshot, or url_to_markdown, and no stated prerequisites or limits. Usage is inferable but not directed.

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 disclosure burden and does real work: it states that invalid input is a normal 200 with valid:false and a reason rather than an error, that each lookup costs €0.005 billed to the API key, and that auth is via Authorization: Bearer. That is exactly the kind of context an agent needs before calling a metered external service. It stops short of the 5 because rate limits, retry/error behaviour on transport failure, and whether the call is free of side effects are not addressed.

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?

Content is dense and front-loaded: capability first, then error semantics, then cost/auth, then parameters. The long parenthetical enumerating IBAN subfields is somewhat crowded but each element carries information. No filler sentences.

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, zero-annotation tool with an output schema, the definition covers the expensive parts — cost, auth header, and the crucial non-error semantics of invalid input — so return values need not be explained. The remaining shortfall is the unstated at-least-one-parameter constraint, which an agent could get wrong.

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 largely does: iban accepts any formatting with spaces ignored, and bic is an alternative or supplement to iban. The one meaningful gap is that both parameters are optional at the schema level, yet the description never says that at least one of iban or bic is required for a sensible call.

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 (IBAN and/or standalone BIC) and what is produced: structure, checksum, country, bank/branch/account codes, derived BIC, and bank name from the registry. That is specific enough to distinguish it from neighbours such as vat_check or phone_validate without opening the schema. It loses a point only because the opening is a noun fragment rather than a clear verb ('Structure and checksum of...') and the explicit validation verb lives in the tool name, not the description.

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 clarifies the iban/bic relationship — 'alternative or in addition to iban' — which is genuine usage guidance for choosing inputs. There is no statement of when to prefer this tool over siblings (e.g. a full company or VAT check) and no exclusions. Usage is implied rather than explicitly framed.

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

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

With no annotations supplied, the description carries the full burden and does so well: it discloses per-call cost (€0.002 charged to the API key in Authorization: Bearer), the classification taxonomy, the returned fields, and the evaluation boundary. It does not cover failure behavior (inaccessible URLs, unsupported formats) or rate limits, which keeps it below a 5.

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

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

The text is compact and front-loaded: capability, verdict values, exclusions, cost/auth, then parameters. The trailing "Parameters — url: image url" is slightly wasted given the schema, but nothing else is 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 one-parameter classification tool with an output schema, the description covers taxonomy, cost, auth, and scope boundaries. The remaining gap is the nullable/optional url semantics and error behavior, which matters modestly since the only input is optional.

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 parameter, so the description must compensate; it only offers "url: image url." That does clarify the URL must point at an image rather than a page, which is real value, but it never explains that the parameter is optional/nullable or what happens when it is omitted.

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?

"Nudity check" names the operation and resource, and the description goes further by listing the outputs (safe/suggestive/explicit verdict, score, faces, boxes) and explicitly excluding weapons, drugs, and text. That exclusion distinguishes it from generic moderation or profanity_filter siblings without naming them 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?

The phrase "for marketplaces and bots" implies a usage context, and the exclusions tell an agent when NOT to use it. However, there is no explicit routing guidance such as "use profanity_filter for text" or "use url_safety for link reputation," so the agent must infer the alternative.

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 at all, the description carries the full burden and does well: it states no documents are stored, gives the exact cost (€0.12 per match billed to the Authorization bearer key), and frames the output as 'a finding, not a payment decision' so the agent understands the limits of the result. It also discloses the fuzzy description-based matching behavior. It does not cover failure modes or rate limits, so 4 rather than 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?

It is dense and front-loads the value proposition before the parameter block, and every clause carries information. The middle sections are long run-on semicolon chains, which costs some readability, but almost 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 complex 8-parameter matching tool, the definition covers cost, data-retention policy, acceptable input formats, the optional-receipt path, tolerance defaults, and per-parameter payload structure, and an output schema exists so return values need not be described. An agent could invoke this correctly from the description alone.

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: all eight parameters are documented with their JSON shapes ({po_number, currency, items[{sku, description, qty, unit_price}]}, receipt items with qty_received, etc.), the url alternatives are marked as alternatives, receipt is marked optional, and both tolerance parameters are explained in percent with defaults of 0.

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 and resource: matches a supplier invoice against both the purchase order and the goods received note, line by line on SKU then fuzzy description. It then enumerates the exact findings produced (price over PO, over-invoicing vs ordered/received, missing lines, off-PO lines, PO reference/currency, amount at risk), which distinguishes it clearly from siblings like invoice_parse, purchase_order_extract, and e_invoice.

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 concrete usage context: each document can be supplied as JSON or as a URL (PDF/scan/photo) that is extracted for you, and it states that the receipt is optional, making it a 2-way match when omitted. What is missing is explicit routing guidance naming alternatives (e.g. when to use invoice_parse first instead), 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 mostly succeeds: it discloses per-document pricing, that billing is charged to the API key in 'Authorization: Bearer', the default OCR language set, and the deterministic checks performed (lines vs subtotal, base × rate vs VAT, IBAN checksum, EU VAT-ID format, due date). The pricing statement is internally muddled — 'mode=pro (€0.06)' alongside 'Cost €0.03 per document' — which leaves the agent unsure of actual cost.

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 extraction target list is well front-loaded, but the body is a dense run-on with a duplicated 'Parameters —' restatement of mode that repeats the earlier mode=pro sentence. The repeated pricing figures differ (€0.06 vs €0.03), so words that should clarify instead create ambiguity.

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

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

An output schema exists, so return values need not be explained; the description covers the remaining agent-critical facts: cost, auth header, defaults, mode differences and PO matching. Gaps remain around failure handling and the fact that url is optional in the schema despite being the core input, but overall it is sufficient to invoke 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%, yet all four parameters are explained with meaning and defaults: url (image or PDF location), language (OCR languages, default en,ru,uk,de), mode (basic default | pro), and po (pro-only purchase order JSON with an explicit {number, items:[{sku, description, qty, unit_price}]} shape). This adds far more than the bare anyOf string schema provides.

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?

Opens with a specific verb-implied resource list: 'Vendor, customer, number, dates, currency, totals, VAT and line items from a photo, scan or PDF invoice.' The input modality (photo/scan/PDF) and the cross-check behavior distinguish it from siblings like ocr, bank_statement_parse and e_invoice without needing to open 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 a clear cost/feature tradeoff for mode selection: basic at €0.03 for totals-level extraction vs pro at €0.06 for SKU/per-line VAT, VAT breakdown by rate, references, checks and PO matching. It does not, however, route the agent away from overlapping siblings such as invoice_3way_match, purchase_order_extract or plain ocr, so tool-level exclusions are missing.

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 supplied, so the description carries the full behavioral burden. To its credit it discloses per-lookup pricing (€0.0003) and that the charge goes against the API key in the Authorization: Bearer header, which is real behavioral value. However, for a billable network tool it says nothing about rate limits, failure/error behavior, caching, or what happens when the key is missing or exhausted.

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?

Roughly two dense sentences, front-loaded with the return payload, then cost/auth, then the parameter note. Every clause carries information; the only mild inefficiency is the long field enumeration, which is partly redundant with the existing output 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 one-parameter read tool with an output schema already published, the description covers the essentials: what comes back, what it costs, how auth works, and the sentinel value. The remaining gap is the null/omitted-input behavior and error handling, which matter given the billing angle but are secondary for a tool this simple.

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 'ip' parameter is nullable with only a default, so the description must compensate — and it does: it specifies accepted formats (IPv4 or IPv6) and defines the 'me' sentinel meaning the caller's own address. It stops short of stating whether omitting the parameter (null default) falls back to the caller address, leaving that inference open.

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 exact resource (an IPv4/IPv6 address) and enumerates the returned attributes — country, region, city, coordinates, EU flag, ASN/org, datacenter flag — so the agent can distinguish it from siblings like domain_health or url_safety at a glance. It lacks an explicit verb such as 'look up' in the leading sentence, but 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?

Usage is only implied: the cost-per-lookup line signals this is a paid operation, and the 'me' = caller address note hints at a common use case, but there is no statement of when to prefer this over alternatives or any precondition (e.g. valid key required). No when-not guidance at all.

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

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

With no annotations supplied, the description carries the full disclosure burden and does so: it states the cost (€0.0005 per call) and the auth mechanism (Authorization: Bearer API key), that tokens and keys are never logged or cached, the 10-minute JWKS cache, and the security property that algorithm families are pinned to key type to block alg-confusion attacks. These are exactly the operational facts 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?

Structure is front-loaded: operations and their key requirements come first, then security/cost properties, then the parameter glossary. It is dense with no filler, though the trailing parameter enumeration reads as one long run-on sentence rather than a scannable 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?

Given nine all-optional params, no annotations and an output schema that handles return values, the definition is nearly complete. The remaining gap is failure semantics: it does not say whether an invalid signature raises an error or returns a negative verdict, nor how malformed tokens are reported, which matters for an agent branching on the result.

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 all nine params are bare titles, so the description must compensate and does: every parameter is annotated with its meaning and which op consumes it (token for decode/verify, secret for HMAC verify/sign, public_key for verify, private_key for sign, jwks_url for verify, payload as a JSON claims object, alg with allowed values and HS256 default, exp_seconds as lifetime). It even resolves the otherwise-ambiguous op default.

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 three concrete operations (decode, verify, sign) on a specific resource (JWT) and states what each does: reading header/payload, checking a signature, or issuing a token. It also makes the decode-vs-verify distinction explicit ('without checking the signature'), which is the main ambiguity an agent could hit; no sibling tool overlaps this space.

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 per-operation selection guidance: use decode to inspect, verify to validate against a secret/PEM/JWKS, sign to mint a token, with op defaulting to decode. It does not state exclusions or point to any alternative tool (e.g. hash or base64 for adjacent tasks), so it stops short of full when/when-not routing.

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

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

With no annotations supplied, the description carries the full burden and does so well: it discloses the auth mechanism (Bearer API key), the exact price (€0.003 per query, answer=true at the same price), indexing side effects on first call, a 7-day cache with instant repeats, and the returned shape (ranked fragments with section and source url). Cost and caching behavior are exactly the traits 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?

Front-loaded with the purpose, then behavior, then a compact parameter glossary — no filler sentences. Slightly dense, with mild redundancy in restating the 'same price' point and a long single-sentence parameter block that could be easier to scan.

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-parameter, zero-coverage schema with a mutation-free but metered operation, the description covers purpose, cost, caching, auth, defaults and return content. Since an output schema exists, the return-value detail it adds is a bonus rather than a gap, and nothing an agent needs to invoke it correctly is missing.

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

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: all six parameters are named with meanings, the registry enum values and auto-resolution order, version default, top_k range and default, and the answer flag's effect and pricing. Minor deduction because it doesn't reconcile with the schema, which types top_k and answer as strings rather than integer/boolean, leaving the true argument format ambiguous.

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

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

States a specific verb and resource ('Answer a question about a package's README and documentation site') and immediately scopes it to package registries, which cleanly separates it from siblings like web_answer, web_search, llms_txt or paper_search. An agent can decide relevance from the first clause 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?

The use case is implied clearly (ask a question about a library's docs), and caching plus per-query price give useful decision context, but there is no explicit when-to-use/when-not guidance and no named alternative for cases where the package docs aren't the right source (e.g. general web questions).

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 supplied, so the description carries the full disclosure burden, and it delivers two things annotations could not: an explicit price (€0.001 per url) and the authentication mechanism (API key in Authorization: Bearer). That is materially useful pre-invocation context. It still omits failure modes for non-public or unreachable URLs and any rate-limit 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?

Three short sentences with a clear progression: outputs, cost/auth, then parameters. No filler. Minor weakness is leading with a noun list of return fields rather than front-loading the action, and the 'Parameters —' fragment is slightly cryptic.

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

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

An output schema exists, so return values need no elaboration, and the description covers cost, auth, and input scope. What remains missing for a paid network-fetching tool is error/edge behavior on non-public or dead URLs and whether the optional url being absent yields an error.

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 url parameter, and the description only restates 'url: page url'. The one piece of genuine semantic value is that the URL must be public, which constrains valid input. It does not state that url is optional (default null) or what happens when it is omitted, so compensation for the coverage gap 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?

The description enumerates exactly what is returned (title, description, image, favicon, site name, canonical, author) for any public URL and frames it as a messenger-style link card, which lets an agent distinguish it from siblings like og_image (renders an image), seo_meta (audits meta tags) or url_to_markdown (converts content). However, the operative verb is never stated — it leads with a noun list, so the agent must infer 'extract preview metadata'. Clear resource and output, but implicit action and no explicit sibling differentiation.

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

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

The only scoping signal is 'any public URL', which usefully excludes intranet/auth-walled pages, but there is no when-to-use guidance, no when-not, and no mention of the near neighbors (seo_meta, og_image, url_to_markdown, url_safety) that an agent would have to choose between. The agent gets no routing help beyond the scope phrase.

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 disclosure burden and does real work: it states the €0.01-per-site charge, that billing hits the Bearer API key, and that robots.txt is respected. Pagination/rate limits, timeout behavior, and failure modes when a site blocks crawling are not covered, so the picture is good but incomplete.

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 the core behavior, then cost/auth, then parameters — a sensible order with no filler. The parameter clause is crammed into one semicolon-chained sentence, which costs a little readability.

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

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

An output schema exists, so return values need not be described, and the cost, auth, and crawl-limit context is supplied. The one real omission is that url is functionally mandatory even though the schema marks nothing required, which an invoking agent needs to know.

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 partly does: url is the site url, max_pages is 1–20 pages crawled only when no llms.txt exists, default 20. Gaps remain — the schema types max_pages as a string with a null default while the description says numeric 1–20 with default 20, and nothing explains whether url must include a scheme or is effectively required despite 0 required 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 set and resource: returns an existing /llms.txt or builds one from the sitemap, per the llmstxt.org spec. That distinguishes it cleanly from siblings such as seo_audit, url_to_markdown, and readability_score, which also touch site content but do not produce this artifact.

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 fetch-or-generate logic is explicit (use the existing file when present, otherwise crawl the sitemap, otherwise fall back to homepage links), which tells the agent what it will get. It stops short of naming an alternative tool or stating when not to use it, so it lands just below the top band.

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

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

With no annotations supplied, the description carries the behavioral burden well: it discloses no code execution, the 500-character input limit, per-call cost of €0.0005, and that billing is tied to the Authorization bearer key. It omits error behavior for malformed expressions, which is the main remaining gap for a stateless compute 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?

Front-loaded with the core capability and squeezed into three dense sentences where each carries distinct information (capability, limits/cost/auth, parameters). The em-dash parameter dump at the end is slightly run-on but nothing is 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?

An output schema exists so return values need no explanation, and the description covers syntax, size limit, cost, auth, and both parameters — enough to call it correctly. Only error handling and required-ness of expression are unaddressed.

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 partly does by naming both parameters, marking vars optional, and giving a concrete expression example. However, it describes vars as a 'JSON object name→number' while the schema types it as string-or-null, leaving an agent unsure whether to pass an object or a JSON-encoded string, and it never states whether expression is in fact required (the schema lists zero required 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 (evaluate arithmetic) and enumerates the supported grammar: operators, parentheses, named functions, pi/e constants. This distinguishes it cleanly from neighbors like regex_test or unit_convert 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?

The 'without eval()' framing implies the use case (compute an arithmetic expression safely) and the 500-char cap sets a boundary, but there is no explicit when-to-use-vs-alternative guidance and no statement of what happens for non-arithmetic needs (e.g., unit conversion belongs in unit_convert).

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 bears the full disclosure burden. It does add genuinely useful behavior: billing at each service price, €0 for setup, and authentication via 'Authorization: Bearer' API key. However, it says nothing about whether the returned configs embed credentials, whether the call is read-only, or what happens with no services configured.

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 purpose appears in the second sentence, after a preamble about Finekot's overall architecture that is context rather than tool-specific instruction. The description ends with a broken artifact ('Parameters — .'), which is wasted text. The billing and auth sentences do earn their place, so it is only moderately front-loaded.

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

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

For a zero-parameter tool with an output schema already present, the description covers what an agent needs: what is returned, which clients are supported, that it is free to run, and how it is authenticated. Gaps are minor — mainly the relationship to the 'services' sibling and whether a pre-existing API key is mandatory.

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

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

The tool takes zero parameters, so the baseline is 4 and the schema has nothing to explain. The trailing fragment 'Parameters — .' is an empty placeholder that adds no meaning but also does not mislead. Nothing further is required of the description here.

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 deliverable: 'This call returns ready configs for Claude Code, Claude Desktop, Cursor and VS Code.' That is a concrete verb+resource an agent can act on. It never distinguishes itself from the sibling tools 'services' and 'account', which cover adjacent territory, so sibling differentiation is missing.

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 statement of when to call this tool versus the similar-sounding 'services' or 'account' siblings, and no prerequisites or exclusions. The only guidance offered is pricing ('Cost €0 per setup'), which is not usage guidance. An agent must infer the trigger condition from the purpose sentence 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 carries the full burden and does so unusually well: raw HTML is escaped and never executed, the PDF path loads no network beyond the same public-host guard as html-pdf, and cost is €0.002 per document charged to the API key in the Authorization Bearer header. These are exactly the security, networking and billing facts an agent must know before calling.

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 purpose first, then security/cost, then parameters; every clause carries information and nothing is redundant. The trailing semicolon-packed 'Parameters —' run is dense enough to cost some readability, but no sentence is 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?

Output schema exists, so return values need not be described; the description instead covers cost, auth, sandboxing and every parameter with defaults. Minor gaps remain around source-count rules (markdown vs url exclusivity), input size limits and failure behavior, which an agent might want before a paid 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 coverage is 0%, so the description must compensate for all five params, and it does: markdown (source text), url (alternative source, .md/.txt), to (html default | pdf | docx), format (A4 default | A3 | A5 | Letter | Legal, gated on to=pdf), margin (example 15mm, gated on to=pdf). Defaults and conditional applicability are supplied where the bare schema has only null-typed strings.

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 with scope: GFM Markdown (tables, strikethrough, autolinks) converted to HTML, PDF or DOCX. The output-format list and the markdown-vs-url source model distinguish it clearly from siblings like url_to_markdown, doc_convert and html_pdf.

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 frames 'url' as an alternative source to 'markdown' and gives defaults per target (to=html default; format/margin only apply when to=pdf). It stops short of naming when to prefer doc_convert, html_pdf or url_to_markdown, so routing between similar siblings still needs inference.

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

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

With no annotations supplied, the description carries the burden and does so well: it discloses deduplication by meaning, recency weighting, per-user/agent namespacing, a 20 000 item capacity, per-item billing at €0.001, and that auth comes from the Authorization: Bearer key. The destructive scope of 'all' (delete the whole space) is surfaced. What is missing is whether deletes are reversible and how failures surface, so not a full 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?

Structure is strong and front-loaded: purpose first, then operational traits (dedup, cost, namespacing), then a compact parameter glossary. The parameter run-on is dense but each clause carries new information; nothing is 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 10-parameter, multi-op tool with zero schema annotation coverage, the description covers purpose, auth, cost, limits, and all parameters, while an output schema handles return values. The remaining gap is op-selection guidance (search vs list vs spaces in practice), 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%, so the description must compensate and it does completely: every one of the 10 parameters is explained with semantics and defaults (op values, space example 'user:42' with default 'default', text vs items batch shape, meta, query, top_k range 1–50 default 5, recency 0–1 default 0, comma-separated ids, all). It also clarifies value encodings (JSON array/object, bool) that the flat string schema leaves implicit.

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 framing ('Long-term memory behind your key') and enumerates the concrete capabilities: add facts deduplicated by meaning, recall by meaning with an optional recency boost, list, forget. An agent can map each verb to an op value. It stops short of naming a sibling or explicitly differentiating from semantic_search/embed, but no sibling covers persistent namespaced memory.

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 states the default op (search) and the per-op parameter mapping, which implies when each op applies. However, there is no explicit when-to-use guidance such as 'use add before search' or 'use list to enumerate instead of search', and no exclusions or prerequisites beyond the cost note.

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 atempo speed adjustment capped at ±20%, the MP3-by-signed-link plus target-language SRT outputs, the 60-minute ceiling, and per-minute billing at €0.08 charged to the Bearer API key. What it omits is failure behavior (e.g. what happens if neither transcript nor audio_url is supplied) and any retention or expiry detail on the signed link.

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