Agentic GIS server to work with Slovenia's cadastre records
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 16 of 16 tools scored. Lowest: 2.9/5.
Most tools have clearly distinct purposes (geocoding vs routing vs POI search). However, the multiple Slovenian cadastral tools (simple, deep, wfs-expert) overlap in functionality, potentially confusing an agent on which to use for a given task.
Tools within subgroups like 'geo-*' follow a consistent verb_noun pattern, and 'slovenia-*' tools use a noun_adjective pattern. However, across the whole set there is no unified naming convention, mixing prefixes like 'eu-', 'events-', 'hikes-', and 'hostel-'.
With 16 tools, the server is slightly above the ideal range (3-15) but still well-scoped. Each tool addresses a distinct geographic need, although the breadth across many domains (transit, cadastre, weather, hostels) feels a bit broad.
The tool set covers core geographic operations (geocoding, routing, POI, isochrones, reverse geocoding) plus specialized Slovenian data and travel amenities. Minor gaps exist, such as lack of general worldwide POI beyond OSM or event discovery beyond Luma, but overall it is comprehensive for its domain.
eu-transit-routerAInspectEU-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.
events-lumaBInspectFind 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.
geo-geocodeAInspectConvert 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.
geo-isochroneAInspectCalculate 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.
geo-osmAInspectFind 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.
geo-reverseAInspectConvert 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.
geo-routeAInspectShortest 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?
No annotations provided, so description bears full burden. It discloses that the tool returns distance in metres and travel time in minutes, and mentions graph radius and timeout. Does not cover failure scenarios or rate limits, but sufficient for a read-only route 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?
Description is well-structured with sections (USE FOR, NOT FOR, EXAMPLE), no unnecessary words, and front-loaded with the core purpose. Every sentence 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?
Given 7 parameters, no output schema, and no annotations, the description explains return values, gives usage examples, and mentions a prerequisite. It could elaborate on the timeout parameter behavior but is otherwise complete for typical use.
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 context like the dist parameter being graph radius and max distance 10 km, but these are already in the schema. The example is helpful but does not significantly augment 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 it computes the shortest walking, biking, or driving route between two coordinates, naming the action and resource. It distinguishes from siblings by explicitly excluding intercity travel and directing to eu-transit-router.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit USE FOR examples and a NOT FOR section with alternative tool (eu-transit-router). Also advises to call geo-geocode when only place names are available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geo-wikiAInspectFind 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 the full burden. It discloses the kind of information returned (summaries of landmarks), instructs against redundant calls ('DO NOT iterate...'), and specifies constraints (max radius 10,000m, max 50 results). It could be more explicit about potential side effects or authentication needs, but for a read-only search tool, the description is sufficiently transparent.
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 (general purpose, USE FOR, NOT FOR, additional instructions). It is appropriately sized, with every sentence serving a purpose. However, the 'DO NOT iterate' instruction could be integrated into the guidelines section, slightly reducing redundancy. Overall, it is efficient and easy to parse.
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 and no output schema, the description provides adequate context: it explains the output type (summaries of landmarks), usage patterns, and constraints. It could specify the exact output format (e.g., text, structured fields) but the examples and instructions for composing a summary sufficiently guide the agent. The description covers all necessary behavioral aspects for a smooth interaction.
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 meaning beyond the schema: it implies the lat/lon define a search center and the dist/limit/timeout are flexible, but these details are already in the schema. The usage examples provide context for lat/lon, but no new semantic information is added.
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 a well-defined resource ('landmarks, towns, and remarkable sites near a coordinate'). This distinguishes it from sibling tools like geo-geocode or geo-reverse, which serve different purposes.
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 under 'USE FOR' (e.g., 'What's near Predjama Castle?') and clear exclusions under 'NOT FOR' (e.g., directions, finding specific cafes/shops, raw geocoding). It also advises against iterating over results and instructs the agent to combine results into a single summary. This gives excellent guidance on when and how to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hikes-trailsAInspectGlobal 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.
hostel-pricesAInspectLive 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?
Since no annotations exist, the description discloses important behavioral traits: it requires YYYY-MM-DD date format, defaults currency to EUR, and explains how to interpret fields like summary.floor vs summary.average. It also mentions the free_cancellation flag. It does not explicitly state it is read-only, but the context implies no side effects. This is sufficient for safe 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 well-structured: starting with a clear purpose statement, followed by use cases, return description, and critical instructions. It is front-loaded and every sentence adds value. A slight reduction from 5 because it is a bit verbose with the use case list, but overall efficient.
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 provides a good overview of return values: per-property prices, guest ratings, free cancellation flag, and summary stats. It also includes critical instructions for date format, currency, and field interpretation. This fully equips an agent to use 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?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds value by clarifying date format, default currency, and usage of summary fields, which are not present in schema descriptions. This goes beyond the baseline of 3.
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 'Live hostel and budget accommodation prices from Hostelworld for any city worldwide.' This specifies the verb (get/list) and resource (hostel prices), and the scope is broad but defined. No sibling tool covers accommodation prices, so it stands out.
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 multiple example queries (cheapest hostels, dorm beds, compare cities) and explicit use cases like budget travel planning. It also gives instructions on how to interpret summary fields for specific queries. However, it does not explicitly state when not to use it or name alternatives, so it falls 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.
slovenia-cadastral-deepAInspectDeep 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.
slovenia-cadastral-simpleAInspectQuery 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.
slovenia-car-rideAInspectSearch 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 fully handles behavioral disclosure. It discloses that times are in CET/CEST local time and instructs including phone numbers in output. This adds valuable context beyond basic functionality, such as timezone handling and output requirements.
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 and well-structured: a one-line purpose, followed by clear agentic examples under 'Agentic examples:', and a critical note section. Every sentence adds value, with no redundancy. The format is easy to scan and front-loaded with key 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?
Despite no output schema, the description sufficiently explains return behavior (times in CET/CEST, include phone numbers). The tool has moderate complexity with 6 parameters and 2 required, and the description covers essential behavioral aspects. Minor gaps: no mention of error handling or empty results, but overall 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 baseline is 3. The description does not add semantic detail beyond the schema; the agentic examples demonstrate parameter usage but don't clarify meaning beyond what the schema already provides (e.g., from_city, to_city, when, limit).
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 searches for car rides on Prevoz.org in Slovenia, with a specific verb and resource. The verb 'Search' and resource 'car rides on Prevoz.org in Slovenia' distinguishes it from sibling tools like geo-route or slovenia-weather.
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 multiple agentic examples covering typical use cases (date, limit, dry-run). It implies when to use (searching rides in Slovenia) but does not explicitly state when not to use or alternatives. The context is clear and sufficient for an AI agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
slovenia-realty-priceAInspectMarket 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.
slovenia-weatherCInspectCurrent 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.
slovenia-wfs-expertAInspectMulti-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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
