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

Adds real context beyond the annotations: the submission is one-way with no reply, and there are hard privacy prohibitions (no names/emails, never patient names, DOB, medical details). This matters because annotations only say readOnly=false and destructive=false, which is easy to misread as a safe read. No rate limits or retention behavior are stated, so it is not fully exhaustive.

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?

Two sentences, front-loaded with the purpose and the accepted content types, followed by the routing/privacy constraints. The repetition of the privacy rule is deliberate reinforcement of a safety constraint, not padding.

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 single-message submission tool with an output schema present, the description covers purpose, one-way behavior, and safety constraints adequately. The remaining gap is the undescribed category enum, which the description could have disambiguated but does not.

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 67% — message and toolName are documented in the schema, while category is an undescribed enum. The description echoes the message content expectations (question, tool, confusing answer) but says nothing about the category values or when to use 'other' vs the specific buckets, so it adds only marginal value over the schema.

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?

Names a specific verb+resource ('Tell Tabflows what you looked for and could not find') and enumerates the exact kinds of gaps accepted: unanswered questions, missing tools, confusing answers. This is clearly distinguishable from siblings like ask, search, or fetch, which retrieve rather than report.

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 trigger condition ('what you looked for and could not find') and, via 'Tabflows reads these to fill the gaps and sends no reply', implicitly rules out using it when a reply is wanted. It never explicitly names an alternative such as ask for cases where the agent wants an answer, so it stops short of full when/when-not guidance.

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