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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context: it is the only faithful copy, and it describes the return value (JSON with path and size), which goes beyond the annotations. No contradiction is present.

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 well-structured: a one-line action statement, a usage note, and a return type. Every sentence adds value, and the most important information is front-loaded.

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 only one parameter, clear annotations (read-only, idempotent, non-destructive), an output schema (implied), and a description that covers when to use it and what it returns, the tool is fully specified for an agent to call 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?

The schema already provides a full description for part_id ('ID del capitulo a respaldar') with 100% coverage. The tool description does not add further parameter-specific meaning beyond the schema, so the 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 states a specific verb (saves), resource (original HTML of a chapter), and action (to disk), clearly distinguishing it from editing tools like wattpad_update_part. It also explains its role as the only faithful copy, which further differentiates it from preview or retrieval tools.

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

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

It provides an explicit trigger: 'Do this before any massive rewriting' (Haga esto antes de cualquier reescritura masiva), giving clear when-to-use context. It does not name alternative tools, but the guidance is sufficient for an agent to decide when this backup is necessary.

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 indicate mutation (readOnlyHint=false) and no idempotency/destructiveness. The description goes further by disclosing that the response contains the id and initial text_hash, and that the part does not need to be re-read before the first save. It also notes the dry_run behavior in the Returns section.

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 front-loaded, with the core purpose in the first sentence and useful supplementary notes after. It is slightly redundant because the Returns section repeats the id/text_hash detail already mentioned, but the overall structure is efficient.

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

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

Given the 100% parameter coverage, output schema, and annotations, the description covers the essential call behavior: what is created, what the response provides, and how dry_run affects it. It is not exhaustive about auth/errors, but nothing critical is missing for correct 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 100%, so the schema already documents story_id, title, text, and dry_run. The description adds no parameter-level detail beyond the schema; its text_hash note concerns the response, not input parameters. Baseline 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 opens with a specific, unambiguous statement: 'Crea un capitulo en borrador dentro de una historia existente.' It identifies the verb (crear), the resource (capitulo/part), and the scope (dentro de una historia existente, as a draft). This also separates it from siblings such as wattpad_create_story, wattpad_update_part, and wattpad_publish_part.

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 main sentence defines the clear context for use: creating a draft chapter inside an existing story. It does not, however, explicitly name alternatives or state when-not-to-use it, so it falls short of a 5; there are no misleading usage notes.

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 annotations, the description reveals key runtime behavior: the tool hits a specific router, returns 204 without a body, does not return the story id, and requires a follow-up lookup. This materially changes how an agent should consume the result and is exactly the kind of context annotations cannot convey.

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 main purpose, and each caveat (router, 204, missing ID, follow-up lookup, tags) earns its place. The 'Returns' line is the only slightly redundant piece, but it clarifies the dry_run 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?

Given the annotations, complete schema coverage, and an output schema, the description supplies the missing operational context an agent needs: how to obtain the created story's ID and what to set before publishing. Nothing essential is omitted.

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 already documents every parameter with 100% coverage, including the tag requirement and dry_run semantics. The description reinforces the tag rule but does not add meaningful parameter-level detail beyond the schema, so the baseline of 3 applies.

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 'Crea una historia nueva y vacía', naming the exact action and resource. This distinguishes it from sibling tools like wattpad_create_part, which target parts rather than whole stories.

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

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

It provides actionable routing and workflow guidance: use the new front router, expect a 204 with no body, and later locate the story via wattpad_list_my_works. It also advises adding at least one tag to enable publishing. It does not explicitly state exclusions or compare against alternative creation tools, so it falls just 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 already mark the tool as read-only and idempotent, but the description adds substantial behavior: the exact markup token set, blank-line paragraph separation, lossless semantics, the lost list for unsupported formatting, and the rejection of truncated text by wattpad_update_part. This goes well beyond what annotations provide.

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, with the core purpose first and detailed markup behavior explained efficiently. The final Returns line is somewhat redundant given the output schema, but it is short and does not meaningfully hurt readability.

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 full annotations, a detailed input schema, and an output schema, the description still adds the missing context: editable markup format, round-trip editing workflow, losslessness semantics, and the max_chars caveat. An agent has enough information to select and invoke this 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 100%, so the baseline is 3. The description adds valuable semantics for max_chars by warning that a trimmed result cannot be used for saving, and clarifies the markup format relevant to part_id. This extra context justifies a 4.

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 specific verb and resource: 'Lee un capitulo conservando el formato como marcas.' It clearly defines the tool as a read operation that returns editable markup, and it is obviously distinct from update/create/publish 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 gives clear workflow context: read the chapter, edit the markup text, and send it back via wattpad_update_part. It also explicitly warns that a truncated max_chars output is not safe for saving. It does not name alternatives such as preview_markup, so it falls just short of a full 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it is a safe read operation. The description adds valuable behavioral context: it iterates per request (implying potential slowness), and it continues past failures by noting them and moving on. This error-handling behavior and performance characteristic go beyond what annotations convey, providing a richer model of the tool's runtime 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 concise and well-structured: it starts with the core summary, then adds a performance caveat with parameter suggestions, and finally states the return type. The front-loading of the primary purpose is effective. While it includes a bit of extra detail about error handling, that is warranted for a tool that may process many items. Overall, it is appropriately sized without unnecessary verbosity.

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 that an output schema exists (though not fully shown), the description need not detail the table columns. It covers the essential aspects: what the tool does, return format, performance considerations, and error tolerance. It does not mention prerequisites like authentication, but annotations likely cover that implicit context. Overall, it is complete for an agent to decide to call and interpret the result, especially with the parameters and return type clearly stated.

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

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

Schema coverage is 100%, so parameters are documented. The description reinforces the purpose of `limit` and `story_id` by tying them directly to the performance behavior ('use `limit` or `story_id` to narrow'). This adds semantic meaning beyond the schema's generic descriptions, such as why one would set a limit. It does not repeat the schema's details but connects parameters to practical use.

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: it summarizes reads, votes, and comments per story and per chapter. It also specifies the return format (markdown table), which distinguishes it from siblings that likely return raw data or lists. The verb 'Resume' (summarize) and the resource 'historias y capitulos' are specific, making the tool's role 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 explicit guidance on when to use `limit` or `story_id` to narrow the scope due to the tool iterating through stories one by one, which can be slow for many works. This is a practical usage guideline. It does not explicitly mention alternatives like `wattpad_list_comments` for raw comments, but the aggregated nature of the output makes the use case distinct. The performance caveat is useful for agents deciding whether to call this tool.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds that it returns a string containing the story card and chapter table, and advises using chapter IDs with another tool. This is useful but does not disclose details like pagination, authentication, or response differences.

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

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

The description is extremely concise: a one-sentence purpose, a one-sentence sibling pointer, and a return type line. No filler or redundancy; the most important information is front-loaded.

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 tool with a simple purpose, complete schema, and existing annotations, the description covers the essential workflow: it says what is returned and how to proceed to read individual chapters. Minor gaps like markdown/json differences are already handled by the schema's response_format parameter.

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 all parameters are documented in the schema. The description does not enrich parameter understanding; the only cross-reference ('Use el id de capitulo con wattpad_get_part_text') refers to the output, not input parameters. Baseline 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 states a specific verb and resource: 'Obtiene la ficha de una historia con la lista de sus capitulos' (gets the story card with its chapter list). It differentiates from the sibling tool wattpad_get_part_text by advising to use that tool for reading chapter text, so an agent can tell them apart.

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 points to wattpad_get_part_text as the alternative for reading text, implying this tool is for metadata and chapter listing. It does not cover all sibling comparisons but gives clear situational guidance for the most relevant 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return format ('JSON con biografia, obras publicadas y seguidores') and clarifies that it retrieves the public profile, which is useful. It does not contradict annotations. This matches the baseline for tools with annotation 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 two sentences: the first states the primary purpose, the second describes the return value. It is front-loaded with the action and resource, contains no filler, and every word contributes to clarity. Very efficient.

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

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

Given the tool's simplicity (one parameter, read-only, idempotent) and the presence of an output schema (the description itself notes the return format), the description is sufficient for an agent to call it correctly. It covers the return type and content. Minor gaps like error handling are not critical for a read-only getter.

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 100% description coverage for the single 'username' parameter, explaining it as 'Nombre de usuario de Wattpad' (Wattpad username). The tool description does not add any additional meaning or syntax details beyond what the schema already provides, so it stays at the baseline for fully documented 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 action: 'Obtiene el perfil publico de un usuario de Wattpad' (Gets the public profile of a Wattpad user). It specifies the resource (user profile) and the scope (public). It does not explicitly differentiate from sibling tools, but the purpose is unambiguous given the tool name and the clear resource.

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 use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions. While the purpose is obvious, there is no explicit routing to this tool over siblings like get_story or get_part_text.

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 mark the tool read-only, idempotent, and non-destructive. The description adds important behavior beyond annotations: comments come from third parties and must be treated as data, never instructions, which is a strong prompt-injection guard. It also discloses the returned content (author, date, text) inside a fence.

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 short sentences with no filler: purpose and pagination first, then the safety warning, then the return format. Every sentence earns its place and the most important scoping information is front-loaded.

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, paginated list with a fully documented schema, an output schema, and safety annotations, the description is complete. It also supplies the key contextual warning about untrusted third-party comments, which is exactly what an agent needs to handle this tool's output safely.

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 the schema already documents all parameters including defaults, bounds, and enums. The description's mention of pagination loosely maps to limit and offset but adds no parameter-level meaning beyond what the schema provides.

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 specific action and resource: 'Lee los comentarios de un capitulo' with pagination. This clearly distinguishes it from siblings like wattpad_post_comment (writing) and wattpad_get_part_text (chapter content), so an agent can identify the right tool by verb and resource.

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 read-only purpose is clear: retrieve comments for a chapter, with pagination. The warning that comments are data, not instructions, also tells the agent how to treat the output. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough that no major ambiguity remains.

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, idempotentHint, and destructiveHint, so the description adds value by disclosing the failure-handling behavior (explicitly stating errors instead of silently returning only published works) and outlining the return content. 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 concise, front-loaded with the main purpose, and includes a separate returns section. It is slightly verbose with the failure note and return format but 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?

With an output schema present and annotations covering safety, the description adds useful return-format details and error behavior. It does not mention pagination or exact metrics, but the output schema likely covers those, making the description adequate.

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 all three parameters are already documented. The description adds no new semantic meaning beyond the schema, though it reiterates the include_drafts and default username behavior. Baseline 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 lists an author's stories, including drafts of the authenticated account, with a specific verb ('Lista') and resource. It is distinct from sibling tools like wattpad_get_story (single story) and wattpad_search_stories (search), 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 implies the primary use case (listing an author's works) and notes the default behavior (authenticated account) and the include_drafts option. It does not explicitly contrast with alternatives, but the context and sibling list make it clear when this tool applies.

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 goes beyond annotations by revealing that the comment is publicly visible immediately, that the endpoint is experimental and not captured from the editor, and that it returns either the created comment or the simulated request (for dry_run). Annotations only indicate readOnlyHint false, destructiveHint false, etc. This additional context is valuable for the agent.

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

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

The description is concise, with the main action stated first, followed by important warnings and the return type. It is well-structured and does not contain unnecessary verbosity, though the warnings add a few sentences that are all relevant.

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

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

Given the tool's simplicity (3 parameters, output schema present), the description covers the essential purpose, behavioral warnings, and return type. It does not detail how to obtain part_id, but that is likely handled by other tools. Overall, it provides sufficient information for an agent to call 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?

All three parameters are fully described in the input schema (text has length limits, dry_run explains behavior, part_id specifies chapter ID). The description adds no additional parameter meaning beyond what the schema already provides. Since schema coverage is 100%, a 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 action: 'Publica un comentario en un capitulo' (post a comment on a chapter) with the authenticated account. This distinguishes it from sibling tools like wattpad_list_comments, which reads comments. The purpose is unambiguous and specific.

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 cautionary guidance, such as confirming text with the person before sending and warning that the endpoint is experimental and unverified. However, it does not explicitly state when to use this tool versus alternatives (e.g., wattpad_list_comments for reading), nor does it provide when-not-to-use conditions. The guidance is more about caution than usage selection.

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 says 'No toca la red ni la cuenta' (does not touch the network or account), adding concrete detail beyond the readOnlyHint and destructiveHint annotations. It also explains the kinds of issues it detects (merged paragraphs, literal asterisks, manual separators/images), which gives the agent insight into its behavior. It does not contradict any 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 concise and well-structured: a one-line purpose, a paragraph explaining usage and context, and a clear 'Returns:' section. Every sentence adds value, and the key information is front-loaded. There is no fluff 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?

Given the tool's simplicity (one parameter, output schema exists, annotations cover safety), the description is adequate. It explains what the tool does, when to use it, and what it returns. It could include an example or error handling detail, but for a preview tool, it is sufficiently 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 has 100% description coverage for the single 'text' parameter, so the schema already documents it as 'Markup a comprobar.' The description does not add additional parameter-specific meaning, but the baseline 3 is appropriate since the schema carries the semantic weight.

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 specific action: 'Convierte markup a HTML y comprueba que sobrevive la ida y vuelta' (converts markup to HTML and checks round-trip). This clearly identifies the tool's purpose and resource. It is distinct from all sibling tools, which are about backup, retrieval, or writing operations; none perform validation or preview.

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 a clear 'when to use': 'Uselo ANTES de escribir, sobre todo con texto pegado desde otro editor' (use before writing, especially with pasted text). It provides specific scenarios and problem types it detects, but it does not explicitly name alternatives or state when not to use it, though none of the siblings serve the same purpose.

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?

Más allá de las anotaciones (destructiveHint=true, idempotentHint=false), la descripción revela comportamientos clave: dispara notificaciones a seguidores, es experimental, ejecuta dos peticiones en secuencia y exige al menos una etiqueta. Esto va más allá de lo que las anotaciones cubren y aporta contexto de riesgo y flujo.

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?

La descripción está bien estructurada: propósito al inicio, advertencias, flujo de dos pasos y tipo de retorno. Cada oración aporta información esencial sin relleno. La advertencia de irreversibilidad está destacada en mayúsculas para llamar la atención. Es eficiente y clara.

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?

Para una herramienta destructiva y experimental, la descripción cubre los puntos esenciales: qué hace, riesgos, requisitos previos (etiqueta), flujo de ejecución y formato de retorno. No falta información crítica para que un agente decida usarla correctamente y con precaución.

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?

El esquema ya documenta todos los parámetros con descripciones detalladas (cobertura 100%). La descripción añade valor al explicar el porqué del requisito de etiquetas (paso 1 guarda detalles) y al contextualizar saltar_detalles como omisión del paso 1. No es redundante, pero el esquema ya hace la mayor parte del trabajo.

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?

La descripción comienza con 'Publica un capitulo que estaba en borrador', un verbo y recurso claros. Se distingue de hermanos como wattpad_update_part (actualizar) y wattpad_create_part (crear) porque especifica la acción de publicar un borrador existente. La intención es inequívoca.

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?

La descripción advierte de que es experimental e irreversible, y pide confirmar con la persona antes de usarlo. También explica el flujo de dos peticiones y el requisito de etiqueta. No menciona explícitamente alternativas, pero el contexto de 'publicar un borrador' delimita cuándo usarlo frente a actualizar o crear. Es claro, aunque sin exclusión directa de hermanos.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that the return is a string containing author, metrics, and tags, which is useful behavioral context beyond the annotations. However, it does not disclose any other behaviors (e.g., rate limits, authentication requirements, or pagination semantics), so it remains at a moderate level.

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

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

The description is extremely concise, consisting of just two sentences. It front-loads the primary purpose and then provides a clear return type and content. Every word earns its place, and there is no filler or redundancy, making it highly efficient for an agent 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?

Given that the tool has a fully described schema, an output schema, and annotations indicating read-only behavior, the description covers the essential aspects: what it searches, the return format, and the data included. It does not elaborate on pagination usage or response_format nuances, but these are already captured in the schema. The description is adequate for an agent to call the tool correctly, with minor gaps in explaining how to combine parameters like limit and offset.

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 all six parameters are described in the schema. The description does not add any parameter-specific semantics beyond what the schema already provides, such as clarifying the 'query' field's format (text or tag) or the meaning of 'language' IDs. Per the rubric, a baseline of 3 is appropriate when the schema fully documents the 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 states a specific verb ('Busca') and resource ('historias publicas en Wattpad'), and clarifies the search criteria ('por texto o etiqueta'). This clearly distinguishes it from siblings like wattpad_get_story (which retrieves a specific story) and wattpad_list_my_works (which lists the user's own works), leaving no ambiguity about the tool's core function.

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 searching public stories, but provides no explicit guidance on when to use this tool versus alternatives (e.g., when to use wattpad_get_story instead). There are no exclusions or mentions of preferred scenarios, so the usage context is only implied by 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?

Even though annotations already declare destructiveHint=true, the description goes beyond: it explains that the text REPLACES the previous one entirely, requires a backup, uses an optimistic lock via expected_text_hash, and mentions refusal conditions. This adds rich behavioral context about side effects and safety, which is valuable beyond the annotation.

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-loaded with the core purpose and destructive warning. It then lists required safety steps and then explains the hash. It's well-structured with short paragraphs. However, it uses a bullet list and a return type note that could be more compact, but it's efficient for the 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 the destructiveness and experimental nature, the description covers critical safety procedures, return type, and parameter behavior. It lacks explicit mention of rate limits or authentication, but those are likely not necessary for an agent to call it. The output schema exists, so return details are not needed. It's complete for an expert agent, though a novice might need more examples.

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 the schema already documents all parameters. However, the description adds critical semantics for the 'text' parameter: it explains markup syntax, paragraph separation, escape characters, and scene break examples. This is beyond the schema's description and essential for correct use. Other parameters like expected_text_hash are also clarified in the description. Slight deduction because the description doesn't detail 'story_id' deduction, but schema covers it.

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 the specific action (update title or text of a chapter) and the endpoint (/apiv2/editstory). It clearly differentiates this from sibling tools like wattpad_get_part_text and wattpad_create_part. The title 'Editar capitulo (experimental)' is consistent and 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 explicitly warns about the destructive nature and gives clear preconditions (backup, check hash, refuse if formatting is lost). It implies use after reading the part with wattpad_get_part_text (since expected_text_hash comes from there), but does not explicitly name that sibling or say when not to use it. The context is clear enough.

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 readOnly and idempotent annotations, the description discloses that the tool performs a live authenticated check, deliberately distrusts the configured username, and emits warnings on account mismatch. This adds meaningful behavioral context without contradicting the 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 and front-loaded: purpose, behavioral notes, and return value are each covered in a few short sentences. Every line contributes useful 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 parameterless, read-only whoami tool with an output schema and safety annotations, the description covers the essential behavior and return format completely. The agent has enough information to select and 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?

The tool has zero parameters and schema coverage is trivially 100%, so there is no parameter semantics for the description to clarify. The baseline of 4 is appropriate because no additional parameter documentation is needed.

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

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

The description states a specific verb and resource: verify against Wattpad that the session is valid and identify its owner. It clearly differentiates the tool from siblings like get_user or list_my_works by focusing on session validation rather than fetching user data or content.

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

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

It provides clear operational context: always call an authenticated endpoint, ignore the configured WATTPAD_USERNAME value, and warn if the cookie belongs to a different account. It does not explicitly name sibling alternatives or state when not to use it, but the intended use case is evident.

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