hemmabo_host_onboarding_link

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description reinforces and extends this by explicitly listing what it does not do: no account creation, no domain purchase, no Stripe configuration, no Supabase writes, no booking-site provisioning. It also clarifies that parameters are only prefill and never affect the landing page, and nothing is stored server-side – valuable behavioral context beyond the annotations.

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 long but every section earns its place: primary purpose, explicit alternatives, read-only safety disclaimers, parameter prefill semantics, and return-value scope. It is front-loaded with the action and audience, then handles exclusions and behavioral guarantees without repetition.

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 tool's moderate complexity, six optional parameters, rich annotations, and an output schema, the description covers everything an agent needs: when to call it, what it returns, what it does not do, how parameters behave, and how it relates to siblings. There are no meaningful gaps left for the agent to infer.

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?

Although schema coverage is 100%, the description adds important cross-cutting parameter semantics: all parameters are optional prefill, they never change the destination URL, blank values are omitted, and nothing is stored server-side. This tells the agent the six parameters collectively behave as lightweight prefills rather than affecting routing or behavior, which the per-property schema descriptions do not convey.

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 names the specific verb and resource: returning a safe HemmaBo onboarding handoff URL for vacation-rental hosts. It also explicitly contrasts it with hemmabo_search_properties and hemmabo_host_readiness_check, so the agent can distinguish it from the most similar siblings without inspecting their schemas.

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?

It states exactly when to use the tool ('after explaining the fit or when the host asks to start'), when not to use it ('Not for guests'), and which sibling to use instead for guests (hemmabo_search_properties). It also routes evaluative conversations to hemmabo_host_readiness_check, which already returns the same URL, giving explicit alternatives and conditions.

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