Nomad Stays

createStayApplication

Start a new Stay Application for the caller. Any fields can be supplied now or filled in later via saveStayApplication — the applicant's name defaults from their Nomad Stays profile if not supplied. Call getCountries and getBusinessModels first to resolve stayCountryId/postalCountryId/businessModelId, since country-specific rules (VAT number, tourism number, permitted business models) are enforced server-side and rejections name the specific field/reason. Requires NOMADSTAYS_MCP_AGENT_TOKEN.

Input Schema

TableJSON Schema

Name	Required	Description
`zip`	No
`city`	No
`state`	No
`mobile`	No
`street`	No
`website`	No
`comments`	No
`stayName`	No
`vatNumber`	No	Required if the postal country's vatNumberRequired flag is true (see getCountries)
`hasKitchen`	No
`businessName`	No
`monthlyPrice`	No
`downloadSpeed`	No
`numberOfRooms`	No
`stayCountryId`	No	tbCountry.CountryId for where the Stay is actually located — this is the country the application itself is filed under. Use getCountries to find a value.
`tourismNumber`	No	Required if the stay country's tourismNumberRequired flag is true (see getCountries)
`applicantEmail`	No
`workFacilities`	No
`businessModelId`	No	tbBusinessModel.EntryID — use getBusinessModels. If the stay country's bookingModelsRestricted flag is true, only a 'StayDirect'-prefixed model is accepted.
`postalCountryId`	No	tbCountry.CountryId for the applicant's billing/postal address — used only to check whether a VAT number is required, and stored on the member's business profile (not on the application itself). Use getCountries to find a value.
`applicantLastName`	No	Overrides the profile default for this application only — does not change the member's profile
`laundryFacilities`	No
`applicantFirstName`	No	Overrides the profile default for this application only — does not change the member's profile
`availabilitySupplier`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

AddedJul 31, 2026

TDQS

A4.8/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Nomad Stays tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, with detailed descriptions differentiating the many getStaysBy* search variants and the four availability tools. However, the overlap between checkStayAvailability, getRoomAvailability, findNearestAvailability, and getAvailabilityByMonth could still cause confusion for an agent, though the descriptions largely mitigate this.

Naming Consistency3/5

The tools mostly follow a verb-noun pattern with get*, update*, create*, and delete* dominating, but the mix of additional verbs (check, find, list, search, signup, book, quote, purchase, submit, save, reorder, upload) and inconsistent noun forms (Stay vs. Stays, MyStay vs. Stay) prevents a fully predictable naming scheme. CamelCase is consistent, but the verb variety is high.

Tool Count1/5

With 76 tools, this server far exceeds the well-scoped range and even the 50+ threshold for extreme mismatch. While the platform covers multiple domains, this many tools is overwhelming for an agent and would likely be better split into focused sub-servers.

Completeness3/5

The tool surface is broad, covering search, stay management, applications, bookings, products, and help center. However, there are notable lifecycle gaps: no cancel booking, no delete stay, no delete application, and no way to update or delete a booking. These missing operations create potential dead ends for common workflows.

createStayApplication

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources