Agentic GIS server to work with Slovenia's cadastre records
Scored across 16 tools
Most tools are clearly differentiated by explicit USE FOR/NOT FOR sections, but the cadastral tools (slovenia-cadastral-deep, slovenia-cadastral-simple, slovenia-wfs-expert) overlap in purpose, and descriptions reference non-existent tools like 'slovenia-cadastre', causing potential misselection.
All 16 tools use consistent kebab-case naming with clear domain prefixes (geo-, slovenia-, eu-), with no mixing of conventions such as camelCase or snake_case.
16 tools is slightly above the ideal range of 3-15, but the breadth of domains (transit, geocoding, routing, trails, hostels, cadastral, weather) justifies each tool's presence without redundancy.
The surface covers a wide range of geo/travel operations, but minor gaps exist (e.g., global weather, urban public transit), and some tools point to non-existent alternatives, slightly limiting completeness.
EU-wide public intercity transit router. Accepts PLACE NAMES (not coordinates). Returns multi-leg itineraries via Transitous.
CRITICAL FOR AGENTS:
This tool handles geocoding internally. Do NOT pre-geocode or look up coordinates.
Do NOT call this tool multiple times with different spellings. Call it ONCE.
If a location isn't found, present the error message and STOP.
TEMPORAL HANDLING: This tool returns live real-time schedules only (no date parameter). If user asks for 'tomorrow' or a future date, pass it as --requested-date. The tool will add an explanatory note about schedule patterns.
EXAMPLES:
--from "Ljubljana, Slovenia" --to "Maribor, Slovenia"
--from "Podbrdo" --to "Nova Gorica" --requested-date "2026-06-05" --limit 3
--from "Bled" --to "Trieste, Italy" --modes "BUS WALK"
FAILURE MODES (present directly to user, do not retry):
LOCATION_NOT_FOUND → Check spelling
NO_ROUTES_FOUND → Try different modes or check locations are in Europe
ROUTING_FAILURE → Upstream API error, try again later
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of alternative itineraries to return. Range: 1-5. | |
| modes | No | Space-separated transport modes. Allowed: TRANSIT WALK BUS RAIL TRAM SUBWAY FERRY BICYCLE CAR. Always include WALK with TRANSIT. | TRANSIT WALK |
| to_place | Yes | Destination place name. Example: 'Nova Gorica, Slovenia' | |
| from_place | Yes | Origin place name. Example: 'Podbrdo, Slovenia' or 'Ljubljana' | |
| requested_date | No | User's requested date in YYYY-MM-DD format (optional). Used only to generate a note about real-time vs. future schedules. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses geocoding internally, live real-time schedules, and failure modes. Could be more explicit about output format, but covers key behavioral traits.
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?
Well-structured with sections for critical instructions, temporal handling, examples, and failure modes. Slightly verbose but every section adds value 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?
Comprehensive given no output schema and 5 parameters. Covers purpose, usage, parameters, failure modes, and temporal handling. Examples illustrate all parameter combinations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds functional context: place names (not coordinates), requested-date usage, modes allowed with WALK requirement, and limit range. Elevates above 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 clearly states the tool is an 'EU-wide public intercity transit router' accepting place names and returning multi-leg itineraries. It distinguishes from siblings like geo-route by focusing on public transit and handling geocoding internally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use instructions: do not pre-geocode, call once, present errors, and handle temporal requests with requested-date. Failure modes and examples provide clear guidance on usage vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find upcoming events in any city from Luma platform
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name (e.g., milan, vienna, london) | |
| limit | No | Max events to return (default: 20) | |
| country | No | Country code for ambiguous cities (e.g., IT for Venice Italy) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the basic purpose without mentioning authentication, read-only nature, rate limits, or any side effects. This is insufficient for safe agent usage.
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, well-structured sentence that immediately conveys the tool's purpose. It is concise with no wasted words.
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 no output schema, the description should explain what is returned (e.g., event details, dates). It does not, leaving the agent without understanding the output format. However, for a simple event listing tool, it is minimally 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?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain how to use parameters effectively or provide examples. It meets the minimum threshold.
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 states the tool finds upcoming events from the Luma platform, specifying the action (find) and the resource (events from Luma). It is specific and unambiguous, earning a top score.
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 provides no guidance on when to use this tool vs alternatives, nor does it mention when not to use it. With no sibling event tools, it still lacks any usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a place name or address into coordinates (lat/lon).
USE FOR:
"Where is Izola bus station?"
Resolving a place name before calling geo-route, geo-osm, geo-isochrone or other tools
NOT FOR: reverse lookup (coordinates → address) → use geo-reverse instead.
EXAMPLE: User: "Geocode Izola bus station" → --query "Izola bus station, Slovenia"
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Address or place name to look up. Be specific — include city/country when possible. | |
| timeout | No | Hard timeout in seconds (max 60). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description is straightforward but lacks details on data source, rate limits, error handling, or whether the operation is idempotent. It does not expand beyond the basic function.
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 extremely concise and well-structured: a single sentence for purpose, followed by bullet-point usage guidelines and an example. Every sentence is useful and no unnecessary 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?
Given the simplicity of the tool (2 parameters, no output schema), the description is adequate but does not specify the exact response format or potential error messages, which would be helpful for an AI agent to interpret results.
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 both parameters well-described. The description adds marginal value by advising specificity (include city/country) and providing an example, but does not significantly enhance 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 clearly states the action: 'Convert a place name or address into coordinates (lat/lon)'. It distinguishes itself from the sibling tool 'geo-reverse' which handles reverse lookups.
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 provides 'USE FOR' and 'NOT FOR' sections, guiding the agent to use this tool for forward geocoding and directing reverse geocoding to 'geo-reverse'. It also suggests using this tool before calling other geo tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate how far you can travel in N minutes from a point. Returns reachable node count, approximate radius, and a bounding box.
USE FOR:
"How far can I walk from here in 15 minutes?"
"What's reachable by bike in 10 minutes from Koper center?"
NOT FOR: directions between two specific points → use geo-route instead.
EXAMPLE: User: "Walking isochrone from Koper center, 15 minutes" → --lat 45.548 --lon 13.730 --minutes 15 --profile walk
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Origin latitude. | |
| lon | Yes | Origin longitude. | |
| dist | No | Road network radius to load in metres (max 10 000). Increase for longer travel times. | |
| minutes | No | Travel time budget in minutes. | |
| profile | No | Travel mode: walk, bike, or drive. | walk |
| timeout | No | Hard timeout in seconds (max 60). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as side effects, authentication needs, rate limits, or failure behavior. The only behavioral hint is in the schema (max distance) but not highlighted in the description. The description fails to provide adequate transparency.
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 succinct and well-structured with clear sections ('USE FOR', 'NOT FOR', 'EXAMPLE'). Every sentence adds value, and there is no redundant or extraneous 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?
The description explains the purpose and output types but lacks details on output format, precision, or behavior with edge cases (e.g., very short/long times). Given the absence of an output schema, more specificity would be beneficial. However, it covers the essential use case adequately.
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 baseline is 3. The description adds minimal extra meaning beyond the schema—it provides an example with values but does not explain parameter constraints or defaults beyond what's already in the schema. No additional semantics are conveyed.
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 states the tool calculates travel reach within N minutes from a point, listing outputs (node count, radius, bounding box). It explicitly distinguishes from the sibling 'geo-route' by stating it is not for directions, making its purpose 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?
The description includes a 'USE FOR' section with example queries and a 'NOT FOR' section that points to an alternative tool (geo-route), providing clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find nearby places on OpenStreetMap (cafes, ATMs, shops, parks, etc.).
CRITICAL: The 'tags' argument MUST be passed as a single stringified JSON text block, NOT a nested JSON object. Example: "{"amenity":"cafe"}"
USE FOR:
"Find a cafe near X"
"Are there any ATMs close to Y?"
"Show me supermarkets near Z"
NOT FOR: directions, geocoding, Wikipedia, isochrones.
EXAMPLE: User: "Find cafes near Koper station" → --lat 45.548 --lon 13.730 --tags '{"amenity":"cafe"}' --dist 300
COMMON TAGS: amenity: cafe, restaurant, atm, pharmacy, parking shop: supermarket, bakery, convenience tourism: hotel, museum, attraction
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude of the search center. | |
| lon | Yes | Longitude of the search center. | |
| dist | No | Search radius in metres (max 10 000). | |
| tags | Yes | JSON OSM tag filter passed strictly as a stringified/escaped JSON string. DO NOT pass a JSON object. Example format: '{"amenity":"cafe"}' | |
| limit | No | Max results (1–50). | |
| timeout | No | Hard timeout in seconds (max 60). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the critical tag format requirement, search radius limits (max 10,000m), hard timeout (max 60s), and result limit (1-50). However, it does not describe the response structure or whether results include coordinates, names, etc., which would improve transparency.
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 well-structured with sections (CRITICAL, USE FOR, NOT FOR, EXAMPLE, COMMON TAGS). Every section is concise and informative, with no wasted sentences. The use of bold for critical information enhances readability.
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 the tool's complexity (6 parameters, no output schema, no annotations), the description is remarkably complete. It covers purpose, usage guidelines, parameter specifics, an example, and common tag values. The agent has sufficient information to invoke the tool 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?
Although the input schema covers all 6 parameters with descriptions, the explanation adds significant value: it details the exact format for the tricky 'tags' parameter (stringified JSON), provides an example, and lists common OSM tags by category. This goes well 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 clearly states the tool finds nearby places on OpenStreetMap (cafes, ATMs, etc.), specifying the resource (OSM) and action (find nearby places). It distinguishes itself from siblings by explicitly listing what it is not for (directions, geocoding, Wikipedia, isochrones).
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 provides explicit use cases ('Find a cafe near X'), a clear 'NOT FOR' list, and a concrete example with parameters. This guides the agent on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert coordinates (lat/lon) into a street address.
USE FOR:
"What's at 45.5, 13.6?"
Turning raw coordinates into a human-readable location
NOT FOR: place name → coordinates → use geo-geocode instead.
EXAMPLE: User: "What address is at 46.05, 14.51?" → --lat 46.05 --lon 14.51
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude to reverse-geocode. | |
| lon | Yes | Longitude to reverse-geocode. | |
| timeout | No | Hard timeout in seconds (max 60). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description lacks behavioral details like return format, error handling, or rate limits, which are needed for full transparency.
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 concise, well-structured with headings, and front-loads the key purpose and usage guidance.
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?
Lacks mention of output format or error handling; could be more complete for a tool with no output schema.
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 description adds minimal value beyond the schema, only showing an example usage for lat and lon without discussing the timeout parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts coordinates to a street address with specific verb and resource, and distinguishes from sibling tool geo-geocode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE FOR' and 'NOT FOR' sections with an example provide clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shortest walking, biking, or driving route between two coordinates. Returns distance (metres) and estimated travel time (minutes).
USE FOR:
"Walking directions from A to B"
"How long to bike from X to Y?"
Short local trips (under ~10 km)
NOT FOR: intercity trains/buses → use eu-transit-router instead.
EXAMPLE: User: "Walk from Koper bus station to Izola center" → --lat 45.548 --lon 13.730 --to-lat 45.537 --to-lon 13.660 --profile walk
If you only have place names, call geo-geocode first to get coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Origin latitude. | |
| lon | Yes | Origin longitude. | |
| dist | No | Graph radius in metres — increase if origin/destination are far apart (max 10 000). | |
| to_lat | Yes | Destination latitude. | |
| to_lon | Yes | Destination longitude. | |
| profile | No | Travel mode: walk, bike, or drive. | walk |
| timeout | No | Hard timeout in seconds (max 60). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and largely does: it discloses return units, the local-trip scope (~10km), and the coordinate precondition. It does not state failure modes (e.g. what happens when origin/destination exceed the graph radius or the 30s timeout is hit), which would matter for a routing call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then scannable USE FOR / NOT FOR / EXAMPLE sections. The example uses CLI-style flag syntax (--lat) that is slightly mismatched with an MCP JSON call, a minor bit of noise, but overall there is no wasted prose.
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?
Seven parameters with full schema coverage and no output schema, so the description only needs to explain returns and scope, both of which it does (metres, minutes, ~10km local trips). Error and edge-case behavior for the dist/timeout limits is the only remaining 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%, so the baseline is 3. The worked example goes beyond the schema by mapping real coordinate values to lat/lon/to_lat/to_lon and showing a concrete profile choice, giving the agent a usable invocation pattern rather than just field definitions.
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 first sentence states a specific verb+resource ('shortest walking, biking, or driving route between two coordinates') and immediately names the returned values (distance in metres, time in minutes). It also positions itself against the sibling eu-transit-router, so an agent can distinguish it without inspecting either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit USE FOR bullets (walking directions, bike time, sub-10km trips) and an explicit NOT FOR routing to eu-transit-router for intercity travel. It also tells the agent what to do when only place names are available: call geo-geocode first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find info about notable/historic landmarks, towns, and remarkable sites near a coordinate.
USE FOR:
"What's near Predjama Castle?"
"Notable landmarks around Ljubljana center"
"Tell me about places near 46.05, 14.51"
Finding historic, cultural, or geographic summaries for an entire area at once.
DO NOT iterate over the results to query individual items again.
One call is sufficient to answer the user's broad geographic inquiry. Combine the results into a single comprehensive summary for the user immediately.
NOT FOR: directions, finding specific cafes/shops, raw geocoding.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude of the search center. | |
| lon | Yes | Longitude of the search center. | |
| dist | No | Search radius in metres (max 10 000). | |
| limit | No | Max results (1–50). | |
| timeout | No | Hard timeout in seconds (max 60). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that one call is sufficient and results should be combined into a single comprehensive summary, and warns against iterating. No destructive behavior is implied.
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 well-structured with clear sections for purpose, use cases, and exclusions. It is slightly verbose but each sentence adds value. Front-loaded with the main purpose.
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 the tool has 5 parameters with full schema coverage, no output schema, and clear usage scenarios, the description provides sufficient context. It covers behavioral expectations (combine results, no iteration) and limitations, making it complete for a tool of this complexity.
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 descriptions for all parameters. The description does not add additional meaning beyond the schema; it only restates the coordinate parameters implicitly in examples. Baseline of 3 is appropriate as the schema does the heavy lifting.
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 states the tool finds info about notable/historic landmarks, towns, and remarkable sites near a coordinate. It uses specific verbs ('Find info') and resource ('landmarks, towns, sites'), and distinguishes from sibling tools like geo-geocode, geo-reverse, geo-route, etc.
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 provides explicit 'USE FOR' examples and a 'NOT FOR' section listing exclusions (directions, finding specific cafes/shops, raw geocoding). It also advises against iterating over results and instructs to combine into a single summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Global Waymarked Trail & Mountain Route Explorer. Queries real-time OpenStreetMap relation networks for designated hiking, biking, and mountain trails anywhere in the world.
USE FOR:
"How long does it take to hike up Črna Prst from Podbrdo?"
"Are there any marked mountain paths near this coordinate?"
"Find biking or mountain biking (MTB) trails around this area."
Discovering waymark symbols, route difficulty metrics, and trail networks.
CRITICAL INSTRUCTIONS FOR AGENT:
Use this tool instead of standard street routers (geo-route) if the destination is a mountain peak, ridge, national park trail, or alpine hut.
Set a small buffer (e.g., 0.005 for 500m, up to 0.02 for ~2km) around coordinates to avoid massive data payloads.
Accept the features returned by this tool as complete. DO NOT iteratively search or run multiple tag queries sequentially. Read the returned trail distances, calculate speed profiles, and answer immediately.
NOT FOR: Street-grid driving directions, finding urban shops/cafes, raw city geocoding.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Target center latitude coordinate of the trail scan. | |
| lon | Yes | Target center longitude coordinate of the trail scan. | |
| type | No | Limit the scanned infrastructure footprint. Choose from: 'hiking', 'biking', or 'all'. | all |
| buffer | No | Bounding search window radius in decimal degrees. (0.005 is ~500m, Max allowed is 0.05 / ~5km). | |
| endpoint | No | Select a high-availability server mirror track number (1: kumi-systems, 2: de-main, 3: openstreetmap-fr). | 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses real-time OSM query behavior, network scope (hiking/biking/mountain trails), and instructs the agent to accept returned features as complete. It hints at non-iterative usage but lacks explicit mention of response format or rate limits, which are minor gaps.
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 well-structured with sections (header, USE FOR, CRITICAL INSTRUCTIONS, NOT FOR). Every sentence adds value: examples, constraints, and behavioral guidance. No redundancy; front-loaded with key purpose.
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 the tool has 5 parameters, no output schema, and no annotations, the description is quite thorough. It explains usage context, buffer limits, and endpoint options. It could be improved by specifying the return format (e.g., features with geometry and properties), but the instruction to 'calculate speed profiles' implies output structure. Slight gap for full completeness.
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 the schema already documents parameters well. The description adds context like buffer examples (0.005 for 500m) and endpoint mirror options, but does not fundamentally expand beyond what the schema provides. Baseline score 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 clearly states it explores global waymarked trails via OpenStreetMap relation networks for hiking, biking, and mountain routes. It provides specific use cases and distinguishes from sibling tools like geo-route (street routing) and geo-osm (raw OSM).
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 provides 'USE FOR' examples, 'NOT FOR' exclusions, and critical instructions including when to use instead of geo-route, setting buffer limits, and not iterating queries. This gives clear decision context for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live hostel and budget accommodation prices from Hostelworld for any city worldwide. USE FOR:
"What are the cheapest hostels in Paris next week?"
"Find dorm beds in Bangkok for 3 nights from July 10"
"Compare hostel prices in Ljubljana vs Belgrade"
Budget travel planning, accommodation cost context, backpacker routing RETURNS: Per-property dorm and private room prices per night, guest ratings, free cancellation flag, and summary stats (floor/avg/top price). CRITICAL INSTRUCTIONS FOR AGENT:
Always pass date as YYYY-MM-DD format.
currency defaults to EUR.
Use summary.floor for "cheapest" queries, summary.average for general cost context.
free_cancellation=true properties are preferable for uncertain itineraries.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name, e.g. Ljubljana, Paris, Bangkok, New York | |
| date | Yes | Check-in date in YYYY-MM-DD format | |
| guests | No | Number of guests, e.g. 2 | 2 |
| nights | No | Number of nights to stay, e.g. 3 | 5 |
| currency | No | Currency code: EUR, USD, GBP, etc. | EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully addresses behavior: it returns per-property prices, guest ratings, free cancellation flag, and summary stats. The critical instructions add transparency on formatting and best practices. No contradictions.
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 well-structured with clear sections (USE FOR, RETURNS, CRITICAL INSTRUCTIONS). It is front-loaded with the main purpose and each sentence adds value. No redundant or missing 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?
Given 5 parameters (2 required), no output schema, and no annotations, the description is complete. It explains the return structure (dorm/private prices, ratings, cancellation flag, stats) and parameter usage. An agent can confidently invoke the tool with this information.
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%, but the description adds significant value beyond the schema by explaining how to interpret derived fields (summary.floor for cheapest, summary.average for general context) and emphasizing date format and default currency. This directly helps an agent use parameters 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 clearly states the tool's purpose: 'Live hostel and budget accommodation prices from Hostelworld for any city worldwide.' It uses a specific verb (get/prices) and resource (hostel prices), and distinguishes from sibling tools which are unrelated (geo, events, etc.). No ambiguity.
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 provides explicit USE FOR examples and critical instructions (date format, currency default, meaning of summary fields, free_cancellation preference). This gives clear guidance on when and how to use the tool, with no missing exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep parcel and building analysis for Slovenia using GURS WFS data. Returns zoning, actual use, heritage protection, road access, buildings on parcel, and utilities.
USE FOR:
"Analyze parcel 3086 in Ljubljana center"
"Find buildable parcels ~500m² in Ljubljana"
"What buildings are on this parcel?"
"Find parcels near these coordinates"
"Get full details on building 1234"
NOT FOR: simple parcel lookup → use slovenia-cadastre instead (faster, lighter). NOT FOR: spatial/zoning map queries → use slovenia-wfs-expert instead.
SEARCH MODES — pick ONE per call:
PARCEL BY NUMBER (requires --parcel AND --ko) → --parcel 3086 --ko 1725
LOCATION SEARCH (requires --lat AND --lon, or --location) → --lat 46.058 --lon 14.501 --radius 100 → --location "Tivoli Park Ljubljana" --radius 200
BUILDING BY NUMBER (requires --building, optionally --ko) → --building 1234 --ko 1728
COMMUNITY SEARCH (requires at least --community or --size) → --community LJUBLJANA --size 500 --buildable
COMMON KO IDs: 1725 = Ljubljana center 1728 = Ljubljana Šiška 1740 = Ljubljana Bežigrad 2131 = Maribor
NOTE: This tool makes multiple WFS calls per result and can be slow (10-30s). Use --limit to keep response times reasonable.
| Name | Required | Description | Default |
|---|---|---|---|
| ko | No | KO ID (cadastral municipality). Required with --parcel or --building. | |
| lat | No | Latitude for location search. Requires --lon. | |
| lon | No | Longitude for location search. Requires --lat. | |
| size | No | Approximate parcel size in m² to search for. | |
| limit | No | Max results to return (default: 10). Keep low to avoid timeouts. | |
| parcel | No | Parcel number. Requires --ko. | |
| radius | No | Search radius in metres for location search (default: 100). | |
| workers | No | Parallel WFS workers (default: 5). Reduce if hitting rate limits. | |
| building | No | Building number. Optionally combine with --ko. | |
| location | No | Place name to geocode instead of --lat/--lon. Example: 'Tivoli Park Ljubljana'. | |
| buildable | No | If true, return only buildable parcels. | |
| community | No | Community name in uppercase, e.g. LJUBLJANA or MARIBOR. | |
| tolerance | No | Size tolerance fraction for --size search (default: 0.1 = ±10%). | |
| built_year | No | Filter buildings by construction year. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it notes the tool makes multiple WFS calls per result, can be slow (10-30s), and recommends using --limit to avoid timeouts. It also implies the tool is read-only by listing analyses and not mentioning mutations.
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 long but well-structured with sections, bullet points, and clear delineation of search modes. It is front-loaded with purpose and output, though slightly verbose; however, every part adds value.
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?
Despite no output schema, the description lists the types of information returned (zoning, buildings, etc.). It covers all 14 parameters, search modes, examples, and performance notes, making it comprehensive for an agent.
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%, but the description adds significant meaning by grouping parameters into search modes, providing usage examples, and listing common KO IDs. This goes beyond the schema's individual descriptions.
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 states 'Deep parcel and building analysis for Slovenia using GURS WFS data' and lists specific outputs like zoning, actual use, and heritage protection. It differentiates from siblings by noting that slovenia-cadastral-simple is faster and lighter, and slovenia-wfs-expert is for spatial/zoning map queries.
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 provides 'USE FOR' examples and 'NOT FOR' exclusions with alternative tool names. It also defines four search modes with required parameters, making it clear when to use each mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query Slovenian cadastral data - resolve parcels, addresses, buildings, and find properties by location.
COMMANDS & EXAMPLES:
PARCEL - Find all addresses on a specific parcel Example: --command parcel --parcel-num 3086 --ko-id 1725 Returns: Parcel details with all addresses located on it
ADDRESS - Find which parcel contains a street address Example: --command address --street "Trg republike" --house-number 1 --city Ljubljana Returns: Parcel information for that address
BUILDING - Get building details and its parcel Example: --command building --building-num 1234 --ko-id 1728 Returns: Building info and associated parcel
NEAR-COORDS - Find parcels near GPS coordinates Example: --command near-coords --lat 46.058 --lon 14.501 --radius 100 --limit 20 Returns: List of parcels within radius, sorted by distance
NEAR-LOCATION - Find parcels near a named place (built-in geocoder) Example: --command near-location --location-name "Tivoli Park Ljubljana" --radius 200 --limit 10 Returns: Geocoded location + parcels within radius
All outputs are JSON format. Use --help for more details.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude in WGS84 (Slovenia: 45.4-46.9). Example: 46.058 | |
| lon | No | Longitude in WGS84 (Slovenia: 13.3-16.6). Example: 14.501 | |
| city | No | City or settlement name. Example: Ljubljana | |
| ko_id | No | Cadastral municipality ID. Example: 1725 (Ljubljana) | |
| limit | No | Maximum number of results. Example: 10 | |
| radius | No | Search radius in meters. Example: 200 | |
| street | No | Street name. Example: Trg republike | |
| command | Yes | Command: parcel, address, building, near-coords, or near-location | |
| parcel_num | No | Parcel number (for parcel command). Example: 3086 | |
| building_num | No | Building number. Example: 1234 | |
| house_number | No | House number. Example: 1 | |
| location_name | No | Place name to geocode. Example: Tivoli Park Ljubljana |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the tool is read-only, any authentication requirements, rate limits, data freshness, or side effects. It only describes functionality without behavioral constraints.
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 well-structured with clear command headings and examples, but it is verbose. It could be more concise by reducing example repetitions. However, the layout aids readability and quick understanding.
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 lacks an output schema and does not detail the structure of the JSON response beyond stating 'All outputs are JSON format.' It also omits error handling or edge cases. For a tool with 12 parameters and no output schema, more completeness is needed.
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?
With 100% schema description coverage, the schema already documents all parameters. The description's examples (e.g., --parcel-num 3086 --ko-id 1725) add marginal context by showing usage, but do not significantly enhance parameter semantics 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 clearly states the tool's purpose: 'Query Slovenian cadastral data - resolve parcels, addresses, buildings, and find properties by location.' It then lists five specific commands with examples, making the purpose unambiguous and differentiating it from siblings like slovenia-cadastral-deep.
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 provides explicit commands and examples for each use case, guiding when to use each sub-command. However, it does not differentiate this tool from its sibling slovenia-cadastral-deep, which could provide more detailed queries. The name 'simple' implies a simpler interface, but this is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for car rides on Prevoz.org in Slovenia
Agentic examples:
User: "Find rides from Ljubljana to Maribor tomorrow" → --from Ljubljana --to Maribor --when tomorrow
User: "Show me 5 rides from Koper to Bled today" → --from Koper --to Bled --when today --limit 5
User: "Preview available rides from Celje to Kranj" → --from Celje --to Kranj --dry-run
User: "Search up to 20 rides from Novo Mesto to Portorož tomorrow" → --from Novo_Mesto --to Portorož --when tomorrow --limit 20
CRITICAL: All departure and arrival times returned by this tool are in CET or CEST format (strictly local time). Always include drivers' phone numbers into output.
| Name | Required | Description | Default |
|---|---|---|---|
| when | No | Travel date (today or tomorrow) | today |
| limit | No | Max rides to return (1-50) | |
| scope | No | Search scope identifier | default |
| timeout | No | Maximum operation timeout in seconds | |
| to_city | Yes | Arrival city name | |
| from_city | Yes | Departure city name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does add real value by declaring the timezone semantics of returned times (CET/CEST, strictly local) and that driver phone numbers must be surfaced, but it says nothing about authentication, rate limits, scraping fragility, or failure behavior for a tool that pulls from an external site.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the one-line purpose, then examples, then a clearly marked CRITICAL block, so the structure is easy to scan. The example block is somewhat repetitive across four near-identical mappings, and the 'Always include drivers' phone numbers into output' instruction is an output-formatting directive rather than tool behavior.
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 annotations and no output schema, the description must carry everything. It covers timezone and output content, but leaves city-name format ambiguous (examples mix 'Novo_Mesto' underscores with accented 'Portorož'), and never explains 'scope' or 'timeout' beyond the schema's one-liners, or what an empty/failed search looks like.
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 the schema already documents all six parameters and the baseline is 3. The examples add useful defaults (limit, when) but are written as CLI flags (--from, --to, --when) that do not match the schema's snake_case names, and the '--dry-run' example references a parameter that does not exist in the schema, which risks the agent attempting an unsupported call.
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 (Search), resource (car rides), source (Prevoz.org) and geography (Slovenia) in one line. No sibling tool overlaps with ride-sharing search, so differentiation is implicit rather than stated, which keeps it just below 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?
The four agentic examples give clear context for when this tool applies and how natural-language requests map onto it. There is no statement of when NOT to use it or what alternative to pick for other Slovenian travel data, 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.
Market price statistics for a Slovenian cadastral municipality (KO), using ETN transaction data.
USE FOR:
"What are prices like in Ljubljana center (KO 1723)?"
"Market stats for KO 2242"
"What's the price per m² in KO 0168?"
NOT FOR: building- or parcel-specific valuation → not currently exposed by this tool. NOT FOR: parcel details, zoning, heritage → use cadastral-explorer or slovenia-cadastre. NOT FOR: live listings or asking prices → this uses historic transaction records only.
INPUT: --ko Required. KO ID (cadastral municipality), e.g. 1723.
OUTPUT: JSON with building and land price stats for the KO (median price, price/m², transaction count, year range) and a data_quality flag: high / medium / low / insufficient, based on transaction count.
| Name | Required | Description | Default |
|---|---|---|---|
| ko | Yes | KO ID (cadastral municipality), e.g. 1723. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses that the tool uses historic transaction records only (not live listings) and that the output includes a data_quality flag. While it does not cover rate limits or error handling, it provides enough behavioral context for an agent.
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 well-structured with clear sections (USE FOR, NOT FOR, INPUT, OUTPUT) and front-loaded with purpose and examples. Each sentence adds value, though it is slightly lengthy.
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 the simplicity (one parameter, no output schema), the description adequately explains the output fields and data source (ETN transaction data). It is complete enough for an agent to understand what the tool returns and when 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 the schema already documents the 'ko' parameter. The description does not add significant meaning beyond the schema (only repeats the KO ID example). 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 clearly states the tool provides market price statistics for Slovenian cadastral municipalities using ETN transaction data. It gives specific example queries and distinguishes from siblings by explicitly stating what it is NOT for (parcel details, zoning, listings).
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?
Includes explicit 'USE FOR' and 'NOT FOR' sections, with clear use cases and alternative tools mentioned (cadastral-explorer, slovenia-cadastre). This provides excellent guidance on when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current weather observation from the nearest ARSO surface station to given coordinates. Returns temperature, humidity, wind, precipitation, and snow depth. Data is live from meteo.arso.gov.si.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in decimal degrees (WGS84), e.g. 46.0511 | |
| lon | Yes | Longitude in decimal degrees (WGS84), e.g. 14.5051 | |
| full | No | Return full observation record including soil profile temperatures, hydrology, webcam URL, and quality flags. | |
| count | No | Number of nearest stations to return (default: 1). Returns {results:[...]} array when count > 1. | |
| radius | No | Restrict results to stations within this radius in km. Returns error if none found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions live data source and some return fields, but does not discuss rate limits, caching, geographic restrictions (Slovenia only), error conditions, or required permissions. Under-specified for a live data 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?
Two concise sentences that front-load the core functionality and data source. However, could be slightly more structured (e.g., separated output fields from data source) without adding 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?
Given no output schema, the description partially covers return fields but omits error handling, pagination behavior, or station selection details. Adequate for a simple weather tool, but not exhaustive.
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 each parameter has a description. The tool's description does not add explanatory value beyond what the schema already provides, maintaining baseline score.
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?
Clearly states the tool provides current weather observation from the nearest ARSO station to given coordinates, listing returned fields (temperature, humidity, etc.). The name 'slovenia-weather' and description imply geographic scope, which helps distinguish it from siblings like 'hikes-trails' or generic geo tools, but lacks an explicit verb-action statement.
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 on when to use this tool versus alternatives (e.g., other Slovenia tools or generic weather sources). Does not specify prerequisites, coordinate bounds, or situations where it might fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-endpoint Slovenian WFS Explorer. Dynamically browses and runs spatial bounding box queries against national geographic catalogs. Handles cadastral translation and matches zoning codes.
COORDINATE SYSTEMS: Automatically accepts WGS84 coordinates OR resolves parcel numbers via GURS Cadastre (EPSG:3794).
ENDPOINTS:
'1': Slovenian Cadastral Portal (GURS KN)
'2': Slovenian Municipal Spatial Planning & Zoning (MNVP PA)
'3': Slovenian Cadastre of Economic Infrastructure (GURS KGI)
| Name | Required | Description | Default |
|---|---|---|---|
| ko | No | 4-digit Cadastral Municipality identifier code used to resolve parcel boundaries. | |
| lat | No | Latitude coordinate value (WGS84) to define the search center. | |
| lon | No | Longitude coordinate value (WGS84) to define the search center. | |
| list | No | List all default registered Slovenian geographic service endpoints. | |
| layer | No | Comma-separated string of numbers or exact target layer identifiers to query (e.g., '3,5'). Use 'all' if total count is low. | |
| buffer | No | Search bounding box half-size distance offset specified in decimal degree parameters. | |
| parcel | No | Official parcel identifier code string within the specified municipality. | |
| building | No | Unique building designator index code number mapped within the local municipality. | |
| discover | No | Query the remote endpoint capabilities and list all available geospatial layers. | |
| endpoint | No | Target reference code ('1', '2', '3') or a raw public WFS gateway service URL string. | 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It discloses coordinate system handling (WGS84 and EPSG:3794) and endpoint mapping, which is helpful. However, it omits behavioral details such as error handling, performance characteristics, pagination, or authentication requirements. The provided info is moderate but not comprehensive.
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 highly concise—three short paragraphs with clear headings. It front-loads the purpose and then organizes coordinate systems and endpoints. Every sentence adds value without repetition or fluff.
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 complex tool with 10 parameters, no output schema, and multiple endpoints, the description covers endpoints and coordinate systems well. However, it lacks example queries or expected output format, which would improve completeness for an agent. Still, it is fairly comprehensive given reliance on schema for parameter 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds context about coordinate systems and endpoints, but does not significantly enhance understanding of individual parameters beyond the schema. For instance, 'ko' is already described as a 4-digit code. The baseline is 3, and the description adds marginal value.
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 states the tool is a multi-endpoint WFS explorer for Slovenia that handles cadastral translation and zoning codes. It uses specific verbs ('browses and runs') and identifies the resource ('spatial bounding box queries against national geographic catalogs'). This distinguishes it from sibling tools like slovenia-cadastral-simple by emphasizing multi-endpoint capability and zoning code matching.
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 guidelines are provided. The description does not specify when to use this tool over its siblings (e.g., cadastral-specific tools). There is no discussion of prerequisites, exclusions, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
geo-route1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "to_lat",
- "lon",
- "to_lon"
-]New value: +[
+ "to_lat",
+ "to_lon",
+ "lat",
+ "lon"
+]geo-wiki1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon"
-]New value: +[
+ "lon",
+ "lat"
+]hostel-prices1 field changedInput schema / requiredPrevious value: -[
- "date",
- "city"
-]New value: +[
+ "city",
+ "date"
+]slovenia-car-ride1 field changedInput schema / requiredPrevious value: -[
- "from_city",
- "to_city"
-]New value: +[
+ "to_city",
+ "from_city"
+]geo-isochrone1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon"
-]New value: +[
+ "lon",
+ "lat"
+]geo-osm1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "lat",
- "tags"
-]New value: +[
+ "lat",
+ "lon",
+ "tags"
+]geo-reverse1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "lat"
-]New value: +[
+ "lat",
+ "lon"
+]geo-route1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "to_lon",
- "to_lat",
- "lon"
-]New value: +[
+ "lat",
+ "to_lat",
+ "lon",
+ "to_lon"
+]geo-wiki1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "lat"
-]New value: +[
+ "lat",
+ "lon"
+]hostel-prices1 field changedInput schema / requiredPrevious value: -[
- "city",
- "date"
-]New value: +[
+ "date",
+ "city"
+]geo-isochrone1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "lat"
-]New value: +[
+ "lat",
+ "lon"
+]geo-osm1 field changedInput schema / requiredPrevious value: -[
- "tags",
- "lon",
- "lat"
-]New value: +[
+ "lon",
+ "lat",
+ "tags"
+]geo-route1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "to_lat",
- "to_lon",
- "lat"
-]New value: +[
+ "lat",
+ "to_lon",
+ "to_lat",
+ "lon"
+]geo-wiki1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon"
-]New value: +[
+ "lon",
+ "lat"
+]hikes-trails1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "lat"
-]New value: +[
+ "lat",
+ "lon"
+]hostel-prices1 field changedInput schema / requiredPrevious value: -[
- "date",
- "city"
-]New value: +[
+ "city",
+ "date"
+]slovenia-weathereu-transit-router1 field changedInput schema / requiredPrevious value: -[
- "to_place",
- "from_place"
-]New value: +[
+ "from_place",
+ "to_place"
+]geo-isochrone1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon"
-]New value: +[
+ "lon",
+ "lat"
+]geo-osm1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "tags",
- "lon"
-]New value: +[
+ "tags",
+ "lon",
+ "lat"
+]geo-reverse1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon"
-]New value: +[
+ "lon",
+ "lat"
+]geo-route1 field changedInput schema / requiredPrevious value: -[
- "to_lon",
- "lon",
- "lat",
- "to_lat"
-]New value: +[
+ "lon",
+ "to_lat",
+ "to_lon",
+ "lat"
+]geo-wiki1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "lat"
-]New value: +[
+ "lat",
+ "lon"
+]hostel-prices1 field changedInput schema / requiredPrevious value: -[
- "city",
- "date"
-]New value: +[
+ "date",
+ "city"
+]slovenia-realty-price8 fields changedInput schema / properties / areaRemoved value: -{
- "description": "Area in m². Optional for building/parcel — uses median from transaction data if omitted.",
- "type": "number"
-}Input schema / properties / buildingRemoved value: -{
- "description": "Building number. Required for --command building.",
- "type": "string"
-}Input schema / properties / commandRemoved value: -{
- "description": "One of: building, parcel, ko, compare.",
- "type": "string"
-}Input schema / properties / ko / descriptionPrevious value: -"KO ID (cadastral municipality). Required for building, parcel, ko, and compare (first KO)."New value: +"KO ID (cadastral municipality), e.g. 1723."Input schema / properties / ko2Removed value: -{
- "description": "Second KO ID. Required for --command compare.",
- "type": "string"
-}Input schema / properties / no_verifiedRemoved value: -{
- "description": "If true, include unverified transactions. Default: verified only.",
- "type": "boolean"
-}Input schema / properties / parcelRemoved value: -{
- "description": "Parcel number. Required for --command parcel.",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "command"
-]New value: +[
+ "ko"
+]geo-isochrone1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "lat"
-]New value: +[
+ "lat",
+ "lon"
+]geo-osm1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "lat",
- "tags"
-]New value: +[
+ "lat",
+ "tags",
+ "lon"
+]geo-reverse1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "lat"
-]New value: +[
+ "lat",
+ "lon"
+]geo-route1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "to_lat",
- "lon",
- "to_lon"
-]New value: +[
+ "to_lon",
+ "lon",
+ "lat",
+ "to_lat"
+]hostel-prices1 field changedInput schema / requiredPrevious value: -[
- "date",
- "city"
-]New value: +[
+ "city",
+ "date"
+]events-lumageo-isochrone1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon"
-]New value: +[
+ "lon",
+ "lat"
+]geo-reverse1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon"
-]New value: +[
+ "lon",
+ "lat"
+]geo-route1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "to_lat",
- "lat",
- "to_lon"
-]New value: +[
+ "lat",
+ "to_lat",
+ "lon",
+ "to_lon"
+]hikes-trails1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon"
-]New value: +[
+ "lon",
+ "lat"
+]slovenia-car-ride1 field changedInput schema / requiredPrevious value: -[
- "to_city",
- "from_city"
-]New value: +[
+ "from_city",
+ "to_city"
+]eu-transit-router1 field changedInput schema / requiredPrevious value: -[
- "from_place",
- "to_place"
-]New value: +[
+ "to_place",
+ "from_place"
+]geo-osm1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "tags",
- "lat"
-]New value: +[
+ "lon",
+ "lat",
+ "tags"
+]geo-reverse1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "lat"
-]New value: +[
+ "lat",
+ "lon"
+]geo-route1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon",
- "to_lon",
- "to_lat"
-]New value: +[
+ "lon",
+ "to_lat",
+ "lat",
+ "to_lon"
+]geo-wiki1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon"
-]New value: +[
+ "lon",
+ "lat"
+]hostel-pricesslovenia-car-ride1 field changedInput schema / requiredPrevious value: -[
- "from_city",
- "to_city"
-]New value: +[
+ "to_city",
+ "from_city"
+]eu-transit-router1 field changedInput schema / requiredPrevious value: -[
- "to_place",
- "from_place"
-]New value: +[
+ "from_place",
+ "to_place"
+]geo-isochrone1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "lat"
-]New value: +[
+ "lat",
+ "lon"
+]geo-osm1 field changedInput schema / properties / tags / descriptionPrevious value: -"JSON OSM tag filter. Example: '{\"amenity\":\"cafe\"}'"New value: +"JSON OSM tag filter passed strictly as a stringified/escaped JSON string. DO NOT pass a JSON object. Example format: '{\"amenity\":\"cafe\"}'"geo-route1 field changedInput schema / requiredPrevious value: -[
- "to_lat",
- "lon",
- "to_lon",
- "lat"
-]New value: +[
+ "lat",
+ "lon",
+ "to_lon",
+ "to_lat"
+]geo-wiki1 field changedInput schema / requiredPrevious value: -[
- "lon",
- "lat"
-]New value: +[
+ "lat",
+ "lon"
+]hikes-trailsslovenia_car_rideslovenia-car-rideeu-transit-router1 field changedInput schema / requiredPrevious value: -[
- "from_place",
- "to_place"
-]New value: +[
+ "to_place",
+ "from_place"
+]geo-osm1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon",
- "tags"
-]New value: +[
+ "lon",
+ "tags",
+ "lat"
+]geo-route1 field changedInput schema / requiredPrevious value: -[
- "to_lat",
- "lat",
- "lon",
- "to_lon"
-]New value: +[
+ "to_lat",
+ "lon",
+ "to_lon",
+ "lat"
+]slovenia_car_ride1 field changedInput schema / requiredPrevious value: -[
- "from_city",
- "to_city"
-]New value: +[
+ "to_city",
+ "from_city"
+]geo-isochrone1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon"
-]New value: +[
+ "lon",
+ "lat"
+]geo-osm1 field changedInput schema / requiredPrevious value: -[
- "tags",
- "lon",
- "lat"
-]New value: +[
+ "lat",
+ "lon",
+ "tags"
+]geo-route1 field changedInput schema / requiredPrevious value: -[
- "lat",
- "lon",
- "to_lon",
- "to_lat"
-]New value: +[
+ "to_lat",
+ "lat",
+ "lon",
+ "to_lon"
+]slovenia_car_ride1 field changedInput schema / requiredPrevious value: -[
- "to_city",
- "from_city"
-]New value: +[
+ "from_city",
+ "to_city"
+]eu-transit-router9 fields changedInput schema / properties / end_latRemoved value: -{
- "description": "Destination latitude, WGS84 decimal. Example: 46.5622",
- "type": "number"
-}Input schema / properties / end_lonRemoved value: -{
- "description": "Destination longitude, WGS84 decimal. Example: 15.6554",
- "type": "number"
-}Input schema / properties / from_placeAdded value: +{
+ "description": "Origin place name. Example: 'Podbrdo, Slovenia' or 'Ljubljana'",
+ "type": "string"
+}Input schema / properties / modes / descriptionPrevious value: -"Space-separated transport modes. Allowed: TRANSIT WALK BUS RAIL TRAM SUBWAY FERRY BICYCLE CAR. Always include WALK with TRANSIT. Example: 'TRANSIT WALK'"New value: +"Space-separated transport modes. Allowed: TRANSIT WALK BUS RAIL TRAM SUBWAY FERRY BICYCLE CAR. Always include WALK with TRANSIT."Input schema / properties / requested_dateAdded value: +{
+ "description": "User's requested date in YYYY-MM-DD format (optional). Used only to generate a note about real-time vs. future schedules.",
+ "type": "string"
+}Input schema / properties / start_latRemoved value: -{
- "description": "Origin latitude, WGS84 decimal. Example: 46.0569",
- "type": "number"
-}Input schema / properties / start_lonRemoved value: -{
- "description": "Origin longitude, WGS84 decimal. Example: 14.5058",
- "type": "number"
-}Input schema / properties / to_placeAdded value: +{
+ "description": "Destination place name. Example: 'Nova Gorica, Slovenia'",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "start_lon",
- "end_lon",
- "end_lat",
- "start_lat"
-]New value: +[
+ "from_place",
+ "to_place"
+]geo-geocodegeo-isochronegeo-osmgeo-reversegeo-routegeo-wikiglobal_geoagentic_clislovenia_car_ride2 fields changedInput schema / properties / dry_runRemoved value: -{
- "default": false,
- "description": "Preview search without API calls",
- "type": "boolean"
-}Input schema / requiredPrevious value: -[
- "from_city",
- "to_city"
-]New value: +[
+ "to_city",
+ "from_city"
+]slovenia-cadastral-deepslovenia-cadastral-simpleslovenia-cadastreslovenia-realty-priceeu-transit-routerglobal_geoagentic_clislovenia_car_rideslovenia-cadastre2 fields changedInput schema / properties / limit / defaultPrevious value: -"20"New value: +20Input schema / properties / radius / defaultPrevious value: -"100"New value: +100slovenia-wfs-experttest_skillslovenia-cadastretest_skill
Add one secure layer between your agents and this server.