Corissia Resorts Crete

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description's 'API v3, read only' merely restates the readOnlyHint and adds no new behavioral context (no return shape, no pagination, no caching). Adequate but adds little beyond structured data.

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 with the resource and the comparison axes front-loaded; no filler. The trailing 'API v3, read only' is largely redundant with the annotations, which keeps it from a 5.

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 output schema, the description usefully enumerates what the comparison covers (location, season, ages, character, opening periods), which gives the agent a reasonable expectation of the response. For a zero-required-parameter, read-only tool this is close to complete, though it could note the format of the side-by-side result.

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

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

There is a single optional 'lang' parameter with 100% schema coverage and an inline enum description including the default. The description adds nothing about language behavior, which is acceptable given the schema carries it entirely.

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

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

The description names the specific resource (the five Corissia Resorts hotels in Crete) and the exact comparison dimensions: location, season, ages, character and opening periods. An agent can tell it is a comparative, all-hotels-in-one response rather than a single-hotel lookup. It does not explicitly name sibling tools such as get_hotel_facts, so it falls short of full sibling differentiation.

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 by the phrase 'side by side' and 'the five hotels' – an agent can infer this is for whole-portfolio comparison versus per-hotel detail. There is no explicit when-to-use, when-not, or pointer to get_hotel_facts for granular lookups.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds non-obvious behavior beyond them: the response may describe a different stay than the one requested, and stay.checkin/stay.checkout reveal which stay it actually is — an important caveat an agent could not get from structured fields alone. It does not cover rate limits, caching, or response shape.

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 with no filler, and the core purpose is front-loaded. The trailing 'kept unchanged for the integrations of the first server' is slightly cryptic in wording but still earns its place as a compatibility signal.

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 three-parameter read-only tool with a fully documented schema and no output schema, this covers what an agent needs: what it returns (offers), for what inputs, and the critical caveat about possibly mismatched stays. Details like offer/price structure or pagination are left implicit but are not blocking.

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% and the hotel enum is documented in the schema, so the parameters are already well specified and the baseline is a 3. The description adds only the negative note that no guests parameter is accepted, which implies a sibling API variant takes one but adds no date or hotel semantics.

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

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

The description names a specific verb and resource ('Hotel offers for a Corissia hotel and date range') and identifies the API variant ('API version 2.0, without a guests parameter'). It stops short of distinguishing itself from the closest siblings such as get_quote or compare_hotels, so an agent still has to infer which one is the price-request tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use statement, and the alternatives (get_quote, compare_hotels, get_room_details) are never mentioned. The only implicit guidance is the 'API version 2.0, without guests' framing plus the 'kept unchanged for integrations of the first server' note, which hints this is a legacy-compatible variant but does not tell an agent whether to prefer it.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The one genuinely additive sentence is the note that a fact answering "unknown, ask the hotel" is not confirmed by the hotel — valuable interpretation guidance for the returned data. Beyond that, nothing is said about response shape or granularity, and there is no output schema to compensate.

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 and dense — the resource and its fact domains arrive in one sentence. The trailing "API v3." is vestigial metadata that earns no place in an agent-facing description.

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 read-only lookup with three enum params and no output schema, the description covers what kinds of facts exist but not how they are returned (flat key/value list? grouped by category? one record per room?), which matters given the 'room' category. The unconfirmed-fact note helps but the return shape remains unspecified.

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% and all three parameters are enum-documented, so the schema fully carries parameter meaning. The description adds no parameter-level guidance, such as the defaulting behavior of lang or the effect of omitting category. Baseline 3 applies.

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

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

Names a specific resource (one hotel and its rooms) and enumerates the fact domains covered: identity, operation, policies, location, pools, dining, services, accessibility, terms, rooms. That enumeration maps directly onto the category enum, making the tool's scope unambiguous. It does not explicitly distinguish itself from get_room_details or compare_hotels, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (fetch facts for a single hotel, optionally one category) but never states when to choose it over siblings like get_room_details, compare_hotels, or get_venue, which overlap on hotel/room data. No exclusions or prerequisites are given.

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

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

Beyond the annotations (read-only, idempotent, open-world), the description discloses the JOB_NOT_FOUND condition, the meaning of a null salary, what salary_note refers to, and that applications happen on the returned url with no personal data flowing through the connector. That is real behavioral context the annotations cannot convey, though it omits any note on output shape or caching/freshness of postings.

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?

Purpose is front-loaded and nearly every clause carries information (error semantics, null semantics, privacy). The long semicolon-chained middle sentence and the trailing "API v3." fragment make it denser and less scannable than it could be.

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 output schema, the description takes on the job of describing return content and does so at a high level (tasks, skills, benefits, apply url, salary fields) while also covering the failure mode. It is adequate for a two-parameter read tool, with only minor gaps in enumerating the returned fields.

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% and both parameters (job_id pattern, lang enum with default) are already fully documented in the schema. The description adds nothing about parameter behavior or format, so the baseline 3 applies.

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?

"One open position with its full description (tasks, skills, what we offer) and the page to apply on" names a specific resource plus the payload it returns, which is clearly distinct from a listing tool. It never names list_jobs as the multi-result counterpart, so the agent must infer the boundary from the singular "One open position".

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 required job_id plus the parenthetical error case "JOB_NOT_FOUND: the position is not open (any more)" make the retrieval context explicit and tell the agent what a failure means. There is no explicit exclusion or pointer to an alternative sibling (e.g. list_jobs to discover ids), which keeps it 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.

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

The annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds useful context beyond annotations: prices are in EUR from the website, tied to as_of, may change, and null price means no price is shown. It also explains lang_served semantics.

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 dense and front-loads the resource and price context. It is generally efficient, though the trailing 'API v3' adds little practical value for an agent selecting or invoking the tool.

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 output schema present, the description appropriately supplies key return semantics: currency, as_of, price null behavior, and lang_served meaning. It is fairly complete for a read-only menu/treatment retrieval tool, with remaining gaps mainly around explicit sibling routing.

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 input schema already documents the lang, venue, and section parameters. The description adds meaning to returned fields like price and lang_served, but does not add much input-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 resource: a venue's menu, drinks, or spa treatments with website prices. It is specific enough to identify the operation, but it does not explicitly distinguish this tool from related siblings such as get_venue.

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 by the resource description. There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as get_venue for general venue facts.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: the 'available' vs 'on_request' distinction, the 20% deposit condition for website booking, and the explicit statement that the connector neither books nor takes payments. The booking_url explanation, including that the link carries no personal data and where name/e-mail/phone are entered, is exactly the kind of side-effect context an agent needs.

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?

Purpose is front-loaded in the first sentence and every subsequent clause carries information (errors, availability semantics, booking path, data privacy). The semicolon-chained sentences around availability_status are dense and would read better as a short list, costing it a point on structure rather than on filler.

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 output schema, the description correctly takes on the burden of explaining return semantics: error codes, availability_status values, rate-level booking_url. It stops short of describing the overall rate/price response shape or currency, which leaves a small gap for a pricing tool with 7 parameters.

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%, and the schema already documents hotel enum, date patterns, room/board filters and children_ages with its own OCCUPANCY_NOT_SUPPORTED note. The description adds nothing parameter-level beyond restating that results are for the requested dates and guests, so baseline 3 applies.

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 opening sentence gives a specific resource and scope: prices and offers for an exact stay, guest-composition and single hotel. That implicitly separates it from multi-hotel siblings like compare_hotels and corissia_offers, but no sibling is named, so an agent must infer the boundary rather than read 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 description makes clear the answer is bound to the requested dates and guests and that failures come back as coded errors, which tells the agent what this tool is for. It never states when to prefer it over compare_hotels, corissia_offers or get_room_details, so tool selection is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered elsewhere. The description adds useful context about id provenance ('Room type ids are those of the rooms of the hotel') and the API version, but says nothing about behavior on an invalid room id or how localization affects the 'facts' payload.

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

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

A single compact sentence with the resource stated first and the returned fields immediately after. The trailing 'API v3' is terse and slightly orphaned, but nothing else is wasted.

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 read-only single-record lookup with three fully documented parameters and no output schema, the description gives enough to call it correctly and even sketches the returned payload. The missing piece is disambiguation from get_hotel_facts and any note on nonexistent room handling.

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% and two parameters carry enums, so the schema already defines every parameter. The description's only added value is a concrete id format example, which is a marginal gain over the documented 'Room type id, e.g. harmony-double' in 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 names a specific verb-plus-resource ('Details of one room type of a hotel') and enumerates what is returned: name, booking limits (maximum adults, children, total) and facts. It does not explicitly contrast itself with the sibling get_hotel_facts, so an agent may need a second look to confirm this is room-level, not hotel-level, data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the tool is for retrieving one room type, illustrated by the id example 'harmony-double'. There is no statement of when to call this versus get_hotel_facts or compare_hotels, and no prerequisites or error conditions are mentioned.

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

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

Annotations already cover the read-only, idempotent, open-world safety profile, and the description adds genuinely new behavior: hours/prices are as published and may change or vary by season, and a null reservation means the website offers no reservation. The null semantics in particular are valuable disclosure the annotations could not convey.

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 core scope is front-loaded, but the middle is a dense run-on packing access, reservation, and exclusion clauses together, and the trailing 'API v3.' is unexplained filler. It is information-dense rather than wasteful, yet poorly structured for scanning.

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?

There is no output schema, so the description carries the return-value burden and does a fair job: it names the top-level sections and explains the access and reservation sub-structures. It does not describe the services-with-prices or opening-hours shape in comparable detail, leaving a modest gap for a detail-retrieval tool.

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

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

Schema coverage is 100% with both parameters documented, so baseline is 3. The description spends its detail on response field semantics (access categories, min_age with age_note) rather than adding meaning to the venue or lang inputs, which the schema already covers.

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

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

The description opens with a specific scope: one venue, and enumerates the content returned (access, minimum age, opening hours, services with prices, reservation and menu sections). It is clearly distinguishable from list_venues (plural listing) and get_menu (menus only) in the sibling set.

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?

It gives useful exclusions — the connector does not reserve tables or treatments, and board contents (half board, all inclusive) are not part of the answer — but it never names an alternative tool or tells the caller to resolve the venue id via list_venues first. Usage is implied rather than routed.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, yet the description still adds real context: results are sorted newest-first, salary is null when the site publishes none and salary_note comes from the career page, and the connector never receives personal data or submits applications. API version (v3) is disclosed. It stops short of describing pagination or how many positions are returned.

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 resource and what it returns, followed by ordering, then the application-policy caveat and null-salary semantics. It is a single dense block rather than a run-on of filler; every sentence carries information, though the field enumeration in the first sentence is long.

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?

There is no output schema, so the description's enumeration of return fields and the newest-first ordering plus salary/salary_note null semantics are exactly what an agent needs to interpret results. Filtering behavior is left to the fully documented schema, and only pagination/volume behavior is missing.

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% and all three parameters are enums with documented values, so the schema carries this dimension. The description echoes location values (Georgioupolis, Chania) but in the context of returned fields, not filter semantics, and it says nothing about the lang or department filters beyond the schema. Baseline 3 applies.

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?

Opens with a concrete verb+resource pair (open positions/jobs at Corissia Resorts hotels in Crete) and enumerates the fields returned (title, summary, departments, location, employment type, salary, date posted, url). It never names the sibling get_job, so an agent must infer that this is the list view versus the single-position view.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: it's clearly a browse/search endpoint, and the note that 'applications are made only on the page of the position' clarifies what the tool cannot do. There is no explicit guidance on when to call list_jobs versus get_job, and no statement about pagination or result limits that would shape invocation.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered; the description adds genuinely new behavioral context — data is as published on the website and may change, hours vary by season, and reservation: null signals the site offers no reservation. It also explicitly disclaims any booking capability, which prevents an agent from assuming the tool can act.

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 content is dense and mostly earns its place, but the opening is a verbless noun phrase followed by fragmented clauses ('access: hotel_guests, other_guests with their condition...') that read like field notes rather than prose. The trailing 'API v3.' is noise, and the access/min_age detail would be better structured than run together mid-paragraph.

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 output schema, the description carries the burden of explaining returns, and it does so by naming access_for_hotel, the access categories, min_age with age_note, and reservation with phones and URL. Combined with the seasonality caveat and out-of-scope note, an agent has enough to call and interpret this correctly; only the behavior with no filters applied is left implicit.

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 all three parameters enum-documented, so the baseline of 3 applies. The description adds modest meaning for 'hotel' by framing it as an access filter rather than a location filter, but it says nothing extra about 'lang' or 'type' beyond the schema's own enum 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 enumerates exactly what the tool returns — restaurants, bars, cafés, spa, room service and beach service across the five Corissia hotels — including hours, prices, access and reservation links, which clearly separates it from siblings like get_venue and get_menu. It never uses an explicit verb such as 'list' or 'returns', leading with a bare noun phrase, and it does not name the sibling tools it is distinguished from.

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?

It gives concrete usage context for the optional hotel filter ('the venues its guests may use') and clear exclusions: the connector does not reserve tables or treatments, and what a board includes 'is not part of this answer', which implicitly routes those needs elsewhere. It stops short of naming alternatives such as get_venue for a single venue's detail or get_menu for menu contents.

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