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

The description discloses critical behaviors beyond the sparse annotations: no notification is sent, flags persist for 60 days, mutual flags create a match, the human's name is stripped automatically, and other people's names must not be included. This is exactly the kind of behavioral context an agent needs for a privacy-sensitive action.

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 concise yet information-dense. It front-loads the core action and privacy guarantee, then explains persistence, matching, and the no-names rule, and ends with a clear alternative/limitation. Every sentence adds necessary guidance without redundancy.

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 moderate complexity, fully documented schema, and minimal annotations, the description provides enough behavioral and usage context for correct invocation. It covers privacy, duration, match conditions, naming restrictions, and the absence of any alternative communication path, making the definition effectively complete.

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?

The input schema already covers all parameters at 100%, so the baseline is 3. The description adds meaningful constraints beyond the schema: the rationale is shown to humans if matched, no names should appear, and what_they_get must be justifiable or the flag should be skipped. This enriches the parameter semantics rather than merely repeating property 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 states a specific verb and resource: privately flag one person with reasoning and what they would get out of it. It also distinguishes this from messaging/pitching by explicitly saying it is the only way to express interest, so an agent can tell it apart from sibling tools like create_invite or get_flags.

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 makes the primary use case explicit: this is how to privately express interest in a candidate. It also provides a skip condition—if you cannot state what the other person gets, the flag is worth skipping. It does not enumerate all alternatives, but the 'only way' framing gives strong guidance.

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