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

No annotations provided, so description carries full burden. It states that the tool creates a blueprint and returns metadata with an assigned id. However, it doesn't disclose behavioral traits like idempotency, error conditions, or resource limits. Adequate for a create operation.

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?

Description is concise: a one-line summary followed by a brief Args section and a note about return value. No fluff, but the Args section could be more structured. Still, it's efficient.

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?

Tool has 2 required parameters and an output schema, so description need not explain return values in detail. The description provides essential context: it creates a blueprint and returns metadata with id. The schema for 'data' is complex, but the description points to a README for examples, which is acceptable given complexity.

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 0%, but description explains the two parameters: 'name' is a display name, and 'data' is the full blueprint payload with a list of components. This adds meaning beyond the schema, which only provides titles. However, 'data' is described as a complex payload but details are deferred to a README, leaving gaps.

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?

Description clearly states 'Create a new Cloudcraft blueprint' with a specific verb and resource. Distinguishes from siblings like 'update_blueprint' and 'delete_blueprint' by explicitly saying 'create' and 'new'. The sibling list includes other operations on blueprints, so this description makes it distinct.

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?

No explicit when-to-use or when-not-to-use guidance, but the description implies it's for creating new blueprints. The sibling tools like 'update_blueprint' and 'delete_blueprint' provide alternatives, but no exclusions or prerequisites are mentioned. Adequate but minimal.

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

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

Since no annotations are provided, the description fully carries the burden of behavioral disclosure. It clearly states the destructive and irreversible nature of the tool, which is critical for an AI agent to understand before invocation.

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 extremely concise: one line for purpose and a warning, plus a single parameter doc line. No unnecessary text, front-loaded with the critical irreversible warning.

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 simple tool with one parameter and an output schema (implied), the description is complete. It covers purpose, usage guidance, behavioral transparency, and parameter meaning. No gaps given the tool's simplicity.

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 description mentions 'blueprint_id: Blueprint UUID', adding context that the parameter is a UUID. Given that schema description coverage is 0%, this helps clarify the parameter meaning beyond the schema, though it could provide more detail like format or example.

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 clearly states the action 'delete' on the 'blueprint' resource. It is unambiguous and distinct from sibling tools like 'create_blueprint' or 'update_blueprint'.

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?

Explicitly warns that the operation is irreversible and advises confirmation before calling. This provides clear guidance on when and how to use the tool, distinguishing it from non-destructive operations.

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

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

No annotations are provided, so the description carries the full burden. It explains the parameters and return value well, but does not disclose side effects (e.g., file creation on disk, permission requirements, or any destructive behavior). The description is accurate and non-contradictory.

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 bullet-like Args and Returns sections, front-loading the core action. Every sentence provides essential information; no fluff. It's concise yet comprehensive.

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?

Given the tool's complexity (5 params, 1 required, no enums, has output schema), the description covers the action, parameters, and return format adequately. It doesn't explain file overwrite behavior or disk space implications, but these are minor. The output schema exists but the description still explains return values, which is helpful.

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 description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains each parameter's purpose, allowed values (format options), and constraints (scale/transparent for PNG only). The output_path default is specified. This compensates for the lack of schema descriptions.

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 clearly states the tool renders a Cloudcraft blueprint to an image file on disk, specifying the verb 'render' and the resource 'blueprint image'. It distinguishes itself from siblings like get_blueprint (which likely returns JSON) and snapshot_aws (AWS snapshot).

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?

The description provides default values and allowed formats but does not explicitly state when to use this tool versus alternatives like get_blueprint or list_blueprints. The return format is described, but no guidance on prerequisites or when not to use is given.

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

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

No annotations provided, so description carries full burden. It describes the return payload components but doesn't mention read-only nature, performance implications, or any side effects. Adequate but not comprehensive.

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?

Description is concise, with a one-line summary and clear Args section. No wasted words, though the docstring style is slightly more verbose than necessary.

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?

Given the tool has only one parameter and an output schema, the description is mostly complete. It covers purpose and parameter source. Could add return format details or pagination/limits, but output schema may cover that.

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 0%, and description adds meaning for the one parameter (blueprint_id) by referencing list_blueprints to obtain it. However, it doesn't specify format or constraints beyond what the schema shows (string).

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 it fetches the full blueprint payload, listing components like nodes, edges, groups, and layout. This is clear and specific, but doesn't explicitly differentiate from siblings like list_blueprints which lists metadata only.

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?

The description implies usage when a full blueprint is needed, but provides no when-not-to-use or alternative guidance. It references list_blueprints for obtaining the ID, which is helpful context.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states the tool lists accounts, which is a read-only operation, but does not describe any behavioral traits like output format, pagination, or error conditions. A score of 3 is adequate but not comprehensive.

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 a single, clear sentence with no wasted words. It is front-loaded with the action and resource.

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?

The tool has no parameters, has an output schema, and is simple. The description is complete enough for its simplicity, though it could mention that the output schema provides details of the accounts.

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% (no parameters), so there is nothing to add. The description correctly indicates the tool has no parameters, which is sufficient. Baseline 4 is appropriate given no param info is needed.

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 uses a specific verb ('List') and resource ('AWS accounts registered with Cloudcraft'), and it distinguishes the tool from siblings by specifying the purpose ('for live-scan snapshots'). It clearly separates this from other tools like 'snapshot_aws' which triggers a snapshot.

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?

The description implies usage context (listing accounts for snapshots) but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or alternatives are mentioned.

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

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

With no annotations provided, the description carries full burden. It states the tool is a read operation returning a compact summary with specific fields (id, name, tags, updatedAt). This is adequate transparency for a listing tool.

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 two sentences, front-loaded with the primary action, and every sentence adds value. No wasted words.

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?

Given zero parameters and an output schema exists (handling return value explanation), the description is complete. It tells the agent what the tool does, what it returns, and how to proceed next.

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 description coverage is 100% (no parameters), so baseline is high. The description adds context by explaining what the output contains (compact summary) and the specific fields, which is helpful beyond an empty schema.

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 uses a specific verb ('List') and resource ('Cloudcraft blueprint (diagram)') and clarifies scope ('in the authenticated account'). It clearly distinguishes from siblings like 'get_blueprint' by noting this returns a summary, not full node/edge JSON.

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?

The description explicitly states to use 'get_blueprint' afterwards for full details, providing clear guidance on the tool's role in a workflow. However, it does not mention when not to use it or any alternative among siblings.

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

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

No annotations are provided, so the description carries full burden. It mentions 'live-scan' implying real-time data retrieval, but does not disclose potential side effects, permissions, rate limits, or whether it modifies state. Annotations would have helped, but the description adds some context beyond the schema.

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 concise, with a clear one-sentence summary followed by parameter explanations in a standard docstring format. No unnecessary words, but could be slightly more structured (e.g., bullet points).

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?

Given the complexity (3 parameters, no annotations, but has output schema), the description adequately explains the tool's purpose and parameters. It references a sibling tool (list_aws_accounts) for account_id, which helps. The output schema exists, so return values need not be described.

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 0% (no descriptions in schema), so the description must compensate. It explains each parameter: account_id (from list_aws_accounts), region (with example), and service (with examples). This adds significant meaning beyond the schema's bare property names.

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 clearly states it takes a 'live-scan snapshot' of an AWS service via Cloudcraft, specifying the exact action (snapshot) and resource (AWS service). This distinguishes it from sibling tools like create_blueprint or export_blueprint_image.

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?

The description implicitly indicates this is for scanning live AWS services, and the mention of list_aws_accounts for getting account_id provides cross-reference. However, it does not explicitly state when not to use it or mention alternatives.

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

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

No annotations are provided, so the description must fully disclose behavior. It states the update replaces the full payload (destructive overwrite), which is critical. However, it doesn't mention idempotency, version conflicts, or whether existing fields not included in data are cleared, leaving some behavioral gaps.

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 two short sentences, front-loaded with the primary action, and includes a concise bullet list for parameters. Every sentence adds value without redundancy.

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?

Given the complex schema (nested objects) and no annotations, the description provides essential behavioral context (full replacement) and references the creation schema for data shape. An output schema exists, so return values aren't needed. Minor gap: no mention of versioning or conflict handling.

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 description adds meaning by stating 'data' must be the full blueprint payload with the same shape as create_blueprint, which the schema alone doesn't clarify. Schema description coverage is 0%, so the description compensates. However, the blueprint_id parameter is minimally described as 'Blueprint UUID'.

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 clearly states it replaces the full data payload of an existing blueprint, using specific verbs and resources ('Replace the full data payload of an existing blueprint'). This distinguishes it from siblings like create_blueprint (creates new) and delete_blueprint (deletes).

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?

The description implies this tool is for updating an existing blueprint, contrasting with create_blueprint for new ones. It notes the 'data' parameter must have the same shape as create_blueprint, guiding reuse of the creation schema. However, no explicit when-not-to-use or alternative suggestions for partial updates are given.

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

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

No annotations provided, but description indicates a read-only operation returning profile info. It does not mention side effects, but with zero parameters and output schema, the behavior is well-understood. The description is clear enough for a simple tool.

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 short sentences with no fluff. The first sentence states purpose, the second provides usage context. Highly efficient.

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?

Given zero parameters and an output schema, the description is complete. It explains what the tool does and when to use it. No missing information for effective use.

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 has no parameters and 100% coverage, so description need not add parameter info. It correctly omits parameter details since there are none.

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?

Clearly states the tool returns the user profile for the current API key. The verb 'return' and resource 'user profile' are specific. However, it does not differentiate from siblings since no other tool returns user info.

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?

Explicitly states it's useful as a sanity check after configuring a new key, providing clear context for when to use it. No alternatives or exclusions are mentioned, but given no other sibling does this, it's sufficient.

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