Get the full current state of one Stay Application, including a nextAction hint and (if incomplete) a missingFields list naming exactly which required fields are still empty. Requires NOMADSTAYS_MCP_AGENT_TOKEN.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationId | Yes | The application's ID (use listStayApplications to find it) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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.
Add one secure layer between your agents and this server.
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.
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.
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.
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.
