Nomad Stays

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

Discloses server-side re-validation of price/availability, rejection of stale/expired quotes, the requirement to send the checkoutUrl to the member (and that the agent cannot pay on their behalf), and the token/scope requirement. These go well beyond the annotations (which only hint at non-readonly behavior). No contradiction with 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?

Four sentences, each earning its place: purpose/output, re-validation behavior, agent action requirement, and auth requirement. No filler, front-loaded with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even without an output schema, the description explains the return value (checkoutUrl), the workflow from quote, error handling for stale quotes, and the agent's role in payment. This is complete for a complex booking-creation 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?

The schema already covers all 5 parameters with 100% description coverage, including the origin of quoteId and defaults for contactName/contactEmail. The description adds no additional parameter-level semantics beyond the schema, so a 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 states 'Create a real booking from a quoteId returned by quoteStayBooking, and return a hosted checkoutUrl' — a specific verb, resource, and input. It clearly distinguishes bookStay from quoteStayBooking (quote vs booking) and from other booking-related tools like getBookingStatus and listMyBookings.

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 places the tool in the workflow after quoteStayBooking, states that a stale quote will be rejected and to call quoteStayBooking again, and instructs the agent to send the checkoutUrl to the member. It does not explicitly name alternative tools, but the context and workflow are clear enough for an agent to choose it appropriately.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it 'returns availability status and room details', which provides useful behavioral context beyond the annotations without contradicting them.

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 two concise sentences, front-loaded with the core purpose and followed by the return type. No redundant information 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 simple read-only tool with no output schema, the description covers the purpose, scope, and return type sufficiently. It does not mention edge cases (e.g., invalid stay ID), but given the annotations and schema richness, this is not a significant gap.

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

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

Schema description coverage is 100%, so every parameter (stayId, checkIn, checkOut, roomType) is already documented. The description does not add extra meaning to the parameters beyond what the schema provides, so the 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 a specific verb ('check'), a resource ('a specific stay'), and the scope ('for given check-in and check-out dates'). It distinguishes itself from siblings like getRoomAvailability or findNearestAvailability by focusing on a single stay's 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?

It gives clear context: use when you have a specific stay ID and date range. It does not explicitly mention alternatives or when not to use this tool, but the purpose is self-evident enough that a user can select it appropriately without confusion.

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 indicate a write operation (readOnlyHint false) but the description adds valuable context: no billing step, nextAction proceeds to 'submit', country must be exact and not sanctioned, and an auth token is required. No contradiction with 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?

The description is concise, front-loaded with the main purpose, and each sentence adds meaningful information (workflow contrast, prerequisite, auth requirement). No 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?

For an 8-parameter creation tool with no output schema and sparse annotations, the description covers the essential workflow, prerequisites, and auth. It doesn't mention return values or idempotency, but the main behavioral context is well covered.

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 only 13% schema coverage, the description compensates partly by naming the fields required for the 'submit' path (coworkingName, applicantName, applicantEmail, city, country) and clarifying country semantics. However, address, website, and telephone remain unspecified, leaving gaps.

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 ('Start a new Coworking Application') and the resource, and it distinguishes this tool from related applications by contrasting it with Stay/Experience apps and by specifying the 'create' vs. 'save'/'submit' workflow.

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 explicitly explains when to use this tool (simple, no billing, no VAT) versus alternatives, and provides a direct prerequisite: 'Call getCountries first'. It also notes the required auth token, making usage guidance strong.

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?

It discloses several non-obvious behaviors: the applicant name defaults from the Nomad Stays profile, country-specific rules are validated server-side with field-specific rejections, experiences must run at least 4 days, and a token is required. It does not explicitly state the application's draft lifecycle or return value, but the mention of filling in later via saveExperienceApplication implies a draft workflow; overall this adds substantial context beyond the 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?

Four front-loaded sentences cover purpose, alternatives, prerequisites, validation rules, and auth with no filler. Each sentence earns its place, and the structure flows naturally from what the tool does to how to use it correctly.

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 28-optional-parameter create tool with no output schema, the description covers the essential context: why to call helper tools, what server-side rules apply, how to update later, and authorization. It could further clarify the post-creation state or return shape, but the provided context is sufficient for a reasonably safe first invocation.

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 only 36% schema description coverage, the description compensates by explaining the key relationships for experienceCountryId, postalCountryId, and businessModelId, including VAT/tourism number requirements. Many of the remaining 28 parameters are optional and deferred, and the description says any fields can be supplied later, reducing the risk of incorrect invocation despite incomplete per-parameter detail.

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 'Start a new Experience Application', a specific verb and resource, and immediately distinguishes this creation action from saveExperienceApplication and submitExperienceApplication. It clearly frames the tool as initiating a draft that can be completed later.

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 instructs the caller to call getCountries and getBusinessModels first to resolve experienceCountryId/postalCountryId/businessModelId, and points to saveExperienceApplication for filling in fields later. It also notes server-side enforcement and the 4-day minimum, giving clear when-to-use and when-to-defer context.

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 description adds behavior beyond the annotations: the applicant's name defaults from the profile, country-specific validation is enforced server-side, and rejections name the specific field/reason. It also discloses the token requirement. None of this contradicts the annotations, and it materially improves the agent's understanding of what happens when this tool is invoked.

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 sentences, front-loaded with the primary action, followed by incremental detail and a required-token note. Each sentence earns its place: purpose, deferral to saveStayApplication, prerequisite calls and validation behavior, and authentication.

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 24 optional parameters and no output schema, this is a well-rounded description covering purpose, fill-in-later flow, ID resolution, and server-side validation. It would be slightly stronger if it explicitly stated what the tool returns (e.g., application ID) and whether the new application is a draft, but the overall context is sufficient for the agent to proceed.

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 only 29% schema coverage, the description compensates for the most ambiguous parameters by explaining that stayCountryId/postalCountryId/businessModelId come from getCountries/getBusinessModels, and how VAT/tourism number requirements are tied to country flags. It also clarifies that applicant name overrides are profile-only. It does not explain every one of the 24 parameters, but the key complex ones are addressed.

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

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

The description opens with 'Start a new Stay Application for the caller,' which names a specific verb and resource. It also distinguishes itself from the sibling tools saveStayApplication and submitStayApplication by framing creation as a separate first step and referencing saveStayApplication for later edits.

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 tells the agent to call getCountries and getBusinessModels first to resolve the required ID fields, and notes that fields can be filled later via saveStayApplication. It also warns about country-specific server-side rules, giving clear before-versus-after guidance. The required token adds an auth-related usage condition.

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 description adds the auth requirement, which is not in the annotations. It also states creating a new package, consistent with readOnlyHint=false. But it doesn't disclose side effects like price row replacement or server-computed sellPrice, though those are covered in the schema. Given the annotations already handle safety, this is moderate value.

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 sentence that front-loads the verb and resource, then adds the auth note. No fluff or redundant details.

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 provides the essential purpose and prerequisite. The input schema is exceptionally detailed, covering constraints like tier enums and sellPrice computation, so the description doesn't need to repeat them. It doesn't mention the return value or response format, but without an output schema this may be acceptable. Given the complexity is high but schema richness compensates, a 4 is appropriate.

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

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

The schema provides 100% coverage for all 12 parameters with detailed descriptions. The tool description only mentions 'optionally with initial price tiers', which repeats schema information. No additional parameter semantics are provided, so 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 uses the specific verb 'Create' and identifies the resource as 'a new pricing package on a Stay', clearly distinguishing from sibling update/delete tools. It also mentions the optional initial price tiers, adding scope.

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 for creating a new package, and the 'Requires an MCP agent token scoped to the owning account' note gives a prerequisite. However, it doesn't explicitly name alternatives like updateStayPackage or state when not to use it, 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.

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

The description discloses important behavioral details beyond the annotations: the need for an MCP agent token scoped to the owning account, the boutique cap that causes rejection after 6 rooms, and the auto-assignment of Boutique1-6 slots for boutique stays. These complement the annotations, which only show readOnlyHint=false and destructiveHint=false, and there is no contradiction.

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 four sentences with the primary purpose front-loaded, followed by prerequisites, constraints, and auth requirements. Every sentence contributes meaningful information without redundancy or 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?

The description provides prerequisite calls, auth requirements, a hard cap, and special boutique behavior, which is thorough for a mutation tool with no output schema. It doesn't state the return value or success indicator, but that is not strictly necessary given the absence of an 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?

The input schema already covers 100% of parameters with rich descriptions, including the boutique-specific behavior of roomTypeFK and mcpRoomId. The description adds caller guidance (e.g., 'find valid roomTypeFK/roomFacilityFk values') but does not introduce new per-field semantics beyond what the schema already provides, so a baseline 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 opens with 'Create a new room on a Stay', which is a specific verb and resource, and it clearly distinguishes this from sibling tools like updateStayRoom and deleteStayRoom. The rest of the description reinforces the creation purpose by mentioning prerequisites and constraints.

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 instructs to call getRoomTypeOptions(stayId) and getRoomFacilityOptions() first, and warns about the boutique 6-room cap. It doesn't explicitly discuss when not to use it versus alternatives like updateStayRoom, but the creation context is clear and the guidance is actionable.

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 destructiveHint annotation, the description adds the authentication requirement ('Requires NOMADSTAYS_MCP_AGENT_TOKEN') and the need for an exact fileName from getMyStayRooms. It does not describe side effects like irreversibility, but the annotation already signals destructiveness.

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, with three short sentences. It front-loads the action, then provides the prerequisite and auth requirement. Every sentence adds necessary information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, prerequisite, and auth. Given the tool has no output schema, it doesn't explain return values, but for a delete operation this is often implicit. The roomArea enum is not explained in the description, but the schema covers it. Overall, the description is sufficiently complete for the tool's complexity.

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

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

With 100% schema description coverage, the schema already documents all four parameters. The description adds context by instructing to call getMyStayRooms first to obtain the exact fileName, which clarifies the source of that parameter. It doesn't add much for roomArea or stayId/roomId but the prerequisite is valuable.

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 action: 'Delete one photo from a room's gallery.' It distinguishes from sibling tools like deleteStayPhoto (which deletes stay photos) by specifying 'room's gallery.' The mention of 'roomArea' further clarifies it handles both regular and coworking galleries.

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 a clear prerequisite: 'Call getMyStayRooms first to find the exact fileName.' This guides the agent on the required preceding step. It also notes the auth requirement. However, it does not explicitly mention when not to use it or name alternatives, though the distinction from deleteStayPhoto is implied by the resource.

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?

Discloses that this is a hard, permanent delete and that all price tiers are removed. The auth scope requirement adds useful context beyond the destructiveHint annotation. No contradiction with 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?

Two short sentences that front-load the action and scope, then add the important contrast and auth requirement. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-param delete with annotations marking it destructive, the description covers the core behavior, permanence, and auth. Could optionally mention the return format or constraints (e.g., whether bookings block deletion), but these are not critical for this 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?

The input schema already provides 100% coverage with descriptions for both parameters (stayId and packageId). The description adds no additional parameter-level meaning, so the baseline of 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?

Clearly states 'Permanently delete a pricing package and all its price tiers from a Stay' with a specific verb and resource. The explicit contrast with room deletion ('unlike room deletion, which is soft') distinguishes it from the sibling tool deleteStayRoom.

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 gives context by contrasting with soft room deletion and states the authorization requirement ('MCP agent token scoped to the owning account'). However, it does not explicitly mention when to prefer updating over deleting, such as using updateStayPackage.

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?

With annotations already declaring destructiveHint=true, the description adds valuable context by specifying the required auth token (NOMADSTAYS_MCP_AGENT_TOKEN) and the necessary lookup step via getMyStayPhotos. It is consistent with the annotations and provides extra procedural detail without contradicting them.

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 three short, information-dense sentences: action, prerequisite, and auth requirement. Every sentence earns its place with no redundancy 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 straightforward delete operation, this description is complete. It covers the prerequisite workflow, the auth requirement, and, combined with the rich schema and annotations (destructiveHint), fully informs the agent about the tool's usage and constraints. The schema handles the area restriction, so the description does not need to repeat 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?

The input schema provides 100% coverage for all three parameters, including the area enum with an explicit note about unsupported room photos and an example for fileName. The description merely reiterates that the fileName should be exact, adding no meaningful semantic value 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 specifies the action ('Delete one photo from a Stay') and the resource, making it easy to understand the tool's core purpose. However, it does not explicitly distinguish itself from the sibling deleteRoomPhoto, which is a similar tool for room photos; the schema's area parameter notes this limitation instead.

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 gives a clear prerequisite: 'Call getMyStayPhotos first to find the exact fileName.' This establishes the expected workflow and when to use the tool. It does not explicitly state when not to use it (e.g., for room photos) or mention alternatives like deleteRoomPhoto, which is left to the schema's area parameter description.

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 description discloses that the delete is a soft-delete, which is not implied by the annotations' destructiveHint=true (which could suggest a hard delete). It also mentions the token scope requirement, adding auth context beyond structured annotations. This goes beyond what annotations alone convey, though it doesn't describe reversibility or side effects.

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, front-loaded sentence that immediately states the action and object. It includes a necessary auth caveat without adding fluff. Every word contributes value, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter delete operation with no output schema, the description covers the core purpose and the key auth context. It is sufficient for an agent to use the tool correctly. A minor omission is that it doesn't say what happens after deletion (e.g., return value), but this is non-critical for a soft-delete operation.

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

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

The input schema already provides 100% coverage with descriptions for both parameters, including how to find the roomId via getMyStayRooms. The description itself adds no extra parameter meaning, so the baseline of 3 applies, as the schema does the heavy lifting.

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

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

The description states a specific action (Delete) on a specific resource (a room from a Stay), and clarifies it is a soft-delete. This clearly distinguishes it from sibling tools like deleteRoomPhoto, deleteStayPackage, and deleteStayPhoto. The verb+resource structure is 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 gives a clear context for when to use the tool (to soft-delete a room) and a prerequisite (MCP agent token scoped to the owning account). It does not explicitly mention alternatives or when not to use it, but the context is straightforward and the auth requirement is useful guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds useful behavioral detail: it searches a window and can adjust length of stay, which goes beyond the annotations. No contradictions found.

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 two sentences, front-loaded with the core purpose, and every phrase adds value. No fluff or repetition.

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 moderate complexity, the description covers the essential purpose and behavior. Although there is no output schema, the description does not explain return values or edge cases (e.g., what if no availability is found). However, the annotations and parameter schema are rich enough that the description is largely adequate for selection and invocation.

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 mentions 'within a specified window' and 'adjust length of stay', which loosely map to searchWindowDays and min/maxLengthOfStay, but it does not add detailed parameter-level semantics beyond what the schema already provides.

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 function: finding the nearest available dates when requested dates are unavailable. It specifies the resource (available dates) and the verb (find), and distinguishes itself from sibling tools like checkStayAvailability by focusing on alternative date searches.

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 when to use this tool: when requested dates are not available. It explains the search mechanism (within a specified window) and the ability to adjust length of stay, giving clear context. However, it does not explicitly name alternatives or state when not to use it, though the 'when requested dates are not available' phrase serves as a strong trigger.

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 readOnlyHint annotation, the description warns that the values are NOT booleans but lookup IDs, and discloses the required token (NOMADSTAYS_MCP_AGENT_TOKEN). This adds meaningful behavioral context that the agent would not otherwise know.

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

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

The description is compact (three sentences) and front-loaded with the primary purpose. Every sentence contributes useful information without repetition or 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?

Given the simple one-parameter read-only tool and no output schema, the description adequately explains what the tool returns (valid picklist values) with examples. However, it could mention the return format (e.g., array of option objects) to be fully complete, so a slight deduction applies.

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

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

The input schema already defines the filterName enum (Children Allowed, Pets Allowed, Parking) with 100% coverage. The description merely restates those enum values and does not add deeper parameter semantics, so the baseline 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 the tool lists valid values for Additional Information picklists (Children Allowed, Pets Allowed, or Parking). It ties the tool to a specific consumer (updateStayOrganisationalData) and names the exact fields it supports, distinguishing it from sibling tools.

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 tells the agent when to use it: 'call this to find the right value before writing petsAllowedId/childrenAllowedId/parkingId'. This provides a clear use case and context, even if alternatives are not 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds meaningful context by specifying the grouping and the underlying database references (tbStaysFacilities and tbStaysRoom.RoomFacilityFk), which clarifies what 'all' means and how results are organized.

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, front-loaded sentence that begins with the action and object. The parenthetical table references are concise and add necessary grouping context without 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?

For a zero-parameter read-only list tool with no output schema, the description adequately conveys purpose and grouping. It does not detail the exact return format, but the grouping statement largely covers expectations. The lack of explicit output shape is a minor gap, not a critical one.

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

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

The tool has zero parameters and schema coverage is vacuously 100%. The baseline for 0-parameter tools is 4, and since no parameters exist, the description correctly adds no parameter-specific details.

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 a specific action ('List all possible amenities') with a defined scope (database-wide) and a meaningful grouping into Stay Amenities and Room Amenities. This distinguishes it from sibling tools like getRoomAmenities by emphasizing the 'all possible' scope and the grouping.

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 explicit when-to-use or alternative guidance is provided. The scope implies use for obtaining the full master list of amenities, but the description does not contrast with related siblings like getRoomAmenities or getFacilityGroups, leaving some ambiguity.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds behavioral context by noting it returns 'active' categories, which implies a filter on inactive ones, and frames it for discovery.

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 sentences: the first states what it does, the second states when to use it. No filler, front-loaded, highly 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 the tool's simplicity (no params, no output schema), the description fully covers the purpose, the active filter, and its role in a workflow with a sibling tool. Nothing essential 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?

The tool has zero parameters, so the baseline is 4. There is nothing to document about parameters, and the description doesn't need to compensate.

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 returns active lifestyle/genre categories, using a specific verb ('Returns') and identifying the resource. It also distinguishes itself from the sibling tool getStaysByLifestyle by positioning itself as the discovery step.

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 explicitly says to use this tool before searching with getStaysByLifestyle, providing both when to use and an alternative. This is direct and actionable.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat safety traits. It adds value by explaining the filtering behavior ('meet the minimum length of stay requirement') and the output shape ('Returns all possible check-in dates and their corresponding available periods'). This is useful context beyond the annotations, though it doesn't cover edge cases like response limits or date ranges.

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 two sentences, both informative and free of fluff. It front-loads the main purpose and includes a brief output explanation. Every word earns its place, making it highly concise and well-structured.

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 query tool with a simple schema and no output schema, the description is largely complete. It states the purpose and output format clearly. However, it could briefly mention that results are tied to a specific stayId (though schema implies this) or clarify how 'available' is determined, which would make it fully complete.

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%, with all four parameters (year, month, stayId, minLengthOfStay) already documented in the schema. The description only reinforces the minLengthOfStay concept without adding new semantic meaning. It earns the baseline score for high schema coverage but doesn't elevate it further.

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 function: 'Get all available booking windows in a specific month that meet the minimum length of stay requirement.' It uses a specific verb ('Get'), identifies the resource ('available booking windows'), and specifies key constraints ('specific month', 'minimum length of stay'). The added detail about returning 'check-in dates and their corresponding available periods' further clarifies the output, distinguishing it from other availability tools.

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 context (monthly availability with length-of-stay filter) but does not explicitly differentiate it from sibling tools like checkStayAvailability or findNearestAvailability. There is no mention of when to prefer this tool over alternatives or when not to use it. The guidance is implicit rather than explicit.

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 readOnlyHint annotation, the description adds crucial behavioral context: direct re-verification against Airwallex, account ownership restriction, and the required token scope. This enriches the agent's understanding without contradicting the 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?

The description is three dense sentences, each contributing distinct value: purpose, verification logic, account restriction, and authentication requirement. There is no redundancy or wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only tool with no output schema, this description covers all essential aspects: what it checks, how it behaves, who can access what, and what authentication is needed. It is sufficiently complete for an agent to select and 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?

The schema already provides 100% coverage of the single 'pnr' parameter, describing it as the booking reference returned by bookStay. The description only repeats 'by PNR' and adds no new semantic detail, so the 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 opens with a specific verb and resource: 'Check a Stay booking's real payment status by PNR.' It clearly identifies the tool's operation and scope, but does not explicitly contrast it with sibling tools like getPurchaseStatus or listMyBookings.

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 provides clear contextual guidance: the status is freshly re-verified against Airwallex, and the agent is told never to trust client-supplied success claims. It also states the tool only returns bookings owned by the caller's account, but it does not name alternative tools for other cases.

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 readOnlyHint annotation, the description adds meaningful context: the value is displayed on the Stay, not editable via MCP or host UI, and requires the NOMADSTAYS_MCP_AGENT_TOKEN. These details clarify the tool's behavior and constraints beyond what annotations alone provide.

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 packs in the action, scope, read-only status, edit restrictions, and auth requirement without wordiness. Every clause 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?

For a simple parameterless read-only options-listing tool, the description fully covers purpose, scope, field, read-only nature, edit restriction, and token requirement. With annotations handling safety traits and no output schema expected, the description is complete.

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

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

The tool has 0 parameters and the schema is empty, so the baseline of 4 per rubric applies. The description references businessModelId as output scope, but no parameter documentation is needed. No additional parameter semantics could be 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 lists valid values for a Stay's listing/business model, with the specific field businessModelId. This distinguishes it from sibling options tools like getRoomTypeOptions or getStayTypeOptions by naming the exact domain and field.

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 for read-only lookup of valid business model values and explicitly notes the field is not editable via MCP or host UI. However, it does not explicitly state when to choose this tool over alternatives or provide exclusions, so it falls one point short of full guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the requirement of NOMADSTAYS_MCP_AGENT_TOKEN, disclosing an authentication need beyond the annotations. It doesn't describe the return format, but for a list tool this is implied.

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

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

The entire description is one sentence that front-loads the action ('List valid values') and includes only necessary information: the purpose and the authentication requirement. 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?

For a zero-parameter, read-only tool with no output schema, the description fully covers what it does, what it's for, and the auth requirement. The annotations cover safety. This is complete for the tool's simplicity.

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

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

The input schema is empty with zero parameters, so the baseline is 4. The description mentions cxPolicyId but that is a field in another tool, not a parameter here; no additional parameter documentation is needed.

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 uses the specific verb 'List' and identifies the resource as 'valid values for a Stay's cancellation policy', and further clarifies it pertains to the cxPolicyId field in updateStayOrganisationalData. This clearly distinguishes it from other options-list sibling tools like getRoomTypeOptions or getCountryOptions.

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 clear context by linking the output to the cxPolicyId field in updateStayOrganisationalData, indicating this tool is used when needing valid cancellation policy values for that update operation. It does not explicitly list when not to use it or name alternatives, but the purpose is specific enough 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.

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safe read behavior is covered. The description adds the auth requirement ('Requires NOMADSTAYS_MCP_AGENT_TOKEN') and the return content (name and 2-letter code), providing useful context beyond the 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?

The description is two concise sentences, front-loaded with the action and then the auth note. Every sentence adds necessary information with no filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, zero-parameter, read-only tool, the description fully covers what is returned (country name and 2-letter code), its purpose (valid values for countryId), and access requirements. The lack of an output schema is compensated by explicitly stating the return contents.

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 are zero parameters, so schema coverage is trivially 100%. The description adds value by explaining the purpose of the output (valid values for countryId) even though no parameter documentation is needed. Baseline 4 applies due to no params.

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 function: 'List valid values for a Stay's country' with output details ('name and 2-letter code'). It also distinguishes from siblings by referencing the specific field (countryId in updateStayOrganisationalData), 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 implies when to use the tool by tying it to a specific field ('countryId in updateStayOrganisationalData'), which guides the agent to use it when needing valid country values for updates. It does not explicitly exclude alternatives or mention when not to use it, but the context is clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds valuable behavioral context beyond annotations: it discloses the auth token requirement and specifies the return content (nextAction hint and missingFields list for incomplete applications), which is 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?

The description is a single, front-loaded sentence that immediately states the core purpose, then provides key additional details (return content, auth requirement) without unnecessary words. Every clause earns its place, and there is no repetition of schema or annotation 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?

For a single-parameter read-only tool with no output schema, the description adequately explains what the tool returns (full state, nextAction hint, missingFields) and mentions the auth requirement. Given the low complexity, this is complete enough for an agent to select and 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?

Schema description coverage for the single parameter is 100%, and the schema itself already provides guidance ('use listCoworkingApplications to find it'). The description does not add additional parameter syntax or format details, so it stays at the baseline of 3 since the schema does the heavy lifting.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource ('one Coworking Application') and scope ('full current state'). It also adds distinctive details (nextAction hint, missingFields list) that differentiate it from listCoworkingApplications and other get tools.

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 clearly implies when to use this tool: when you need the full current state of a single application, particularly to see a nextAction hint or missing required fields. It also notes an auth requirement (NOMADSTAYS_MCP_AGENT_TOKEN). However, it does not explicitly state when not to use it or mention direct alternatives beyond the schema hint for applicationId.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the domain context (currency ids/codes for currencyFK) but does not disclose response formats or other behavioral details. With annotations covering the core, this is adequate but not rich.

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 sentence, directly front-loaded with the action ('List valid currency ids/codes'), and contains no unnecessary words. It is optimally concise.

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 simplicity (no parameters, no output schema), the description provides sufficient context about its purpose and output. It could specify the exact return structure (e.g., array of strings), but the phrase 'List valid currency ids/codes' already implies the output shape, making it nearly complete.

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

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

The tool has zero parameters, and the schema coverage is 100%, so there is no need to explain parameters. The description compensates by clarifying what the output represents (valid currency ids/codes), earning the baseline score of 4 for parameterless tools.

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 'List valid currency ids/codes' with a specific purpose ('for use as a package's currencyFK'). The verb 'List' and the resource definition make it distinct from siblings like getCountryOptions or getRoomTypeOptions, which target different fields.

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 'for use as a package's currencyFK' provides clear context on when to use this tool, implying it is appropriate when setting or validating the currency of a package. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a full 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?

Annotations already indicate read-only, non-destructive, non-open-world. The description adds value by disclosing the auth token requirement and the specific response details (nextAction hint, missingFields). No contradictions with 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?

Two concise, information-dense sentences with no filler. Front-loaded with the core action and immediately useful response details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with one parameter, the description covers the purpose, auth requirement, and return characteristics, even without an output schema. It's sufficiently complete.

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 applicationId parameter is well-described in the schema with a pointer to listExperienceApplications. The tool description itself adds nothing about parameters, 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 description uses a specific verb ('get') and resource ('one Experience Application'), and differentiates from sibling listing/writing tools by stating it retrieves the full current state. It also mentions the nextAction and missingFields details, which further clarifies its unique function.

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 the tool is for reading a single experience application's state, and the parameter description directs users to listExperienceApplications to find the ID. However, it doesn't explicitly mention alternatives or when not to use it, so context is clear but exclusions are absent.

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 read-only and non-destructive behavior. The description adds useful context beyond annotations: the requirement for NOMADSTAYS_MCP_AGENT_TOKEN and the scope (list of group names only). It does not contradict 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?

Two sentences that are information-dense with no redundancy. The first sentence defines the action and provides examples; the second covers usage context and auth requirements. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool with no output schema, this description is complete: it states what is returned (group names), when to use it (before dependent tools), and the required token. It fully covers the agent's need to select and 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?

The tool has zero parameters, so the baseline is 4. The description correctly implies no parameters are needed by saying 'List every...' and gives examples of the data returned, which is sufficient for a no-parameter tool.

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: 'List every facility/checkbox group name that exists on the platform' with specific examples. It also distinguishes from siblings by explicitly referencing getMyStayFacilities/updateStayFacilities as the intended consumers of the output.

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 provides explicit usage guidance: 'Call this first if you don't already know the exact group name to pass to getMyStayFacilities/updateStayFacilities.' This tells the agent exactly when to use it and names the alternative tools, making the decision context clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is established. The description adds value by explicitly stating the output includes full article content, title, slug, and categories, which is useful behavioral context beyond the 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?

The description is two sentences long, front-loads the primary action, and contains no filler or redundant wording. Every word contributes to understanding 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?

For a simple single-parameter fetch tool with no output schema, the description adequately explains what the tool does and what it returns. It covers the essential information an agent needs to select and 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?

The schema already provides full coverage for the single parameter 'id' with a clear description that it is a WordPress post ID. The tool description adds no new semantic detail about the parameter beyond what the schema already states, so the baseline 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 uses a specific verb 'Fetch' with a clear resource ('specific NomadStays Help Center article') and identifies the method of identification ('by its ID'). It also lists what is returned (article content, title, slug, and categories), which distinguishes this from the sibling tools 'searchHelpCenter' and 'listHelpCenterCategories'.

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 'by its ID' clearly implies that this tool is for retrieving a known article, whereas 'searchHelpCenter' would be for finding articles by query. However, it does not explicitly mention alternative tools or exclusions, 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.

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

Beyond the read-only annotations, the description discloses that bank/tax-ID details are never exposed via MCP and that a specific auth token is required. This adds meaningful context about data scope and authentication.

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?

Four concise sentences, each serving a purpose: definition, exclusions, usage order, and auth requirement. No redundant phrases.

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 zero-parameter getter with no output schema, the description provides sufficient context: field list, exclusions, sequencing, and auth. No gaps in understanding what the tool does.

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

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

The tool has zero parameters, so the schema is effectively empty. The description adds no parameter-specific semantics, but the baseline of 4 is appropriate given the absence of parameters.

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 'Get the host account's business profile' and enumerates specific fields (legal business name, VAT numbers, registration status). This distinguishes it from sibling tools like updateHostBusinessProfile and other getters.

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 instructs to 'Call this before updateHostBusinessProfile', providing a clear sequencing guideline. Also states exclusions (bank/tax-ID details) to prevent misuse.

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 read-only and non-destructive behavior, so the description adds value by disclosing the required auth token ('Requires NOMADSTAYS_MCP_AGENT_TOKEN') and enumerating the exact return fields, which is especially important given no output schema. It also reveals the sequencing dependency (before updateStayContacts). It does not contradict annotations. Slight deduction for not mentioning rate limits or error conditions, but overall strong.

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 concise sentences: purpose with return fields, usage context relative to updateStayContacts, and auth requirement. Each sentence serves a distinct purpose. It is front-loaded with the main action and not padded with filler. Despite the long enumeration in the first sentence, it is information-dense and well-structured.

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 there is no output schema, the description fully enumerates the expected return fields, which is essential for the agent to know what this tool provides. It also includes the auth requirement and sequencing with updateStayContacts, making it self-contained for the agent's decision-making. No additional information is needed 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?

The input schema covers 100% of parameters: stayId is described as 'The Stay's EntryID (use getMyStays to find it)'. The description itself does not add any additional parameter-specific meaning; it focuses on the return value instead. Per the rubric baseline of 3 for high schema coverage, this 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 states a specific verb 'Get' plus a distinct resource: a Stay's contact/owner/manager details and social media links. It enumerates the exact fields (owner/manager name/email/mobile, booking email/phone/mobile, website/social links), which clearly differentiates it from generic getMyStayDetail. The explicit reference to updateStayContacts further clarifies its role.

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?

Description gives explicit usage guidance: 'Call this before updateStayContacts so the agent knows current values.' This tells the agent when to invoke this tool relative to a sibling and provides a rationale. It clearly implies this is the precursor read for contacts before making updates, which is the primary use case.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by mentioning the auth requirement ('Requires NOMADSTAYS_MCP_AGENT_TOKEN') and implying a read of current state ('current values'), which goes beyond the structured 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?

Each of the three sentences earns its place: purpose, usage guidance, and auth requirement. No fluff or redundancy; the description is front-loaded with the primary purpose and stays under three sentences.

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 simplicity (one parameter, read-only, no output schema), the description is complete. It specifies what is returned (title, description, listed status), the scope (your stays), the prerequisite (call before updateStayDetail), and the token requirement, covering all necessary context for an agent to invoke 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?

The input schema already has 100% description coverage for stayId, including guidance to use getMyStays. The tool description does not add parameter-level semantics beyond that, so the schema carries the full burden, matching the baseline score 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 uses a specific verb ('Get') and clearly identifies the resource ('the current title, description, and listed status for one of your Stays'). It distinguishes from siblings by scope ('your Stays') and by naming the exact fields returned, unlike getStayByID which likely returns broader stay 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?

Explicitly states when to use: 'Call this before updateStayDetail so the agent knows the current values and doesn't accidentally overwrite them.' This provides a clear prerequisite and rationale, effectively guiding tool selection relative to the updateStayDetail sibling.

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

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

Annotations already declare readOnlyHint=true, but the description adds meaningful context by explaining that the tool returns all platform-supported options plus the currently selected ones, using a concrete example. It also discloses the required auth token, offering behavioral details beyond structured fields.

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

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

The description is compact—three sentences that front-load the core purpose, then add a clarifying example, usage guidance, and auth requirement. No filler or redundancy; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description adequately describes the response concept (all supported options + current selections) via example. It also provides necessary prerequisite guidance and parameter context. It could be more precise about the exact response structure, but it is sufficient for a simple 2-param read-only 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 described. The description reinforces the exact group name requirement and provides examples, but does not add significant semantic value beyond what the schema already states. Baseline 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 the tool's function: getting both available options and current selections for a facility/checkbox group on a Stay. It uses a specific example ('Languages Spoken') and distinguishes itself from sibling tools like getFacilityGroups (which lists group names) and updateStayFacilities (which modifies selections).

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 explicitly says to call getFacilityGroups first if the exact group name is unknown, which provides direct guidance on prerequisites and an alternative. It also lists common group names, giving clear context on when to use this tool, though it does not explicitly state exclusions for other tools like room-related facility queries.

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 (readOnlyHint, destructiveHint), the description adds valuable field-level caveats: Wi-Fi is a test-freshness score not speed, Operator Information is a status label not a percentage, and both are marked via isPlaceholder/behavior. It also mentions the required auth token, giving operational context.

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 front-loaded with the primary purpose, followed by usage guidance and caveats. It's a bit long due to the field clarifications, but every sentence adds value and nothing is redundant.

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 tool with no output schema, the description explains what the response contains: six named scores plus an overall percentage, with important caveats about placeholder semantics. It also covers authentication. It lacks exact value formats, but is otherwise complete for a read-only status 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?

The single parameter stayId is fully described in the schema with a helpful pointer to getMyStays. The description itself doesn't add extra parameter details, but with 100% schema coverage, 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?

The description clearly states the tool's function: 'Get the Stay's listing-completion scores' with specific detail about the six dashboard cards and overall percentage. It distinguishes itself from sibling getMyStay* tools by focusing on completion/onboarding status rather than details, photos, or packages.

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 when-to-use guidance: 'Use this when a host asks how far along they are with onboarding or what's left to finish.' It doesn't name alternative tools, but the usage context is clear and sufficient for selection among the many sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds the token requirement and the purpose of retrieving current values. This is useful context beyond annotations, though it does not discuss rate limits or response details.

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 two sentences, front-loaded with the core purpose, then usage guidance, then auth requirement. Every sentence earns its place with no 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?

No output schema exists, but the description compensates by explicitly listing the categories of returned data, giving the agent a clear picture of what to expect. Combined with the parameter guidance and auth note, it is fully self-contained for a simple read operation.

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%: the single parameter stayId has a descriptive schema entry explaining it's the EntryID and how to find it. The description adds no additional parameter information, so a 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's function with a specific verb 'Get' and resource 'Stay's organisational data', and enumerates the exact data categories (address, check-in/out policy, etc.). This distinguishes it from sibling getMyStay* tools by explicitly narrowing scope.

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 instructs to call this before updateStayOrganisationalData to obtain current values, providing clear sequencing guidance. It also notes the token requirement, alerting the agent to authentication prerequisites.

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 mark readOnlyHint=true and destructiveHint=false; the description adds auth requirements ('Requires NOMADSTAYS_MCP_AGENT_TOKEN') and specifies the exact pricing fields returned. No contradiction or destructive behavior is implied. Minor gap: no mention of pagination or response shape, but the field enumeration helps 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?

Two focused sentences, front-loaded with the verb and scope. The second sentence adds actionable guidance and auth info without fluff; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only lookup with one well-documented parameter and strong annotations, the description covers purpose, return fields, auth, and usage order. No output schema exists, but the listed fields sufficiently describe the return value.

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 single parameter already has a clear description ('The Stay's EntryID (use getMyStays to find it)'). The tool description adds no extra parameter-level details, so the baseline of 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?

Description opens with 'List all pricing packages on one of your Stays', a specific verb+resource+scope, and enumerates returned fields (days, buy/sell/comparison price, listed status). It is clearly distinct from siblings like createStayPackage and updateStayPackage.

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 instructs 'Call this before createStayPackage or updateStayPackage', naming the relevant alternatives and giving direct when-to-use guidance. The rationale ('hosts often forget exactly what packages/pricing they've already set') further clarifies context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context by disclosing the output format (full https URLs, not filenames), the scope (all photo areas), and an auth requirement (NOMADSTAYS_MCP_AGENT_TOKEN). No contradiction with 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?

The description is two sentences, front-loaded with the primary purpose, and every sentence delivers useful information: scope, output format, usage timing, and auth. 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 the simple tool (1 param, no output schema), the description is complete: it explains what is returned (full URLs), the breadth of coverage (all areas), prerequisites (token), and when to invoke it (before delete/reorder). This is sufficient for an agent to select and call 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 description coverage is 100% for the single parameter stayId, whose description already explains it is the Stay's EntryID and points to getMyStays. The tool description adds no additional parameter-level meaning, so the baseline of 3 applies without needing compensation.

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 uses a specific verb ('Get') and resource ('every current photo for a Stay'), clarifying scope by enumerating all areas (listing gallery, main/hero, workspace/coworking gallery, host). It also distinguishes from sibling photo tools by emphasizing full CDN URLs and 'all areas'.

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 instructs when to use this tool: 'Call this before deleteStayPhoto or reorderStayPhotos to see current filenames.' This names alternative/related tools and provides a clear workflow context, exceeding minimal guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by revealing the auth requirement (NOMADSTAYS_MCP_AGENT_TOKEN), the resolved-to-names behavior for facilities, and the inclusion of viewable CDN URLs for photos. These details go beyond annotations, though it doesn't mention pagination or error behavior.

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

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

Three sentences, each earning its place: purpose + return contents, usage timing + benefit, and auth requirement. No fluff or repetition, with key information front-loaded.

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 compensates by listing the main fields returned (bed setup, occupancy, facilities, photo URLs) and hints at roomId/fileName availability. It's a simple one-parameter tool, so this is fairly complete. Could be improved by explicitly stating the return is an array of rooms, but the wording 'List all rooms' implies that.

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 stayId described as 'The Stay's EntryID (use getMyStays to find it).' The description doesn't add anything about the parameter itself, relying on the schema. This matches the baseline for full schema coverage.

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 verb and resource: 'List all rooms currently configured on one of your Stays.' It goes beyond a simple list by enumerating the returned data (bed setup, occupancy, facilities resolved to names, photo CDN URLs), which distinguishes it from sibling tools like getMyStayDetail or getMyStayPhotos. The mention of being a prerequisite for room mutation tools further clarifies its unique role.

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 states when to call: 'Call this before createStayRoom, updateStayRoom, deleteStayRoom, deleteRoomPhoto, or reorderRoomPhotos.' It also explains the benefit: 'so the agent can show current values or find the right roomId/fileName.' This provides clear, actionable guidance and implicitly differentiates from the mutation tools.

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 indicate readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable context: it discloses the account-bound scope, the specific return fields (stayId, title, listed status), and the authentication requirement (NOMADSTAYS_MCP_AGENT_TOKEN). This goes beyond the annotations, though it doesn't mention pagination or potential empty results.

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 three sentences, each earning its place: the first states what the tool does, the second lists return fields and the primary use case, and the third notes the auth requirement. It is front-loaded with the action and resource, and there is no filler or repetition of schema/annotation 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?

For a simple zero-parameter list tool with no output schema, the description is complete: it states the scope, return values, authentication need, and the practical use case (finding stayId). No additional context seems necessary for an agent to invoke this 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?

With zero parameters, the input schema provides no meaning to clarify. The description compensates by explaining that the tool returns stays owned by the token-bound account and includes stayId, which is useful context. Baseline for 0 params is 4, and the description meets that 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 specifies the action ('List all Stays'), the resource ('Stays owned by the account bound to the MCP agent token'), and the returned fields. It distinguishes itself from public stay search tools and owner-scoped detail tools by emphasizing the ownership scope and the 'find a stayId' purpose.

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 gives explicit guidance on when to use it ('use this to find a stayId before calling any other owner-scoped tool'), which is clear and actionable. It doesn't explicitly state when not to use it or name alternatives, but the 'before any other owner-scoped tool' instruction effectively implies a prerequisite role.

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 description adds substantial behavioral context beyond the readOnlyHint annotation: it reveals the isWaivedForCaller return field, the special case for re-applying Stay Partners, and the authentication token requirement. No contradiction with 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 sentences each add distinct value: purpose, return behavior/waiver logic, and auth requirement. No redundancy, front-loaded with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only lookup with annotations, the description covers purpose, output meaning, the special waiver condition, and authentication. It is complete enough for an agent to decide when to use the tool and what to expect.

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

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

The input schema already fully documents productId, including instruction to use 8. The description repeats this info but does not add new parameter semantics beyond what the schema provides, so 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 looks up a product's price and purchasability, identifies the specific product (8, Stay Application fee), and distinguishes it from purchaseProduct by focusing on lookup rather than purchase. The verb 'look up' and resource 'Nomad Stays product' are specific.

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 as a pre-purchase check, referencing purchaseProduct for processing waivers, and notes the token requirement. However, it does not explicitly state when not to use it or list alternative lookup tools among many siblings.

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 description adds substantial behavioral context beyond the readOnlyHint annotation: it discloses that a fresh server-side check is performed against the payment provider, lists the possible statuses, and notes the token requirement. This exceeds the annotation baseline.

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 two sentences, front-loaded with the primary purpose, and includes necessary caveats and statuses without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's behavior, return statuses (pending, paid, failed, waived), and authentication requirement, making it fairly complete despite lacking an output schema. It doesn't specify the exact return format, so 4.

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

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

The schema already provides 100% coverage with a clear description for saleId ('returned by purchaseProduct'), so the description doesn't need to add parameter details. The baseline of 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 description clearly states the tool's function with a specific verb ('Check') and resource ('whether a purchase has been paid'), and provides the possible statuses. It distinguishes itself from siblings like getBookingStatus by focusing on purchases rather than bookings.

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 clear usage guidance, instructing to 'never trust the member's own claim' and to 'always poll this instead', indicating this is the authoritative source for payment status. However, it doesn't explicitly name alternatives or exclusions, so it's not 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safe read-only nature. The description adds the return contents (room details, facilities, network performance), but does not disclose potential edge cases (e.g., invalid roomId, missing WiFi data) or formatting details, so it provides only modest additional behavioral context.

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 front-loads the main action and lists the expected returns. Every phrase provides useful information without redundancy, making it highly concise and 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 the simplicity of the tool (one input, read-only, no output schema), the description sufficiently summarizes what the tool returns. It doesn't specify behavior for missing or invalid inputs, but for a straightforward getter this is a minor gap. The description is complete enough for an agent to understand the tool's core functionality.

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

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

The input schema covers 100% of the parameter (roomId) with a clear description. The tool description adds minimal value by referring to 'a specific room' but does not elaborate on parameter behavior, formats, or constraints beyond the schema. Baseline 3 is appropriate given high schema coverage.

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: to get a comprehensive list of facilities and amenities for a specific room, including WiFi metrics. It distinguishes itself from siblings like getAllAmenities (global list) and getRoomFacilityOptions (options) by specifying 'for a specific room' and including unique data like jitter.

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 when to use this tool: when you need detailed amenities for a specific room, indicated by 'for a specific room'. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough to infer the intended use case, though it could benefit from a direct comparison with similar tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns per-night availability status, which is useful context but does not disclose additional behavioral traits like error handling, authentication requirements, or date inclusivity nuances. With annotations covering safety, this is adequate but not exceptional.

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 two sentences, front-loaded with the primary action, and contains no unnecessary information. It directly states the purpose and what is returned, making it highly 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?

For a read-only tool with three simple parameters and no output schema, the description adequately covers the purpose and return format (per-night availability status). It does not explain edge cases like whether checkOut is exclusive, but this is minor for the tool's simplicity. Given the richness of annotations, the description is sufficiently complete.

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%, with all three parameters (roomId, checkIn, checkOut) already documented in the input schema. The description only loosely refers to 'date range' without adding new meaning beyond what the schema provides, so a 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 the tool's purpose: checking a specific room's availability for each night in a date range. The verb 'check' + resource 'room availability' + scope ('specific room', 'date range') distinguishes it from sibling tools like checkStayAvailability or getAvailabilityByMonth.

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 the use case—checking per-night availability for a specific room—which is clear context. However, it does not explicitly mention when not to use this tool or name alternative tools that might be more appropriate for other availability queries (e.g., findNearestAvailability).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety is known. The description adds an auth token requirement and the mandatory Wi-Fi behavior, providing valuable context beyond what annotations offer.

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 sentences, each serving a clear purpose: purpose/examples, mandatory Wi-Fi caveat, auth requirement. No wasted words and front-loaded with the primary action.

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 no-parameter, no-output-schema tool, the description covers purpose, special behavior, and auth. It's sufficient for an agent to select and invoke. Minor gap: doesn't specify return format, but the examples imply a list of strings.

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

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

The tool has zero parameters, so there are no parameter semantics to clarify. Per the baseline for 0-param tools, the description doesn't need to explain parameters; it adds contextual meaning by linking the output to roomFacilityFk usage.

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 uses a specific verb ('List') and identifies the exact resource: all room-level amenity/facility options. It explicitly references roomFacilityFk in createStayRoom/updateStayRoom, distinguishing it from sibling tools like getAllAmenities or getRoomAmenities.

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 clearly implies when to use this tool: to discover valid roomFacilityFk values for room creation/update endpoints. It also provides a usage caveat that Wi-Fi is mandatory and always included. However, it doesn't explicitly mention alternative tools or state when it should not be used.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds context about the token requirement and how valid values differ by stay type. This goes beyond annotations by explaining the conditional behavior of the returned options.

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 tightly written sentences: the first states the core action, the second explains the dependency rule, and the third notes the auth requirement. 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?

Despite lacking an output schema, the description makes the return type clear ('List valid room types') and explains the two categories of valid values. Combined with the single well-documented parameter and safety annotations, this is sufficient for an agent 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?

The schema already fully describes stayId as 'The Stay's EntryID' with 100% coverage. The description reinforces its role by linking to specific stay rooms but does not add new format or type details 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 'List valid room types for a specific Stay's rooms' and explicitly ties it to roomTypeFK in createStayRoom/updateStayRoom. This specific verb+resource scope distinguishes it from sibling tools like getStayTypeOptions or getRoomFacilityOptions.

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 specifies the use case is to get valid room types for a stay's rooms, with a clear dependency on stay type (boutique vs standard). It directly references the context of roomTypeFK in createStayRoom/updateStayRoom, making when-to-use clear, though it does not explicitly name alternative tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds value by disclosing the auth token requirement and describing the response shape (nextAction hint, missingFields list). This contextualizes behavior beyond the structured annotations, though it could detail more about the 'nextAction' 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 two sentences, front-loaded with the core purpose and response details, followed by the auth requirement. Every word adds value, with no redundancy 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?

For a read-only single-resource getter, the description covers the return content, conditionality (if incomplete), and auth requirements. No output schema exists, so the description carries the burden and does so well. Minor gaps like the meaning of 'nextAction' or state transitions prevent a perfect score, but overall it is complete enough for effective tool selection.

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

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

The input schema has 100% coverage with a clear description for applicationId, including guidance to use listStayApplications. The tool description adds no additional parameter-level meaning, but since the schema already fully explains the parameter, the baseline 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 the tool gets the full current state of one Stay Application, specifically naming the nextAction hint and missingFields list. This distinguishes it from sibling tools like listStayApplications (which lists applications), getCoworkingApplication, and getExperienceApplication by using the explicit resource 'Stay Application' and unique response details.

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 when you need the complete state of a specific stay application, including next steps and missing fields. The parameter schema adds 'use listStayApplications to find it', giving a clear path to obtain the required ID. However, there is no explicit exclusion of alternative tools, so it falls short of a full 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?

Annotations already mark the operation as read-only and non-destructive; the description adds a meaningful behavioral detail by stating the id parameter searches both EntryId and StayId fields. However, this contradicts the input schema's parameter description, and return format/pagination are not mentioned, so it is not a perfect score.

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, front-loaded sentence with no filler. Every word contributes meaning: it states the action, scope, and a key search behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple one-parameter read tool with strong annotations (readOnlyHint=true) and a description that clarifies the search scope. Without an output schema, 'full details' sufficiently conveys the response type, though a bit more detail about response structure or common use cases would make it fully complete.

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

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

The schema already provides a description for the only required parameter (100% coverage), so the baseline is 3. The tool description adds that the id searches both EntryId and StayId, but this conflicts with the schema's statement that it 'searches the EntryId field,' creating ambiguity rather than purely adding 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 identifies the action ('Returns full details') and the specific resource ('a single stay'), and distinguishes this tool from sibling listing/search tools by noting it operates on a single ID and searches both EntryId and StayId fields.

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?

Use is implied: call this when you have a stay identifier and need full details. However, there is no explicit guidance on when to choose this over similar sibling tools like getMyStayDetail or getStaysByLocation, and no exclusion criteria.

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 establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral details—that the tool searches both stay-level (tbStayFacilities) and room-level (tbRoomFacilities) references and supports two match modes—which goes beyond annotation information.

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 three sentences long, front-loaded with the main purpose, and every sentence adds value (purpose, match behavior, optional filter). There is no redundancy or 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?

Despite lacking an output schema, the description sufficiently covers the tool's operation: it identifies what is searched, the two scanning levels, the matchType behavior, and the optional WiFi speed threshold. For a read-only search tool with these parameters, this is complete.

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 parameters are well-documented. The description enriches the schema by explaining the dual-level search scope (referencing tbStayFacilities and tbRoomFacilities) and clarifying the matchType semantics, adding context not present in the parameter 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 opening sentence 'Find all stays that have specific amenities' uses a specific verb and resource, and the subsequent detail about searching both stay-level and room-level amenities clearly defines the tool's scope, distinguishing it from amenity-specific siblings like getStaysByWiFiSpeed.

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 instructions on using matchType 'any' vs 'all' and the optional minWifiSpeed filter, giving clear context for when to apply these options. However, it does not mention alternative tools for amenity-specific searches or exclusions, so it falls short of full 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds behavioral context by stating that country is optional and can search globally, which is not directly inferable from the schema alone. The example queries further clarify how the budget and duration parameters are interpreted together.

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 three sentences long, front-loaded with the core purpose, and includes two illustrative examples without any fluff. Every sentence earns its place, and the structure flows naturally from the primary function to optional parameters to concrete usage scenarios.

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 covers the essential aspects: what the tool does, the optional country filter, and example queries. It does not explain the return format or the limit/checkInDate parameters, but those are documented in the schema. Given the existing schema coverage and the tool's search-oriented nature, the description is sufficiently complete for an agent to select and invoke it 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?

The input schema has 100% parameter coverage, so the baseline is 3. The description exceeds this by providing example mappings (e.g., '1 month under EUR 1000' translates to durationDays=30, maxPrice=1000, currency='EUR'), which clarifies how the parameters interact. It also reinforces that countryCode is optional, adding meaning beyond the schema's field 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 the tool's function: searching for stays within a budget for a given duration. It distinguishes itself from sibling tools by focusing on budget as the primary filter, and the examples ('Find me somewhere to stay for 1 month under EUR 1000') make the purpose immediately actionable.

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 clear context on when to use the tool (budget-based searches) and highlights that country is optional, enabling global or country-specific queries. It does not explicitly name alternatives or exclusions, but the example queries effectively illustrate the intended use cases, making it easy for an agent to infer when this tool is appropriate.

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 provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context ('from the NomadStays database') but does not disclose details like default pagination or return format, which is acceptable given annotations cover the key behavioral trait.

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 two short sentences with the main purpose in the first sentence and continent examples in the second. No redundant words or repetition; every word 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?

For a simple read-only filter tool with two parameters and no output schema, the description is sufficiently complete. It explains what is returned and how to search, while the schema handles parameter details. It does not mention other filter alternatives, but that is not necessary for this tool's functionality.

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 baseline is 3. The description adds continent examples, but the schema already defines 'continent' as 'Continent name or partial match' with examples, so the added value is marginal. The 'limit' parameter is not mentioned in the description but is fully explained 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 clearly states the tool 'Returns stays from the NomadStays database filtered by continent,' using a specific verb and resource. It also provides continent examples, which distinguishes it from sibling tools like getStaysByCountry or getStaysByAmenities.

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 gives clear context: it is used when searching stays by continent name. It does not explicitly mention alternatives or when-not-to-use, but the continent filter is unambiguous and the examples make the usage obvious.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds a useful behavioral detail: partial country names are matched (e.g., 'Antigua' matches 'Antigua and Barbuda'). It doesn't discuss pagination or limits, but with annotations covering safety, this is adequate.

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 two sentences, front-loaded with the main action, and every word earns its place. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only search tool, the description covers the essential aspects: entity, search criteria, and matching behavior. The lack of an output schema is not a major gap since the intent is clear, though the return structure is not described.

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 baseline is 3. The description adds example values for countrycode and clarifies partial matching behavior, but does not add meaning for the limit parameter beyond what the schema already states.

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 'Returns stays from the NomadStays database' with a specific verb+resource. The tool name 'getStaysByCountry' and the search criteria (country code or name) distinguish it from sibling tools like getStaysByContinent and getStaysByLocation.

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 clearly implies use when filtering by country, with explicit examples of accepted inputs. However, it does not explicitly exclude or contrast with alternatives like getStaysByContinent or getStaysByLocation, making the guidance clear but not fully explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's added note that 'each stay can belong to multiple lifestyle categories' provides useful result-set semantics that help interpret duplicate appearances. This goes beyond structured fields and does not contradict any annotation.

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 two sentences, front-loaded with the primary function and quickly adds the multi-category nuance. Every word contributes meaning, with no filler or redundant 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 tool is a straightforward read-only list filter. The combination of schema (with parameter details), annotations (read-only, safe), and a clear description fully covers usage. No output schema is needed for this simple list operation, and the description provides sufficient context for an agent to invoke it 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?

Both parameters (lifestyle and limit) have detailed schema descriptions with 100% coverage. The schema explains the partial-match behavior and default limit, while the tool description only repeats examples and adds no new parameter semantics. The baseline of 3 is appropriate since the schema carries the full load.

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 uses the specific verb 'Returns' and identifies the resource as 'stays from the NomadStays database', filtered by 'lifestyle/genre category'. It includes concrete examples that clarify the domain and clearly distinguishes it from sibling tools like getStaysByAmenities or getStaysByBudget, which filter by different criteria.

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 establishes this tool as the lifestyle-based filter for stays, and the parameter description directs users to the getAllLifestyles tool for valid categories. It does not explicitly state when not to use it or name alternative filtering tools, but the context is clear enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description adds behavioral context by specifying the multi-field search behavior, which helps the agent understand the tool's flexible matching semantics. It does not contradict annotations, and the added detail is useful beyond the structured fields.

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 two sentences with no redundancy. It opens with the primary purpose, then details the fields and provides concrete usage examples, all in a compact format that respects the agent's attention.

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 two simple parameters, no output schema, and read-only annotations, the description provides sufficient context for a tool of this complexity. It communicates what is returned (stays), the search scope (fields), and when to use it. Minor omissions like return format or pagination are not critical given the simplicity and the presence of a 'limit' parameter.

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% (both 'location' and 'limit' have descriptions). The tool description essentially repeats the schema's examples and field list, adding no new parameter-level meaning. Per the calibration baseline, a score of 3 is appropriate when the schema carries the parameter documentation burden.

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 'Returns stays from the NomadStays database that match a location search term', using a specific verb and resource. It also lists the exact fields searched (City, State, location_name, location_country, location_description), distinguishing it from sibling tools like getStaysByCountry or getStaysByContinent which likely use more structured filters.

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 says 'Use this for flexible location searches' with examples like 'Paris', 'California', 'Beach', 'Mountain', providing clear guidance on when to choose this tool. However, it does not explicitly mention when not to use it or name alternatives (e.g., use getStaysByCountry for exact country matches), leaving some ambiguity among the many getStays* siblings.

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

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

Annotations already declare readOnlyHint:true and destructiveHint:false, covering the safety profile. The description adds the 'listed and not suspended' filter, which is useful context, but does not disclose other behavioral details like pagination, response format, or default limits. Since annotations cover the main safety aspects, the description provides moderate additional value.

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 sentence that front-loads the core filter criteria and contains no extraneous words. Every piece of information is relevant and clearly structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only filter tool with two optional parameters and no output schema, the description covers the essential purpose and filtering criteria. It omits mention of limit/pagination behavior, but the schema documents the limit parameter, and the annotations cover safety. A brief note on result ordering or pagination would make it more complete, but it is adequate for the tool's simplicity.

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% for the two parameters, and each has a clear description. The description adds semantic value by specifying 'greater than' for minWiFiDownloadSpeed, clarifying an exclusive comparison, and it highlights the default threshold (10Mbps). This goes beyond simply restating 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 explicitly states the verb 'find', the resource 'stays', and the specific filter criteria: WiFi download speed greater than 10Mbps, plus status filters (listed, not suspended). This clearly distinguishes it from sibling tools like getStaysByAmenities or getStaysByBudget which filter by other attributes.

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 when to use this tool (when searching for stays with fast WiFi), but it does not explicitly mention alternatives or state when not to use it. Given the large number of similar sibling filter tools, explicit guidance such as 'for other filters see getStaysBy*' would improve clarity. However, the core use case is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by disclosing an authorization requirement (NOMADSTAYS_MCP_AGENT_TOKEN) that is not in annotations. It also adds domain context by referencing the target field. No contradiction with 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?

The description is a single, front-loaded sentence with no filler. It efficiently communicates the action, scope, and authorization requirement without redundant repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple no-parameter, read-only option-list tool, the description is complete. It states the output (valid values), domain context (Main Accommodation Type), and a special requirement (token). No output schema exists, but the description sufficiently informs an agent about expected behavior.

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

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

The tool has zero parameters, so the baseline is 4. The description adds semantic value by explicitly identifying the data scope (Main Accommodation Type) and the related field (stayTypeId), clarifying what the tool operates on beyond the empty 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 function with a specific verb ('List') and resource ('valid values for a Stay's 'Main Accommodation Type''). It also distinguishes itself from sibling option-getter tools by referencing the exact field (stayTypeId) and its usage in updateStayOrganisationalData.

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 clear context by linking the tool to a specific field in updateStayOrganisationalData, implying when it should be used. It does not explicitly exclude alternatives or mention when-not-to-use scenarios, but the context is sufficient for an AI agent to select it correctly among similar option-listing tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context: the draft/submitted scope, the nextAction hint values, the no-fee distinction, and the auth token requirement. It does not describe full return structure, but this is acceptable given the 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?

The description is four sentences, each contributing value: purpose, fee distinction, invocation trigger, and auth requirement. It is front-loaded with the core list action and contains no 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?

For a parameterless list operation, the description covers scope (draft/submitted), output hints, the fee-flow difference, a concrete use case, and auth. This is sufficient for an agent to select and 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?

The tool has zero parameters and an empty schema, so the baseline of 4 applies. No parameter explanations are needed, and the description correctly focuses on output and usage context rather than inventing parameter details.

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 begins with a specific verb and resource: 'List the caller's Coworking Applications (draft and submitted)'. It distinguishes Coworking from Stay/Experience by noting the absence of pay_application_fee and enumerates nextAction hint values, clearly separating it from sibling list tools.

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 gives a direct use case: 'Call this to find an in-progress application's applicationId before resuming it.' It also contrasts the Coworking fee flow with Stay/Experience. However, it does not explicitly name alternative tools (e.g., listStayApplications) for other application types, so it lacks full when-not guidance.

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 declare readOnlyHint=true, so safety is known. The description adds beyond that: it requires NOMADSTAYS_MCP_AGENT_TOKEN, scopes to the caller's own applications, and details the nextAction field with possible values. This is useful context beyond the 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?

The description is three sentences, front-loaded with purpose, then a specific use case, then an auth requirement. Every sentence adds value 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?

For a simple list tool with no output schema, the description covers the key output field (nextAction with enumerated values) and the primary use case, plus auth and scope. It does not describe pagination or sorting, but those are likely not essential.

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

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

The tool has zero parameters and the schema is an empty object with 100% coverage. The description adds no parameter details because there are none, matching the baseline for 0 parameters.

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 specifies the verb 'List' and the resource 'the caller's Experience Applications' with scope ('draft and submitted'). It distinguishes from siblings like listStayApplications by naming the specific application type and from getExperienceApplication by stating its use for finding an applicationId before resuming.

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 says 'Call this to find an in-progress application's applicationId before resuming it,' providing a clear usage context. It does not mention alternatives or exclusions, but the context is specific enough to guide an agent.

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 the tool read-only and non-destructive. The description adds that it returns all categories with specific fields (ID, name, slug, description, article count), which is useful. However, it does not disclose other behavioral traits like pagination, ordering, or error conditions beyond the 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?

The description is a single sentence that front-loads the action and resource, then concisely lists return fields. Every word earns its place with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, parameterless listing tool with annotations indicating safe read-only behavior, the description sufficiently covers what the tool does and what it returns. No output schema exists, but the field list in the description compensates. The complexity is low, so the description is complete.

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

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

The input schema is empty with zero parameters, so there is no parameter semantics to clarify. The description correctly implies no parameters are needed. Baseline for 0 params is 4, and the description does not undermine this.

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: 'List all available NomadStays Help Center categories.' It uses a specific verb (list) and resource (categories), and distinguishes itself from sibling tools like getHelpCenterArticle or searchHelpCenter by focusing on category listing, not articles.

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: use when you need all help center categories. However, it lacks explicit guidance on when to choose this over alternatives, such as using searchHelpCenter or getHelpCenterArticle for article-specific queries. No exclusions or alternative recommendations are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds valuable context: authentication requirement (token with 'bookings' scope), result details (needsAction flag, checkoutUrl), and ordering. No contradiction with 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?

The description is front-loaded with the core action and then adds necessary details (ordering, status, needsAction, usage guidance, auth). Each sentence earns its place without redundancy, though slightly long, it remains 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?

With no output schema, the description explains return values (status, needsAction, checkoutUrl), covers usage context, and states auth requirements. For a zero-parameter listing tool, it is fully complete.

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

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

The input schema has no parameters, so the baseline is 4. The description properly focuses on behavior and output, and no parameter explanation is needed.

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 uses a specific verb ('List') and resource ('all Stay bookings owned by the caller's own account'), with clear ordering ('most recent first') and content ('current status'). It distinguishes itself from siblings like getBookingStatus (single booking) and getMyStays (likely host's stays).

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 states when to call proactively ('at the start of a session, or when the member asks what's pending') and why ('there is no other way for them to be notified'), while also advising to surface needsAction bookings. This provides clear usage context with alternatives 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 indicate readOnlyHint=true, so the read-only nature is declared. The description adds value by revealing the nextAction hint behavior and the token requirement, giving extra context about what the tool returns and what's needed to call it.

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 sentences, front-loaded with the core action, and no unnecessary words. Each sentence adds useful information: what the tool lists, the nextAction hint, the use case, and the required token.

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 parameterless list tool with a read-only annotation, the description covers the essential aspects: scope (caller's applications), states (draft/submitted), the nextAction hint, the practical purpose, and authentication. No output schema exists, but the description mentions the key output fields (applicationId, nextAction).

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 are zero parameters and the schema is empty, so the baseline is 4. The description explains the response characteristics (nextAction values) which is relevant despite no parameters, and it doesn't need to compensate for schema gaps.

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 action and resource: 'List the caller's Stay Applications'. It distinguishes from sibling list tools by specifying 'Stay' and mentioning draft/submitted states and the nextAction hint, which is unique to this 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?

Provides a clear use case: 'Call this to find an in-progress application's applicationId before resuming it.' This tells when to use it, though it doesn't explicitly mention alternatives or exclusions. The context is strong enough for an agent to decide correctly.

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 only indicate readOnlyHint=false and destructiveHint=false, which are minimal. The description goes far beyond this by detailing side effects (purchase initiation), possible immediate resolution with 'waived' status, the return of a checkoutUrl, the agent's inability to pay on behalf, the need to poll for payment status, and a required auth token. This is rich behavioral context that no annotation provides.

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, with four sentences that each carry essential information. It front-loads the core action, then explains conditional behavior, the payment flow, and follow-up steps. No filler or redundant content.

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 that there is no output schema, the description handles return behavior well by explicitly mentioning the 'waived' status, checkoutUrl, and saleId. It also covers the required authentication token and the process flow (handing URL, polling). Combined with clear parameter schema, the description is sufficiently complete for an agent to select and 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?

The input schema already provides 100% coverage, including example values for productId ('use 8 for the Stay Application fee') and a clear explanation of applicationId. The description adds no direct parameter-specific detail beyond what the schema states. It does add broader context (like the waived scenario) but that doesn't alter parameter meaning. Baseline 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 the tool's purpose: 'Start a purchase of a Nomad Stays product on the caller's own behalf.' It uses a specific verb and resource, and distinguishes itself from sibling tools like getPurchaseStatus by framing it as the initiation step. It also clarifies the 'caller's own behalf' nuance, making it unmistakable what the tool does.

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 workflow guidance: it explains when the tool resolves immediately (waived status) versus when it returns a checkoutUrl, and instructs that the URL must be handed to the member (not paid by the agent). It also directs the agent to poll getPurchaseStatus afterward, effectively naming the follow-up tool. This is clear, actionable guidance for when and how to use the tool.

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 annotations, the description discloses crucial behaviors: price is always re-derived from actual pricing tiers, the tier-selection algorithm with fallback, quoteId validity of ~15 minutes, and the specific OAuth scope requirement. This significantly enriches the minimal annotations (readOnlyHint=false only).

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 but every sentence earns its place: purpose, pricing behavior, tier selection, quote validity, next step, and auth requirement. No redundancy or filler. Front-loaded with the primary 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?

Without an output schema, the description covers return value (quoteId), validity, pricing logic, fallback behavior, and required scope. It is complete for a quote tool, addressing edge cases and next steps. No major gaps.

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%, providing baseline 3. The description adds value by explaining how the parameters (e.g., checkIn/checkOut length) map to pricing tiers, and clarifies the meaning of packageId. This extra contextualization justifies a 4.

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 verb+resource: 'Get a server-computed price and availability quote for booking a Stay package'. It clearly differentiates from siblings like bookStay (which creates the booking) and checkStayAvailability (which likely only checks 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?

It states when to use the tool (before booking) and explicitly directs the caller to use bookStay with the returned quoteId for actual booking. It also explains the required OAuth scope and how it differs from other tools, though it doesn't explicitly contrast with checkStayAvailability.

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 only indicate readOnlyHint=false and destructiveHint=false, so the description adds valuable behavioral context: it must be called after getMyStayRooms, the fileNames must exactly match the current set, and it requires a specific token. This goes beyond the schema and 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?

The description is two sentences, front-loaded with the purpose and immediately giving critical constraints. Every sentence adds value without redundancy or 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?

For a mutation tool with four parameters and no output schema, the description provides all necessary context: prerequisite workflow, required token, and the critical fileNames constraint. It is complete for an agent 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?

The input schema covers all four parameters with descriptions, achieving 100% coverage. The description reinforces the fileNames constraint but does not add significantly new parameter meaning beyond what is already in the schema. 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 action: 'Change the display order of a room's photo gallery.' It specifies the resource (room's photo gallery) and the operation (reorder), which distinguishes it from sibling tools like deleteRoomPhoto or reorderStayPhotos.

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 gives explicit usage context by requiring 'fileNames must be the FULL current gallery' and instructs to 'call getMyStayRooms first.' This provides a clear precondition, though it does not explicitly name alternatives like reorderStayPhotos for comparison.

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 are minimal (all false), so the description carries the disclosure burden. It clearly states the operation is a mutation ('Change'), requires an authentication token, and emphasizes that fileNames must be the full current gallery, which indicates validation behavior. It does not describe error handling on mismatch, but overall provides meaningful behavioral context beyond the 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?

The description is three sentences, front-loaded with the primary purpose, and every sentence adds essential information (purpose, prerequisite, limitation, auth). No wasted words or repetition of schema details.

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 tool with no output schema and sparse annotations, the description covers key contextual aspects: auth requirement, prerequisite call, behavioral limitation, and correct usage. It lacks explicit success/error response details, but for a simple reorder operation this is not critical. Overall, it is more complete than many similar tool descriptions.

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