Stránky webu
strankySeznam stránek webu — služby kanceláře, právní informace, o makléřce. Obsah konkrétní stránky vrátí nástroj stranka.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
strankySeznam stránek webu — služby kanceláře, právní informace, o makléřce. Obsah konkrétní stránky vrátí nástroj stranka.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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.
Add one secure layer between your agents and this server.
Every tool has a clearly distinct purpose: list/detail pairs are separated by the detail_ prefix, and hledej_nemovitosti is explicitly contrasted with poptavky as the opposite direction. No two tools appear to do the same thing.
Most tools follow a predictable pattern: plural nouns for lists, detail_<entity> for single items, and singular nouns for standalone content like kontakt, reference, and stranka. The pattern is slightly broken by hledej_nemovitosti, which uses a verb style rather than a noun.
Twelve tools is well within the ideal range for a real-estate website integration. Each tool covers a distinct public content area without unnecessary redundancy.
The toolset covers all relevant public surfaces of a real-estate agency site: offers, projects, articles, codebooks, contact, references, and static pages. For an informational read-only integration, no significant lifecycle operations are missing, and the search tool with optional filters avoids dead ends.