GROO reality

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states content scope and does not mention whether the operation is read-only, what the return shape is, how articles are ordered, or whether pagination/freshness behavior applies.

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 one compact clause that states topic and scope without filler. The key noun phrase 'Články z webu' is front-loaded, and every part contributes meaning.

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

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

Given one optional parameter and no output schema, a minimal description can be workable, but this one omits any explicit statement of the return format or ordering. An agent would benefit from knowing that the tool returns a list of articles and what fields to expect.

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 only parameter, limit, already has its default value documented in the schema. The description adds nothing about parameters, but this is acceptable because the schema fully covers them.

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

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

The description 'Články z webu — dění v kanceláři a na realitním trhu' identifies the resource as web articles about office and real-estate market news, which distinguishes it from property-search or detail tools. It lacks an explicit action verb such as 'returns' or 'lists', but the name and title make the retrieval purpose clear.

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 topical context implies when the tool is relevant: for office and real-estate news. However, there is no explicit guidance on when not to use it or which sibling to prefer, and it does not contrast with detail_aktuality for fetching a single article.

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

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

No annotations are provided, so the description must carry the behavioral disclosure. It adds a meaningful detail: municipalities are limited to those where offers actually exist, which is a scoping behavior an agent should know. It does not describe response structure, side effects, or whether the data is static, but for a simple read-only codelist this is a moderate but acceptable gap.

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

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

The description is a single short sentence that front-loads the core concept—'allowed filter values'—and then lists the specific categories. Every word earns its place and there is no redundancy.

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

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

For a simple zero-parameter tool, the description gives a decent sense of what will be returned. However, there is no output schema, and the description does not describe the response shape, grouping, or how these values should be used by other tools. It is minimally adequate but leaves room for ambiguity, especially around how types, categories, dispositions, and municipalities relate.

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 has zero parameters, and the schema description coverage is 100%, so there are no parameter semantics to explain. The description adds value by clarifying what the returned filter values are—types, categories with dispositions, and municipalities—which is the relevant semantic content for this no-parameter tool.

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

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

The description clearly identifies the resource as allowed filter values—types, categories with dispositions, and municipalities with actual offers. It implies a codelist/getter tool and is distinguishable from content and search siblings like hledej_nemovitosti or detail_nabidky, though it lacks an explicit verb such as 'returns' or 'provides'.

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: because this exposes permitted filter values, an agent can infer it should be used to populate or validate filters for real-estate searches. However, it does not explicitly say when to use this tool instead of a sibling, nor does it mention that these values feed into hledej_nemovitosti.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the output is the full article text, but says nothing about read-only behavior, error handling for invalid ids, how the id should be obtained, or the response structure. This is minimal for a tool with zero annotation coverage.

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

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

The description is one short sentence with no filler. The key differentiator ('ne jen perex') is front-loaded, and every word contributes meaning.

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 one-parameter read tool with no output schema, the description conveys the core behavior and the schema covers the parameter. However, it lacks explicit usage guidance and any behavioral details beyond the text returned, so it is 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 description coverage is 100%: the id parameter is described as 'Číslo článku ze seznamu aktuality', so the schema fully documents the parameter. The description adds only implicit context that the id refers to an article and does not provide additional format or syntax details, keeping it at the baseline.

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 the tool provides the full text of a single article ('Celý text jednoho článku') and explicitly distinguishes it from a mere perex ('ne jen perex'), which separates it from the list sibling 'aktuality'. However, it lacks an explicit verb like 'returns' or 'gets', making it clear but slightly less direct.

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

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

The description implies usage context by contrasting with 'ne jen perex', suggesting this tool is for fetching full article content rather than a summary. It does not name alternative tools or state explicit when-to-use/when-not-to-use conditions, so the guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It accurately describes the primary behavior as a read operation returning a single offer's details and lists the data categories, but it does not cover error behavior, invalid ID handling, or any permissions. This is minimally adequate for a simple retrieval tool.

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

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

A single front-loaded sentence states the action and the return content without filler. The enumeration of returned fields is useful and compact, making the description highly efficient for an agent.

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

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

For a tool with low complexity (one required parameter, no output schema, no nested objects), the description is largely complete: it explains what the tool returns and the schema fully documents the input. The main gap is the lack of usage/alternative routing, but that is already accounted for under usage guidelines.

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

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

Schema description coverage is 100%: the only parameter 'id' is already described as an offer number with an example ('groo1516'). The description adds no further parameter semantics, so the baseline score 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 uses a specific verb ('Vrátí' - returns) and a specific resource ('podrobnosti jedné nabídky' - details of one offer), and enumerates the expected content: description, parameters, address, photos, and agent contact. This clearly differentiates it from sibling tools like detail_projektu, which target a different resource.

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 explicit guidance is given on when to use this tool versus alternatives such as detail_projektu or hledej_nemovitosti. The use case is implied by the tool name and the phrase 'jedné nabídky', but 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates the returned content — a project and its units — but does not mention whether the operation is read-only, how the units are ordered, what happens for an invalid id, or what fields the unit list 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?

Tohis is a single short sentence with no filler; the core meaning is front-loaded and every word contributes. It is appropriately concise for a simple detail tool.

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

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

For a simple by-id detail endpoint, the description gives the essential result shape: a developer project with its sale units. However, there is no output schema and no usage or behavioral context, so a bit more detail about the returned data would make the description fully self-sufficient.

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 fully documents the single id parameter as the project number from the projekty list, so the description does not need to add parameter-level detail. The description adds useful context about the returned units, but that is not required for binding the id correctly.

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 that the tool returns a developer project together with a list of units being sold, which clearly identifies the resource and the content. It lacks an explicit verb, but the noun-phrase description is unambiguous and distinguishes it from list-level tools like projekty and from other detail tools like detail_nabidky.

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 guidance is given about when to use detail_projektu versus alternatives such as projekty, detail_nabidky, or detail_aktuality. The tool name and content imply its purpose, but the description does not state selection criteria or exclusions.

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

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

With no annotations, the description carries the transparency burden. It does disclose one useful behavioral trait beyond the name — that the response includes a total match count — and it implies a read-only lookup. But it stays silent on pagination, sorting, or the shape of returned offers, so transparency is partial.

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 deliver the resource, filter flexibility, and a key return-value detail with no redundancy. The core action is front-loaded, and every sentence 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?

The description covers the tool's purpose, optional filters, and the total count. However, with no output schema, it does not explain the structure of returned offers or how results are ordered/limited beyond the limit parameter documented in the schema, leaving a moderate completeness gap.

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

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

Schema description coverage is 88%, so the schema already documents nearly all parameters. The description adds only the high-level guarantee that filters are optional and combinable, which is useful but does not materially deepen parameter understanding beyond the schema.

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

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

The description opens with the verb 'Vyhledá' and a specific resource, 'nemovitosti v aktuální nabídce GROO reality', making the search scope clear. It does not explicitly contrast itself with siblings such as detail_nabidky, so it misses the top score for sibling differentiation.

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

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

It states that all filters are optional and can be combined, which gives some guidance on parameter usage. However, it does not say when to choose this tool over detail_nabidky or projekty, so the usage context is implied rather than explicit.

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

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

There are no annotations, so the description must carry the behavioral burden. It conveys that the tool exposes informational contact data, implying a safe read operation, but it does not explicitly state that there are no side effects or describe any other behavioral characteristics.

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, short phrase that says exactly what the tool provides. It contains no filler, redundancy, or unnecessary detail, and the key information is immediately visible.

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 contact-info tool, the description is largely complete: it names the three key fields (phone, email, address). It could be slightly more explicit about the return format, but the simplicity of the tool makes the description adequate.

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 has zero parameters and the schema shows none, so there are no parameter semantics to clarify. The baseline of 4 applies because there are no parameters for the description to document.

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 clearly identifies the resource: contact information for the real estate office, specifically phone, email, and address. It is unambiguous and immediately understandable, though it does not explicitly differentiate itself from sibling content tools.

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

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

No usage guidance is provided. The description does not say when to prefer this tool over alternatives like 'stranka' or 'reference', nor does it mention any exclusions or context in which the tool should not be used.

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

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

No annotations are present, so the description carries the behavioral burden. It clearly implies a read-only lookup of wanted properties and adds useful context about being the reverse of hledej_nemovitosti, but it never explicitly states that the operation is safe or describes the return shape. There is no mutating language, so behavior is inferable but not fully disclosed.

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

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

The description is a single compact sentence that front-loads the core purpose and immediately follows with usage direction. Every word earns its place, with no filler or redundancy.

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

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

For a zero-parameter lookup tool with no output schema, the description provides all essential context: what the tool returns (sought-after properties), when to invoke it, and how it differs from a sibling. Nothing critical for selecting and calling 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?

The tool has zero parameters and an empty input schema, so there is no parameter contract to clarify. The baseline of 4 applies because the schema fully covers everything about inputs.

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 function: listing properties that GROO reality actively seeks for its clients. It also explicitly differentiates itself from the sibling tool hledej_nemovitosti by declaring the opposite direction, so an agent can distinguish them immediately.

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 provides an explicit when-to-use condition: 'Použij, když někdo prodává nebo se ptá, jestli má o jeho nemovitost někdo zájem'. It also names the alternative tool and characterizes the relationship as 'opačný směr', giving clear exclusion 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states selection criteria only, not whether the operation is read-only, how results are ordered or paginated, or what the response contains. This goes little beyond describing the underlying data subset.

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

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

A single compact sentence with no filler. The defining criteria—section, property type, and sales model—are all included without redundancy.

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

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

For a parameterless collection tool, the description captures the main selection criteria and adequately singles out the intended data set. Minor gaps remain: it does not explicitly say that a list is returned and it gives no routing hints to related sibling tools, but these are not critical to invoking a zero-parameter endpoint.

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 input schema has zero properties and the schema description coverage is 100%, so there are no parameters that need explanation. The baseline of 4 for parameterless tools 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 identifies a specific resource: projects from the Doporučujeme section, limited to new builds and reconstructions sold in multiple units. This scope distinguishes it from detail_projektu and other sibling tools, though the action (listing/returning) is only implied by the plural name and title rather than stated with an explicit verb.

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 guidance is given on when to use this tool instead of alternatives like hledej_nemovitosti or detail_projektu. The description defines the data scope but does not mention exclusions, alternatives, or conditions.

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

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

With no annotations, the description carries the full burden of explaining behavior. It conveys that the tool provides client statements about cooperation, which is useful. However, it does not disclose return format, whether it returns a list or a single page, or any limitations.

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

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

Two short sentences, with the core content front-loaded and the usage context second. Every word earns its place; there is no filler or repetition.

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 zero-parameter content tool, the description is largely complete: it says what the content is and when it is useful. A minor gap is that it does not explicitly state whether the result is a single reference or a collection of references, but this is low-stakes given the lack of parameters.

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

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

The tool has zero parameters and the schema is fully self-explanatory with 100% coverage. The description does not need to explain parameters, and the no-parameter baseline of 4 applies. Nothing is missing here.

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

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

The description clearly identifies the resource: client-written testimonials about collaboration with the office. It distinguishes itself from siblings like 'projekty' or 'aktuality' by specifying client references. However, it lacks an explicit action verb such as 'returns' or 'shows', so it is slightly below the strongest definitions.

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 explicitly states when to use the tool: when someone asks about experiences or reliability of the office. It gives clear usage context but does not mention alternatives or exclusions, which would make it stronger.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It usefully discloses that the result is Markdown text of one page, implying a read-only content retrieval, but it does not address invalid or missing URIs or whether the response can be empty. It is not misleading, but the behavioral detail is minimal.

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 first states what the tool returns, and the second states when to use it. There is no filler, repetition, or unnecessary detail, and the most important information is front-loaded.

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

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

For a one-parameter read-oriented tool, the description adequately covers the output format and the intended use cases. It could be slightly more complete by mentioning that 'stranky' might help discover valid URIs, but the schema example and the natural website-path format make the tool usable without that.

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

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

Schema description coverage is 100%: the 'uri' parameter is fully documented with the path format and examples like 'sluzby/prodej' or 'kontakt'. The tool description adds no parameter-level information beyond the schema, so the baseline of 3 applies.

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

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

The description identifies the tool as returning the text of one website page in Markdown ('Text jedné stránky webu v markdownu') and links it to a concrete use case. It is clear enough to distinguish from content-list tools like 'stranky' and detail tools, though it lacks an explicit verb such as 'vrací' (returns) and does not name a sibling directly.

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

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

The description gives explicit triggers: use it when someone asks how the office works, what it does when selling, or what services it offers. It does not mention when not to use it or point to alternatives like 'stranky' for finding page URIs, but the provided 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?

With no annotations, the description carries the full burden. It states that the tool returns a list (not page content) and gives example page types, but it does not specify whether the list is exhaustive, the exact return format, or what identifiers are included. For a simple zero-parameter listing tool, the core behavior is disclosed clearly enough.

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

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

One sentence front-loads the core purpose, gives illustrative examples, and ends with the sibling pointer. Every part earns its place with no redundant phrasing.

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

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

The description covers purpose, scope, and the relationship to 'stranka', which is enough for a zero-parameter tool. However, since there is no output schema, it would be slightly more complete to state what each list entry contains (e.g., page names or identifiers usable by 'stranka').

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 are zero parameters and the schema is empty, so parameter-semantic burden is minimal. Per the baseline for 0-parameter tools, a 4 is appropriate because there is no parameter ambiguity to resolve.

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

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

The description opens with 'Seznam stránek webu' ('List of website pages'), which names a specific verb (list) and resource (website pages), and then enumerates example page categories. It also names the sibling tool 'stranka' as the one that returns page content, clearly distinguishing this tool from it.

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

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

The final clause 'Obsah konkrétní stránky vrátí nástroj stranka' explicitly tells agents to use this tool for listing pages and to use 'stranka' for page content. This gives a direct when-to-use/alternative instruction.

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