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

With no annotations provided, the description carries the full burden for behavioral transparency. It says 'Crea' and 'Registra', but it gives no concrete details about persistence, side effects, authorization, or whether the change is reversible.

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 short but under-specified. The second sentence 'Registra el módulo visible en la app' is unclear and does not earn its place because it does not clarify the tool's behavior enough to assist an agent.

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?

Even though an output schema is present, the description lacks any context about project relationships, required parameter formats, or intended selection. The description is too thin to be complete for a tool with three input fields and no 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?

The input schema has 0% description coverage, and the description does not explain 'proyecto', 'nombre', or 'descripcion'. It does not add meaning beyond the raw parameter names, so the agent cannot confidently construct valid arguments.

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 begins with 'Crea un mundo', a specific verb and resource, and the parenthetical 'Mundos -> ficha' anchors it to the app's domain. It is distinct from sibling tools like 'escribir_guion' or 'restaurar_snapshot', though the trailing clause about 'módulo visible' adds ambiguity.

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?

There is no guidance on when to use this tool, when not to use it, or how it relates to siblings such as 'proyecto' or snapshot tools. The agent is left to infer from the name alone.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It explicitly labels the operation as destructive ('EDITA (destructiva)'), states that it replaces the content of one scene, and clearly explains the guardrails: preview=true does not write, and writing requires preview=false + confirmar=true. This is strong, useful behavioral disclosure for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the critical destructive warning, and every clause contributes meaning. The safety conditions are stated in a tight, readable way without 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?

The description captures the core purpose and safety model, but it leaves some context implicit: it does not clarify how this differs from escribir_guion beyond 'UNA escena', and it does not explain the 'serie' or 'proyecto' parameters. Since schema coverage is 0%, those implicit details create a meaningful gap, though the output schema may partially compensate.

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 supply parameter meaning. It does clarify 'numero' (scene number), 'texto_fountain' (replacement content), and the preview/confirmar behavior. However, 'serie' and 'proyecto' are not explained at all, leaving important parameters under-specified for an agent.

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 ('reemplaza'), names the exact resource (one scene), and defines the selection method (by number). It clearly differentiates this from read-only siblings like leer_guion and, by the phrase 'UNA escena', from a whole-script operation like escribir_guion.

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 operational guidance: use preview=true for a dry run and set preview=false + confirmar=true to actually write. It also references escribir_guion as a sibling with the same safety model. It does not explicitly state when to choose editar_escena over escribir_guion, but the single-scene framing gives adequate context.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses the destructive nature, two-step confirmation requirement, atomic write mechanism, automatic backup, and abort behavior if the project is open in STARC. This is exceptionally 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 compact and front-loaded: the core destructive purpose appears first, followed by load-bearing safety details. Every sentence earns its place and there is 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?

Given the destructive nature and the presence of an output schema, the description covers the critical aspects: preview behavior, confirmation requirement, atomicity, backup, and STARC lock. It omits minor details like supported formats or whether 'serie' is option option, but these are inferable from defaults and the schema.

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 adds meaning for 'preview' and 'confirmar' and implies that 'source' contains the full script. However, it does not explain 'formato' or 'serie', leaving gaps in parameter understanding.

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 title 'Escribir Guion' and description 'ESCRIBE (destructiva) — reemplaza el guion completo' clearly state the action: overwrite the full script. It explicitly marks the operation as destructive and distinguishes it from partial edits like editar_escena.

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 explicit conditions: use preview=true to receive a report and prevent writing, and write only with preview=false and confirmar=true. It does not explicitly name alternatives like editar_escena for partial edits, so it misses the 'when-not' branch that would warrant 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?

There are no annotations, and the description only says the synopsis is written. It does not explain side effects, whether the document is overwritten, or the role of the preview/confirmar flags.

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 short declarative sentence with no filler. It is concise, though it accomplishes little beyond restating the tool name.

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?

A complete write tool would explain what writing the synopsis means (create vs overwrite), whether confirmation is required, and how preview behaves. None of this is covered.

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

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

Schema coverage is 0% and the description barely hints at `proyecto` (the project) and `texto` (the synopsis text). It gives no guidance for `preview` or `confirmar`, which are non-obvious.

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 identifies the action ('ESCRIBE') and the target ('la sinopsis del proyecto / documento Sinopsis'), making the tool's purpose clear and distinguishing it from related actions like escribir_guion or escribir_tratamiento, though not explicitly.

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 given on when to use this tool versus siblings such as escribir_guion, editar_escena, or how the write/preview/confirmation flow works.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'ESCRIBE' (writes), but does not disclose whether the write is destructive, whether it overwrites existing content, whether 'confirmar' is required to commit, or what the output schema contains. The presence of a 'preview' parameter and a 'confirmar' parameter suggests a two-phase write, but the description does not explain this 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 extremely short, which is concise, but it is under-specified rather than efficiently informative. It front-loads the main action but omits essential context. A single sentence can be a 5 if it carries full meaning; here it does not.

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

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

Given the tool has 4 parameters, no annotations, and an output schema, the description is incomplete. It does not explain the write semantics, the role of 'preview' and 'confirmar', or the relationship to sibling write tools. The output schema exists but the description does not clarify what the tool returns or when it is safe to 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 for the four parameters. It does not explain 'proyecto', 'texto', 'preview', or 'confirmar' beyond their names. The description adds no meaning about how 'preview' or 'confirmar' affect the write operation, leaving the agent to guess.

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

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

The description states a clear verb ('ESCRIBE') and resource ('el tratamiento del proyecto'), so an agent can tell it writes the treatment document. However, it does not distinguish this from sibling tools like escribir_guion or escribir_sinopsis, which are also write operations on project documents. The name and title are nearly identical to the description, adding little 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?

No guidance is given about when to use this tool versus escribir_guion, escribir_sinopsis, or editar_escena. The description does not mention prerequisites, such as whether the project must exist or whether a snapshot is needed before writing. An agent must infer usage from the tool name and sibling list.

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 are absent, so the description carries the full burden of disclosing behavior. It does not mention read-only status, side effects, authentication requirements, or the response shape beyond the existence of an output schema. The tool could plausibly be a fetch or a computation; the description reveals nothing.

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 fragment ('Escenas, palabras, páginas aprox., localizaciones y personajes.') – it is short but under-specified rather than appropriately concise. It does not front-load a clear operation or provide a sentence, so it is more a list of fields than a structured explanation of the tool's behavior.

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?

Although an output schema exists, the description lacks essential context for an agent to know when to use this tool over the siblings and how the parameters (especially 'serie') affect results. For a tool that returns several statistics, the description gives no overview of the calculated fields' meaning or scope, leaving the agent poorly equipped for invocation decisions.

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 2 parameters (proyecto, serie). The description neither mentions these parameters nor explains their meaning or relationship to the statistics output. With the schema itself lacking descriptions, the agent receives no semantic guidance for correct parameter use, so this is a critical 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 lists the content areas (scenes, words, pages, locations, characters) but lacks an explicit verb or phrase like 'gets' or 'returns' to state the operation. This conveys the tool is about statistics, so it is not a tautology, but it is vague and does not clearly distinguish itself from info_proyecto or snapshot without further inference.

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 no guidance on when to call this tool versus the siblings, nor any exclusions or prerequisites. It only lists data categories, leaving the agent to guess whether this should be used instead of info_proyecto, leer_guion, or snapshot in a given scenario.

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

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

With no annotations, the description carries the burden of explaining behavior. It implies a read-only information lookup by listing the returned metadata, but it does not explicitly state the absence of side effects, error behavior, or required validation.

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 short and immediately conveys the core payload. It is concise without padding, though the brevity reduces completeness in other dimensions.

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 existence of many sibling tools, one required parameter at 0% schema coverage, and no annotations, the description is not complete enough. The output schema helps with return values, but the description still leaves project identity, parameter semantics, and tool selection underspecified.

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 says 'de un proyecto' without defining the format or meaning of the 'proyecto' parameter. The agent remains unsure whether to pass a name, ID, or some other identifier.

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 phrase 'Nombres de documentos, tipos y número de escenas de un proyecto' clearly describes the resource (a project) and the content returned (document names, types, and scene count). However, it has no explicit verb and does not differentiate from siblings like listar_proyectos or estadisticas.

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 such as listar_proyectos, leer_guion, or estadisticas. It also fails to explain prerequisites like whether 'proyecto' should be an ID or a name.

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

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

With no annotations, the description carries the behavioral burden. 'Lee' signals a read operation with no obvious side effects, and the phrase 'json (lista de escenas)' discloses the JSON output shape. It does not discuss error behavior or prerequisite project existence, but this is a simple read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded; the first line states the action and target, and the 'formato:' line serves as a quick reference for valid values. There is no filler or repetition beyond a useful format reminder.

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 three-parameter tool with no schema descriptions, the description is only partially complete. It covers the core behavior and format choices, and an output schema exists for return values, but an agent cannot fully determine what `proyecto` should contain or how `serie` affects the output.

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 `formato` (markdown | fountain | json) and hints at `serie` via '(o serie)'. The required `proyecto` parameter is not defined at all, and the behavior of `serie` as a boolean is not explained.

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 concrete verb ('Lee') and object ('guion'/'serie') and explicitly lists the three output formats (markdown, fountain, json), including that json returns a list of scenes. This clearly distinguishes it from siblings like info_proyecto or listar_proyectos, which serve different purposes.

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 intended usage is implied: call this tool when you need a script or series read in markdown, fountain, or JSON. However, it never explicitly states when not to use it or names alternatives, so an agent has to infer the boundary from sibling names.

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

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

With no annotations, the description carries the behavioral burdenasi. 'Lista los proyectos .starc disponibles en el directorio configurado' clearly communicates a read-only listing over the configured directory filtered to .starc projects. It does not mention edge cases or side effects, but the verb and file-type restriction transparently convey 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?

One concise, front-loaded sentence; every phrase adds relevant scope (list operation, .starc file type, configured directory).

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 listing tool with an output schema, it covers the essential operation and scope. It could mention whether the list is sorted or limited, and it doesn't differentiate from info_proyecto, but these are minor for invoking 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?

There are zero parameters, so the schema is trivially complete. The description clarifies that 'directorio configurado' is a fixed environment context rather than an input, which avoids inventing a path parameter.

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

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

The description uses a specific verb and resource: 'Lista los proyectos .starc disponibles en el directorio configurado.' It clearly states the operation (list), the object (.starc projects), and the scope (configured directory). It also distinguishes itself from sibling tools like listar_snapshots or info_proyecto by naming the exact file type.

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 given about when to use this tool versus alternatives such as info_proyecto or leer_guion. The description implies a simple listing action, but it does not state what an agent should do with the results or when another tool would be a better choice.

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

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

No annotations are provided, so the description must carry the behavioral burden. The verb 'listar' (to list) implicitly signals this is a read-only operation and does not mention side effects, which is good. However, it does not explicitly state that it makes no changes or require no special permissions, nor does it disclose any details about the data freshness or ordering. For a non-destructive tool, this is an acceptable but not rich disclosure.

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 concise sentence that front-loads the main action ('Lista ... respaldos'), includes the file pattern, and adds a parenthetical purpose. Every part earns its place; there is zero padding or repetition of the tool name.

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 there is an output schema, the description does not need to explain return values. The one required parameter is named and related to a project, and the purpose is stated. The main gap is the lack of any behavioral annotations, since the tool relies on the description for context, but for a simple list tool this is mostly sufficient.

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 must fully explain the parameter. It literally says 'de un proyecto', which matches the parameter name 'proyecto' and adds a slight relational meaning (the backups belong to a project). However, it does not specify whether the value should be a project ID, name, or any other format. This adds little semantic value beyond the variable name itself, so the score is low.

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 clear verb and resource: 'Lista los respaldos .bak-<fecha> de un proyecto' (lists the .bak-<date> backups of a project). It also adds the purpose '(para restaurar)', which sharpens intent. It does not explicitly differentiate from siblings like 'snapshot' or 'restaurar_snapshot', but the resource and action are clear enough without opening the schema.

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

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

The description implies usage in a restoration context ('para restaurar'), giving a rough sense of when this tool is appropriate. However, it does not explicitly say when not to use it, nor does it mention alternatives like 'restaurar_snapshot' or 'snapshot'. The guidance is only implied, not explicit.

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

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

With no annotations, the description carries the behavioral burden. It states the mutation ('Pone... como portada') and adds an important constraint ('fichero dentro del allowlist'). However, it does not disclose whether an existing cover is overwritten, what permissions are needed, or how errors are surfaced.

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 states the action and the key constraint without filler. Every part 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 two-string-parameter tool with an output schema present, the description is serviceable but not fully complete. It gives the core action and the allowlist prerequisite, but leaves project identifier semantics and side effects unspecified, so an agent may need to infer conventions from sibling tools.

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 clarifies that 'imagen' is a local file within the allowlist and connects 'proyecto' to the project whose cover is being set. It does not explain the expected format of 'proyecto' (name vs. ID) or image path/file-type 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 uses a specific verb ('Pone') and names the resource ('una imagen local' as 'portada del proyecto'), so the operation is clear. It does not explicitly contrast with siblings, but none of the listed siblings handles cover images, so the purpose is still distinguishable.

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 context is clear: use this tool to set a project's cover image from a local file, and the parenthetical excludes files outside the allowlist. It does not explicitly provide alternatives or a 'when not to use' clause, but no sibling tool competes for this operation.

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

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

No annotations are provided, so the description carries the full burden. It explicitly mentions the destructive nature ('destructiva'), the abort behavior if the project is open, and the important safety net of creating a backup before replacing. This is good behavioral coverage, though it omits details about permissions, reversibility (beyond the auto backup), or response format.

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 and front-loads the most important warning ('destructiva'). It uses a compact list format, and every sentence adds value (destructive intent, abort condition, auto-backup). 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 destructive operation with no annotations and no output schema, this description is insufficient. It lacks details on parameter formats (e.g., how to specify the backup date), required permissions (though not specified), and what the response contains. The output schema exists but is not provided, so we can't rely on it. The description covers the essential safety features but leaves many operational details undefined.

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 either parameter beyond the names in the schema. The context signals indicate 0% schema coverage, meaning the schema itself provides no descriptions. The description does not compensate, leaving the agent to guess what 'proyecto' and 'respaldo' refer to, though the names are somewhat 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 tool's action: restoring a .bak-<fecha> backup onto a project. It mentions 'destructiva' to signal mutability. While it doesn't explicitly distinguish from siblings, the action is specific and the resource (restoring backups) is 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 a key usage context: it aborts if the project is openholmes. However, it doesn't explicitly state when to use this tool versus alternatives like 'snapshot' or 'listar_snapshots'. The condition 'if the project is open' is a clear prerequisite, but the description doesn't guide the agent on when to prefer this over other backup-related 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?

With no annotations provided, the description carries the behavioral burden. It explicitly states 'no modifica nada' (does not modify anything), which is the key safety trait for a backup operation, and notes the backup is date-stamped. It does not cover overwrite or storage behavior, but the essential non-destructive nature is clearly disclosed.

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 short sentence with a useful parenthetical guarantee. It is front-loaded, non-redundant, and 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 single-parameter tool with an output schema, the core action and non-modification guarantee are covered. Missing are usage context, relation to sibling snapshot tools, and parameter format details, making it adequate but not fully 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?

Schema description coverage is 0%, and the sole parameter 'proyecto' is undocumented in the schema. The description mentions 'del proyecto', indicating the parameter is the project to back up, but does not specify expected format, ID vs. name, or any constraints, leaving the agent with minimal guidance.

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

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

The description states a clear action ('Copia de seguridad' – backup) and resource ('del proyecto' – of the project), and adds that it is date-stamped. It does not explicitly name sibling alternatives, but the creation semantics distinguish it from listar_snapshots and restaurar_snapshot.

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

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

No explicit when-to-use or alternatives are mentioned. The phrase 'no modifica nada' implies it is safe for creating checkpoints, and the backup action is implied, but there is no guidance on when to choose this over listar_snapshots or restaurar_snapshot.

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