get_blueprint_functions

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

There are no annotations, so the description carries the behavioral disclosure burden. The verbs 'List' and 'Returns' indicate a read-only operation, and the return structure is clearly described. It does not cover failure behavior or invalid blueprint_name handling, but for an introspective listing tool this is a reasonable level of transparency.

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 well-structured with purpose, usage, args, returns, KB link, and an example. It is mostly lean, though the return information is stated twice ('Returns each function's name...' and the 'Returns:' section), adding slight redundancy without much new value.

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 single-parameter tool with an output schema, the description covers why to use it, what it returns, a KB pointer, and an example. The main completeness gap is the unresolved blueprint_name format ambiguity and lack of edge-case behavior, but overall the tool can be invoked reasonably well.

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 schema provides no parameter description, so the description must compensate. It attempts to define blueprint_name as a 'Blueprint asset name (e.g., BP_MyCharacter)' but the example uses a full object path '/Game/MCP_Test/BP_Example'. This internal contradiction makes the accepted input format ambiguous, which is significant for a tool with only one parameter.

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 opens with a specific verb and resource: 'List all function graphs defined inside a Blueprint class.' It then states precisely what is returned: each function's name, input pins, and output pins. This clearly differentiates it from sibling tools like get_blueprint_nodes or add_blueprint_function_node.

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 gives explicit, concrete usage context: 'Use this before calling add_blueprint_function_node on a custom function, or before modifying an existing function graph.' This names a relevant sibling workflow, though it does not explicitly state when not to use the tool or mention alternative listing tools.

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