import_cloudflow_flow

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

Goes well beyond the sparse annotations: create-only semantics, no publishing or schedule activation, incomplete-flag behavior for unbound connections/tables, auto-creation of global variables, table creation limited to structure, and dry-run with no writes. This gives an agent a precise behavioral model.

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 front-loaded with the core behavior and each additional sentence covers a distinct high-value aspect: restrictions, binding/requirement handling, table creation options, and dry-run validation. The length is justified by the tool's complexity with no filler.

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 complex nested bundle importer with no output schema, the description covers the main behavioral contracts, failure/validation modes, and response shape for dry-runs. It also explains tenant-scoped requirements and what happens to unbound resources, so a caller can safely attempt an import.

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 schema coverage at 50%, the description compensates by explaining bindings semantics (requirement key → target resource ID), the createMissingTables behavior, and dry-run's parameter effect. It does not mention every parameter, but the ones with non-obvious semantics are addressed meaningfully.

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 names a specific operation: 'Creates every flow of a previously exported bundle in the authenticated tenant.' It clarifies that imports are create-only with new IDs, which distinguishes it from read/list/export CloudFlow siblings without needing to inspect schemas.

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 clearly explains when to use the tool (importing a previously exported bundle) and instructs to run with ?dryRun=true first to validate and discover required bindings. It does not explicitly name sibling alternatives or state when not to use it, but the context is strong.

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