EvidujZdarma – EET 2.0 (Czech sales registration)

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safe-read profile needs no restating. The description adds genuine non-annotation context: the eligibility gate and its fallback behavior (eligible=false plus reason), the mid-year surcharge rule, and the default assumptions baked into the cost model.

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 comparison logic and eligibility rule before the args block, which is the right order. It is somewhat long and the Args section largely restates the 89%-covered schema, but each line carries a default or semantic gloss rather than being pure duplication.

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 9 parameters and no output schema, the description carries the burden of explaining results, and it does so exhaustively: eligible, reason, verdict, surcharge_czk, evidence_cost_czk, difference_czk sign convention, months, flat_tax_monthly_2027_czk, and the rules block. Nothing needed to call or interpret the tool is missing.

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

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

Schema coverage is 89%, so the schema already documents most parameters and the baseline would be 3. The description goes beyond it by decoding ambiguous values ('0 = not in the flat-rate regime', '1 = whole year') and explaining defaults with business meaning ('pos_cost_monthly_czk default 0 – the EvidujZdarma POS is free', hardware 'spread over 3 years').

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 precise verb and resource: it compares the EET OFF surcharge (1 400 Kč/month) against the modeled real cost of registering sales (time × hourly rate + POS + hardware amortization). This is a specific computational purpose that no sibling tool (check_ico, classify_payment, get_facts) shares, so an agent can route to it unambiguously.

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

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

It gives clear context for when the tool applies: 'only for natural persons in band 1 of the flat-rate tax with income up to 1,000,000 CZK; for others the tool returns eligible=false with the reason,' plus mid-year start handling. It does not name alternative tools, but none of the siblings compute this comparison, so exclusions are effectively covered by the eligibility rule.

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, openWorld), so the description's added value is elsewhere: it discloses that the estimate is heuristic and derived from legal form, CZ-NACE and RŽP licences, and that ARES cannot show in-person payments or flat-tax status, which is why optional inputs override heuristics. It also describes the response payload in detail. Lacks anything on rate limits or failure modes when IČO is unknown/dissolved, but the disclosure of heuristics and data-source limits is substantive.

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

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

Front-loaded with purpose, then a data-source caveat, then explicit Args and Returns blocks — a clean, predictable structure. It is fairly long, and the Args section partially duplicates enum definitions already in the schema, but no sentence is filler.

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

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

No output schema exists, so the description carries return-value explanation itself and does so thoroughly (subject fields, verdict values, eet_off states, reasons, checklist, url, catalog_url). Combined with clear sibling routing and the heuristic/override caveat, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it explains why the optional answers exist (ARES gaps), states they override heuristics, and clarifies the enum semantics ('no' = not in the flat-rate regime). The example IČO format and 'spaces allowed' note are also useful beyond the schema's min/max length.

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 ('Look up a Czech business by IČO in the public ARES register') and the actual outcome ('estimate whether EET 2.0 applies, whether EET OFF is available, and what to do next'). The closing 'Don't use for' clauses name the sibling tools to use instead, so an agent can distinguish it from eet_classify_payment and eet_calculate_eet_off 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?

Explicit routing: 'Don't use for: payment-type questions (use eet_classify_payment) or the EET OFF cost comparison (use eet_calculate_eet_off).' It also tells the agent when to supply optional answers ('pass the optional answers when you know them — they override the heuristics'), which is genuine conditional 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 this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds genuine behavioral context beyond that: the exact return fields, the 'uncertain' semantics for edge cases requiring a tax adviser, and the boundary that activity-level exemptions are out of scope.

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

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

The purpose is front-loaded in the first sentence, followed by tightly packed decision rules and a Returns summary. It is dense but nearly every clause carries a decision rule; the parenthetical enumerations are long yet functional rather than 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?

With no output schema, the description compensates by naming the return fields (evidenced, explanation, note, sources, guide url) and defining the 'uncertain' outcome. Combined with the classification rules and the explicit exemption boundary, an agent has everything needed to invoke and interpret 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 coverage is 100%, so baseline would be 3, but the description goes further by explaining the classification meaning behind the enum values (which instruments count as evidenced vs. which are 'not a payment'), and clarifies that in_person means 'during personal contact or at the premises'. This adds meaning the enum list alone does not convey.

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

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

States a precise verb (decide/classify) and resource (whether a payment is an evidenced sale under EET 2.0), and names the domain term 'kontaktní platba'. It is clearly distinguishable from siblings like eet_calculate_eet_off or eet_get_facts, which handle calculation and fact lookup rather than classification.

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 explicit decision conditions: in-person/premises payments are evidenced, gift-voucher redemption and remote payments (bank transfer, gateway, QR on invoice) are not, and 'uncertain' covers bank transfer on site and cash on delivery. It also routes away the exemption case ('not evaluated here – see eet_get_facts topic exemptions'), though it does not otherwise compare against sibling 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 readOnly/idempotent/non-open-world, so the safety profile is covered. The description adds real value beyond that: facts arrive with official/primary sources and a verification date, and it discloses the specific misinformation it corrects (January 2027 not a pilot, no 50k CZK exemption, tax credit 'up to' 5,000 CZK).

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

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

Front-loaded with purpose, then topics, then corrections, then args/returns. The corrections paragraph is unusual but earns its place by flagging assertions the tool will make; slightly verbose overall but no clearly wasted sentence.

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

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

With no output schema, the description supplies the return shape (facts[{topic,title,text,sources[{label,url}]}], facts_updated), the topic enum, and the default format. Nothing essential to calling it correctly is missing.

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

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

Schema coverage is 100% and the schema already documents both parameters and the enum values. The description's 'Omit topics to get all of them' and the args listing essentially restate the schema, adding little semantic detail beyond it, 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+resource ('Return short, sourced facts about EET 2.0') and its scope ('on chosen topics'), and the enumerated topics make it easy to distinguish from siblings like eet_get_guide or eet_list_misconceptions. An agent can tell what this does 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 gives one operational instruction ('Omit topics to get all of them') but never states when to prefer this over the sibling retrievers (eet_get_guide, eet_search_guides, eet_list_misconceptions). Usage is implied by the topic list rather than explained.

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, openWorldHint, non-destructive). The description adds genuinely useful operational context beyond that: the 5-minute polling cadence, the fact that this is reachability rather than transaction-level health, and where official notices live. It doesn't discuss rate limits, caching/staleness of the 24h/7d/30d windows, or error behavior.

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

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

Front-loaded with the core answer, then the differentiator, then the Args block. The long comma-spliced return-value list in sentence one is dense, and the Args section duplicates schema content, but there is little outright waste.

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

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

With no output schema, the description compensates by enumerating the returned signals (status values, last check, latency, uptime windows, recent outages) and disambiguating what the status actually measures. Nothing an agent needs to call and interpret this tool correctly is missing.

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

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

Schema description coverage is 100% and the enum for response_format is fully documented in the schema, so the schema does the heavy lifting. The description's Args line merely restates 'markdown'|'json' without adding semantics. Baseline 3 is appropriate for a single fully-documented parameter.

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

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

Specific verb + resource: 'Return the current availability of the Finanční správa EET 2.0 interface' with named environments (production trzbyeet.gov.cz, Playground) and the measurement source (EvidujZdarma, every 5 minutes). It enumerates exactly what is returned (status, last check, latency, uptime windows, recent outages), which cleanly separates it from siblings like eet_classify_payment or eet_get_facts.

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

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

Gives clear context for use and an explicit boundary: 'It measures reachability of the server, not the processing of individual sales,' plus a pointer to the authoritative alternative ('Official outage notices are published on eet.gov.cz'). It stops short of naming a sibling tool or stating when-not-to-call in tool-routing terms, so it's strong but not a 5.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds real value beyond that: the 25,000-character truncation limit, the inclusion of FAQ and sources, the Czech/Markdown content, and the expert-review availability filter.

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 purpose sentence followed by a compact Args/Returns layout; the return-field list is genuinely useful given there is no output schema. Minor noise: the garbled resource name 'EvidujZdarma' in the opening line.

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 compensates by enumerating the returned fields and the truncation cap, and it flags the availability precondition. Missing only edge-case handling (what happens when text is truncated, error behavior for invalid slugs).

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 description's parameter notes (slug 'returned by eet_search_guides', response_format markdown/json) essentially restate what the schema and enum already document. Baseline 3 applies when the schema carries the semantics.

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

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

States a specific verb (Return) and resource (the full text of one guide) plus scope qualifiers (single guide, by slug, Czech/Markdown content). It is clearly distinguished from the sibling eet_search_guides, which is named as the source of the slug.

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?

Establishes the workflow dependency explicitly: the slug must come from eet_search_guides, and only expert-reviewed guides are fetchable. It stops short of stating when-not to use it (e.g., use search first if you don't have a slug), but the context is clear.

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, closed-world, non-destructive, so the safety profile is covered. The description adds material behavioral context beyond that: results are sourced, dated with an "as of", and contain a clearly labelled opinion, which tells the agent how much trust to place in each field.

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 first sentence is dense but front-loads what the tool returns and its provenance; the second earns its place as the usage trigger. The Args/Returns block is compact and scannable, with only minor redundancy against the schema.

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

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

There is no output schema, and the description compensates by enumerating the returned fields (id, question, claim, truth, comment, as_of, sources, url, page_url). Combined with the read-only annotations and 100% schema coverage, an agent has everything needed to call it, though pagination or result-count behavior is unstated.

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

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

Schema coverage is 100% with only two parameters, so the schema already documents both, including examples and the enum default. The description restates the query examples and the format options without adding syntax or matching semantics beyond what the schema provides — 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 states a specific verb and resource — returning claims about EET 2.0 that contradict the adopted law or official Finanční správa information — and characterizes the source domain (media, commercial websites). That precision separates it from siblings like eet_get_facts or eet_get_guide without opening either schema.

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

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

"Use it to fact-check a claim before answering" gives a clear triggering condition. It does not name or exclude a specific sibling (e.g. eet_get_facts) as the alternative when the user wants neutral facts rather than debunked claims, so it stops short of full routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description then adds behavior beyond them: the exact result shape, the meaning of the 'reviewed' flag, and a link explaining that review process — genuinely useful since no output schema exists.

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

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

Front-loaded with the core purpose, then Args and Returns in a tight structure; every line carries information. The long topic enumeration in the opening sentence is borderline padding but does aid keyword matching, so only a minor deduction.

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 supplies the return fields (slug, title, description, updated, reviewed, url), explains the 'reviewed' semantics, and tells the agent what to do next. Nothing needed to invoke or follow up on this tool is missing.

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

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

Schema coverage is 67% and the description compensates by noting query accepts Czech or English keywords with concrete examples ('ubytování kauce', 'bez internetu') and restating the limit range/default and the two response_format values. The examples add real value for keyword construction, though the format details largely duplicate the schema.

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

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

States a specific verb (full-text search) and resource (EvidujZdarma guides about EET 2.0), and enumerates the covered topics. It also distinguishes itself from the sibling eet_get_guide by naming it as the follow-up step for reading full text, so the agent can route without opening either schema.

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

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

Clearly frames search as the discovery step and explicitly hands off to eet_get_guide with the returned slug for the full text, which is concrete when-to-use guidance. It lacks any exclusion against the other EET lookup siblings (eet_get_facts, eet_list_misconceptions), 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.