Kódvéna

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so 'Csak olvas' only restates them. The description does add real context beyond that: it will not query Google's pages, meaning results derive from the supplied site and answers, and it returns a score based on the answered profile-status flags.

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 compact sentences: what it checks, what it returns, what it does not do. The checked items and the read-only limitation are front-loaded with no filler.

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

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

No output schema exists, yet the description signals the return shape (item-level match findings plus a score from the answers). With read-only annotations and full schema coverage, the only minor gap is how the score is computed or what the response looks like in detail.

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

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

Schema description coverage is 100%, so the schema already documents business_name, website, city, phone and the boolean answers object. The description only hints at the role of answers (a score derived from profile-status responses) and adds no matching rules or formatting guidance for the name/city/phone comparison, so 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: checking consistency between the Google Business Profile (Google Maps) and the website, enumerating the checked items (name, address, phone, LocalBusiness data, map, review link). A reader knows exactly what the tool does, though it does not name a sibling such as check_website for the website-only case, leaving differentiation implicit.

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

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

The audit scenario is implied (profile/website consistency with a status score), and the sentence 'A Google oldalait nem kérdezi le' rules out a behavior, but there is no explicit when-to-use statement, no prerequisites, and no pointer to alternatives like check_website or compare_competitors.

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?

Goes well beyond the annotations by disclosing the ~1–2 minute runtime, that the operation is async-tolerant ("if it isn't finished by then, the link is still good"), that it is free, and that the deliverable is a kodvena.hu link to hand back to the user. The discrepancy with readOnlyHint=false is not a contradiction, since a browser-based fetch is a heavyweight non-idempotent operation rather than a 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?

A single dense paragraph is front-loaded with what the tool does, then duration, then invocation trigger, then the return artifact. Every clause carries information; only the semicolon-chained style makes it slightly harder 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?

With no output schema, the description correctly compensates by telling the agent what comes back (a kodvena.hu link) and that it should be passed to the user, plus realistic latency expectations. It lacks only error/failure behavior, which is a minor gap for a one-parameter audit 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 100% — the url parameter is fully documented with maxLength and an example (pelda.hu). The description adds no syntax, format, or validation guidance beyond that, 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 (free examination with a real browser) and resource (a website), then enumerates exactly what is measured: speed, security, SEO, LLM search engines, accessibility, content, plus a score and top errors. No sibling in the list performs a site audit, so the function is unmistakable 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?

"A felhasználó kérésére hívd" (call it at the user's request) gives an implied trigger, which is minimal — every tool is invoked on user request. No alternative tools are named and no when-not-to-use condition is given, so routing must be inferred.

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

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

Annotations already declare openWorldHint=true, non-idempotent, non-destructive, so the safety bar is partly covered. The description adds genuinely new behavioral context: the operation takes a few minutes and the output is a kodvena.hu link the agent should hand back to the user. It does not contradict readOnlyHint=false, since a link-producing comparison is a generated artifact rather than a plain read.

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

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

Two short sentences with zero filler: the first defines the operation and its scope, the second gives the trigger and what to do with the result. Everything is front-loaded and earns its place.

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

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

With no output schema, the description usefully discloses that the result is a kodvena.hu link to pass to the user, and warns about the multi-minute runtime. It is close to complete for a two-parameter tool, though it omits any mention of failure cases or what happens if a URL is invalid.

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

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

Schema coverage is 100%, so both parameters (own_url, competitors) are already documented, including the 1–3 array bound. The description restates the competitor count and the 'same criteria' framing but adds no format or syntax detail beyond the schema. 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: comparing the user's own website against 1–3 competitors on the same criteria. It clearly implies a multi-site comparison, which distinguishes it in spirit from single-site siblings like check_website, but it never names an alternative tool 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?

Provides one triggering condition, 'call it at the user's request' (A felhasználó kérésére hívd), which is implied usage rather than a real decision rule. It gives no when-not guidance and does not point to check_website for single-site 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?

Goes well beyond the annotations by disclosing duration (5–10 minutes), asynchronous link behavior with visible progress, that the finished video is downloadable and shareable, that 2 revisions are included, and a strict daily quota (rate limit). The annotations only cover the safety profile (not read-only, open-world, non-idempotent, non-destructive), so this added operational context is genuinely valuable.

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 front-loaded: capability and output variants come first, then duration/behavior, then the call trigger and return value. Every sentence carries information; it is slightly packed but not 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 long-running generation tool with no output schema, the description supplies everything an agent needs: expected duration, async progress URL, downloadable/shareable output, revision allowance, and quota limits. Nothing essential to 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 description coverage is 100%, including enum values for voice and a default for music, so the schema already carries parameter meaning. The description mentions subtitles/music generally but adds no syntax, format or constraint detail beyond the schema — baseline 3.

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

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

States a specific verb+resource: a narrated promo video generated from a website, with explicit output variants (16:9 laptop, 9:16 mobile), subtitles and music. This clearly distinguishes it from adjacent siblings like create_device_preview or create_website_mockup, which produce static previews rather than narrated video.

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?

Provides only 'A felhasználó kérésére hívd' (call it at the user's request), which is a generic trigger that applies to nearly every sibling, and no alternatives or exclusions are named. The note that the result is a kodvena.hu link to hand to the user is useful context, but the selection guidance itself is thin.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent, open-world). The description adds value beyond them by disclosing the return artifact ('az eredmény egy kodvena.hu link') and the expected follow-up action (forward it to the user), which annotations do not convey.

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

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

Two sentences, front-loaded with what is produced and followed by the call trigger and output handling. No filler, though it is terse for a six-parameter generator.

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

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

No output schema exists, but the description compensates by stating the return value is a kodvena.hu link and that it should be handed to the user. All six parameters are documented in the schema, so an agent has what it needs to invoke the tool correctly.

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

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

Schema description coverage is 100%, including per-enum explanations and a required/maxLength note on policy_url, so the schema carries the parameter burden. The description only echoes feature concepts (categories, Consent Mode v2) without adding syntax or format detail beyond the schema, 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 states a concrete deliverable: Hungarian cookie-consent manager code with equal accept/reject, categories, and Google Consent Mode v2, plus embeddable code. This is clearly distinguishable from siblings like draft_privacy_policy or create_website_mockup, though no sibling is 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?

'A felhasználó kérésére hívd' gives generic trigger guidance (call when the user asks) and instructs what to do with the output (pass the kodvena.hu link on). It does not name alternatives or state when NOT to use it, so guidance is implied rather than explicit.

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

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

Annotations declare not-read-only, open-world, non-idempotent and non-destructive, so the mutation profile is already covered structurally. The description adds genuinely useful behaviour: the output is a kodvena.hu link that must be handed back to the user. It does not explain why the call is non-read-only (generation/side effect) or any latency/quota constraints.

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

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

Two tight sentences with the deliverable (framed screenshot, download formats) front-loaded and the result-handling instruction second. Nothing is wasted, though writing the description in Hungarian against an English tool name and sibling set is a mild consistency cost for an agent.

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

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

For a one-parameter tool with no output schema, the description covers the essentials: what is generated, the formats, and that the return value is a link to relay to the user. The only real gap is that a non-read-only, open-world operation gives no hint of cost, delay or failure modes.

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

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

There is a single url parameter with 100% schema description coverage ("A weboldal címe"), so the schema fully documents the input. The description adds no extra meaning such as format, protocol requirements or length limits, which is the expected baseline-3 outcome when the schema already carries the load.

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

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

States a concrete verb+resource: it produces a screenshot of a webpage framed as laptop, tablet and phone, with PNG/JPG/WebP download. That is specific enough to distinguish it from most siblings, though it never explicitly contrasts itself with close neighbours like create_website_mockup, 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?

"A felhasználó kérésére hívd" tells the agent to invoke it when the user asks, which is a usable trigger condition. It gives no when-not-to-use guidance and names no alternative tool (e.g. create_website_mockup), so usage remains implied rather than explicit.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still adds real context: generation takes 1–2 minutes and is subject to a strict daily quota, and the output is a kodvena.hu link to pass on — details no structured field provides.

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 that front-load the purpose, then latency/quota, then usage trigger and result handling. Nothing is redundant and there is no filler.

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

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

For a 12-parameter mutation tool with no output schema, the description usefully explains the return value (a link) and the latency/quota constraint. It omits any auth or permission requirements and what happens when the daily quota is exhausted, but annotations cover the safety profile.

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% and the schema documents every parameter, including enum values and defaults (e.g., style default 'modern', devices default 'all'). The description only restates company/industry/style, adding no meaning beyond the schema, so 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: an AI-generated website mockup shown on laptop, tablet and mobile, derived from company, industry and style. It is clearly distinct from siblings like create_device_preview, create_ai_video or compare_competitors 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?

"A felhasználó kérésére hívd" gives a trigger condition (call when the user asks for it) and tells the agent to hand the resulting link back to the user. However, it names no alternatives and gives no when-not-to-use guidance against related mockup/preview tools.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the safety profile is known. The description adds value beyond that: ~30-60 sec runtime, that it returns the full text plus a link valid 24 hours, and a disclaimer that it is a draft and not legal advice. It omits auth/permission requirements, but the operational behavioral context is strong and consistent with annotations.

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

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

The description is front-loaded with the core purpose, then latency, output shape, disclaimer, and calling instruction. Four short sentences, all earning their place; it is only marginally longer than strictly necessary.

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 17-parameter tool with no output schema, the description compensates well by describing the return value (full text plus a 24h link) and the runtime. With annotations and full schema coverage carrying the rest, little is missing, though it could note that the output link must be retrieved before expiry.

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 every one of the 17 parameters is already documented with label and required/optional status. The description only says input comes 'from the given data' generically and adds no syntax or format nuances beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb+resource: producing a GDPR-compliant privacy policy draft ('adatkezelési tájékoztató vázlata') for a website from supplied data. This is clearly distinct from the closest sibling draft_terms, since the artifact generated is a privacy notice rather than terms of service. An agent can identify the tool's output 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 states 'A felhasználó kérésére hívd' (call on user request), which gives a minimal triggering condition, and it describes the follow-up ('the result is a kodvena.hu link, pass it to the user'). However, it offers no exclusions, no comparison to alternatives such as draft_terms, and no prerequisites, leaving usage largely implied.

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

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

With readOnlyHint=false, idempotentHint=false, and openWorldHint=true already declared, the description still adds real value: expected runtime (30–60s), the conditional branch on the webshop flag, a non-legal-advice disclaimer, and — with no output schema present — the return artifact (a kodvena.hu link) plus the instruction to hand it back to the user. It does not discuss failure modes or 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?

Four short sentences with no filler, and the core purpose plus runtime estimate are front-loaded. The disclaimer and callback instruction are placed afterwards, which is reasonable ordering, though the sentences are somewhat staccato.

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 16-parameter, 7-required generation tool with no output schema, the description covers what an agent most needs: the artifact produced, where it is returned (link), how long it takes, the conditional webshop behavior, and the requirement to relay the result. Enum semantics for customers and offer_type are left entirely to the schema, which is acceptable at 100% coverage.

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 all 16 parameters are already self-documented, and the description adds no per-field syntax or format detail. It conveys only coarse semantics (inputs feed the draft; webshop-related params apply only with a webshop), which matches the baseline for a fully documented schema.

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

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

States a specific verb and resource: drafting general terms and conditions (ÁSZF) from supplied data, for a webshop or service business. This is clearly distinguishable from the sibling draft_privacy_policy, since the output artifact (T&C vs. privacy policy) is 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?

"A felhasználó kérésére hívd" gives an explicit trigger condition (invoke on user request), and the description states a conditional rule for content generation (no webshop → no webshop sections). It stops short of naming a sibling alternative or stating exclusions, so it is clear context rather than full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds that the artifact is a link intended for copy-paste into Gmail/Outlook, which is useful context, but it does not clarify whether the link is merely returned or the builder is opened, nor any limits on the generated URL.

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 compact sentence with no filler, and the core artifact is front-loaded. It is efficient, though the terseness leaves meaning slightly open to interpretation.

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 9-parameter, read-only link generator with no output schema, the description should say more about the returned artifact – e.g. that a URL is produced and how it should be used. The schema covers params well, but the return behavior is only loosely implied by 'link'.

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 89%, so the schema already documents nearly all parameters (name, color, email, phone, address, company, website, job_title). The description adds no parameter-level meaning at all, which is the expected baseline when the schema does the heavy lifting.

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 output – a pre-filled link to the browser-based e-mail signature builder – and its downstream use (copy into Gmail/Outlook). It is distinguishable from siblings like qr_code_link or create_cookie_banner, though the verb is implied rather than explicit ('link' rather than 'generate a link').

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

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

No when-to-use, when-not-to-use, or alternative is named. The clause about copying into Gmail/Outlook describes the result's purpose rather than when an agent should select this tool over its siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds that the whole page text is returned and that any kodvena.hu page qualifies, but says nothing about response size, truncation, or error behavior for unknown ids.

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, front-loaded with the core capability before the usage hint. No filler, though the parenthetical '(vagy bármely kodvena.hu oldal)' slightly dilutes an otherwise tight statement.

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

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

For a single-parameter read tool with rich annotations and no output schema, the description covers what it takes and roughly what it returns. The one material omission is sibling disambiguation against get_page.

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 'id' parameter is already documented in the schema as the result id / page URL. The description only echoes this plus the provenance hint that the value comes from search's id field, adding marginal meaning beyond the schema.

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

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

States a concrete verb+resource: it returns the full text of a page identified by its id/URL, and explicitly says the id comes from the search tool's results. However it never distinguishes itself from the sibling get_page, which an agent could easily mistake for the same capability.

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

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

Gives clear context for when to reach for it: use the id field produced by search results, and it works for any kodvena.hu page. It does not state when NOT to use it, nor how to choose between this and the near-identical get_page sibling.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered without description help. The description adds only the general-vs-industry branching, no return format, length, or pagination detail.

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 with no padding, front-loading the resource before the variant distinction. Slightly awkward phrasing owing to the parenthetical example but nothing wasted.

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

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

For a zero-required-parameter read tool with no output schema and full annotation coverage, the description states the resource and the optional scoping. Adequate; only the return shape is left unstated, which is acceptable here.

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

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

Schema description coverage is 100%, so the single optional 'industry' parameter is already documented with the same example. The description merely echoes that it can be an industry page, adding no syntax or matching rules beyond the schema.

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

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

Names the resource (Kódvéna GYIK) and distinguishes two variants: the general FAQ and an industry-specific page's FAQ, with a concrete example. The retrieval verb is implicit in the name rather than stated, but an agent can tell what content this yields.

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: read the general FAQ, or supply an industry identifier to get a niche FAQ. There is no explicit statement of when to prefer this over siblings like get_page or search, nor any exclusion.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the content is returned 'as it appears on the website' and is scoped to kodvena.hu, which is useful context, but it says nothing about error/404 behavior or rate limits.

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

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

One sentence containing the scope (kodvena.hu page), the returned content (title, description, content), and the rendering semantics. Zero filler and the scope is front-loaded.

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

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

For a one-parameter read tool with full annotation coverage and no output schema, the description supplies domain scope and the shape of the returned content, which is close to sufficient. The only gap is behavior on invalid or missing pages, a minor omission here.

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% and the single url parameter is fully documented in-schema with examples (full URL or path). The description adds no syntax, format, or default information beyond what the schema already provides, 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?

The description names a specific verb+resource (retrieve the full text of a kodvena.hu page) and enumerates what is returned: title, description, content. It is clear enough to distinguish from list_pages (enumeration) and fetch (generic retrieval), though it never names those siblings explicitly.

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

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

There is no statement of when to use this tool versus list_pages, fetch, or check_website, nor any prerequisite or exclusion. The kodvena.hu scope is implied but the agent is given no routing guidance among a large sibling set.

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

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

The annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds content scope (which processes and account topics are documented) but says nothing about format, language, or length of the returned material.

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 main subject (the order process) followed by two parallel parenthetical enumerations. Dense but every clause maps to distinct content scope; the nesting makes it slightly hard 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 parameterless read-only content retrieval tool with full annotation coverage and no output schema, the description supplies enough about what content is available. An agent could select and invoke it correctly; only routing guidance against sibling info tools 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?

The tool takes zero parameters, so the baseline of 4 applies per the rubric. There is no parameter information the description needs to compensate for.

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 the exact content returned: the step-by-step order process, post-delivery deliverables, and customer-account mechanics (tickets, payment, phone, review, complaint). That is a specific resource with clear scope, though it never contrasts itself with the overlapping informational siblings (get_faq, kodvena_overview).

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

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

There is no explicit statement of when to call this tool versus get_faq, kodvena_overview, or list_free_tools, all of which serve overlapping informational needs. The topic list only weakly implies the questions it answers.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description carries a lighter burden. It adds which topics the overview spans but says nothing about return shape, length, or refresh behavior. Adequate given the annotation coverage, but no extra behavioral value.

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 compact sentence listing the covered topics and ending with the usage directive, which is well front-loaded. Very little waste, though the topic list reads as a bare enumeration rather than a structured statement.

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

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

For a no-param, read-only overview tool with no output schema and full annotation coverage, the description tells the agent everything needed to select and call it correctly. Deeper content expectations for payment/contact sections are not described, but that is minor at this 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?

Zero parameters, so the schema imposes no semantic burden and the baseline is 4. Nothing in the description needs to compensate for a parameter 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 plainly what the tool returns: an overview of what Kódvéna is, its services, how to start a job, payment, and contact. The resource is specific and it is easy to tell apart from siblings like get_faq or how_it_works. It lacks an explicit verb ('overview' is implied only by the title), which keeps it out of the top band.

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?

"Ezzel érdemes kezdeni" explicitly tells the agent this is the recommended entry point, which is real usage guidance. However, it names no alternatives or conditions for skipping it, so it stops short of the when/when-not/alternatives pattern.

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

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

Annotations already declare this as a safe, read-only, idempotent, closed-world call, so the safety profile is covered. The description adds one piece of behavioral value beyond that: each entry carries a title and description, i.e. partial return-shape information with no output schema declared. It does not mention ordering, counts, or pagination, so it is a modest additive contribution.

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

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

A single sentence with no filler, front-loading the resource before the parenthetical examples. Nothing to trim.

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

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

For a no-parameter catalog-listing tool with no output schema, stating that entries include title and description is nearly everything an agent needs. Ordering and whether the list is exhaustive or filtered are left unspecified, 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?

The tool takes zero parameters, so the baseline is 4 — there is no parameter semantics for the description to clarify or obscure.

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

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

The description identifies the resource precisely — Kódvéna's free online tools — and enumerates examples (website checker, domain search, mockup generator), so an agent knows the scope of what is returned. It lacks an explicit verb (the 'list' action is only in the name) and never distinguishes this from siblings like get_faq or how_it_works, but the resource itself 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?

There is no when-to-use or when-not-to-use guidance, and no alternatives are named. The use case (browse the catalog of available free tools) is only inferable from the noun phrase, 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds nothing behavioural: no ordering, no pagination semantics despite limit/offset, no indication of result size or what a page entry contains. It only glosses categories that the schema enum already lists.

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 no filler, which is good. But the brevity is achieved partly by omitting essential information, so it sits between genuine conciseness and under-specification.

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 listing tool with no output schema, the definition omits too much: pagination behaviour via limit/offset, the `home` type, whether empty results are possible, and how many pages a category typically returns. An agent could call it, but not confidently predict or paginate 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%, so the description must compensate, and it partially does: it explains the meaning of seven of the eight `type` values (service, industry, tool, blog, info, legal, faq) with Hungarian glosses, which is real added meaning for the key parameter. However, the enum value `home` is omitted entirely, and neither `limit` (max 200) nor `offset` is addressed, so the compensation is incomplete.

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

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

The description identifies the resource (the public pages of kodvena.hu) and its categorisation, but it never states the action in so many words — it reads as a fragment enumerating categories rather than 'lists the public pages'. Most of its content restates the `type` enum values, so the name carries the operative verb. It is decipherable alongside `list_pages` but not self-evidently distinct from `get_page` or `list_free_tools`.

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. The siblings `get_page`, `get_faq`, `list_free_tools` and `search` overlap in surface area, and the description gives no hint about which to pick or in what order (e.g. list first, then get_page by slug).

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond them: the actual phone number is not retrievable by the agent because it is only visible to humans on the website, preventing a false promise of that data.

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 sentence front-loads what the tool returns, followed by the human-only caveat. Nothing is wasted, though the parenthetical asides make it slightly harder to parse than a clean list.

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

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

For a zero-parameter, read-only info tool with no output schema, the description covers what content comes back and flags the key limitation. A brief note on the response format would make it fully self-contained, but nothing critical is missing.

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

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

The tool takes zero parameters, which is the baseline-4 case. There is nothing for the description to clarify beyond the schema, and the description correctly implies a no-argument lookup.

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 resource and enumerates its three contents: the phone menu (which button does what), staff availability (working hours), and the identification method. It is clearly distinguishable from generic siblings like get_faq or how_it_works, though it does not name a sibling to route against.

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

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

Usage is only implied — an agent infers it should call this when a user asks about phone support. There is no explicit when-to-use/when-not statement and no named alternative among the many sibling tools. The one caveat given (the phone number itself is human-only) partially guides expectations.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false), the description clarifies that this only produces a link to an external browser tool and that final customization (logo, color) and PNG/SVG download happen at that destination. That explains the openWorld, read-only nature and correctly signals no artifact is generated locally.

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 compact sentence with the purpose front-loaded and the destination capabilities trailing after the semicolon. No filler, though the parenthetical list and trailing clause could be trimmed without loss.

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

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

For a 4-parameter, read-only link-builder with full schema coverage and existing annotations, the description covers the essentials, and the implied return value (a link) roughly matches the absent output schema. However, it omits any routing versus the 22 sibling tools and says nothing about the 500-character content limit's practical impact.

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 all four parameters (type, content, color, background) are already documented, which sets the baseline at 3. The description only maps the content kinds to the type enum and mentions color in the context of the destination page, adding essentially no new parameter meaning.

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

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

States a concrete verb+resource: it builds a pre-filled link ("Kitöltött link") for the browser-based QR generator, and enumerates the supported content kinds (website, text, email, phone). An agent can grasp what is produced (a link, not an image), though nothing distinguishes it from siblings like email_signature_link or create_device_preview.

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 alternative tool is named. The clause about logo/color/download describes the destination page, not when this tool should be selected, so the agent must infer its role from the title 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only the content-scope enumeration; it says nothing about result count, ranking, or how the limit parameter affects behavior. With annotations carrying the safety burden, a 3 reflects partial added context.

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, with the scope statement front-loaded ahead of the keyword-language tip. No filler or repetition of the title. It could be marginally tighter, but every clause earns its place.

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

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

For a 3-parameter search tool with no output schema, the description covers scope and query language but omits what results look like, how many are returned, and how ranking or the limit interact. It is adequate to invoke the tool but leaves the agent guessing about result shape.

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 67%: query and type carry descriptions, but limit does not. The description's note that Hungarian keywords work best adds semantic value for the query parameter, but it does not explain the type enum values or the limit bounds. Baseline 3 is appropriate given the schema does most of the 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 (search) and a bounded resource (all public pages of kodvena.hu), then enumerates the content families covered (services, blog, free tools, terms, privacy). This lets an agent distinguish it from get_page, list_pages, and fetch, which are page-retrieval rather than keyword-search tools. It stops short of explicitly naming those siblings as alternatives.

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?

"Magyar kulcsszavakkal a legjobb" gives a real usage hint about query language, which is useful context. However there is no explicit when-to-use / when-not-to-use versus get_page, list_pages, or fetch, so an agent must infer that this is the discovery tool and those are the retrieval tools. Usage guidance is implied rather than stated.

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

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

With annotations already declaring openWorldHint=true, destructiveHint=false and non-idempotent, the description adds useful behavioral context by disclosing the return shape ("az eredmény egy kodvena.hu link") — valuable since there is no output schema. However, it never explains why a search operation is flagged readOnlyHint=false, leaving an inconsistency the agent cannot resolve.

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

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

Two tight sentences with the purpose front-loaded and the usage/return instructions following; no filler. Slightly dense but every clause carries information.

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

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

For a no-output-schema search tool, the description covers purpose, a usage trigger and the return format, which is a reasonable floor. It still omits whether results are a single suggestion or a list, how pricing is conveyed, and any reconciliation of the non-read-only annotation.

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

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

Schema coverage is 100%, so query, tlds and keywords are all documented in the schema; baseline is 3. The description echoes the query/TLD inputs (".hu, .com, .eu stb.") but adds no format, limit or constraint detail beyond what the schema already 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?

States a specific verb and resource ("Szabad domainnevek keresése") plus scope (company name/keywords, TLDs like .hu/.com/.eu, with pricing). An agent can immediately tell this is a domain-availability search, distinct from check_website or search. It does not, however, explicitly contrast itself with any sibling 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?

It gives one trigger condition: "A felhasználó kérésére hívd" (call it at the user's request). That is implied usage rather than explicit when/when-not guidance, and it names no alternative tool or exclusion. Adequate but thin.

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

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

Annotations only declare non-read-only, non-idempotent, non-destructive. The description adds substantial context beyond them: it returns a link, the kodvena.hu assistant already knows the summary and only asks for missing details, a human reviews before a quote is issued, and personal contact data must not be sent. This is rich, actionable behavioral disclosure.

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

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

Purpose and the link-handoff are front-loaded, followed by the content-exclusion rule and the invocation gate. Content is dense and earns its place, though the workflow explanation is slightly longer than strictly necessary.

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 mutation tool with no output schema and 9 parameters, the description covers the essential unknowns: what it does, the returned link, the downstream human-review flow, and the constraint on contact data. Field-level detail for the remaining parameters is left thin, but the agent has enough to call it correctly.

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

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

Schema description coverage is 56%, so several parameters (notes, deadline, business_name, project_type) are undocumented. The description implies what the payload is ('az eddig összegyűjtött igényét') and usefully warns against including personal contact data, but adds no format or field-level meaning beyond the schema. Baseline 3 for partial coverage.

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 ('igényleadás indítása' / handing over a collected requirement) and enumerates the trigger scenarios (website, webshop, custom software, integration, fix). An agent can distinguish this from siblings like create_website_mockup or check_website 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?

Gives a clear when-to-use condition (user wants these services from Kódvéna) and an explicit when-not / restriction: 'Csak a felhasználó kifejezett kérésére hívd'. It does not name sibling alternatives, so it stops just short of the top tier, but the gating condition is unambiguous.

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