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

With no annotations, the description carries the full burden of behavioral disclosure. It transparently states that the email is shared with Stobox, that consent is required, that a specialist will contact the user, that a confirmation and next steps are returned, and that the agent must never invent an email. This exceeds the typical level of disclosure.

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 a single dense paragraph, but every sentence contributes either a purpose, a condition, or an exclusion. It is front-loaded with the core action and then adds guardrails. Slightly long but appropriately detailed for a tool with consent/privacy implications.

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 there is no output schema, the description explicitly states the return value ('confirmation + next steps'). It covers prerequisites, exclusions, data handling (email sharing with consent), and the do-not-invent rule. This fully equips the agent to use the tool appropriately.

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 high (83%), so the baseline is 3. The description adds important behavioral context beyond the schema: it emphasizes that email is required and must come from the user ('Never invent an email; ask the user for it first'), and that asset_type must be the user's stated intent. This goes beyond the schema descriptions, earning a 4.

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 opens with a specific verb and resource: 'Send the user's request to start tokenizing their real-world asset to the Stobox team.' It clearly distinguishes from the sibling search/lookup tools by saying 'Do NOT call for general questions — use the search/lookup tools for those.' This is a specific, well-scoped action.

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?

Provides explicit criteria for when to call: 'ONLY when the user explicitly wants to BEGIN... has told you what asset... and consents to be contacted.' It also explicitly lists exclusions ('Do NOT call for general questions') and names the alternative tool category (search/lookup tools). This is exemplary guidance.

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