Find farm stays in Italy and check availability, prices and booking conditions on Agriturismo.net.
Scored across 5 tools
Each tool maps to a distinct step in the discovery flow (resolve location, search, inspect, verify), and descriptions clarify the pre-requisites. However, the three property-oriented tools (get_property, resolve_property, verify_property_availability) all return property data and could be confused at a glance, even if the descriptions ultimately separate identity lookup from static card from date-specific availability.
All five tools follow a clean snake_case verb_noun pattern (get_property, resolve_location, resolve_property, search_availability, verify_property_availability). Verbs vary meaningfully by action but the convention is uniform and predictable.
Five tools is well-scoped for a read-only availability/booking-discovery server, and each maps to a clear pipeline stage. No tool appears redundant or missing from the flow.
The surface covers the full read path: resolve a location or property name, search availability in a zone, fetch the public card, and verify exact dates/prices/booking URL. Minor gaps exist (e.g. no free-text/amenity filtering or listing without dates), but agents can work around them via the existing search step.
Restituisce la scheda pubblica di una struttura pubblicata. Passa la lingua della conversazione; nome e URL seguono la visibilità della scheda pubblica in quella lingua.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ita | |
| propertyId | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful, non-obvious context — the returned name and URL follow the visibility of the public profile in the requested language — but the phrasing is ambiguous and it never says what happens when no visible version exists or the ID is invalid.
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 tight sentences with no filler; the core action is front-loaded and the language rule follows. Slight economy lost because the second sentence is vague enough to require a second read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation. However, for a two-parameter lookup amid four siblings, the definition omits error/failure behavior for unpublished or unknown properties and omits any positioning relative to `resolve_property`, leaving an agent with real ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema alone documents nothing beyond types, a default of 'ita' and a pattern. The description partially compensates by telling the agent to pass the conversation language (the only real semantic guidance available), but `propertyId` receives no explanation at all beyond its name.
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 and resource: returns the public profile ('scheda pubblica') of a published property, with the qualifier that it must be published. That is clear enough to know what the tool does, but it never distinguishes itself from the sibling `resolve_property`, which an agent could easily confuse with it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage-like instruction is 'Passa la lingua della conversazione', which tells the agent how to fill one parameter, plus an implicit restriction to published properties. There is no statement of when to prefer this over `resolve_property`, or what to do when the property is not published.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trova località pubbliche utilizzabili come zona di ricerca. Usalo prima di cercare se il nome della località è ambiguo.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| maxResults | No |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds that only public locations are returned and that they are meant to be used as a search zone, but it says nothing about resolution confidence, ambiguity handling, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose and followed by the usage trigger. Nothing is wasted, though the second sentence could be slightly more informative.
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 output schema covers return values, so the description need not explain them. However, with 0% schema coverage on both parameters, the description should clarify the input semantics and the role of maxResults, and it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the two parameters, and the description does not explain that 'text' is the ambiguous location name or what 'maxResults' controls. It implicitly ties the input to a location name but leaves the result cap entirely undocumented.
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 and resource: finding public locations usable as a search area. The term 'località' distinguishes it from the sibling resolve_property, which handles properties, though the description never names that alternative explicitly.
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?
Gives a clear trigger: use it before searching when the location name is ambiguous. It does not state when not to use it, nor does it name sibling alternatives such as resolve_property for the property case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trova una struttura pubblicata a partire dal nome scritto dall'utente. Non scegliere a caso fra strutture omonime.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| language | No | ita |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond them: the search is limited to published properties and homonymous records can occur, so the agent should not silently pick one. It says nothing about how multiple matches are returned or ranked, which keeps it below 5.
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 tight sentences, zero padding, with the core action front-loaded and the disambiguation caveat immediately after. Nothing is redundant with the name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail is not required, and annotations cover the safety profile. However, an agent still cannot tell what happens on ambiguity (multiple results vs. error), how matching is performed, or what 'language' affects — gaps that matter for correct invocation of a resolver.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for two parameters. The description only clarifies that 'name' is free text written by the user, hinting at fuzzy matching; it never explains the 'language' parameter (default 'ita'), the 4-160 character bounds, or case/diacritic handling. With zero schema coverage the description should compensate more than it does.
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 and resource: find a *published* property from a name typed by the user. The 'published' qualifier and the name-based lookup distinguish it implicitly from get_property (ID-based) and resolve_location (geography), though no sibling is named explicitly.
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 warning 'Non scegliere a caso fra strutture omonime' conveys that ambiguity is expected and must be surfaced to the user, which implies when to use it (name-to-entity resolution). But there is no explicit statement of when to prefer resolve_property over get_property or resolve_location, and no mention of calling it before availability checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cerca strutture pubblicate disponibili per una zona, date e ospiti. Il raggio massimo è 100 km. Non presentare risultati come confermati se il backend li segnala non prenotabili.
| Name | Required | Description | Default |
|---|---|---|---|
| zone | Yes | ||
| adults | No | ||
| checkIn | Yes | ||
| rangeKm | No | ||
| checkOut | Yes | ||
| language | No | ita | |
| childrenAges | No |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, closed-world. The description adds real value beyond that: a hard 100 km radius cap and the rule against treating backend-flagged-unbookable results as confirmed. That last constraint is a meaningful behavioral disclosure not present in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, purpose first, then the range limit, then the safety caveat. No filler, though the caveat could be phrased as a usage rule more directly.
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?
Output schema and annotations relieve some burden, but for a 7-parameter search tool with 0% schema description coverage, the description should cover the remaining parameters and clarify the boundary with verify_property_availability. It's adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 7 parameters. The description explains zone, dates, guests, and the 100 km maximum for rangeKm, but leaves adults defaults, childrenAges, and language entirely undocumented. It partially compensates but not fully.
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 concrete verb and resource (search published available properties) plus the three qualifying dimensions: zone, dates, guests. It's clearly distinguishable from verify_property_availability, but it doesn't explicitly name that distinction in the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: search with zone/dates/guests. The caution about not presenting unbookable results as confirmed is a useful constraint but not a when-to-use vs alternative rule. There is no guidance on preferring get_property/verify_property_availability for follow-up checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifica per date esatte gli alloggi disponibili, prezzi, condizioni e URL di prenotazione di una struttura pubblicata.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | ||
| checkIn | Yes | ||
| checkOut | Yes | ||
| language | No | ita | |
| propertyId | Yes | ||
| childrenAges | No |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that results include availability, prices, conditions, and booking URL, but it does not discuss auth needs, rate limits, or error behavior. No annotation contradiction is present.
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 definition is a single front-loaded sentence with no filler. It is appropriately sized for the amount of information it chooses to convey.
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 output schema exists, so return values do not need explanation, and the annotations cover safety. Still, with 6 parameters and 0% schema description coverage, the description is incomplete for correct invocation because optional parameters and their effects on availability/pricing are undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for six parameters. It only hints at exact dates, which maps loosely to checkIn/checkOut, and never explains propertyId, adults, childrenAges, or language. Optional parameters such as childrenAges are especially left without semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Verifica') and resource ('alloggi disponibili, prezzi, condizioni e URL di prenotazione') scoped to exact dates and a published property. It is clear what the tool does, though it does not explicitly distinguish itself from the sibling 'search_availability'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'per date esatte' and 'struttura pubblicata' implies when to use the tool: exact-date availability checks on a known published property. However, it gives no explicit when-not guidance and does not name or compare against the sibling 'search_availability'.
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.
get_propertyresolve_locationresolve_propertysearch_availabilityverify_property_availability
Add one secure layer between your agents and this server.