QR codes, page Markdown, YouTube captions, data sources, and Columbus résumé skill gaps.
Scored across 11 tools
Each tool has a distinct output type and purpose (barcode vs QR generation, transcript reading, proofreading, SEO checks), so misselection risk is low. Minor overlap exists among the three HTML-reading tools (company_facts, page_to_markdown, seo_check), but their outputs clearly differ.
All names are readable snake_case, but conventions vary: some are verb_noun (find_data, get_transcript, make_qr), some are noun_noun (company_facts, resume_gap), and others are noun_verb (recall_check, seo_check) or a bare verb (proofread). Consistent separator but inconsistent structural pattern.
Eleven tools is a reasonable, well-scoped count with no filler entries; each tool maps to a concrete operation. The set is slightly heavy for a general utility grab-bag but nothing feels redundant.
Tools are largely standalone one-shot operations rather than a lifecycle, so coverage is hard to benchmark. Some asymmetries exist (make_qr has no read_qr counterpart, and the HTML-reading tools are fragmented), but each individual tool appears functionally complete.
Read a business's own home, about and contact pages and return its name, address, phone, email, founding year and what it does, each with the page it came from; needs your OpenRouter key. (API Tool Calls, by Cowerx)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The business's public http or https homepage URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose real behavioral traits: it fetches three specific page types, returns each field with its source page, and requires an OpenRouter key. It does not state failure behavior when pages are missing or any rate/cost limits, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the purpose and return fields up front; dense but every clause carries information. The parenthetical attribution is minor overhead.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema tool, the description adequately stands in for the missing output schema by enumerating the returned fields and their provenance, and it flags the credential requirement. Only failure-mode behavior 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?
Only one parameter and schema coverage is 100%, so the schema already documents 'url' as the public http/https homepage. The description adds no syntax or format detail beyond that, which is the baseline case.
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 (Read), a specific resource (a business's home/about/contact pages), and enumerates exactly what it returns (name, address, phone, email, founding year, what it does). No sibling overlaps with find_data, get_transcript, seo_check, etc., so no differentiation is required.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (given a public homepage URL, extract the business's identity fields) and flags a prerequisite ('needs your OpenRouter key'), but it names no alternatives and gives no explicit when-to-use vs when-not-to-use guidance against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a full free Data Finder plan for up to three sources: fit, cost at your monthly volume, resale terms with recorded clause, URL and read date, and build-it-yourself guidance. No live source lookup. Defaults: volume 0, US, no resale. (API Tool Calls, by Cowerx)
| Name | Required | Description | Default |
|---|---|---|---|
| geo | No | ||
| resell | No | ||
| volume | No | ||
| use_case | Yes | Describe the data you need and what you want to build. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose non-obvious behavior: no live lookup is performed, the plan is free, it is capped at three sources, and defaults are volume 0 / US / no resale. It omits any mention of authentication, rate limits, latency or how deterministic the 'plan' is, which matters for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the deliverable and then the constraints and defaults. 'full free' is mild marketing padding, but nothing is structurally wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description usefully enumerates what the returned plan contains (fit, cost, resale terms with clause, URL and read date, DIY guidance), which stands in for an output schema. It remains thin on parameter formats and on any auth or operational constraints for a 4-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (just use_case), so the description must compensate. It partially does by supplying defaults for volume, geo and resell, which the schema does not state, but it adds no guidance on valid geo values, sensible volume ranges, or what a good use_case string looks like.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and deliverable: it produces a 'Data Finder plan' covering fit, cost, resale terms, URL/read date and DIY guidance. The scope ('up to three sources') and the 'No live source lookup' limit make the output distinguishable, though the term 'Data Finder plan' is somewhat branded and undefined. Siblings (barcode, transcript, seo_check, etc.) are unrelated, so no sibling routing is required.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an implied trigger (you need a data-sourcing plan) and one useful exclusion, 'No live source lookup', plus stated defaults for volume, geo and resale. It never states when to prefer this over another approach or what preconditions must hold, so usage is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read public YouTube captions as timestamped plain text. Captions only, no video or audio. (API Tool Calls, by Cowerx)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL or an 11-character video id. | |
| lang | No | Preferred caption language; falls back to English, then any available track. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden and does disclose some behavior: public-only scope, text-only output, timestamped format. It omits failure/no-caption behavior, any access requirements, and rate limits, so it falls short of full disclosure for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded and efficient at roughly two sentences, with the core purpose stated first and the scope limit second. The trailing '(API Tool Calls, by Cowerx)' attribution is vendor noise that earns no place in the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, the description successfully signals the return shape ('timestamped plain text') and the input domain. Only the no-caption/failure path is unaddressed, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'url' (accepts a URL or 11-char id) and 'lang' (fallback chain) are already fully documented in the schema. The description adds format context ('timestamped plain text') but nothing parameter-specific, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read public YouTube captions as timestamped plain text') plus the output format. It is clearly distinct from every sibling, and the 'Captions only, no video or audio' clause preempts the most likely misreading of the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'public YouTube captions' and the scoping clause, but the description never says when to reach for this versus an alternative (e.g. page_to_markdown for non-YouTube pages) nor what happens when no captions exist. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an SVG barcode. Validates retail check digits and lengths. GS1-128 and GS1 DataMatrix accept bracketed (01)GTIN(17)YYMMDD(10)lot; use make_qr for QR codes. (API Tool Calls, by Cowerx)
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to encode; at most 1024 UTF-8 bytes. | |
| format | No | code128 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It usefully discloses the output format (SVG) and that input is validated against retail check digits and lengths, but says nothing about failure behavior on invalid input or the response shape. Adequate but with clear gaps 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?
Three tight sentences that front-load the core action, then validation, then the special GS1 syntax, then the sibling routing. Every clause carries information; 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?
Given only two parameters and no output schema, the description covers purpose, format selection, special input syntax, and validation. The main omission is error/response behavior, which an agent would need when a barcode fails validation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (the format enum is self-documenting but undescribed), and the description compensates by explaining the bracketed (01)GTIN(17)YYMMDD(10)lot syntax required for gs1-128 and datamatrix. That is meaningful guidance for the text parameter that the schema does not provide.
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 (make) and resource (SVG barcode), and explicitly distinguishes itself from the sibling make_qr. The mention of check-digit/length validation further sharpens what kind of barcode this is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent to make_qr for QR codes, which is the key alternative given the sibling list. It does not spell out when-not to use this tool for other barcode-adjacent tasks (e.g., read_barcode is only implied), so it's clear but not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an SVG QR code for text, a URL, or Wi-Fi network details. (API Tool Calls, by Cowerx)
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Text or URL to encode. Required unless wifi is provided. | |
| wifi | No | Wi-Fi details; takes precedence over text when present. | |
| format | No | svg |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not say what the tool returns (an SVG string, file, or URL), whether the operation has side effects, or whether the output format is fixed — it only echoes the format via the word 'SVG'.
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 efficient sentence with the purpose front-loaded. The trailing vendor tag '(API Tool Calls, by Cowerx)' is boilerplate that earns no place in a functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter generator with a nested wifi object, no annotations, and no output schema, the description is adequate but thin: it omits what the caller receives back and how the SVG is delivered, which matters because no output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, so the schema already documents the text/wifi split and the wifi precedence rule. The description adds only the payload categories ('text, a URL, or Wi-Fi network details') and says nothing about the format parameter or the wifi sub-fields, leaving the gap partly unclosed.
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 (Make) and resource (SVG QR code) and enumerates the three payload types it accepts: text, URL, Wi-Fi details. It is distinguishable from make_barcode/read_barcode by the QR resource, but it never explicitly contrasts itself with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the payload list ('for text, a URL, or Wi-Fi network details') — there is no statement of when to choose this over make_barcode or any prerequisite/exclusion. An agent can infer intent but is given no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one public HTML page as clean Markdown with title, headings, lists, tables and absolute links. No logins, paywalls or JavaScript rendering; 2 MB HTML limit. (API Tool Calls, by Cowerx)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http or https page URL. |
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 capability limits (no auth-gated content, no JS rendering, 2 MB HTML cap) that an agent must know before calling. It does not cover redirect handling, non-HTML responses, timeouts, or rate limits, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences that front-load the core action and then the constraints; nothing is padded. The trailing attribution '(API Tool Calls, by Cowerx)' is non-functional noise that slightly detracts from an otherwise efficient definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, annotation-free, output-schema-free fetch tool, the description covers the essential context: what is retrieved, what the output contains, and the hard limits on input. Some operational details (error behavior, content-type handling) are absent but are not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and schema coverage is 100%, so the schema already documents the url argument fully. The description adds no format or syntax detail beyond what the schema states, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read one public HTML page') and specifies the output form ('as clean Markdown'), plus enumerates what is preserved (title, headings, lists, tables, absolute links). It does not name any sibling, but the sibling list contains no other page-fetching tool, so differentiation is largely unnecessary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear applicability boundaries: 'No logins, paywalls or JavaScript rendering; 2 MB HTML limit' tells the agent which pages this tool cannot handle, which functions as when-not guidance. It stops short of naming an alternative for those excluded cases, so it falls 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.
Fix spelling, grammar, punctuation and word choice while keeping meaning and voice; needs your OpenRouter key. (API Tool Calls, by Cowerx)
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to proofread, at most 2,000 words. |
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 real behavioral context: an external API key requirement and the constraint that edits preserve meaning and voice. It omits whether the tool rewrites aggressively, what the response contains (corrected text vs. change list), and how length limits are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and the preservation constraint before the key requirement. The trailing vendor attribution '(API Tool Calls, by Cowerx)' is non-functional noise an agent cannot act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations and no output schema, so the description must carry behavioral and return-shape information; it covers the action and auth requirement but never says whether the result is corrected text, a diff, or a report — a meaningful gap for a rewrite tool. For a single-parameter tool this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'text' parameter, so the schema already explains the input including the 2,000-word/15,000-character limit. The description adds no additional parameter semantics, which is the expected baseline for fully documented params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb plus enumerated resources: 'Fix spelling, grammar, punctuation and word choice,' with the invariants 'keeping meaning and voice.' No sibling tool (barcode, transcript, SEO, markdown conversion, etc.) overlaps with text correction, so there is no routing ambiguity to resolve.
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 'needs your OpenRouter key' clause states a genuine prerequisite for use, which is more than nothing. However, there is no when-to-use framing, no guidance on input shape or language coverage, and no mention of what to do with the result versus other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read every barcode in a base64 PNG, JPEG or WebP (or data URL). At most 2 MB decoded and 4000 by 4000 pixels. Returns text, format, corner positions and GS1 product number, expiry and lot when present. (API Tool Calls, by Cowerx)
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | Base64 PNG/JPEG/WebP or image data URL; 2 MB decoded maximum. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful traits: decoding limits and the exact return payload (text, format, corner positions, GS1 product number, expiry, lot). It omits behavior when no barcode is found, multiple-barcode handling, and any auth/rate-limit context, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded with the action and the constraints first, then the return contents. No filler, no repetition of the tool name, and the trailing attribution is negligible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates return fields and covers the input constraints, so an agent can call it correctly. It stops short of describing failure or multi-barcode cases, which is a minor gap for a single-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter and schema description coverage is 100%, so the schema already documents the accepted encodings and size limit. The description restates the same constraints without adding format syntax or examples beyond the schema, making the baseline 3 correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read every barcode') plus the accepted input encodings and formats. This is unmistakably distinct from the sibling make_barcode, which generates rather than decodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives hard input constraints (formats, 2 MB decoded cap, 4000x4000 pixel cap), which implies when the tool is applicable. However, it never explicitly says when to use this versus make_barcode/make_qr or what to do for unsupported inputs, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search local U.S. CPSC data for up to 10 recall notices that may match — check the notice. May not cover every batch or country; read the notice. No CPSC endorsement. (API Tool Calls, by Cowerx)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Product name, brand, model number or UPC. |
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 disclose real behavioral traits: results are capped at 10, coverage may be incomplete by batch or country, the data is a local copy, and there is no CPSC endorsement. It still omits whether the call is read-only and how fresh the local data is, but the coverage caveats are genuinely useful context an agent could not infer elsewhere.
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 definition is short and front-loads the core action and result limit before the caveats. The em-dash fragments ("may match — check the notice") read as slightly choppy but cost no real space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter search tool with no output schema, the description covers scope, result cap, and data-coverage limitations. Return-field detail is not required since there is no output schema, though noting that results are recall notices with dates/hazards would have helped the agent interpret them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter's accepted inputs (product name, brand, model number, UPC) are fully documented in the schema. The description adds no additional query semantics beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ("Search") and resource ("local U.S. CPSC data ... recall notices") with an explicit result cap of 10, so an agent immediately knows this is a recall-lookup tool. No sibling differentiation is offered, but none of the sibling tools (barcode, SEO, transcript) are close enough to require 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 only usage directive is the repeated "read/check the notice," which tells the agent to verify returned data but not when to choose this tool over anything else or what preconditions apply. There is no statement of when the tool is inappropriate, so guidance is effectively absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare résumé skills with Columbus, Ohio job postings. Résumé is not stored; full check and rewrite at https://jobs.cowerx.dev. (API Tool Calls, by Cowerx)
| Name | Required | Description | Default |
|---|---|---|---|
| family | Yes | ||
| resume_text | Yes | Plain text of the résumé. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a genuinely useful behavioral fact — the résumé is not stored — and notes that a fuller check/rewrite lives at an external URL, which tells the agent this call is a partial analysis. It says nothing about return shape, limits, or what happens to the submitted text beyond 'not stored'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action front-loaded, and the data-handling caveat placed immediately after. The trailing '(API Tool Calls, by Cowerx)' branding is mild filler but does not bury the operative 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?
There is no output schema and no annotations, so the description is the only source of behavioral detail; it covers privacy and scope but omits what the comparison actually returns (missing skills, match score, posting list). For a 2-parameter analysis tool this is adequate but leaves a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: resume_text is documented in the schema and the family enum values are self-describing, but the description adds no meaning to either parameter — no format guidance, no note on how family scopes the comparison. It neither compensates for the uncovered parameter nor enriches the covered one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (compare) and both resources (résumé skills, Columbus Ohio job postings), so the agent knows exactly what the tool does. It is not confusable with any sibling, since none of them touch résumés or job postings, though it never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase 'compare résumé skills with job postings' and by the pointer to a fuller 'check and rewrite' elsewhere, which hints this is a limited gap check. There is no explicit when-to-use, when-not-to-use, or named alternative, but the absence of any close sibling makes routing low-risk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check one public HTML page with fixed SEO rules. Returns schema 1, score, strengths, ranked fixes and facts. No JavaScript rendering; 10 seconds overall, 2 MB HTML and at most 20 links. Public HTTP/HTTPS ports 80/443 only. (API Tool Calls, by Cowerx)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http or https page URL. |
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 JavaScript is not rendered, an overall 10-second budget, a 2 MB HTML cap, a maximum of 20 links, and that only ports 80/443 on public HTTP/HTTPS are reachable. These are exactly the hard limits that determine whether a call can succeed, plus the shape of the response.
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?
Highly front-loaded: the capability is stated first, then return shape, then hard limits, all in four dense sentences with no filler. The trailing '(API Tool Calls, by Cowerx)' attribution adds no decision-relevant information, which is the only wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers everything needed: what it does, what it returns, and the operational limits that govern success. Return values are enumerated in the description, compensating for the absent output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single url parameter, so the baseline is 3, but the description adds real constraint meaning beyond the schema: the page must be public and served on HTTP/HTTPS ports 80/443 only. That materially narrows what values will work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check one public HTML page') with the scope qualifier 'with fixed SEO rules', and the return payload (schema 1, score, strengths, ranked fixes, facts) makes clear this is an SEO audit rather than a markdown conversion (page_to_markdown) or text review (proofread). An agent can distinguish it from every sibling without opening a 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 constraints ('one public HTML page', public ports only), so an agent can infer the tool is for auditing a single reachable page. However, it never names an alternative or states when-not to use it (e.g., versus page_to_markdown for content extraction), leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
company_factsproofreadmake_barcoderead_barcodeseo_checkfind_data3 fields changedInput schema / properties / geoAdded value: +{
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / resellAdded value: +{
+ "enum": [
+ "yes",
+ "no"
+ ],
+ "type": "string"
+}Input schema / properties / volumeAdded value: +{
+ "maximum": 1000000000000000,
+ "minimum": 0,
+ "type": "integer"
+}recall_checkfind_dataget_transcriptmake_qrpage_to_markdownresume_gap
Add one secure layer between your agents and this server.