add_pcg_subgraph_node

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

Annotations cover the safety profile (readOnly=false, destructive=false), so the bar is lower, but the description still adds a non-obvious caveat: a target graph with no edges from its default input will silently ignore wired data. The returns block also implies the host graph is persisted ('saved'), useful context for a mutation.

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 purpose is front-loaded before the prerequisite checks, and every clause carries information. The em-dash explanatory clause and parenthetical are slightly narrative but earn their place by clarifying intent and the input-node caveat.

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?

With no output schema, the description helpfully lists the return fields and covers prerequisites and the key behavioral gotcha. It leaves minor gaps such as idempotency on repeat invocation and behavior when the subgraph path is invalid, but nothing essential to a correct call is missing.

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 100% and both parameters are documented in the schema as host graph vs. subgraph paths. The description's 'target graph'/'subgraph' wording loosely maps to them but adds no format, constraint, or edge-case detail beyond what the schema already provides, so the baseline 3 applies.

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 gives a specific verb+resource ('Embed one PCG graph inside another as a Subgraph node') and distinguishes it from the plain node-adding siblings by explaining the reuse/library-consumption intent. An agent can tell this apart from add_pcg_node or connect_pcg_nodes without opening the schema.

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 states the context for use (reusing a scatter/filter recipe across biomes, consuming a library graph) and names two prerequisite tools to run first: get_pcg_graph_info and get_pcg_graph_parameters. It never explicitly says when NOT to use this rather than add_pcg_node, so it falls just short of the top band.

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