Skip to main content
Glama

createExperienceApplication

Start a new Experience Application for the caller. Any fields can be supplied now or filled in later via saveExperienceApplication — the applicant's name defaults from their Nomad Stays profile if not supplied. Call getCountryOptions and getBusinessModelOptions first to resolve experienceCountryId/postalCountryId/businessModelId, since country-specific rules (VAT number, tourism number, permitted business models) are enforced server-side and rejections name the specific field/reason. Experiences must run a minimum of 4 days. Requires NOMADSTAYS_MCP_AGENT_TOKEN.

Input Schema

NameRequiredDescriptionDefault
zipNo
cityNo
stateNo
maxPaxNoMaximum participants
mobileNo
streetNo
daysQtyNoMinimum 4 days, enforced server-side
websiteNo
commentsNo
vatNumberNoRequired if the postal country's vatNumberRequired flag is true (see getCountryOptions)
hasKitchenNo
descriptionNo
businessNameNo
hasInsuranceNo
monthlyPriceNoPrice per person (USD)
downloadSpeedNo
tourismNumberNoRequired if the experience country's tourismNumberRequired flag is true (see getCountryOptions)
applicantEmailNo
experienceNameNo
workFacilitiesNo
businessModelIdNotbBusinessModel.EntryID — use getBusinessModelOptions. If the experience country's bookingModelsRestricted flag is true, only a 'StayDirect'-prefixed model is accepted.
postalCountryIdNotbCountry.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 getCountryOptions to find a value.
applicantLastNameNoOverrides the profile default for this application only — does not change the member's profile
laundryFacilitiesNo
applicantFirstNameNoOverrides the profile default for this application only — does not change the member's profile
experienceCountryIdNotbCountry.CountryId for where the experience actually takes place — this is the country the application itself is filed under. Use getCountryOptions to find a value.
availabilitySupplierNo
overnightLocationsQtyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / businessModelId / description
      Previous value: -"tbBusinessModel.EntryID — use getBusinessModels. If the experience country's bookingModelsRestricted flag is true, only a 'StayDirect'-prefixed model is accepted."New value: +"tbBusinessModel.EntryID — use getBusinessModelOptions. If the experience country's bookingModelsRestricted flag is true, only a 'StayDirect'-prefixed model is accepted."
    • changedInput schema / properties / experienceCountryId / description
      Previous value: -"tbCountry.CountryId for where the experience actually takes place — this is the country the application itself is filed under. Use getCountries to find a value."New value: +"tbCountry.CountryId for where the experience actually takes place — this is the country the application itself is filed under. Use getCountryOptions to find a value."
    • changedInput schema / properties / postalCountryId / description
      Previous value: -"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."New value: +"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 getCountryOptions to find a value."
    • changedInput schema / properties / tourismNumber / description
      Previous value: -"Required if the experience country's tourismNumberRequired flag is true (see getCountries)"New value: +"Required if the experience country's tourismNumberRequired flag is true (see getCountryOptions)"
    • changedInput schema / properties / vatNumber / description
      Previous value: -"Required if the postal country's vatNumberRequired flag is true (see getCountries)"New value: +"Required if the postal country's vatNumberRequired flag is true (see getCountryOptions)"
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (which only say non-read-only, non-destructive, closed-world): discloses server-side country-specific rule enforcement, that rejections name the specific field/reason, the 4-day minimum, profile-based name defaulting, and the required NOMADSTAYS_MCP_AGENT_TOKEN. This is exactly the behavioral context annotations cannot carry.

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?

A single dense paragraph, front-loaded with the action, then workflow, then constraints, then auth requirement. Every clause conveys actionable information with no filler.

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?

For a 28-param, all-optional create tool with no output schema, the description covers purpose, prerequisite resolution, server-side validations, and auth. The only minor gap is that it never indicates what the successful call returns (e.g., an application ID) that a subsequent save would need.

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 28 parameters and only 36% schema coverage, the description compensates meaningfully by linking experienceCountryId/postalCountryId/businessModelId to their resolver tools and explaining the VAT/tourism/business-model constraints. It adds cross-parameter semantics, though many remaining fields (maxPax, website, comments, facilities) are left to their bare names.

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?

States a specific verb+resource ('Start a new Experience Application') and immediately positions it against the sibling saveExperienceApplication and siblings like createStayApplication/createCoworkingApplication. An agent knows exactly what this creates.

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?

Explicit workflow ordering: call getCountryOptions and getBusinessModelOptions first to resolve the ID params, and the relationship to saveExperienceApplication for later field completion is spelled out. This is when-to-use guidance with concrete prerequisites rather than implied usage.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.