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

Annotations declare non-read-only, non-destructive, closed-world, but the description adds substantive context the annotations cannot: no Application Fee, no billing step, the nextAction state transition, and an explicit auth requirement (NOMADSTAYS_MCP_AGENT_TOKEN). It stops short of covering idempotency or what happens to a partially filled application.

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

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

Front-loaded with the core action and the sibling contrast, then the prerequisites and auth requirement, all in one dense, waste-free paragraph. Slightly long, but every clause carries information an agent needs.

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 and only 13% schema coverage, the description does the heavy lifting well: it covers authorization, the prerequisite lookup, the required field set and the resulting workflow state. The remaining gap is how create relates to save and submit siblings in the multi-step flow.

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 only 13%, so the description must carry the burden. It names the five fields needed to advance (coworkingName, applicantName, applicantEmail, city, country) and gives real semantic detail for country (exact tbCountry.CountryName, not an ID, cannot be sanctioned), but leaves address, website and telephone entirely undocumented in both places.

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?

States a specific verb+resource ('Start a new Coworking Application') and immediately scopes it against the sibling application flows by noting it lacks VAT/tourism-number/business-model rules and fees. An agent can distinguish createCoworkingApplication from createStayApplication and createExperienceApplication without opening any schema.

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?

Gives a clear prerequisite ('Call getCountryOptions first') and the completion condition (nextAction goes to 'submit' once five fields are present). It does not, however, explain the relationship to the sibling saveCoworkingApplication / submitCoworkingApplication tools, which an agent would need to sequence the workflow correctly.

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