raynet_create_full_pipeline

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

With no annotations, the description must disclose the full behavioral profile. It does reveal a non-obvious behavior—that name-based fields are auto-resolved to IDs—and makes the mutation side effect explicit. But it omits critical side effects and failure modes: how the flat input is split across Company/Person/Lead, whether a failed BusinessCase conversion leaves the Lead created, whether duplicates are possible, and what the response contains.

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-load the composite action and keep the statement compact. The 'ALL IN ONE' and 'One call = entire sales pipeline' phrases are slightly redundant, but the description wastes little space and highlights the tool's key differentiator.

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 10-parameter mutation with no output schema and no annotations, the description leaves important gaps: no return value (does it give IDs of all created entities?), no prerequisite or dependency rules, and no explanation of how the provided fields map onto the three created objects. An agent could guess the intent but cannot confidently predict the outcome.

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 documents all 10 parameters at 100% coverage, so the baseline applies. The description adds one useful cross-cutting behavior—source/category/bc_type/bc_phase accept names and are auto-converted to IDs—but it doesn't add semantics for the remaining parameters or clarify dependencies between auto_convert_to_bc and bc_type/bc_phase.

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 concrete composite action: creates Company + Person + Lead and optionally converts the Lead into a BusinessCase. 'One call = the entire sales pipeline' reinforces the scope. It doesn't explicitly contrast with raynet_create_lead_full, so it misses full sibling differentiation, but the resource list makes the difference clear.

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 communicates a clear intended context: use this when you want the whole Company→Person→Lead→BusinessCase workflow in one call, and the optional conversion hints when a BC is wanted. However, it never names the granular alternatives (raynet_create_lead_full, raynet_convert_lead_to_bc) or states when one would choose those instead.

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