Picorn

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

Annotations already declare readOnlyHint and openWorldHint, so the bar for added behavior context is lower. The description adds 'live' (suggesting real-time data) and 'fair-use limits' (implying quota awareness), which are useful behavioral disclosures beyond the annotations. No contradiction exists.

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, compact sentence that front-loads the verb and clearly itemizes the output categories. Every word adds value, with no redundancy or 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?

Given no parameters, no output schema, and a simple listing behavior, the description covers the essential information. It names all the capability categories returned, which is sufficient for a tool of this simplicity. It does not describe the response structure, but that is not critical for a capabilities list.

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 tool has zero parameters, and the schema coverage is 100% (trivially). Baseline for zero parameters is 4. The description does not need to compensate for missing schema details, and it appropriately describes what the tool lists.

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's function with a specific verb 'List' and explicitly enumerates the resource categories (canvas formats, fonts, layouts, image models, GPU reachability, fair-use limits). This distinguishes it from sibling tools which are all action-oriented (design, edit, render, etc.).

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 as a discovery/preflight tool (e.g., to check available formats or limits before other operations), but it does not explicitly state when to use it or mention alternatives. No exclusions or contextual triggers are provided, leaving usage mostly implicit.

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?

The description discloses key behaviors: it uses generated or researched imagery and returns an inline preview and public creationUrl. Given annotations already indicate non-read-only and open-world behavior, this adds meaningful context about output format and external dependencies without contradicting metadata.

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 three concise sentences, front-loaded with the core action, followed by usage guidance and return value. Every sentence adds value with no unnecessary repetition.

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 tool with six parameters and no output schema, the description adequately covers the purpose, output, and usage context. It could provide more detail on parameters or limitations, but the schema fills most gaps. The mention of preview and creationUrl gives a clear picture of the result.

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 does not explain individual parameters, but the schema itself has 67% coverage with descriptions for most properties. The description adds little beyond schema, so the baseline of 3 is appropriate.

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's function: converting a topic into a finished social image with generated/researched imagery and real typography. It distinguishes itself from siblings by explicitly being the 'best default for ready-to-share work', giving it a specific and unique purpose.

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 phrase 'Best default for ready-to-share work' provides clear guidance on when to use this tool, implying it is the preferred choice for creating final images. However, it does not explicitly mention alternatives or exclusions, so it lacks full comparative 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?

The description adds return behavior ('inline preview and public creationUrl') which is useful and beyond the annotations. However, it does not disclose potential side effects, whether the original is modified, auth requirements, or rate limits. Given the annotations already flag readOnlyHint=false and openWorldHint=true, this additional context is moderate, not rich.

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 exactly two sentences: the first states the action, the second states the return values. There is no fluff, and the information is front-loaded with purpose. Every word earns its place.

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 7-parameter tool with no output schema and minimal annotations, this description is too sparse. It omits parameter semantics, input constraints (e.g., whether imageUrl or imageBase64 is required), and any behavioral details beyond the return. The core purpose is clear, but the description does not sufficiently empower an agent to invoke the tool correctly.

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 0%, so the description must compensate for explaining the 7 parameters. It does not explain any of them, leaving the agent to guess the meaning of 'cfg', 'steps', 'preview', and the relationship between 'imageUrl' and 'imageBase64'. While some names are self-explanatory, the description adds no semantic value over the raw 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 clearly states 'Transform an existing image with Flux 2 Klein' and the title reinforces 'edit an existing image'. This gives a specific verb and resource, and it differentiates from image generation siblings like picorn_generate_image by explicitly mentioning 'existing 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 provides clear context that this tool is for editing existing images, which implies it should be used when an image already exists rather than generating a new one. However, it does not explicitly name alternatives or when-not-to-use conditions, so it stops short of a 5.

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?

Beyond the annotations (non-read-only, open world), the description discloses that position is the layer CENTER, that SVG maps to an image layer with isSvg:true, and that the changed slide is returned as an inline preview automatically. These are meaningful behavioral details not present in the structured data, and there is no contradiction with annotations.

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, well-structured block that leads with the core action, then packs essential details (supported types, position rule, field compatibility, return behavior) without redundancy. Every sentence adds value, making it appropriately sized for the tool's complexity.

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 a complex nested layer object, no output schema, and sparse annotations, the description covers the most critical aspects: valid layer types, positioning rule, accepted fields, SVG handling, and automatic preview. It is sufficiently complete for an agent to use the tool correctly without further clarification.

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 only gives a minimal description for the 'layer' object, but the description enriches it significantly by listing supported types and the full set of accepted persisted fields (transforms, opacity, blendMode, text styles/effects, image filters, shape gradients, QR styling, timeline ranges, trims, volume, keyframes). This context far exceeds the schema's coverage of only 33%.

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 starts with a specific verb+resource ('Add a native editor layer') and enumerates supported types (text, image, shape, group, qr, video, audio), clearly distinguishing it from sibling tools that update, delete, or group layers. It also clarifies the position semantics and SVG handling, leaving no ambiguity about what the tool does.

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 clear context for when to use the tool, listing supported layer types and noting that SVG uses an image layer with isSvg:true. It does not explicitly name alternatives like update_layer or delete_layers, nor does it state when not to use it, so it falls short of a 5.

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?

The description adds behavioral context beyond the annotations by stating the 20-slide limit and that the new slide is returned as an inline preview. However, it does not describe what happens when the limit is reached, whether existing slides are affected, or any error conditions. Since annotations only indicate readOnlyHint=false, the description provides adequate but not rich 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 two sentences long, front-loaded with the primary action, and contains no filler. Every sentence adds value: one states the action and resource, the other states the limit and return format. This is appropriately concise and well-structured.

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 a nested `background` object, three parameters, and no output schema, the description is incomplete. It does not explain the semantics of `role` or `background`, nor does it clarify how to interpret the returned inline preview or handle edge cases. The description establishes basic purpose but leaves significant gaps for an agent to invoke the tool correctly with full parameters.

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 has zero description coverage and the description does not explain the `role` or `background` parameters. While `projectId` is implicitly clear from the phrase 'editor project', the purpose and structure of the optional parameters remain unexplained, leaving the agent without sufficient guidance for complex inputs.

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's function with a specific verb and resource: 'Add another slide to an editor project.' It also distinguishes itself from sibling tools like picorn_editor_update_slide and picorn_editor_delete_slide by focusing on addition, and mentions the key constraint of up to 20 slides.

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 clear context for when to use the tool: whenever another slide needs to be added to an editor project, with the caveat that projects support up to 20 slides. It does not explicitly name alternative tools or exclusions, but the purpose is distinct enough that no conflicting alternative is evident.

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 annotations providing readOnlyHint=false and openWorldHint=false, the agent knows this is a mutation within a closed world. However, the description adds no further behavioral context beyond what 'align' suggests. It does not explain how alignment is computed (e.g., which layer is the reference, how 'shared bound' is determined), nor does it disclose any side effects. The description essentially reiterates the purpose without enriching the behavioral profile.

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 sentence that leads with the action verb and includes all necessary information without any fluff. It is appropriately sized and front-loaded, making efficient use of 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?

For a simple alignment tool with no output schema and minimal annotations, the description is brief but leaves some ambiguity. It does not explain what 'shared bound' means in practice (e.g., based on selection order or a collective boundary), nor does it mention prerequisites for 'positioned layers.' The tool has only four parameters, so the description is arguably adequate but not fully complete given the lack of output schema and sparse annotations.

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 0%, so the description must compensate. It does clarify the 'mode' parameter by listing the enum values ('left, center, right, top, middle, or bottom bound') and implies that 'objectIds' refer to layers. However, it does not explain 'projectId' and 'slideId' beyond their obvious context, and it does not clarify the requirement of at least two objects. This is partial compensation, not complete.

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's function with a specific verb ('Align') and resource ('positioned layers'), and enumerates the alignment modes. It distinguishes itself from sibling tools like 'distribute_layers' and 'reorder_layers' by focusing on aligning to shared bounds rather than distributing spacing or changing z-order.

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 when to use the tool (when you want to align layers to a common edge or center), but it does not explicitly mention alternatives or provide exclusion criteria. There is no reference to sibling tools or 'when not to use' guidance, so it only meets the 'implied usage' level.

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 annotations indicating readOnlyHint=false, the description appropriately adds behavioral context: persistence, one empty slide, return values (projectId, slideId, canvas dimensions), and the critical instruction that the editorUrl must be included in the final answer. This goes beyond the annotations without contradicting them.

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 long, front-loads the primary purpose, and packs essential return-value and usage instructions into the second sentence. Every word earns its place, with no redundant 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?

Given the lack of an output schema, the description lists the key return values and the mandatory editorUrl instruction, which provides critical context for the agent. It does not detail defaults for optional parameters, but the schema's descriptions and enums cover that. The description is sufficiently complete for an entry-point create tool.

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 does not explain parameter behavior, but the input schema already provides descriptions for 5 of 7 parameters (71% coverage). The remaining two (title, aspectRatio) are self-explanatory. The description's mention of 'exact canvas dimensions' hints at width/height relevance, but the schema handles most semantics, so a baseline score of 3 is appropriate.

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 ('create') and resource ('persistent native Picorn editor project'), clearly distinguishing it from sibling tools like picorn_video_create_project or picorn_projects_create. It also states the output of one empty slide, making the tool's purpose unambiguous.

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 says 'This is the starting point for multi-layer and multi-slide work,' giving clear context for when to use the tool. It does not explicitly name alternatives or exclusions, but the starting-point framing effectively guides selection among the editor sibling tools.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds valuable context about the side effect of cleaning group references, which goes beyond the annotations' simple destructive flag.

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, front-loaded sentence that is concise and direct. It states the action and a key side effect without unnecessary 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?

The tool is a simple destructive operation with three required ID parameters. The annotations cover the destructive nature, but the description lacks explanation of parameter usage and any preconditions. It is minimally adequate but leaves gaps in parameter understanding.

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 has 0% description coverage, and the description does not explain the purpose of projectId, slideId, or objectIds. The phrase 'one or more layers' hints at objectIds but does not explicitly map to it, and no other parameter semantics are provided.

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') and the resource ('layers'), and adds scope ('one or more') plus a specific side effect ('clean their group references'). This distinguishes it from sibling tools like delete_slide and update_layer.

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 guidance is provided about when to use this tool versus alternatives, no exclusions, and no mention of alternatives. The usage is only implicitly inferred from the tool name 'delete_layers'.

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?

While annotations already flag this as destructive and non-read-only, the description adds beyond that by disclosing the cascade behavior (deletes layers) and the invariant that a project must keep at least one slide. This gives the agent important context about side effects and constraints.

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 action, and every sentence earns its place. It is appropriately concise without unnecessary fluff.

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 deletion tool with robust annotations and a minimal schema, the description covers the key behavioral aspects: what is deleted, the cascade to layers, and the invariant. Minor omissions like return values or failure handling are not critical for this tool's 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 description coverage is 0%, so the description must compensate, but it does not explain the parameters at all. The parameter names (slideId, projectId) are self-explanatory, but the description does not state which project or slide must be provided or any additional meaning beyond the schema's basic type and required flag.

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 ('Delete') and resource ('a slide and its layers'), clearly distinguishing it from sibling tools like 'delete_layers' and 'add_slide'. It also provides a useful constraint about the project always retaining at least one slide, which adds clarity.

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 the tool is for removing entire slides along with their layers, but it does not explicitly contrast with alternatives such as 'picorn_editor_delete_layers' for removing only individual layers. The usage context is clear but lacks explicit when-to-use or when-not-to-use guidance.

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?

Annotations already indicate this is a mutating operation (readOnlyHint=false). The description adds that layers must already be positioned and that three or more are needed, but it does not mention reversibility, effect on unselected layers, or return value. It provides some context beyond annotations but not substantial detail.

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, concise sentence that is front-loaded with the core action. No unnecessary words or repetition of schema details.

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 distribution operation with four parameters and no output schema, the description covers the essential purpose but omits prerequisites (e.g., layers must be within the same slide/project), side effects, and return behavior. It is adequate but leaves notable gaps given the schema's low coverage.

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 0%, so the description must clarify parameters. It explains 'horizontal or vertical' for axis and implies 'layers' for objectIds (three or more). However, it does not address projectId or slideId, leaving key context undocumented. Minimal compensation for the schema gap.

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's function: evenly distributing layers horizontally or vertically. It uses a specific verb ('distribute'), resource ('layers'), and scope ('three or more', 'horizontal or vertical'), distinguishing it from sibling tools like alignment.

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 for distribution of three or more positioned layers, but it does not explicitly contrast with alternatives like align_layers or state when not to use the tool. The condition 'three or more positioned layers' is a partial guideline but lacks exclusion or alternative references.

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?

Annotations indicate readOnlyHint=false, so the description must clarify the mutating behavior. It adds that 'all style, filter, effect, mask, and animation properties' are copied, which is useful. However, it does not mention side effects such as whether the original is unchanged, how the new layer is positioned (offset semantics), or any naming/ordering implications. This leaves some behavioral ambiguity.

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 sentence that front-loads the action and scope. Every word contributes value; there is no redundancy or filler. It is appropriately concise for a relatively simple operation.

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 5 parameters, no output schema, and only minimal annotations. The description explains the core action and copy scope but omits how offsets affect the result, error conditions (e.g., trying to duplicate a group), and the outcome (new layer ID, placement). This makes the description incomplete for an agent to invoke the tool without guessing.

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 0%, so the description must compensate for parameter meanings. It does not. The schema has 5 parameters, including offsetX and offsetY, but the description gives no hint about what offsets do or their relation to the duplicate. The sole 'including all properties' does not address positioning or the role of the required IDs. Parameter names help, but not enough to clarify semantics.

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's purpose: 'Duplicate a non-group layer...' The verb 'duplicate' and resource 'layer' are specific, and the qualifier 'non-group layer' distinguishes this from group-related operations. It also enumerates what is copied (style, filter, effect, mask, animation properties), making the intent precise.

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 defines when to use this tool: for duplicating a non-group layer. It excludes group layers, which is a useful usage constraint. However, it does not explicitly mention alternative tools for group duplication or provide additional 'when not to use' guidance beyond the non-group condition.

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?

Annotations only provide readOnlyHint=false and openWorldHint=false. The description adds meaningful behavioral detail by disclosing that grouping preserves world positions and render output and creates the same metadata group as the editor. This goes beyond the structured annotations and is consistent with the non-read-only nature of the 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?

The description is two concise sentences, front-loading the core purpose and adding one key behavioral detail in the second sentence. Every word earns its place with no fluff or repetition.

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 description covers the core purpose and an important preservation detail, but with no output schema and zero parameter coverage, it should also mention the expected return value or group semantics. It is adequate for a simple grouping operation but leaves gaps around parameter meaning and result behavior.

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 0%, and the description does not explain any of the four parameters (projectId, slideId, objectIds, name). It does not clarify what objectIds are grouped or how the optional name parameter behaves, leaving all parameter meaning to the raw 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 ('Create') and identifies a clear resource: 'the same metadata group used by the visual editor'. This distinguishes it from sibling tools like ungroup_layers and other layer operations, making the tool's purpose immediately 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?

The description provides context that the group matches the visual editor's format and preserves world positions and render output, which guides when to use it. It does not explicitly name alternatives or exclusions, but the compatibility framing implies usage for parity with the visual editor.

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 readOnlyHint=false, the description adds the behavioral detail that imageBase64 can include or omit a data: prefix, and that the returned imageUrl can be used in native layers. It does not contradict annotations, and it adds useful workflow context without restating the mutation hint.

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-loads the verb and resource, and contains no filler. It is concise yet informative, earning a high score.

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?

While the description explains the overall workflow and the primary input, it omits details on workspaceProjectId/Key and the exact relationship between imageUrl and imageBase64. With no output schema, the description could more fully specify the return structure.

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 already describes 4/6 parameters. The description reinforces imageBase64 handling but does not clarify the relationship between the input imageUrl and the returned imageUrl mentioned in the description. WorkspaceProjectId/Key are not covered, leaving a semantic gap for a parameter-rich tool.

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 imports image bytes into Picorn storage, identifying the specific action and resource. It distinguishes from siblings by focusing on import from external/agent-native generators and framing the workflow bridge, differentiating it from generation tools like picorn_generate_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 provides clear usage context: use when you have image bytes from an external generator and need to place them in Picorn layers. It frames the tool as a bridge in generator-to-editor-to-render workflows, but it does not explicitly name alternative tools or exclusion conditions.

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?

Annotations already establish readOnlyHint=true, so the description's 'Read' is consistent but not adding much beyond that. It does add value by specifying the included data (slides, layers, properties, z-index, image URL), but it does not describe return format, pagination, or potential size, leaving the behavioral profile only partially transparent.

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, front-loaded sentence that conveys the essential purpose and specific contents. Every word contributes information, 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 tool with one obvious parameter and a readOnlyHint annotation, the description is largely complete. It lists the returned data elements, which is helpful given no output schema. It doesn't cover edge cases like missing project or unsaved changes, but these are not critical for a basic inspect operation.

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 0%, and the description does not mention projectId or its semantics at all. While the parameter name is self-explanatory, the description fails to compensate for the low schema coverage, providing no additional meaning beyond the schema's basic type and required flag.

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 ('Read') and resource ('complete project'), and enumerates exactly what is included (slides, layers, properties, z-index, image URL). This clearly distinguishes it from sibling mutation tools like add/update/delete layers.

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 clearly implies the tool is for obtaining the full project state, which is sufficient context for when to use it. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.

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?

Annotations indicate readOnlyHint=false and openWorldHint=true, and the description adds behavioral context by explaining that the tool returns persistent public image URLs, creationUrl, and a canonical editorUrl that must be given to the user. It also discloses the scope of what is rendered (static layers) and what is not (video/audio), which goes beyond the annotations without contradicting them.

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 very concise, with two sentences that front-load the main action and then provide key return information. Every sentence adds useful detail without unnecessary repetition, and the structure is easy to scan.

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 medium complexity (5 parameters, no output schema), the description partially compensates by detailing return URLs and render scope, but it does not explain the structure of the response or the meaning of creationUrl. It also leaves parameter details like format and quality unexplained. Overall, it is adequate but leaves gaps that an agent would need to infer.

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 0%, so the description must compensate, but it only clarifies the slideIds parameter via 'selected or all slides.' Other parameters (format, quality, transparentBackground) are not described at all, and their semantics rely on names and schema constraints. Thus the description adds minimal value for most parameters.

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 slides through the Fabric editor pipeline, distinguishing it from the video render sibling by noting that video/audio timing remains editable data for the video editor. It specifies the resource (slides) and the action (render), making its purpose unambiguous.

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 gives clear context for when to use this tool (to render static slides) and mentions that video/audio timing is for the video editor, implying the alternative. However, it does not explicitly name a sibling tool for video rendering, so while the guidance is helpful, it lacks an explicit exclusion or alternative.

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?

The annotations indicate readOnlyHint=false, and the description adds non-obvious behavioral detail: omitted IDs are not removed but instead preserve their relative order on top. This is critical for an agent to understand the tool's partial reordering behavior, going beyond the basic write-operation hint.

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: two sentences, no filler, and immediately states the action. The key semantic detail about omitted IDs is packed into one clear sentence. It is efficiently front-loaded and easy to parse.

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 layer-reordering tool, the description fully covers the necessary behavioral nuances: the ordering convention and the handling of omitted IDs. The mutation context is provided by annotations, and no output schema is needed. An agent can confidently invoke this tool without further clarification.

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 0% schema description coverage, the description compensates by explaining the key parameter objectIds ('bottom-to-top'). However, projectId and slideId are not elaborated beyond their names, relying on obvious context. The essential ordering parameter is well covered, but the other two are left unspecified.

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 and unambiguous verb+resource: 'Set layer order.' It clearly distinguishes this tool from siblings like add_layer or delete_layers by focusing exclusively on reordering. The added detail that objectIds are 'bottom-to-top' precisely defines the intended operation.

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 explains how to use the tool by defining the order semantics and the behavior for omitted IDs ('retain their relative order on top'). This gives clear context for when to use it, though it does not explicitly name alternative tools or state when not to use it.

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?

Annotations already declare readOnlyHint=false, so the mutation nature is known. The description adds the key behavioral trait that child layers are preserved, which is critical for understanding the operation's effect. However, it does not explain side effects like re-parenting or nested group behavior.

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, direct sentence with no filler. It states the action and outcome efficiently, earning its place without unnecessary detail.

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 operation, the description captures the core effect. However, it leaves open questions about return values, whether groupId must reference an existing group, and how child layers are re-parented. With no output schema and sparse annotations, a bit more detail would improve completeness.

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 has 3 required string parameters with no descriptions (0% coverage). The description does not mention any parameters or explain how projectId, slideId, and groupId relate to the operation. With low schema coverage, the description fails to compensate, leaving parameter semantics under-specified.

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 the specific verb 'Remove' with the resource 'group' and clarifies the outcome 'preserving all child layers'. This clearly distinguishes it from sibling tools like delete_layers (likely removes children) and group_layers (creates a group).

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 the use case (removing a group while keeping children) but does not explicitly name alternatives or state when not to use it. There is no mention of how it contrasts with delete_layers or the need for a valid existing group.

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?

Annotations already declare readOnlyHint=false and openWorldHint=false, so the agent infers this is a write operation. The description adds the return behavior ('Returns the changed slide as an inline preview automatically') and enumerates what can be patched. However, it does not explain whether the patch merges or overwrites layer properties, which is important for predicting side effects.

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 action and then the return value. The list of properties is long but informative and not wasteful. There is no redundancy or 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?

Despite listing many patchable properties, the description omits key contextual details: the 'commitType' parameter is undocumented, the structure of the nested 'patch' object is unspecified, and there is no output schema to clarify the preview format. For a tool with this complexity, the description is incomplete for reliable invocation.

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 0%, so the description is the only source for parameter semantics. Although it lists editable property categories, it does not provide the exact key names or value structures expected inside the 'patch' object, nor does it explain the 'commitType' enum. This is insufficient for correctly constructing a patch call.

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 ('Patch') and names the resource ('a layer') with a comprehensive list of editable properties, including content, position, size, and more. This clearly distinguishes it from sibling tools like update_slide for slide-level changes and gives the agent a precise understanding of the tool's scope.

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 clearly implies when to use this tool: whenever you need to modify any property of a specific layer. However, it does not explicitly state when not to use it or mention alternatives like update_slide for slide properties, so it stops short of full exclusion guidance.

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?

Annotations already indicate this is a mutating operation (readOnlyHint false). The description adds that it 'returns the changed slide as an inline preview,' which is useful behavioral context beyond the annotation. No contradictions with annotations.

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 concise sentence with no redundant wording. It front-loads the action and scope, making it easy for an agent to parse quickly.

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 five parameters (including a nested object), no output schema, and sparse annotations, the description gives a high-level purpose and return behavior but lacks details on parameter formats, constraints, or how to construct the background object. It is adequate for a simple update tool but leaves gaps for full invocation.

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 0%, so the description must compensate. It does map 'background,' 'semantic role,' and 'image prompt' to the role/background/imagePrompt parameters, but it omits explanation of required projectId/slideId and the background object's nested structure. Thus partial compensation.

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's function: 'Change a slide background, semantic role, or image prompt.' The verb 'change' and the specific slide attributes distinguish it from siblings like add_slide, delete_slide, and update_layer.

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?

Usage is implied by the description—it is the tool for modifying slide background/role/prompt—but there is no explicit when-to-use guidance or mention of alternatives among the many sibling tools. The context is clear enough for basic selection, but no exclusions 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?

The description adds context beyond annotations by noting it returns an inline preview and a public creationUrl, indicating the generated image is publicly accessible. However, it doesn't disclose potential costs, rate limits, or what happens to the image after generation. It does not contradict annotations (readOnlyHint=false, openWorldHint=true).

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 main action, and contains no redundant words. It efficiently conveys the core purpose and key output details.

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 six parameters, no output schema, and no parameter explanations, the description leaves significant gaps. It mentions the return includes a preview and creationUrl but doesn't explain parameter usage or output structure. The tool is a complex generation action, so more context is needed.

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 0%, and the description provides no explanation for any of the six parameters (prompt, seed, width, height, preview, aspectRatio). Without any parameter guidance, the agent cannot infer how to set values correctly.

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 generates a raw image using Z-Image Turbo, which is a specific verb and resource. However, it does not differentiate from sibling tools like picorn_design_image or picorn_edit_image, which also generate or modify images.

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 guidance is provided on when to use this tool instead of alternatives. There is no mention of use cases, exclusions, or prerequisites.

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?

Annotations already indicate it's not a read-only operation. Description adds that it creates a container project and returns workspaceProjectId and workspaceProjectKey that must be used later, which is valuable behavioral context. Does not contradict annotations.

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-loaded with purpose, followed by a critical usage instruction. 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?

Description covers the essential purpose and post-creation usage, but lacks parameter guidance and a full return shape since there is no output schema. With sibling create tools, more explicit differentiation would help, though 'marketing' aids this.

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 0% and the description does not mention the name, brandColors, or description parameters. It does not add meaning beyond the schema, which itself lacks 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?

States specific verb+resource: 'Create a marketing project' that holds editor files and image assets. The term 'marketing' distinguishes from sibling create tools for editor and video projects.

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?

Gives clear usage context: project is a container for editor files and image assets, and instructs to keep the returned IDs together for related files. Does not explicitly mention alternatives like picorn_editor_create_project, but the 'marketing' qualifier provides differentiation.

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?

Annotations already declare readOnlyHint=true, and the description aligns with that by listing read-only items (files, assets, brand profile). It adds context beyond annotations by specifying the included fields (thumbnail, status, creation URL, editorUrl) and instructs the agent to always surface editorUrl, which is useful behavioral guidance.

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 three sentences, each earning its place: the first states the core action and scope, the second details what file entries include, and the third gives a clear user-facing directive. It is front-loaded with the action and contains 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 read-only inspection tool with no output schema, the description covers the main return contents (files, assets, brand profile, and specific fields) and provides the instruction about editorUrl. It does not explain the meaning of 'status' or the structure of the response, but given the annotations and the nature of the tool, it is reasonably complete.

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 lists two required parameters (workspaceProjectId, workspaceProjectKey) with 0% description coverage. The tool description does not explain their meaning or format, leaving the agent without clues about how to fill them. This is a critical gap for a tool with required params.

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 clearly identifies the resource: every editor file, imported asset, and the project brand profile. This distinguishes it from other project tools like picorn_editor_inspect_project by the detailed scope of what is listed.

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 inspecting a marketing project's contents, and the instruction 'Always give the user that editorUrl' provides a usage directive. However, it does not explicitly state when to prefer this tool over the similar picorn_editor_inspect_project or any other 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?

The annotation readOnlyHint=false already signals mutation, and the description reinforces this with 'Update' while adding useful behavioral context: it returns 'its complete file, asset, and brand index'. This goes beyond the structured annotations, though it does not detail side effects or failure modes.

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 well-structured sentence, front-loaded with the action ('Update'), followed by the update targets and the promised return value. There is no filler or redundant wording.

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, no parameter descriptions, and only readOnlyHint=false, the description carries most of the burden. It gives a high-level purpose and return value but fails to explain required identifiers, brand color item format, or partial-update behavior, leaving the agent without enough information to construct a correct call.

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 0%, so the description must compensate. It mentions three updatable fields (name, description, brandColors) but omits the required workspaceProjectId and workspaceProjectKey, and does not explain the structure of brandColors items. This is insufficient for reliable invocation.

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 ('Update'), identifies the resource ('marketing project'), and lists the updatable fields ('name, description, or named color scheme'). This clearly distinguishes it from sibling tools like picorn_projects_create and picorn_projects_inspect.

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 makes the context clear: use this tool to modify an existing project's name, description, or colors. It does not explicitly name alternatives or provide exclusion criteria, but the update semantics are obvious from the verb and resource.

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?

The description discloses that the tool 'Returns an inline preview and public creationUrl', adding behavioral context beyond the openWorldHint annotation. It also mentions 'real typography' processing, but does not elaborate on side effects or data persistence. No contradiction with annotations.

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 clear sentences that front-load the purpose and output. No fluff or redundancy; every word earns its place.

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 description covers the basic behavior and output but omits parameter usage, optional settings, and any guidance on when to use this tool versus sibling rendering tools. Given the minimal schema and no output schema, the description leaves important gaps.

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 provides zero information about the parameters (svg, width, height, preview). With schema description coverage at 0%, the description must compensate but fails to mention even the required svg parameter, let alone optional ones.

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 'Render your SVG through Picorn', identifying the specific verb and resource. It distinguishes from sibling tools like picorn_editor_render_project and picorn_video_render_project by focusing on SVG input.

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?

Usage is implied: use when you need to render an SVG design. No explicit alternatives or exclusions are provided, but the SVG emphasis gives a clear signal relative to sibling render tools.

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?

The readOnlyHint annotation already declares this a safe read operation; the description adds the behavioral detail that results are 'approved' shapes, indicating a curated set. No contradictions.

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 sentence that immediately states the primary action and resource, with zero filler 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?

While the core purpose is clear, the description omits any explanation of the three parameters, the meaning of 'approved', or the output format. With no output schema, the agent is left without sufficient context to construct effective queries.

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 0%, so the description must compensate. It provides examples of shape types (torn, wavy, blob, banner) that likely map to the 'style' parameter, but gives no guidance on 'limit' or 'aspect', leaving their semantics unexplained.

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 ('Find') and names the resource ('approved torn, wavy, blob, banner and other decorative shapes'), clearly distinguishing it from sibling tools like picorn_search_icons.

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 the tool is for retrieving decorative shapes for designs, but does not explicitly state when to use it over alternatives like picorn_search_icons, nor does it mention any exclusions or prerequisites.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds the 'vector icon library' context and timing but does not describe what the search returns or any other behavioral details. This is adequate but not rich.

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, concise sentence that is front-loaded with the key action and resource. 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?

For a simple read-only search tool, the description covers the essential purpose and timing. However, it omits guidance on how to effectively use parameters (e.g., query format, style restrictions), and there is no output schema to clarify return values. The description is minimally viable but leaves room for improvement.

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 has 0% description coverage, and the description provides no additional meaning for any of the three parameters ('query', 'limit', 'style'). The description does not compensate for the low coverage, leaving the agent to rely solely on parameter names and types, which are not fully self-explanatory.

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 ('Search') and the specific resource ('Picorn's vector icon library'), and adds contextual timing ('before composing a design'). This distinguishes it from sibling tools like picorn_search_areas and picorn_capabilities.

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 phrase 'before composing a design' indicates when to use the tool. However, it does not explicitly mention alternatives or when not to use it, though the context is clear enough for an agent to infer its place in the workflow.

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?

Annotations only state readOnlyHint=false and openWorldHint=true. The description adds valuable behavioral detail: it is a mutable operation (add), requires approved media host URLs, and specifies coordinate and frame conventions. It does not mention error handling or side effects, but it goes beyond the annotations meaningfully.

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 three sentences long, with the first sentence immediately stating the core action and target. The second and third sentences efficiently add essential constraints and encoding details. No words are wasted.

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?

This is a complex tool with 16 parameters, nested objects, and no output schema. The description provides a few high-level constraints but does not explain required fields, return values, failure modes, or the semantics of many parameters. It is insufficient for an agent to confidently invoke the tool without further information.

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 has no descriptions for any of its 16 parameters (0% coverage). The description compensates partially by explaining that positions are center coordinates and timing/trim values are frame-based, which clarifies parameters like position, startFrame, and trimStartFrame. However, many parameters (e.g., volume, size, transform, name) are left unexplained, so it only partially bridges the gap.

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's verb and resource: 'Add a video or audio clip to a Picorn timeline.' It also highlights that positions are center coordinates and timing is frame-based. However, it does not explicitly distinguish itself from sibling tools like picorn_video_import_media, so it lacks full differentiation.

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 by saying 'add... to a Picorn timeline,' and it provides a key constraint (source URLs must use an approved public media host). It does not explain when to prefer this tool over alternatives or when not to use it, especially given the sibling tool picorn_video_import_media.

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?

The description adds behavioral context beyond annotations, such as 'persistent' and 'real 30fps timeline', but does not disclose important traits like whether existing projects are overwritten, permissions required, or what the canonical link is used for. Annotations only indicate it is a non-read operation, so the description carries some but not full burden.

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, front-loaded sentence that conveys essential information efficiently. Every word contributes to the purpose, with no wasted text or 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?

For a tool with 9 optional parameters, nested objects, no output schema, and a mutation operation, the description is too sparse. It fails to convey how to use the parameters, what the response looks like, or how it fits into the broader video editing workflow, making the tool's full context incomplete.

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 only 22%, and the description adds no parameter details. It does not explain width, height, background, aspectRatio, or workspace identifiers, nor does it clarify the meaning of fps or durationFrames beyond what the schema already states. The mention of '30fps' is a feature statement, not a parameter explanation.

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 'Create' and identifies the resource as a 'persistent video project' with distinctive features (real 30fps timeline, native layers, keyframes, canonical /video/editor link). This clearly differentiates it from sibling tools like picorn_editor_create_project and picorn_projects_create.

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 usage is implied by the video project context, but the description does not explicitly state when to use this tool over alternatives or provide exclusions. It lacks direct contrast with sibling creation tools, so guidance is only implicit.

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?

The description adds context beyond annotations: accepted formats, size limit, and the intended use for timeline layers. However, it does not disclose the return value, side effects, or whether the upload overwrites existing media. The annotations (readOnlyHint=false) already indicate a write action, but the description could be more transparent about what the agent should expect as a result.

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 sentence, front-loaded with the action and resource, and includes key constraints (formats and size limit) without unnecessary detail. It is highly concise and structured effectively.

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 mutation tool with no output schema and minimal annotations, the description is missing critical information about the return value or how to reference the uploaded media in subsequent operations (e.g., media ID). It covers the main constraints but leaves the agent without enough context for follow-up steps.

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 67% (mediaBase64 and contentType have descriptions), and the description adds a list of supported file formats, which helps map to contentType values. However, it does not explain the 'name' parameter, which lacks a schema description. The description adds some value but does not fully compensate for the gap.

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 ('Upload') and a specific resource ('agent-owned MP4, WebM, MOV, MP3, WAV, AAC, M4A or OGG bytes') into 'Picorn storage', clearly stating the purpose ('for use by video/audio timeline layers'). This distinguishes it from siblings like picorn_video_add_clip, which adds clips to a timeline rather than uploading raw media.

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 a clear context: this tool is for uploading media assets to be used by video/audio timeline layers. It implies the usage (do this before adding clips) and implicitly excludes unsupported formats via the listed extensions, but it does not explicitly name alternatives or state when not to use it.

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 annotations only providing readOnlyHint=false and openWorldHint=true, the description adds some behavioral context: it lists what the render includes (multi-slide sequencing, timed layers, video frames, keyframe animation, mixed audio) and what it returns (a public video URL plus /video/editor link). However, it does not disclose potential side effects, whether the operation is asynchronous, cost/resource implications, or error behaviors.

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 core action and output format. The second sentence efficiently bundles inclusions and return values. No filler or redundant information.

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 render operation with 5 parameters and no output schema, the description provides a solid overview of inputs (projectId implied), what happens during rendering, and the output. However, it omits parameter-specific details (e.g., fps, quality), usage guidance, and potential blocking/async behavior, leaving gaps for an agent to invoke it correctly.

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 property descriptions), so the description must compensate. It partially explains the `format` param via 'MP4/H.264 or WebM/VP9' and `slideIds` via 'multi-slide sequencing', but it does not attribute meaning to `fps` or `quality`. The description adds some value but is insufficient for the full parameter set.

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's function: 'Render the native timeline to a finished MP4/H.264 or WebM/VP9 file.' It specifies a verb ('Render'), a resource ('native timeline'), and output formats. However, it does not explicitly differentiate from the sibling tool 'picorn_editor_render_project', leaving the distinction to names/titles rather than the description.

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 when to use the tool (for rendering a video project to a finished file) but does not provide explicit when-not guidance or mention alternatives. It lacks prerequisites, constraints, or comparisons to other render-related sibling tools.

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