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

Annotations already declare the operation is non-read-only, non-destructive, non-idempotent, and open-world, so the safety profile is covered. The description adds the useful framing that submissions are treated as research/validation signals, but says nothing about required consent/rights handling, data sensitivity, or what happens after submission.

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 tight sentences, front-loaded with the use directive. The phrase 'unless control and demand are separately established' is slightly cryptic but carries real qualification, so little waste overall.

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 14-parameter, 9-required submission tool with no output schema and near-zero schema description coverage, the description is far too thin. It should at minimum explain the consent requirement, rights_status enumeration, and the meaning of the key content fields.

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?

With 14 parameters, 9 required, and only 7% schema description coverage (just idempotency_key documented), the description must compensate and does not — it mentions no field, not consent, rights_status, economic_consequence, or country_location. An agent gets essentially no help on what to populate.

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 defines what qualifies as a bottleneck signal ('a recurring constraint or missing capability that may not yet be a formed project'), which implicitly distinguishes it from the sibling submit_project_opportunity. The verb is carried by the name/title rather than the description, and no sibling is named outright, so it falls short of a 5.

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 opens with 'Use for...' and adds a qualifier that this is a research/validation signal absent established control and demand, giving implied context. However, it never states when NOT to use it or names an explicit alternative among the six sibling submission tools, leaving the routing decision to inference.

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