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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which already tell the agent this is a safe, idempotent creation with no destructive side effects. The description adds meaningful context beyond this: auto-layout behavior for missing coordinates, and the note that the result is directly openable/editable in Fluyo. It doesn't contradict annotations. It doesn't cover every edge case but adds value beyond the structured data.

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?

Three sentence description — front-loads the core purpose and output format, then adds auto-layout behavior, and closes with concrete sibling-tool references for valid values. Zero wasted words, every sentence 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?

Given 13 parameters, no output schema, and no nested objects, the description is reasonably complete. It covers the output format (.fluyo.json), the auto-layout behavior, and points to sibling tools for valid enums. It could mention the build/stagger animation behavior or the single mode, but those are documented in the schema. It's adequate for a creation tool with this parameter richness.

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 62% (8 of 13 parameters described in-schema), so baseline is 3. The description adds context on node 'key' as a temporal identifier used only within the call, and explains auto-layout positions nodes when x/y omitted. However, the description doesn't enumerate or elaborate on the many styling parameters (dots, speed, stagger, single, build) beyond what the schema already provides, so it doesn't push above baseline.

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 explicitly states it creates a complete architecture diagram in .fluyo.json format from nodes and edges — specific verb+resource+output format. It clearly distinguishes from siblings by naming edit_diagram and export_diagram as follow-up tools rather than overlapping functions. The purpose is 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: it handles auto-layout when x/y are missing, and the resulting JSON can be opened directly in Fluyo or further edited/exported. It also points to list_icons and list_templates for valid values, giving helpful usage hints. However, it doesn't explicitly state when NOT to use this vs creating from a template (create_from_template is a sibling), which would elevate it to 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?

Annotation contradiction: the description implies a mutation/write operation ('Instancia... un documento Fluyo completo, con auto-layout aplicado') creating a new document, but annotations declare readOnlyHint=true and idempotentHint=true. Creating a document is inherently a state-changing write, contradicting the read-only annotation. Even setting aside the contradiction, the description doesn't add meaningful behavioral context beyond what a brief 'creates a document with auto-layout' provides.

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 one tight sentence with a parenthetical clarification for labelOverrides. It's front-loaded with the core purpose and efficient. No wasted words, though the parenthetical could arguably be moved entirely to parameter-level documentation.

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 creation tool with 4 params, 25% schema coverage, no output schema, and annotations that contradict the described behavior, the description is under-specified. It doesn't explain the return value/result of creation, requirements around templateId validity, or how theme interacts with the template. The auto-layout note is helpful but insufficient given the write-operation nature and annotations confusion.

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 25% (only labelOverrides has a description in the schema). The tool description does add value by explaining labelOverrides as 'mapa key -> nuevo texto' which clarifies its purpose beyond the schema example. However, it doesn't add meaning for theme, pageName, or templateId beyond what the names imply. Baseline is 3 given low coverage, but the description only partially compensates.

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 ('Instancia') plus resource ('templates de list_templates') and explains what it produces (un documento Fluyo completo con auto-layout). It clearly distinguishes itself from create_diagram by focusing on template instantiation. However, it doesn't explicitly note the sibling differentiator beyond referencing list_templates.

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 ('Instancia uno de los templates de list_templates') by referencing how to get templates, which gives some contextual guidance. But it doesn't explicitly state when to choose this over create_diagram, nor provide exclusion criteria or prerequisites/alternative guidance. The context is implied rather than stated.

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 provide readOnlyHint=true and destructiveHint=false, and the description adds important context: operations apply sequentially, add_node/add_edge interact via temporary keys, and editing existing elements requires numeric IDs from the document JSON. The relayout operation's description even warns it deletes ALL manual waypoints—genuinely useful behavioral detail that complements the annotations rather than 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 a compact, densely informative paragraph with no filler. Every clause serves a purpose—listing operations, explaining ordering semantics, and clarifying the key/id mechanism. The relayout sub-description is brief but packs critical destructive behavior into one sentence. Zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 3-parameter tool with nested operation objects and 9 operation types, the description covers the core interaction model (document source, ordering, key references, id-based editing). The relayout op gets its own warning, which is the kind of edge-case disclosure needed. It could detail edge cases for other operations (e.g., what happens with invalid ids), but the description covers the essential for an agent to use it confidently. No output schema, so return-value expectations are not described, but that is acceptable given the complexity-heavy input side.

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 67% schema coverage, the description adds meaningful value beyond the schema. It explains that 'document' must be the full Fluyo JSON from create_diagram or a saved .fluyo.json file, clarifies that add_edge's 'from' can reference a temp key from the same call, and explains that existing-element edits use numeric 'id'. The parameter descriptions inside the schema for document and from also add context, though some nested fields remain 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 opens with a specific verb+resource ('Aplica una lista de operaciones... sobre un documento Fluyo existente') and lists all 9 supported operation types explicitly. It clearly distinguishes from sibling create_diagram by requiring an existing document as input, and the signature of supported operations differentiates it from read/export siblings.

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 states operations are applied in order, explains add_node can define a temporary 'key' that add_edge references within the same call, and specifies that existing nodes/edges use numeric 'id' from the document JSON. It doesn't explicitly name alternatives or say when NOT to use it, but the target usage (editing an existing document) is clear enough given sibling 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is fully covered. The description adds useful context about output format parity with the app's export and the lack of animation. However, with no annotations on return/output schema, it doesn't describe what the SVG output looks like structurally, though the parity statement partially compensates.

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 dense, front-loaded sentences covering purpose, use cases, exclusions, and the app-parity guarantee. No wasted words; every clause earns its place. The information about what is NOT available (PNG/GIF, animation) is precisely the disambiguation an agent needs.

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 export tool with 100% schema coverage and clear annotations, the description fully disambiguates the output format, parity guarantee, animation limitations, and use cases. It correctly delegates document structure details to the schema and eliminates ambiguity about which format is being produced.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are documented. The description adds value by explaining the default behavior of crop (matching app parity for identical output) and describing the document parameter as the complete .fluyo.json object referencing sibling tools create_diagram/edit_diagram. This adds context beyond bare schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what it does: renders a Fluyo document page to static SVG with identical shapes, colors, icons, fills, borders and typography as the in-app 'Exportar → SVG'. It identifies the resource (document page), verb (render/export), and output format (SVG), and differentiates from siblings by its format specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it ('útil para pegar el diagrama en Notion/Confluence/Markdown o previsualizarlo sin abrir Fluyo') and when NOT to ('no incluye animación... para el GIF animado hay que abrir el documento en Fluyo'). It also names the alternative path (opening in Fluyo for GIF/PNG) and explicitly states PNG/GIF are unavailable here.

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, idempotentHint=true, destructiveHint=false, so the safety profile is well covered. The description adds meaningful context: that animations are drawn frame-by-frame in the canvas and exported GIF, and that static SVG shows only the reference frame. This adds real behavioral value beyond 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 compact yet informative, using exactly three sentences to convey purpose, behavioral detail, and usage context. No wasted words, front-loaded with the core purpose.

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 zero-parameter list tool with strong annotations and no output schema, the description is complete. It explains what's returned (valid keys), what the animations are for, and how they manifest in different outputs. Minor gap: it doesn't describe the exact return format/structure, but for a key-listing tool this is acceptable.

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 parameters and 100% schema coverage, the baseline is 4. There are no parameters to document, and the description correctly explains the output semantics (valid keys) without needing parameter details.

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 returns valid keys for shape='anim' nodes, describing what animated GIFs are (frame-by-frame animations Fluyo draws). It distinguishes from siblings by being specifically about animation keys, complementing list_icons, list_colors, list_fonts which handle other resource types.

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 clearly when to use this tool: to get valid animation keys for anim-shaped nodes that signal states (loading, processing, error). It doesn't explicitly name alternatives/exclusions, but the sibling set of list_* tools makes the resource-type distinction implicit and clear.

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 destructiveHint=false, so the read-only behavior is covered by structure. The description adds useful context that the tool returns valid values for certain parameters and that hex values are also accepted as an alternative. It doesn't describe return format (list shape, structure) but with no output schema and a read-only, idempotent tool, this is moderate coverage.

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 conveys the purpose, the parameter fields where the values apply, and the hex fallback. Zero wasted words. The inclusion of the parenthetical about hex acceptance is valuable because it prevents unnecessary lookup calls when a user already has a hex value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only, idempotent lookup tool with sibling similar tools like list_icons/list_fonts, this description is complete. It explains what values are returned for, where they apply, and when hex bypasses the need for this tool. The only minor gap is not describing the exact format of the returned list, but for a simple listing tool this is acceptable.

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 0 parameters, so the baseline is 4. The description appropriately explains the tool involves no input and describes the applicability of outputs to specific param names. No parameter documentation burden exists since there are no parameters to document.

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 returns accepted semantic color names used in specific fields ('color', 'lineColor', 'dotColor') and that hex values are also accepted. The verb+resource ('Devuelve los nombres de color semántico') is specific, and while there's no explicit sibling differentiation, the 'list_colors' name and context (`list_icons`, `list_fonts`, etc.) make it clear this is the color-listing tool.

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 is used to look up valid color values before passing them to color-related parameters in diagram tools. The sibling tools (create_diagram, edit_diagram) would consume these colors, giving implied context. However, it doesn't explicitly state when to use this vs alternatives or 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 provide readOnlyHint=true and idempotentHint=true, so the read-only nature is established. The description adds value beyond annotations by clarifying a critical detail: the value stored in documents is the complete CSS family, not the short name displayed. It also discloses the inheritance behavior for nodes without 'font', which is useful operational context an agent needs to correctly set font values.

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 primary purpose. Each sentence earns its place: the first states what it returns and for what field, the second clarifies the storage format distinction (CSS family vs short name), and the third explains inheritance behavior. No filler 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 parameterless read-only listing tool with strong annotations, the description is nearly complete. It explains the return semantics (font families for the 'font' field), a critical storage-format caveat, and inheritance behavior. The only minor gap is that it doesn't explicitly state the return format (e.g., list of names vs objects), but with no output schema available and the tool being a simple listing, the description covers the essential context well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, so parameter semantics are trivially satisfied. Per the rubric, 0 params = baseline 4. The description appropriately focuses on the return values and their semantics rather than parameters, which is the relevant information for this parameterless listing 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 what the tool does: 'Devuelve las familias tipográficas que ofrece Fluyo' (returns typography families offered by Fluyo). It specifies the resource (font families), the verb (returns/list), and adds scope by noting it's for the 'font' field of nodes and edges, distinguishing it from sibling list tools like list_icons, list_colors, and list_anims.

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 establishes clear usage context: these are the font families for the 'font' field of nodes and edges. It adds the important behavioral note that the stored value is the complete CSS family, not the short name, and that a node without 'font' inherits the global typography. It doesn't explicitly say when NOT to use it versus alternatives, but the purpose is sufficiently distinct from sibling list tools that this is a minor gap.

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, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds useful context that it mirrors the application's drawer icons ('Son los mismos íconos que ofrece el cajón de la aplicación'), confirming parity with UI. It doesn't describe the exact return format, but with a simple read-only list tool and full annotation coverage, this is adequate.

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, dense sentence that packs the resource, the scope restriction, the group structure, and the parity with the UI drawer. It's efficient with no wasted words. Slightly more structure (e.g., separate sentences for groups and parity) could improve scannability, but it's not verbose by any measure.

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 this is a zero-parameter, read-only, idempotent tool with a fully self-explanatory purpose, the description is largely complete. It covers what's returned, the scope (shape='icon'), and grouping. The only minor gap is the return format (e.g., whether it's a flat list or nested object), but with the grouping enumerated it's reasonably inferable for a competent agent.

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 0 parameters, so there's nothing to document. The description explains what the OUTPUT will be (grouped icon keys), which compensates for the lack of an output schema. Since there are no params, the baseline of 4 applies and the description appropriately focuses on the value/format instead.

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?

Clear verb+resource: 'Devuelve las claves de ícono válidas' (returns valid icon keys) for shape='icon' nodes. It specifies the exact scope (icon keys for shape='icon'), the grouping structure (General, GCP, AWS, Azure, Estados, Varios), and differentiates from siblings since it's the icon-specific list vs list_colors, list_anims, list_fonts, list_templates.

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 states the explicit use context: obtaining valid icon keys for nodes with shape='icon'. The grouping info gives practical usage context. However, it doesn't explicitly state when NOT to use it or name alternatives (e.g., to get color options use list_colors), though the sibling names make this reasonably inferable.

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, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no behavioral detail beyond the annotation set—no mention of return format, ordering, pagination, or whether results are cached. Given strong annotations, the bar is lower, but the description contributes minimal additional behavioral context.

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?

Single-purpose, single-sentence description that is compact and front-loaded. It could arguably add a brief note about relationship to sibling tools, but as-is it is efficiently written with zero 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 zero-parameter, read-only listing tool with strong annotations (readOnly, idempotent, non-destructive), the description is sufficiently complete. It names the consuming tool (create_from_template), which is the most critical contextual link. No output schema exists, but for a listing tool the description adequately scopes the return semantic (predefined architecture patterns).

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 schema coverage is 100%, so there is nothing for parameter semantics to add. Per the rubric baseline, 0 params warrants a 4. The description correctly acknowledges this by not listing any 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?

States clearly it returns predefined architecture patterns available for instantiation with create_from_template. Verb+resource is specific, and the cross-reference to create_from_template is helpful. However, it doesn't explicitly distinguish from siblings like list_icons, list_colors, list_anims, list_fonts whose names self-evidently clarify their purpose—this one relies on the 'diagram templates' meaning which is reasonably clear in the title.

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 (get templates to use with create_from_template), naming the dependent tool. However, it doesn't explicitly state when NOT to use this vs alternatives, and there's no guidance on when you'd pick this over other listing tools. The relationship to create_from_template is the main anchoring guidance.

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