Věci Obecní

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. With no output schema, the description usefully discloses what is actually returned (text, decisions, places, documents) – real added value beyond the 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?

One front-loaded sentence stating the return content first, then the input source. No filler, nothing 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 one-parameter, read-only lookup with no output schema, the description covers what is returned and where the ID comes from. It stops short of describing the structure/format of the returned text and decisions, leaving a minor gap.

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

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

Schema coverage is 100% and the single parameter is documented as 'Identifikátor bodu'. The description adds provenance the schema lacks – that the ID is obtained from hledat or tydenni_prehled – which is meaningful for correct invocation.

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 ('Vrátí') and enumerates the exact resource returned (text, rozhodnutí, místa a dokumenty jednoho bodu), and names the sibling tools (hledat, tydenni_prehled) that produce the identifier. An agent can distinguish this detail-lookup tool from the search tools without opening any schema.

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

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

Explicitly states the prerequisite workflow: bod_id comes 'z nástroje hledat nebo tydenni_prehled', so the agent knows this is a follow-up call after a search. No explicit when-not or exclusion guidance is given, keeping it just short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context by disclosing chunked return and how to fetch the next chunk, but omits chunk size and how the agent detects the end of the document.

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 purpose and the pagination mechanism are both front-loaded and nothing is repeated from the schema or annotations.

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

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

For a two-parameter read tool this covers the essentials, but with no output schema the description should explain what a chunk looks like and how completion is signaled (empty text, offset beyond length). That missing termination signal is a real gap for a paginated read.

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, including odsazeni's character-offset semantics. The description adds the continuation usage of odsazeni but no syntax or bounds detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Vrátí text dokumentu') plus the delivery mode ('po částech'), which tells an agent exactly what comes back. It also differentiates from siblings by naming detail_bodu as the source of dokument_id, though it doesn't explicitly rule out other retrieval paths.

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 the prerequisite chain ('dokument_id z nástroje detail_bodu') and explains the continuation mechanism via odsazeni, which is real when/how context. No exclusions or when-not-to-use guidance are offered, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, closed-world and non-destructive, so the safety profile is covered. The description adds the query-construction constraint (Czech, max 5 words), which is genuinely useful behavioral context, but says nothing about result limits, ordering, or whether empty/misspelled queries return an error.

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

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

Two tight sentences: the search scope first, then the query-format rule with an inline example. Every clause earns its place and nothing is buried.

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

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

With no output schema the description need not explain return shape, and it adequately covers scope and query form. It is slightly thin on how results are ordered/paged and on routing relative to hledat_v_okoli, but nothing blocks a correct call.

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

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

Schema coverage is 100%, so the optional obec/od_data filters are already documented. The description goes beyond the schema by adding a soft query-length ceiling (max 5 words) and an example query, complementing the schema's 'aspoň 2 znaky' minimum and clarifying how 'dotaz' should actually be phrased.

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

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

Names a specific verb (fulltextově prohledá) and concrete resources (oznámení z obecních zastupitelstev a úředních desek a parcely), so an agent knows exactly what corpus is searched. However, it does not distinguish itself from the sibling hledat_v_okoli, which is a plausible alternative for a spatial query, so sibling differentiation is absent.

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 real query-formulation guidance (Czech, max 5 words, worked example 'prodej pozemek'), which is actionable for invocation. But it never says when to choose this tool over hledat_v_okoli, najit_obec, or dokument, leaving the routing decision to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description usefully adds the result cap ('nejbližších 20'), but says nothing about ordering, pagination, or what happens with an unmatched address.

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 scope and result limit front-loaded and no wasted words. It is perhaps slightly under-specified rather than verbose.

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

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

For a simple, read-only, fully documented two-parameter search with annotations covering the safety profile and no output schema, the description is largely sufficient. Only minor gaps remain (result ordering and the meaning of the returned 'oznámení').

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% – both 'adresa' and 'polomer_m' (with min/max and default) are fully documented in the schema. The description adds no syntax or format detail 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?

States a concrete verb ('Najde') and resource ('oznámení') scoped to 'okolí libovolné české adresy', which distinguishes it from the generic sibling 'hledat'. It does not, however, explicitly name or contrast 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?

The use case (find notices tied to places near an address) is implied by the description, but there is no explicit when-to-use/when-not guidance and no mention of 'hledat' as the alternative for non-geographic searches.

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 the safety profile is covered. The description adds genuinely new context by noting the response includes identifiers usable in other tools, but says nothing about ordering, empty-state behavior, or result size for a user with many follows.

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

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

A single sentence that front-loads the action and enumerates the returned resources in order of importance, with the downstream-usefulness hint appended. Nothing is wasted.

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

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

With no output schema and no parameters, the description carries the burden of stating what comes back, and it does so by naming the three categories plus the identifier payload. A brief note on ordering or handling of an empty follow list would make it fully complete.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly signals that no input filtering is expected.

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

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

The description gives a specific verb ('Vypíše') and enumerates the exact resources returned: followed municipalities, addresses with their radius ('okruhem'), and communities. This is clearly distinct from siblings like sledovat_obec or prestat_sledovat_adresu, 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?

Usage is only implied: the phrase 'včetně identifikátorů pro další nástroje' hints that this should be called first to obtain IDs for follow/unfollow or detail tools, but there is no explicit when-to-use statement, no prerequisites, and no named alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered structurally. The description adds useful content-level context (plan, limit consumption, entitlements) but says nothing about authentication requirements, whether it fails when unauthenticated, or freshness of the usage counters.

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 well-formed sentence with no filler, front-loaded on the return content. It is appropriately sized, though it could be marginally tighter by ranking the most important returned field first.

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 carries the burden of describing return values, and it does so by enumerating the three content groups an agent will receive. For a zero-parameter, read-only tool this is close to sufficient; only the authentication precondition is left implicit.

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 there is nothing for the schema to document and the baseline of 4 applies. The description correctly implies the identity is taken from the session rather than from input.

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 ('Vrátí') and resource (the logged-in user's tarif), plus the concrete data returned: daily limit usage and features available in the plan. It is unmistakably distinct from siblings like detail_bodu or smlouvy_obce, though it does not explicitly contrast itself with any of 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?

No when-to-use guidance, no prerequisites, and no alternatives named. The purpose is self-evident enough that an agent can infer 'call this when you need the signed-in user's account state', but that is inference, not stated 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 behavior, so the safety profile is covered. The description adds the one behavioral fact annotations cannot convey and no output schema supplies: that the result is an identifier usable by other tools. It omits match-count/multiple-result behavior, keeping it from a 5.

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

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

A single front-loaded sentence delivering purpose, output, and downstream use with no filler. 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 one-parameter lookup with no output schema, the description supplies the essential missing piece – the shape of the return (id) and why it matters. Combined with full schema coverage and safety annotations, nothing needed to call it correctly is absent.

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

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

Schema coverage is 100% and the single parameter 'dotaz' is already documented with its minimum-length constraint in the schema. The description adds no syntax or format detail beyond what the schema 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?

States a specific verb ('Vyhledá') and resource ('obce'), and adds the key outcome – returns the municipality id that other tools need. This clearly separates it from siblings like sledovat_obec or zasedani_obce, which consume that id rather than produce it.

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

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

The clause 'který ostatní nástroje potřebují' establishes clear context: use this as the lookup step to obtain an id for downstream tools. It does not name an alternative search tool (e.g. hledat) or state exclusions, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the bar is lower. The description adds valuable context beyond them: the return format is markdown and no login is required.

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

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

Three short sentences, front-loaded with the action and output format, each sentence earning its place (what it does, where slugs come from, auth).

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

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

For a simple single-parameter read tool, the definition covers purpose, slug source, auth, and output format. With no output schema, the markdown-format note suffices; minor gap is no mention of pagination or behavior on invalid slug.

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 a described slug parameter, so the baseline is 3. The description adds that slug must be a valid value from napoveda_seznam, but nothing about format beyond the schema example.

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 ('Vrátí text jedné stránky nápovědy jako markdown') and distinguishes the singular article from its sibling list tool napoveda_seznam by pointing to where valid slugs come from.

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

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

Explicitly routes the agent to napoveda_seznam to obtain valid slug values, implying this tool is for fetching a known page. No explicit when-not, but the context of use 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 and non-destructive, so the safety profile is covered. The description adds genuine context beyond them by stating that no login is required and by listing the returned fields, though it omits any note on ordering or pagination.

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 action and return payload front-loaded and no filler. Every clause carries information.

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

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

With no parameters, no output schema and rich annotations, the description supplies the return fields and the auth precondition an agent would otherwise lack. It is complete enough to invoke correctly, missing only ordering/pagination details.

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 there is nothing for the description to disambiguate; the baseline for a 0-param tool 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 ('Vrátí seznam stránek nápovědy') and enumerates the returned fields (slug, název, popis, odkaz), so the agent knows exactly what it gets. It does not name the obvious sibling napoveda_clanek, but the list-vs-article distinction is inferable from the wording.

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 or when-not-to-use guidance, and no reference to the alternative tool napoveda_clanek for fetching a single article. The only contextual note is 'Nevyžaduje přihlášení', which is a precondition rather than 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 readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the mutation and idempotency profile is covered. The description adds one useful piece of behavioral context not present in the annotations: that existing tracking/follow data is left untouched, which reassures the agent this toggle has a narrow side-effect surface.

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

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

Two short sentences with the action front-loaded and no filler. The second sentence earns its place by scoping the side effects.

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 toggle with full schema coverage, a complete annotation set and no output schema, the description supplies what is needed to invoke it correctly. The only gap is that it does not say where the toggle takes effect or what the user should expect to receive, though that is minor 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?

The single boolean parameter is fully documented in the schema ('true = zapnout, false = vypnout'), giving 100% schema coverage. The description adds no additional meaning beyond that, so the baseline 3 for high-coverage schemas 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 concrete verb (zapne/vypne) and a concrete resource (týdenní e-mailový souhrn uživatele), so the action is unambiguous. It does not, however, distinguish itself from similarly named siblings such as tydenni_prehled (viewing the weekly overview) or ukazka_souhrnu (sample summary), so an agent must infer the boundary.

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

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

There is no explicit statement of when to use this tool versus alternatives like tydenni_prehled or ukazka_souhrnu. The sentence 'Sledování zůstává beze změny' hints at scope (this is not a follow/unfollow action) but is a side-effect clarification, not usage guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds the authentication fact (no login needed), which is genuinely useful context beyond the annotations, though nothing about return format or limits is given.

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

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

One dense sentence covering scope, content, and the login constraint, with no filler. The purpose is front-loaded immediately.

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

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

For a simple informational/static tool with a zero-param schema and full annotation coverage, the description says enough to call it correctly. It does not need to explain return values since there is effectively no structured output, though a note on what the response contains would round it out.

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 there is nothing for the description to disambiguate; baseline for a no-param tool is 4.

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

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

States a specific verb and resource: it briefly describes what Věci Obecní is and which features are free versus paid. This clearly separates it from the help-article siblings (napoveda_clanek, napoveda_seznam), though it never names those alternatives explicitly.

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

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

Gives one useful context cue ('Nevyžaduje přihlášení'), which tells the agent it can call this unauthenticated. However, it offers no when-to-use guidance relative to the other informational tools like napoveda_clanek or napoveda_seznam, so usage is only implied.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the agent knows this is a destructive but safe-to-repeat mutation. The description adds that it removes an address from 'watched places,' clarifying what is destroyed (the watch relationship), but it does not explain side effects, reversibility, or error conditions.

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 a single, front-loaded sentence with no wasted words. It is appropriately concise, though it could benefit from a bit more context without becoming verbose.

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 destructive mutation tool with one parameter and no output schema, the annotations cover some behavioral aspects, but the description leaves gaps: it does not mention what happens if the address is already unwatched, whether the action is reversible, or any permission requirements. It is minimally adequate but not fully complete.

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

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

Schema coverage is 100%, so the parameter 'adresa_id' is fully documented in the schema (as an identifier from 'moje_sledovane'). The description adds no further information about the parameter, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Odebere') and resource ('adresu ze sledovaných míst'), clearly indicating it removes an address from watched locations. It does not differentiate itself from sibling tools like prestat_sledovat_obec or prestat_sledovat_komunitu, which also stop watching things.

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

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

There is no guidance on when to use this tool versus alternatives such as prestat_sledovat_obec or prestat_sledovat_komunitu. The description simply states what it does without any context about prerequisites or appropriate scenarios.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, covering the core safety profile. The description adds useful specificity that the subscription being removed is the weekly community digest, but it does not explain reversibility, permissions, or re-subscription options.

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 a single, front-loaded sentence with no filler. Every word contributes to stating the action and scope.

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 mutation tool with rich annotations and full schema coverage, the description is largely sufficient. It could mention that the user can re-subscribe via sledovat_komunitu, but such context is not strictly required to invoke correctly.

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

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

The schema has 100% description coverage, including a description for komunita_id that references moje_sledovane. The tool description adds no additional parameter meaning, 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 uses a specific verb ("Odhlásí") and resource ("týdenní souhrn komunity"), making the action clear. It distinguishes itself from the follow tool by implication of "prestat," but does not explicitly name a sibling alternative.

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

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

Usage is only implied by the verb "Odhlásí"—there is no explicit guidance on when to use this versus changing summary settings or unsubscribing from an address/community. No alternatives or exclusions are mentioned.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds a meaningful post-condition beyond the annotations: previously published notices remain on the web, which reassures the agent about side effects of removal.

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, zero waste, with the core removal action front-loaded and the post-condition second.

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?

A single-parameter mutation tool with rich annotations and full schema coverage; the description covers the action and its key side-effect. Only missing piece is explicit guidance on the sibling alternatives and failure behavior when the obec isn't followed.

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 sole parameter obec_id is documented with its source ('z nástroje moje_sledovane'). The description adds nothing extra about the parameter, 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 ('Odebere obec ze sledovaných'), making the inverse relationship to sibling sledovat_obec clear. It could explicitly name the alternative siblings (prestat_sledovat_adresu/komunitu) but the operation is unambiguous.

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

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

Usage is implied by the inverse of sledovat_obec and by the note that published notices remain, but there is no explicit statement of when to use this versus the address/community variants, nor any prerequisite (e.g. obec must currently be followed).

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, idempotentHint=true, and destructiveHint=false, so the safety profile is largely covered. The description adds real value by explaining the downstream consequence (the weekly summary includes nearby notifications) and the default radius, though it says nothing about auth requirements or failure behavior for an invalid address.

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 compact two-clause sentence with the action front-loaded, so the agent reads the core purpose first. The final clause on the 700 m default is mildly redundant with the schema but reinforces the parameter, costing little.

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, the description covers the action, its effect, and the default radius, while annotations carry the safety profile (idempotent, non-destructive). It is nearly complete, missing only edge-case behavior such as what happens with an unrecognized address.

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 three parameters are already documented in the schema, including the 100–2000 range and the 700 m default. The description's mention of "Výchozí okruh je 700 m" merely repeats what the schema already states, so it adds no meaning beyond the structured fields. Baseline 3 is appropriate.

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

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

States a specific verb and resource: "Přidá českou adresu s okruhem mezi sledovaná místa" (adds a Czech address with a radius to tracked places). The action is clearly distinguishable from siblings like prestat_sledovat_adresu (stop) and zmenit_okruh_adresy (change radius) without opening any schema.

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

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

The description conveys the purpose and effect ("týdenní souhrn pak zahrne oznámení z okolí"), giving implied context for when this is useful. However, it never names an alternative or states when-not to use it, leaving the agent to infer the boundary against zmenit_okruh_adresy and the other sledovat_* 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 the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so safety is covered. The description adds the useful cadence detail that the subscription is weekly, but says nothing about what happens on repeat calls, whether the subscription is reversible, or any auth prerequisite.

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 zero filler, front-loading the action and the resource. It is efficient, though its brevity reflects missing usage guidance rather than tight editing of rich content.

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

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

For a low-complexity, one-parameter subscription tool with full schema coverage and adequate annotations, the description covers the core action. It still leaves the agent without routing guidance among the many sledovat_/prestat_sledovat_ siblings, which is the main gap for this tool family.

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

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

Schema coverage is 100% with a single well-documented komunita_id, so the schema carries the parameter meaning. The description adds no format, range, or lookup guidance beyond what the schema already states, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource ('Přihlásí uživatele k týdennímu souhrnu komunity') and the community scope distinguishes it from the address/municipality siblings. However, it never explicitly contrasts itself with related siblings such as nastavit_souhrn or prestat_sledovat_komunitu, so sibling differentiation relies on the name alone.

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

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

There is no statement of when to use this tool, when not to, or which alternative to pick. The presence of nastavit_souhrn and the three prestat_sledovat_* siblings makes routing guidance genuinely valuable here, and none is provided.

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

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

Annotations already declare this as a non-destructive, idempotent write, so the bar is lower. The description adds a genuinely useful behavioral constraint beyond the annotations: the number of followed municipalities is capped by the user's plan, which warns the agent that the call can fail for quota reasons.

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, front-loaded sentences with no filler: the action comes first, the resulting benefit second, and the plan-limit caveat last. Nothing is repeated from the title or schema.

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

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

For a one-parameter follow tool whose annotations already cover safety and idempotency, this is nearly complete: purpose, benefit, and the plan limit are all stated. It could go one step further by saying what happens when the limit is reached or by naming the inverse tool, but no critical information for invoking it 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?

There is a single parameter with 100% schema description coverage, so the schema already carries the semantics (including that the ID comes from najit_obec). The description adds nothing about obec_id, 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?

The description states a specific verb and resource – adds a municipality to the followed list – and adds the benefit (weekly summary, overviews), which makes the intent unambiguous. It does not explicitly name the sibling it contrasts with (prestat_sledovat_obec, moje_sledovane), but the verb 'Přidá' makes the direction of the operation clear enough to distinguish it from the unfollow siblings.

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

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

Usage is only implied: the parenthetical (týdenní souhrn, přehledy) hints at why an agent would follow a municipality, and the schema states obec_id comes from najit_obec. There is no explicit when-to-use/when-not guidance and no pointer to prestat_sledovat_obec for the inverse operation.

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, so the safety profile is fully covered. The description adds the data source (Registr smluv) and the nature of the returned content, but says nothing about result volume, pagination, or date/keyword scoping 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?

Two tight sentences, front-loaded with the purpose before the input directive, with no filler. Slight redundancy between the second sentence and the schema's obec description keeps it from a 5.

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 read-only, 3-parameter search tool with 100% schema coverage and annotations carrying the safety profile, the description is adequate. It is missing result-limit/pagination expectations and any routing to sibling tools, which leaves gaps for an agent deciding how to use it.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description only reiterates the obec input format, adding no 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?

States a specific verb and resource: 'Najde smlouvy obce v Registru smluv' and even previews the returned fields ('s kým, kdy a za kolik'). It is clear what the tool does, but it does not reference the potentially confusable sibling najit_obec (finding a municipality) to draw the boundary.

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

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

No when-to-use or when-not guidance is given; it never says how it relates to siblings like hledat or najit_obec. The only instruction ('Obec zadejte IČO nebo jednoznačným názvem') is about parameter formatting, not about selecting this tool over alternatives.

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 safety is covered structurally. The description's one added behavioral fact is the default to the current week when tyden is omitted; it says nothing about volume, pagination or what an 'oznámení' record contains.

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 tightly written sentence plus a short default-behavior clause; the scope and the source of the selection are front-loaded and nothing is redundant.

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

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

For a read-only, idempotent, fully documented 3-parameter tool with no output schema, the definition covers what the agent needs to call it. The one gap is that it does not describe the shape of a returned oznámení, which the missing output schema would otherwise require.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuinely non-schema information: omitting tyden returns the current week, and the result set mirrors the weekly e-mail selection. That meaningfully clarifies the optional parameter's behavior.

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

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

The description gives a specific verb and resource ('Vrátí oznámení') scoped to a week and to a watched place of type obec/adresa/komunita, which cleanly separates it from sibling tools like zasedani_obce or smlouvy_obce. It does not explicitly name a sibling it is not, so it falls short of a 5.

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

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

Usage is implied rather than stated: the tool applies to a place the user already follows, and the schema notes the id comes from moje_sledovane, which hints at the prerequisite flow. There is no explicit when-not-to-use guidance or named alternative, so the agent must infer the routing.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds two traits not in the annotations: the result is limited to the first followed item, and there is a per-account quota (3 samples, shared with e-mail summaries). It stops short of saying what happens once the quota is exhausted.

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

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

Two short sentences: the purpose leads, the quota constraint follows. Nothing is padded, and the quirk about the first followed item is front-loaded. It could be marginally tighter, but it earns its length.

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

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

For a zero-parameter, read-only tool with no output schema, the description covers what an agent needs: what is returned (the first followed item's summary) and the quota limit. The main gap is the absence of any hint about behaviour when the quota is used up or the user follows nothing.

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

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

The tool takes zero parameters, so there is no parameter semantics to document and the baseline is 4. The schema has no properties to describe, and nothing in the description misrepresents the input contract.

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 ('Ukáže týdenní souhrn') and pins down a non-obvious scope: it is the summary of the FIRST followed item only. That is enough for an agent to understand the action, but it never distinguishes itself from the sibling 'tydenni_prehled', which sounds like an overlapping weekly-overview tool.

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

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

The mention of the Free-tier allowance (3 samples per account) implies this is a preview/sample capability aimed at non-paying users, which gives some usage context. However, there is no explicit statement of when to call this instead of 'tydenni_prehled' or 'nastavit_souhrn', so the routing decision is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: it returns links to both detail pages and original announcements, and it covers a fallback scope (unprocessed municipalities). No mention of result count, pagination, or rate limits, which keeps it at a solid but not rich 3.

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

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

Two tightly written sentences with the core purpose front-loaded and the scope caveat second. No filler or redundancy; only the absence of any pagination/limit note keeps it from a 5.

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 read-only list tool with no output schema, the description tells the agent what it returns (latest board items, detail links, original-announcement links) and when the tool is the only viable option. The remaining gap is result volume/pagination behavior, which is minor.

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 obec_id parameter is documented there, including a pointer to najit_obec as its source. The description adds no parameter syntax or constraints beyond the schema, so the baseline 3 for fully-covered schema 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 ('Vypíše nejnovější položky úřední desky obce') and clarifies the payload includes links to detail and to the original announcement. It also implicitly carves itself out from point-based siblings by noting it works for municipalities not yet processed into points. It stops short of naming a sibling directly, so an agent must infer the boundary.

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

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

The second sentence gives a real usage condition: for municipalities not yet processed into body/points, this is the only route to their announcements. However, it never says when to prefer this over the nearby smlouvy_obce, zasedani_obce or point-based flow for processed municipalities, so guidance 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 readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds the genuinely useful dual-mode behavior and the shape of what comes back (meeting list vs. agenda items), which no annotation conveys. It still omits ordering, result limits and whether the organ filter changes the returned list, so it stops short of 'rich'.

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

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

A single front-loaded sentence that contrasts the two call modes in parallel clauses. Nothing is padded and no sentence is wasted.

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

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

With no output schema, the description takes on the burden of indicating return contents, and it does so at a high level for both modes. For a three-parameter, read-only lookup that is nearly sufficient; pagination, sort order and the effect of combining 'datum' with 'organ' remain 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%, so the baseline is 3, but the description goes beyond the schema's neutral 'optional date' wording by explaining that the presence of 'datum' switches the tool between list mode and single-meeting mode. 'obec_id' and the 'organ' enum are left entirely to the schema, which is acceptable given full 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 concrete resource (municipal meetings) and spells out both modes of operation – a list of bodies when called without a date, and the agenda items of a single meeting when a date is supplied. That is far more specific than a bare restatement of the name, though it never names a sibling tool to disambiguate from detail_bodu or smlouvy_obce.

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

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

The description makes the selection condition explicit: omit 'datum' to enumerate meetings, supply it to drill into one meeting's agenda. That is actionable routing guidance, but it offers no exclusions (e.g. when to prefer detail_bodu for a single agenda item) and no prerequisites such as needing obec_id from najit_obec, which only the schema notes.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds a genuine behavioral detail the annotations lack: the radius must be a multiple of 100 m within 100–2000 m. It says nothing about failure behavior when the address is not currently followed, so it is solid but not rich.

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

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

A single sentence with the constraint range parenthesised inline, no filler and no repetition of the title. Front-loaded with the action.

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

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

For a two-parameter idempotent mutation with full annotation coverage and no output schema, the essentials are present. However, it omits the precondition that the address must already be watched (obtainable via moje_sledovane) and any note on what happens if it is not, leaving a real gap for correct invocation.

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

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

Schema description coverage is 100%, so both parameters are already documented (adresa_id sourced from moje_sledovane, polomer_m in metres). The description's only addition beyond the schema is the 100 m step constraint, which the min/max bounds alone do not convey, so baseline 3 is appropriate.

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

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

The description states a specific verb ("Nastaví") and resource ("okruh u sledované adresy"), so the agent knows it modifies an existing watched address's radius. It does not name a sibling or clarify how it differs from sledovat_adresu / prestat_sledovat_adresu, so it stops short of a 5.

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

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

There is no statement of when to use this tool versus the sibling follow/unfollow tools, nor any prerequisite such as the address already having to be followed. Usage can only be inferred from the name and the schema's reference to moje_sledovane.

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