InfoGrunt

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds what comes back (gmina, obręb, location, parcel-page link), but says nothing about behavior when the number is malformed or the parcel does not exist.

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 packs the action, the required key, an example, and the returned fields. The trailing list after the colon is slightly ambiguous as to whether it describes the number's components or the response, which is minor friction.

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 an output schema present and annotations covering the read-only profile, the essentials are covered for a one-parameter lookup. However, no failure mode or alternative-routing guidance is given, which matters for a sibling set containing find_parcel_at_point.

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 0% and the schema only constrains length (3-60 chars), so the description carries the load and does so usefully by supplying a concrete example format (101710_2.0007.1504/6). It stops short of decomposing the identifier segments, leaving some parsing inference to the agent.

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 and resource ('Znajdź działkę') and pins the lookup key to a full cadastral number ('pełny numer ewidencyjny'), which implicitly separates it from find_parcel_at_point's spatial lookup. It does not name a sibling explicitly, 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 find_parcel_at_point, get_parcel_overview, or get_parcel_section. The only usable hint is that a complete identifier is required, which the agent must infer from 'pełny numer'.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety and side-effect profile is covered. The description adds that the result includes parcel number, commune, and a link, but since an output schema exists, this is not substantial additional behavioral disclosure.

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

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

The description is short, front-loaded as a question, and easy to scan. The second sentence partly restates return fields already covered by the output schema, but it remains efficient overall.

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 two-parameter lookup with rich annotations and an output schema, the description covers the core purpose and basic return content. It leaves gaps around parameter semantics and alternative tools, which matters more here because the input schema has no parameter descriptions.

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

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

Schema description coverage is 0%, so the description must compensate for the lat/lng parameters. It only says 'point on the map of Poland' and does not explain the latitude/longitude distinction, expected format, or coordinate order beyond what the schema's min/max bounds already imply.

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: it finds which parcel lies at a map point in Poland and returns parcel number, commune, and a link. It is clear and distinct from a general parcel lookup, but it does not explicitly name or differentiate itself from the sibling find_parcel 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?

Usage is implied by the phrase 'for a point on the map of Poland,' which tells the agent this tool is for coordinate-based parcel lookup. However, there is no explicit when-to-use guidance, no when-not-to-use guidance, and no mention of alternatives such as find_parcel or search_location.

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 closed-world, so the safety profile is covered. The description adds value beyond that by disclosing the time horizons returned (last week, month, year) and that a price-map link is included, which tells the agent what a call yields.

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 the resource and metric front-loaded, followed by the scope and the return contents. No padding 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?

With one optional parameter, annotations covering safety and an output schema handling return shape, the description supplies what is missing: scope granularity and time windows. The one residual gap is that it does not state the 'Polska' default explicitly.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden — and it does: it clarifies that the single 'region' argument accepts either the whole country or one voivodeship, which is exactly the semantics the bare schema lacks. It stops short of naming accepted values or confirming the default, keeping it off a 5.

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

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

The description names a specific resource and metric ('ceny działek budowlanych' – prices of building plots) and a specific scope (all of Poland or a single voivodeship), so an agent can tell this is a regional price-trend tool. It implicitly contrasts with the municipality-level sibling get_municipality_market but never names it, so differentiation is left to inference.

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 phrase 'w całej Polsce albo w jednym województwie' implies the granularity at which this tool operates and thus when it is the right choice over a municipality-level tool. However, no alternative is named and no explicit when-not guidance is given, 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 readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile needs no restating. The description adds value by disclosing data provenance ('z prawdziwych transakcji') and that results carry a period and a confidence measure, which hints at data coverage/recency concerns an agent should weigh — but it does not say what happens for municipalities with sparse transactions or how the confidence field should be interpreted.

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

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

Three compact sentences: a leading question framing the outcome, a list of what the answer contains, and the input requirement placed last but with zero filler. The rhetorical question is slightly wasteful, but nothing else could be cut without losing 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 an output schema present, return values need no explanation, and rich annotations cover safety and idempotency. The description supplies the one thing the schema lacks — where the TERYT code comes from — plus the data-quality context; the only gap is the absence of any hand-off rule versus the other market-oriented siblings.

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

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

Schema description coverage is 0%, so the description must carry the burden for the single parameter, and it does add meaning: it names the source of the value (a 6-digit code from an address search) rather than just the format. The 6-digit constraint itself is already enforced by the schema pattern, so the description's contribution is the origin of the code, not its shape.

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 resource (land-plot prices in a municipality) and enumerates the substance of the answer: median prices from real transactions, sale count, period, and confidence. It is clear at a glance, but it never distinguishes itself from the sibling get_market_pulse, which plausibly overlaps in scope, so an agent must infer the split.

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 closing sentence gives practical sourcing guidance — the municipality is indicated by a 6-digit code obtained from an address search — which is a real usage hint for obtaining the required argument. However, there is no statement of when to pick this tool over get_market_pulse or get_parcel_overview, so routing between siblings stays implicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety and idempotency behavior are covered. The description adds useful scope by listing the domains included and noting that it returns a link to the full report, but it does not disclose data freshness, partial availability, or other operational 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?

The description is compact and front-loaded: it names the tool's purpose, then lists the data categories covered, then notes the returned report link. The list is dense but each item contributes to scope; there is little wasted text.

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?

An output schema exists, so the description need not explain return values in detail, and the annotations cover safety traits. However, it still omits important context: how parcel_id is sourced, how this overview differs from get_parcel_section, and whether results are partial or cached. It is adequate but incomplete for a multi-domain overview tool.

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

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

Schema description coverage is 0%, so the only structured information about parcel_id is its type and length constraints. The description does not explain the parcel identifier format or how an agent should obtain a valid parcel_id, for example from find_parcel or search_location. For a tool with a single required parameter, this leaves a meaningful gap.

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

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

The description gives a clear verb+resource ('Sprawdź działkę') and enumerates the parcel data domains the overview covers: zoning plan, building conditions, flood risk, utilities, access, nature protection, landslides and local prices. It is clearly an overview tool, but it does not explicitly differentiate it from siblings such as get_parcel_section or find_parcel.

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 tool is for checking what is known about a parcel and obtaining a link to a full report. There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as using find_parcel first or get_parcel_section for section-level detail.

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 open-world behavior, so the safety profile is covered. The description adds a useful provenance detail — results include source, date, and a link back to the parcel page — but says nothing about invalid sections, availability for a given parcel, or caching.

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

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

Two short sentences, front-loaded with what the tool returns and then the value-add (examples plus provenance). Nothing is padded, though one clause about where parcel_id comes from would have earned 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?

An output schema exists, so return values need no further explanation. However, for a read-only lookup whose only real difficulty is picking the right section and sourcing parcel_id, the description leaves both partially unresolved and does not say how this differs from get_parcel_overview.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. Its examples translate several opaque enum values (mpzp, flood, utilities, road_context, transactions) into human terms, but several enum values (egib, wz, protected_areas, landslides, air_quality, identity_and_geometry) remain unexplained and parcel_id's origin/format is never addressed.

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+resource: retrieving a single thematic section for a parcel, and gives concrete examples (zoning plan, flood, utilities, road access, nearby transactions). It does not explicitly contrast with the sibling get_parcel_overview, so sibling differentiation is only implied by 'jednego tematu'.

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 — call this when you need one specific topic rather than the whole overview — but no alternatives are named and no conditions for choosing this over get_parcel_overview or find_parcel are stated. The agent must infer the routing from the word 'one topic'.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds that a result places the point on a parcel map and exposes a municipality plus an InfoGrunt.pl link, which is mild extra context beyond annotations but largely repeats what the output schema can express.

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

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

Two short sentences, front-loaded with the search scope before the output description, with no filler. The second sentence partly duplicates what the output schema already conveys, which costs one point.

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 a rich annotation set and an existing output schema, the description only needs to cover the input contract and routing, and it covers the input format by example. The missing piece for a catalog of six geospatial siblings is routing guidance: nothing tells the agent to use this for addresses/towns and the find_parcel family for cadastral parcels.

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 'query' parameter has 0% schema description coverage, so the description carries the burden. The worked example 'Polna 5, Wieliczka' usefully demonstrates that 'street number, town' is an accepted format, but nothing is said about the 2–200 character bounds, whether a country qualifier is needed, or how partial or ambiguous names are resolved.

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

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

The description names a specific verb (Znajdź) and a specific resource class (adres, ulica, miejscowość), which is distinguishable from the parcel-oriented siblings like find_parcel and find_parcel_at_point. It stops short of explicitly stating that it does NOT search parcels, so the differentiation is inferable rather than declared.

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 example 'Polna 5, Wieliczka' implies the intended use case (geocoding a free-text location in Poland), so usage is implied. However, no sibling is named and there is no guidance on when to pick this over find_parcel or find_parcel_at_point, which are plausible alternatives for a user asking about a place.

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