hemmabo_host_readiness_check

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description reinforces these by stating it does not create accounts, buy domains, configure Stripe, or provision websites. It adds valuable context about input sensitivity (what counts toward the verdict and what only prefills the URL) and the no-input generic summary behavior. A 4 is appropriate because behavior is well-disclosed, though not everything is covered (e.g., exact verdict format), but the description exceeds the baseline given annotation coverage.

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 information-dense but quite long and runs on as a single paragraph. The most critical routing guidance (host vs guest) is front-loaded, but the deep parameter semantics are buried mid-paragraph and require careful reading. It earns its length given the 11 parameters and nuanced behavior, but could be better structured with separate sentences for clarity. It's not concise, but it is purposeful.

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 complexity (11 optional parameters, nuanced input semantics, output schema present), the description covers everything an agent needs: who should use it, what it returns (fit verdict, host benefits, setup inputs, next step), what it does not do, and how inputs affect the verdict. The existence of an output schema covers return value details. No critical operational detail is missing for correct 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 the schema handles basic parameter meaning. The description adds significant semantic value beyond the schema: it distinguishes 'countable' inputs (domain, currentChannels, location, wants* booleans) from prefilling-only inputs (propertyName, preferredLanguage), explains that omitting wants* booleans never lowers the verdict, and states that no inputs yield a generic summary. This is meaningful guidance on how parameters affect the tool's output, well beyond schema 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 this is a read-only fit check for hosts evaluating HemmaBo, distinguishing it from guest-oriented tools. It specifies the resource (host readiness) and the context (own booking website/engine) with precise verb 'fit check produces verdict'. It explicitly names the sibling tool hemmabo_search_properties as the alternative for guests, making differentiation 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 explicit usage criteria: use when user is a host, not a guest. It names the exact alternative (hemmabo_search_properties) and the follow-up action (hemmabo_host_onboarding_link). It also specifies what the tool does NOT do (create account, buy domain, configure Stripe, etc.), providing clear when-not guidance.

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