devflow

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

With no annotations, the description carries the full behavioral burden. It does disclose a key behavior—no-op when the issue already has an assignee—which is useful, but it omits return values, error behavior, and permission requirements.

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

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

The description is a single concise sentence that front-loads the core action and adds only the important idempotency behavior. There is no redundant or filler content.

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

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

For a tool with one simple parameter and no output schema, the description is mostly complete: it defines the action, the scope, and the no-op case. It could mention what the tool returns on success or failure, but the call itself is unlikely to be misused.

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 issueKey parameter is already well documented. The description adds no additional parameter-level detail, which is acceptable given the schema covers the only 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 states a specific action ('Asignar un issue') and the target scope ('al usuario actual'), so the tool's purpose is unambiguous. It does not explicitly differentiate itself from sibling tools like df_issue or df_transition, but the current-user assignment scope is distinctive enough.

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

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

The description implies when to use the tool: to assign an issue to the current user, and it hints that calling it on an already-assigned issue has no effect. However, it provides no explicit 'when to use vs. alternatives' guidance or exclusion conditions.

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

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

With no annotations present, the description carries the full behavioral burden. It discloses meaningful guardrails: the confirmation flag is mandatory and the tool verifies that no unpushed changes exist before proceeding. It could add more about whether the branch is created locally or remotely and what happens on failure, but the disclosed behavior is genuinely useful.

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

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

Two short, front-loaded sentences deliver the action, naming rule, and required preconditions with no filler. Every sentence earns its place and no schema information is redundantly repeated.

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 four-parameter tool with no output schema and no annotations, the description supplies the essential operational context: base branch, naming pattern, mandatory confirm flag, and the unpushed-changes preflight check. It does not specify the return value or failure mode, but an agent has enough to invoke it correctly.

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

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

The schema already documents all four parameters at 100% coverage, but the description adds value by showing how issueKey, type, and description combine into the branch name format feat/PROJ-123-desc. It also reinforces that confirm must be true, which is important operational context beyond the raw parameter 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 opens with a specific action and object: 'Crear una nueva branch desde la rama base', and it gives the exact required naming convention feat/PROJ-123-desc or fix/PROJ-123-desc. This clearly distinguishes it from siblings like df_checkout or df_find_branch without needing to inspect schemas.

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 concrete preconditions: the tool requires confirm: true and checks that there are no unpushed changes before creating the branch. It does not explicitly name alternatives such as df_checkout for switching branches, so it stops short of a full when/when-not comparison.

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?

Without annotations, the description carries the full burden of behavioral disclosure. It does state a meaningful behavior: it verifies there are no un-pushed changes before switching. However, it does not explain what happens if such changes exist, whether it discards or preserves working tree changes, or what the tool returns. This adds partial transparency but leaves key behaviors undisclosed.

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 consists of two short, front-loaded sentences with no filler. It states the purpose first, then the behavioral check. Every word earns its place, making it appropriately sized and well structured.

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

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

Given the tool has one parameter, no annotations, and no output schema, the description provides the core purpose and a key precondition. However, it omits error behavior (e.g., what if un-pushed changes exist or the branch is not found), return values, and side effects on the working tree. It is minimally adequate but not 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 input schema fully documents the 'branch' parameter as 'Nombre de la rama' (branch name), so baseline is 3. The description adds the semantic restriction that the branch must be an existing one ('a una rama existente'), which is not present in the schema. This extra constraint enhances parameter understanding beyond the schema.

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

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

The description states a clear action, 'Cambiar a una rama existente' (switch to an existing branch), identifying the verb and resource. The qualifier 'existente' distinguishes it from branch creation, and the additional verification about un-pushed changes adds a specific behavior. However, it does not explicitly name sibling tools, so it stops short of full sibling differentiation.

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

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

The description implies usage when the user wants to switch to an existing branch, and the verification statement hints that a clean un-pushed state is expected. It does not mention alternative tools like df_push or df_branch, nor does it provide explicit when-not-to-use guidance. The guidance is mostly implicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses the confirmation guard, which is useful, but it does not mention permissions, idempotency, reversibility, or what happens if confirm is false. For a mutating tool, this leaves significant behavioral gaps.

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

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

The description is two short sentences, front-loading the action and then stating the critical execution requirement. There is no filler or redundant content.

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

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

The tool is simple and the schema covers all parameters, but with no output schema and no annotations, the description does not explain return values, side effects, or behavior when confirm is absent. The confirmation guard adds context, but the agent is left to infer the outcome of execution.

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 three parameters. The description adds no meaning beyond the schema, except restating the confirm requirement that the schema already conveys.

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: 'Añadir un comentario a un issue de Jira' (add a comment to a Jira issue). This clearly distinguishes it from sibling tools like df_transition or df_assign, even without naming them.

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 a clear intended use and a key prerequisite ('Requiere confirm: true para ejecutar'), but it does not contrast with alternatives such as df_issue or df_assign, nor explain when not to use this tool. Usage is implied rather than 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?

No annotations are provided, so the description carries the burden of disclosure. It adequately reveals that the tool searches both local and remote branches and returns null when no match exists. It does not mention potential side effects or fetch behavior, but for a read-only lookup the key behavioral traits are 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 two concise sentences with no filler. The purpose is front-loaded, the matching condition is stated immediately, and the return behavior is included without unnecessary detail.

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

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

For a simple one-parameter lookup tool, the description covers the operation, the search scope, and the return value (branch or null). There is no output schema, but the return behavior is described. It is sufficiently complete for an agent to select and call 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?

The input schema already documents `issueKey` with 100% coverage and an example. The description adds slight semantic value by clarifying that the branch name must 'contenga' the issue key, but it mostly restates what the schema provides. 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 ('Buscar') and resource ('una rama local o remota'), and clarifies the matching condition ('contenga un issue key'). It also specifies the return value ('Devuelve la rama si existe o null'), making the tool's purpose unambiguous and distinct from sibling branch-management 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?

The description provides clear context: use this tool to check whether a branch matching an issue key already exists locally or remotely. It does not explicitly name alternatives or exclusion conditions, but the search-oriented purpose is clear enough for an agent to decide when to invoke 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?

No annotations are provided, so the description must carry the behavioral burden. It discloses the auto-execution behavior (the AI runs it when trigger matches), which is valuable. However, it omits other behavioral details such as idempotency, overwrite behavior, or error conditions.

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

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

The description is two concise sentences. The purpose is front-loaded, and the behavioral note about trigger execution is added without unnecessary fluff. Every word contributes 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?

With 3 required parameters fully described in the schema and a concise description covering purpose and auto-execution, the tool is largely usable. However, it lacks details on error handling, idempotency, or what happens if a flow with the same name exists, which would be helpful for safe 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?

The schema description coverage is 100% – all three parameters (name, trigger, steps) have descriptions. The description only restates these parameter names without adding new semantics or examples beyond what the schema already 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 clearly states the verb 'Crear' (create) with the resource 'flow (playbook)' and lists the key attributes (name, trigger, steps). It also explains the tool's role in the system (executed when trigger matches), which distinguishes it from sibling tools like df_flow_update or df_flow_delete.

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 creation but does not explicitly contrast with alternatives like df_flow_update or df_flow_delete. It mentions the trigger execution context, which gives some situational guidance, but lacks explicit when-to-use/when-not-to-use language.

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 present, so the description carries the full burden. It labels the operation as deletion but does not mention permanence, side effects, required permissions, or consequences. The only additional behavioral detail is the narrow confirm requirement for the 'start-task' flow, leaving much undisclosed.

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

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

Two short sentences: the first states the action directly, the second adds a relevant edge case. No filler or redundant restatement of the schema.

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 tool with no annotations and no output schema, the description covers the basic action and one caveat but omits irreversibility, default flow behavior, and any guidance on comparing with sibling operations. It is adequate but has clear gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful semantic detail by specifying that the 'start-task' flow requires confirm:true, which goes beyond the schema's generic boolean description and helps the agent set the correct value.

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 'Eliminar un flow', a specific verb and resource, and clearly distinguishes itself from flow creation, retrieval, listing, and update siblings. The additional caveat about 'start-task' doesn't muddy the core purpose.

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

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

No guidance is given on when to use this delete tool versus other flow management tools. The confirm:true note is a parameter prerequisite rather than a usage-context instruction, and no alternatives or exclusions are mentioned.

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

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

No annotations are provided, so the description carries the behavioral burden. 'Ver' signals a read-only operation, and the description adds context by specifying the returned content (name, trigger, steps), but it does not disclose error behavior, permissions, 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?

A single sentence with no filler, front-loaded with the verb and resource. Every word contributes to explaining what the tool does.

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

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

For a simple one-parameter getter, the description is nearly complete: it states what detail is returned, and the schema fully documents the parameter. It omits only not-found/error behavior, which is minor for a read operation.

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

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

Schema description coverage is 100%: the only parameter 'name' is documented as 'Nombre del flow'. The description adds no additional parameter-level meaning, so the baseline 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 uses the verb 'Ver' and identifies the resource as 'el detalle completo de un flow', enumerating name, trigger, and all steps. This clearly distinguishes it from df_flow_list, which would list flows rather than return full detail.

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

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

The description implies the tool is for retrieving complete flow detail, but it does not explicitly state when to use it instead of df_flow_list or other flow tools. No alternatives or exclusions are mentioned.

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

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

With no annotations, the description carries the behavioral burden. 'Listar' signals a read-only operation and the description reveals the output contract (name, trigger, step count). It does not discuss project scope, sorting, or response format, but for a parameterless list tool this is sufficient.

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 short sentence with every element earning its place: action, scope, and output fields. No filler or repetition.

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

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

For a zero-parameter list operation with no output schema, the description provides everything needed: what is listed and what fields are returned. No prerequisite information is required.

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 100% schema coverage, so the description does not need to explain parameters. Per the baseline for zero-parameter tools, this is correct.

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 ('Listar'), names the resource ('flows configurados'), and specifies the returned fields ('nombre, disparador y numero de pasos'). This makes it easy to distinguish from the related df_flow_get, which would retrieve a single flow.

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

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

The phrase 'todos los flows configurados' gives clear context: use this when you need the full set of configured flows and their summary metadata. It does not explicitly mention alternatives such as df_flow_get for a single flow, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'modify' implying mutation but does not explain side effects, prerequisites, or behavior on missing flows. For a mutation tool, this is a significant gap.

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?

A single, concise sentence with no unnecessary words. It effectively communicates the core purpose without padding.

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

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

The tool is simple with three parameters, all covered by the schema. However, it lacks behavioral details such as whether steps are replaced entirely or merged, and what happens if the flow does not exist. This is incomplete for a mutation tool, especially with 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?

Schema coverage is 100%, so each parameter has a description. The description adds context by mentioning 'disparador y/o pasos', which maps to trigger and steps, but does not provide additional semantics beyond the schema. 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 ('modificar') and resource ('flow existente'), and clearly identifies the changeable aspects (trigger and/or steps). It distinguishes itself from siblings like df_flow_create and df_flow_delete by focusing on updating an existing flow.

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

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

The phrase 'flow existente' implies this is for updating already-created flows, contrasting with creation/deletion. However, it does not explicitly state when not to use it or mention alternatives, leaving some inference required.

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 and explicitly discloses that the operation is read-only and has no side effects. This is valuable safety information for an agent, though it does not mention auth requirements or error 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 one short, front-loaded sentence followed by a safety qualifier. Every word contributes value and there is no 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 simple single-parameter read-only tool, the description is nearly complete. It conveys the operation, scope, and safety profile, though the absence of an output schema means 'detalle completo' is somewhat 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 single parameter issueKey is fully documented in the input schema with an example format. Since schema description coverage is 100%, the description does not need to add parameter details, and it does not.

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 and resource: obtain the full detail of a single Jira issue. It distinguishes itself from siblings like df_issues by conveying that this tool targets one specific issue's complete detail, not a list.

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

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

The description gives clear context for use: when you need the complete detail of one Jira issue. It does not explicitly name alternatives or exclusions, but the read-only note and singular scope make the applicable use case 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?

With no annotations provided, the description carries the full burden. 'Listar' clearly indicates a read-only operation, and 'mis issues asignados' transparently scopes results to the authenticated user. It does not explicitly declare side-effect freedom, but the listing verb and scope give sufficient behavioral clarity for a 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 a single, front-loaded sentence that names the verb and resource first, followed by the optional filters. Every word earns its place, with no filler or redundant detail. It is appropriately sized for a simple read tool.

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

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

For a tool with two optional filters and no output schema, the description adequately covers the key context: what it does, whose issues it lists, and what filters are available. It does not mention return format, but for a listing tool this is reasonably inferable, and no other critical information 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%, with both status and project already described with examples. The description only mentions 'filtros opcionales por proyecto y estado,' which restates the schema without adding new semantic detail or context beyond what the parameter descriptions already provide. Baseline 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 clearly states the tool's verb ('Listar') and resource ('mis issues asignados en Jira'), specifying the scope as issues assigned to the user. This distinguishes it from siblings like df_issue (which likely targets a single issue) and df_statuses (which lists statuses), so an agent can identify the right tool without 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?

The description implies usage by stating its purpose (listing assigned issues) and mentions optional filters, but it does not explicitly compare with alternatives or state when not to use this tool versus df_issue, df_statuses, or other siblings. The guidance is implied through the phrasing, but no explicit routing to alternatives is provided.

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 hay anotaciones, por lo que la descripción debe informar sobre el comportamiento. Indica que no se ejecuta sin confirm true y que ante conflictos los reporta sin abortar, lo cual es relevante para un comando mutador. No detalla todos los efectos secundarios ni la salida de éxito, pero cubre los riesgos principales.

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?

Dos frases breves y directas, con el propósito al inicio y sin relleno. 'Requiere confirm: true' y el comportamiento ante conflictos aportan información necesaria sin alargar el texto.

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 de dos parámetros sin esquema de salida, la descripción cubre la condición de ejecución y el manejo de conflictos, suficiente para invocarla correctamente. Sería más completa si describiera la salida/resultado en éxito, pero no impide la selección ni la llamada.

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?

La cobertura del esquema es del 100% y ambas propiedades ya tienen descripciones significativas (branch y confirm). La descripción añade poco más allá de reforzar que confirm debe ser true, así que el esquema hace el trabajo principal.

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 usa un verbo específico y el recurso exacto: 'Mergear una rama en la rama actual'. Esto delimita claramente la operación y la distingue de herramientas hermanas como df_checkout, df_pull o df_push.

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?

Comunica claramente el contexto de uso (merge en la rama actual) y una condición previa concreta: confirm: true. No menciona explícitamente alternativas o exclusiones, pero el caso de uso queda lo bastante claro.

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 of behavioral disclosure. It reveals that the tool creates a PR/MR, but does not mention side effects, authentication requirements, whether it pushes the branch, or what happens if a PR already exists.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently conveys the action, target platform, and branch scope.

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

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

For a simple two-parameter creation tool with complete schema descriptions, the description is largely sufficient. It covers what is created and for which branch, though it does omit some contextual details about preconditions and side effects.

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 title and body parameters are already documented in the schema. The tool description adds no additional parameter meaning, which matches the baseline of 3.

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 ('Crear... Pull Request o Merge Request') and a clear scope ('para la rama actual'). It unambiguously identifies the resource being acted on and is distinct from siblings like df_merge or df_push.

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 is appropriate when the current branch is ready for a PR/MR, but it does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions or preconditions such as needing a remote branch or avoiding duplicate PRs.

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 behavioral disclosure. It indicates deletion but does not explain whether the action is irreversible, what artifacts are removed, whether special permissions are required, or what response is returned. This is a meaningful gap for a destructive operation.

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

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

The description is a single, concise sentence with no wasted words and the action is front-loaded. It is efficient, though its brevity limits the amount of useful operational context it conveys.

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 one-parameter delete operation, the description plus schema are minimally adequate for invoking the tool. However, with no annotations and no output schema, the description omits important operational context such as permanence, side effects, and preconditions, so it is 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 100%, and the single parameter 'name' is already documented as 'Nombre del proyecto a eliminar.' The tool description does not add meaning beyond the schema, but it does not need to because the schema fully explains the 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 states a specific action ('Eliminar' = delete) and resource ('proyecto configurado' = configured project), making the core purpose clear. It is implicitly distinct from sibling operations like df_project_update, df_project_list, and df_project_switch, though it does not explicitly name alternatives.

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 about when to use this tool, what preconditions exist, or when to prefer sibling tools such as df_project_update or df_project_list. The only usage information is implied by the verb 'Eliminar.'

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 behavioral disclosure. It only states the action and does not mention side effects, read-only nature, output format, ordering, or any other behavioral characteristics.

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?

A single, direct sentence with no filler. It is appropriately sized for a trivial zero-parameter listing operation.

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

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

For a zero-parameter list operation, the description is essentially complete: it names the resource and the action. The lack of output schema or return-value notes is a minor gap, but not critical for such a simple read-style operation.

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

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

The tool has zero parameters, so semantic enrichment is largely unnecessary. The baseline of 4 applies because there is no parameter detail the description must compensate for.

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 ('Listar') and resource ('todos los proyectos configurados'), clearly indicating the operation and scope. It distinguishes this tool from project mutation and flow/rule listing siblings by focusing on listing configured projects.

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

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

The description gives no guidance on when to use this tool versus alternatives like df_project_switch or df_flow_list. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage solely from the operation 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 provided, the description carries the behavioral transparency burden. It explicitly discloses that the tool auto-detects Jira type, API version, Git provider, and base branch, and it clearly instructs the agent to request credentials rather than assume them. It stops short of describing side effects or persistence, but the key behavioral traits are 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 three short, purposeful sentences. It front-loads the core purpose, then adds auto-detection behavior and a critical credential warning. There is no filler, repetition, or unnecessary overlap with the schema.

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

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

For a tool with 9 parameters, no annotations, and no output schema, the description covers the setup purpose, auto-detection, and credential handling reasonably well. However, it does not describe the expected result or return value, nor does it clarify what side effects occur after setup, leaving some ambiguity for the 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?

Schema description coverage is 100%, so the baseline of 3 applies. Each parameter already has detailed instructions such as 'PREGUNTA AL USUARIO' and examples. The description adds only a general credential-handling policy rather than parameter-specific semantics, so it does not exceed the 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 opens with 'Configurar un nuevo proyecto' — a specific action and resource — and clarifies that the tool links Jira and a Git provider. It distinguishes from siblings mainly through the word 'nuevo' (new project), though it does not explicitly name df_project_update or state when to use one over the other.

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 use case is implied: setting up a new project that links Jira and Git. The IMPORTANTE block adds practical guidance by telling the agent to ask the user for all credentials and never invent them. However, it does not explicitly discuss alternatives or exclusions, such as using df_project_update for existing projects.

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 hay anotaciones, por lo que la descripción es la única fuente de comportamiento. Revela un rasgo importante: el cambio es solo de sesión y se revierte al reiniciar. Sin embargo, no menciona efectos colaterales, permisos necesarios ni qué ocurre con operaciones posteriores dependientes del proyecto activo.

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 es breve, directa y sin palabras de relleno. La acción principal está al inicio y el matiz de comportamiento ('Al reiniciar vuelve al default por scope') está integrado de forma compacta.

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 de un solo parámetro requerido y sin schema de salida, la descripción cubre lo esencial: qué hace y su carácter transitorio. Aun así, el significado de 'default por scope' no está definido, lo que deja un pequeño margen de ambigüedad.

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 schema ya documenta el parámetro 'name' como 'Nombre del proyecto' y la cobertura es del 100%. La descripción no añade significado adicional sobre el formato, origen o validación del nombre, por lo que se mantiene la línea base de 3.

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 el verbo 'Cambiar' y el recurso 'proyecto activo', dejando claro que la operación es cambiar el proyecto activo de la sesión. Es distinguible de otros tools de proyecto porque se enfoca en el proyecto 'activo' y no en crear, listar o actualizar proyectos, aunque no menciona explícitamente a ningún sibling.

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 frase 'Al reiniciar vuelve al default por scope' aporta contexto útil sobre cuándo tiene efecto el cambio, pero no indica explícitamente cuándo usar esta herramienta frente a alternativas como df_project_list o df_project_setup. El uso queda implícito: cambiar el proyecto activo para la sesión actual.

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 of behavioral disclosure. It only says it modifies configuration; it does not reveal whether changes are reversible, whether they affect existing flows, whether authentication is required, or what the response looks like. For a mutation tool, this is a significant gap.

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

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

The description is a single concise sentence with no filler words and the verb-object structure is front-loaded. It is efficient, although it is brief enough to under-specify operational context.

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 10 parameters, no annotations, and no output schema, the description is too thin to fully orient an agent. It does not mention the required 'name' parameter, the relationship to sibling tools, or the behavior/return value of the update operation.

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

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

Schema description coverage is 100%, so the input schema already documents all 10 parameters with meaningful descriptions. The tool description itself adds no parameter-specific detail, but given full schema coverage, the baseline of 3 is appropriate.

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

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

The description states a specific action ('Modificar la configuracion') and a clear resource ('un proyecto existente'), which distinguishes it from related tools like df_project_setup by focusing on existing projects. However, it does not explicitly name sibling tools or specify which configuration aspects are modifiable.

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 use case is implied: modify configuration of an existing project, as opposed to creating one with df_project_setup. But there is no explicit when-to-use guidance, no exclusion of alternatives, and no mention of prerequisites or required input like the project '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 full burden of behavioral disclosure. It merely restates the action without explaining side effects such as merge vs. rebase, potential conflicts, or requirements like a clean working tree. Minimal behavioral information is provided.

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

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

The description is a single concise sentence, front-loaded with the verb. It has no wasted words and is easy to parse, making it efficient for an agent to quickly understand the tool's 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?

Given the tool has no parameters and no output schema, the description covers the core action but lacks detail on behavior, preconditions, or results. For a zero-parameter operation, it is minimally adequate but could mention merge vs. rebase behavior or potential outcomes.

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 no parameters, so there is nothing to explain beyond the schema. The baseline score of 4 applies because there is no parameter schema to describe, and the description correctly implies no inputs are 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 ('pull') and resource ('current branch from remote'), which clearly distinguishes it from sibling tools like push, checkout, and merge. The action is unambiguous and matches the tool's name.

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 guidance on when to use this tool versus alternatives. Usage is implied by the action name, but it doesn't mention conditions, prerequisites, or contrast with other git operations like merge or rebase.

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 successfully discloses a key behavioral trait: 'Requiere confirm: true para ejecutar. Sin confirm devuelve preview.' This tells the agent that the tool is preview-only by default and only mutates the remote when confirm=true. It does not discuss potential failure modes or remote state effects beyond that.

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 only two sentences and front-loads the primary action. Every word contributes meaning; no filler or redundant schema repetition.

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

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

Given the simple one-parameter tool and no output schema, the description covers purpose, parameter behavior, and safety confirmation. It lacks explicit mention of remote mutation side effects, but the 'push' action and confirm gate largely 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?

Beyond the schema's 'true para ejecutar el push', the description clarifies that omitting confirm yields a preview, which is not stated in the schema. This fully defines the parameter's behavior and default.

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

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

The description clearly states the tool's function: 'Hacer push de la rama actual al remote' (push the current branch to the remote). It uses a specific verb and resource, and the action is distinct from sibling tools like df_pull.

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 through the action 'push current branch to remote' and explains the confirm requirement, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. No sibling differentiation is mentioned.

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

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

No annotations are provided, so the description carries the burden. It does add useful behavioral context by explaining that rules can block or warn about actions. However, it does not disclose potential side effects of creation, authorization requirements, or what happens on success/failure.

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

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

Two short sentences with no filler. The primary action 'Crear una regla configurable' is front-loaded, and the second sentence adds relevant context about what rules do.

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 4-required-parameter creation tool with no output schema, the description plus schema is minimally sufficient to invoke it correctly. Still, it lacks any mention of return value, side effects, or setup prerequisites, and the absence of annotations increases the need for such context.

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 four parameters including enums for scope and action. The description only reinforces the action/enum semantics ('bloquear o advertir') and does not add new parameter-level detail beyond the schema.

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

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

The description uses the specific verb 'Crear' plus the resource 'regla', and clarifies what rules do ('Las reglas pueden bloquear o advertir sobre acciones'). This cleanly distinguishes df_rule_create from sibling operations like df_rule_update, df_rule_list, and df_rule_delete.

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

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

The description implies the tool should be used when creating a new rule, which is clear from 'Crear una regla configurable'. However, it gives no explicit guidance about when not to use it or which sibling(s) to prefer (e.g., df_rule_update for modifying an existing rule), leaving the agent to infer the selection logic.

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 for behavioral disclosure. It only repeats the deletion action implied by the tool name and does not warn that deletion is likely irreversible, affect rule project overrides, or remove associated configurations. Some credit is given because 'eliminar' does clearly signal a destructive operation.

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

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

The description is extremely brief with no filler or redundant content. It is front-loaded as a direct action phrasecars, though the brevity also contributes to the lack of usage and behavioral guidance.

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 one-parameter deletion tool with full schema coverage, the description plus schema technically provides enough information to invoke it. However, it lacks context about what deletion entails, possible side effects, or how it differs from toggling or updating a rule. This is adequate but clearly incomplete.

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

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

Input schema coverage is 100%: the single required parameter 'name' is already described as the name of the rule to delete. The description adds no additional parameter semantics, which is acceptable given that this is a minimal one-parameter 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 'Eliminar una regla' clearly identifies the operation as deleting a ruleeb, distinguishing it from sibling tools like df_rule_create, df_rule_update, and df_rule_toggle. It uses a specific verb and resource, though it does not add any extra scoping or differentiation text.

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 versus other rule-related tools such as df_rule_update or df_rule_toggle. The description does not state prerequisites, exclusions, or consequences, so an agent must infer usage solely from the tool name and schema.

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 of disclosing behavior. 'Ver' indicates a read operation with no mutation implied, which is a useful signal, but it does not mention error cases, required permissions, or what the returned detail contains. The transparency is adequate for a simple get but not rich.

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

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

The description is a single, focused sentence with no filler or redundant content. It front-loads the tool's purpose clearly and is appropriately sized for a simple get operation.

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

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

For a one-parameter read tool, the description is minimally viable: it states the action and resource, and the schema covers the parameter. However, with no output schema and no annotations, the description leaves ambiguity about the exact structure of the returned rule details and how this differs from list behavior.

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

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

The schema already fully describes the single required parameter 'name' as 'Nombre de la regla', with 100% coverage. The description adds no extra meaning about the parameter, so it does not go beyond the baseline set by the input schema.

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

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

The description clearly states the tool's action and resource: viewing the complete details of a rule. It is specific enough to convey the core purpose, but it does not explicitly contrast with sibling tools such as df_rule_list, which likely lists rules rather than fetching one rule's full detail.

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 like df_rule_list, df_rule_update, or df_rule_delete. There are no exclusions, prerequisites, or context hints, leaving the agent to infer usage 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?

No annotations are provided, so the description carries the behavioral disclosure burden. 'Listar' implies a read-only operation, and the description adds that the output includes activation state. However, it does not explicitly state side-effect-freedom, permission requirements, or pagination/response behavior.

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

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

The description is a single compact sentence with no filler. It front-loads the action and resource, then adds the key detail about rule state, making every word informative.

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 list operation with no output schema, the description is largely sufficient: it tells the agent what will be returned (all configured rules with status). It could be more complete by describing the output shape or empty-result behavior, but the low complexity keeps the gap small.

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, so there is nothing for the description to clarify beyond the schema, which already covers 100% of the parameter space. The baseline for a zero-parameter tool is 4, and the description provides appropriate context by stating the scope of what will be listed.

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 ('Listar') and a specific resource ('todas las reglas configuradas'), and it clarifies the returned data includes each rule's state. This clearly distinguishes df_rule_list from single-rule tools like df_rule_get and from mutating tools like df_rule_create or df_rule_delete.

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 what the tool does but gives no explicit guidance on when to choose it over alternatives such as df_rule_get or df_rule_flow_list. There are no conditions, exclusions, or comparisons, so an agent must infer usage from the tool name and 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Añadir' implies a state-changing action, but the description does not mention permissions, idempotency, whether it can overwrite existing rules, or what happens if a rule with the same name already exists. This is a significant gap 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 a single, direct sentence with no redundant words. It front-loads the essential fact: this is a project-scoped rule addition. It is appropriately concise.

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

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

Given the lack of annotations and output schema, the description needs to compensate by explaining side effects, prerequisites, and how this differs from similar rule tools. It only states the basic action and scope, leaving important contextual information missing for an agent to select and invoke the tool confidently.

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 fully documents all four parameters with names and descriptions, so the baseline is 3. The tool description adds the project-scope context but does not enrich the meaning of the individual parameters beyond what the schema already 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 clear verb ('Añadir'), a resource ('regla'), and a specific scope ('solo aplica al proyecto actual'). It is understandable, but it does not explicitly distinguish this tool from sibling tools like df_rule_create or df_rule_project_override, so it falls short of full 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 phrase 'solo aplica al proyecto actual' implies this is for project-scoped rules, but it does not explicitly say when to use this tool versus df_rule_create or df_rule_project_override. Usage context is present but alternatives and exclusion conditions are not mentioned.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the override applies only to the current project, but it does not mention reversibility, what happens to an existing override, required permissions, or side effects. That is a meaningful but incomplete 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?

Two short, focused sentences with the action first and the scoping constraint second. No filler or redundancy; every word earns its place.

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

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

For a low-complexity two-parameter toggle with fully documented parameters, the description covers the action and the crucial project-only scope. The only gaps are lack of confirmation/return behavior and explicit prerequisite about the current project, which are minor for this tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the enabled semantics and adds the override concept, but it does not add detail beyond the schema's own parameter 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 uses a specific verb ('Activar o desactivar') and a specific resource ('una regla global para el proyecto actual'), and the second sentence ('El override solo aplica a este proyecto') distinguishes it from global rule tools such as df_rule_toggle. An agent can tell what this tool does 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 clearly conveys that this tool is for project-scoped overrides and that the effect is limited to the current project, which orients the agent toward using it instead of a global rule toggle. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the removal behavior but does not mention that the action is destructive, irreversible, or restricted by permissions, nor what happens if the rule is in use. The added distinction between project rules and global overrides is helpful but insufficient for a deletion 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?

A single, concise sentence that front-loads the action and then clarifies the two supported scopes. There is no filler or repetition.

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

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

This is a simple one-parameter tool without an output schema, so the description need not explain return values. However, it lacks explicit guidance on how this tool relates to sibling tools like df_rule_delete or df_rule_project_add, and it omits any note about destructive effects, which leaves some contextual ambiguity for an 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?

Schema description coverage is 100%, with 'name' documented as 'Nombre de la regla a eliminar'. The tool description adds no parameter-level detail beyond that, so the baseline of 3 applies: the schema already handles the semantics.

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

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

The description clearly states the action ('Eliminar') and the target ('regla propia del proyecto actual' or 'override de regla global'), which is more specific than the tool name alone. It does not explicitly differentiate itself from sibling df_rule_delete, but the project-scoped vs. global-scoped distinction adds useful clarity.

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

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

The description implies when to use the tool: when removing a project-specific rule or removing a global-rule override in the current project. However, it does not explicitly contrast with df_rule_delete or df_rule_project_add, leaving the agent to infer the boundary between deleting a rule and removing an override.

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, but it only restates the core toggle action. It does not mention persistence, idempotence, required permissions, side effects, or what the tool returns after toggling.

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 with no filler. It efficiently conveys the core purpose, though it is minimal enough that it could arguably carry more context.

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

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

The tool is simple, with only two fully documented parameters and no nested objects, so the schema covers the invocation essentials. However, the absence of annotations and any note about return values or choice vs. df_rule_update leaves the description only minimally viable.

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%: both `name` and `enabled` are already documented. The description adds no new parameter-level meaning beyond restating that the rule is activated or deactivated, so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Activar o desactivar') and the resource ('una regla'), so an agent understands this toggles a rule's enabled state. However, it does not explicitly distinguish this from the sibling df_rule_update, which could also change the enabled field.

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 usage context is provided: the description does not explain when to prefer df_rule_toggle over df_rule_update or any other sibling. There are no conditions, exclusions, or alternative routing hints.

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, so the description must carry the full burden of behavioral disclosure. It only conveys mutation ('modify'), but does not state whether the update is partial or full, what permissions are required, whether changes are reversible, or what response to expect.

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

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

The description is very concise and front-loaded, but it is under-sized relative to the tool's complexity. While it avoids filler, it provides little more than a terse restatement of the tool's name and does not earn its place as a complete guide.

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

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

With no annotations, no output schema, and only a one-sentence description, the tool lacks important context about update semantics, how the required name identifies an existing rule, and whether omitted fields are left unchanged or cleared. An agent can infer basic behavior from the schema but not enough to invoke the tool confidently.

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 four parameters have descriptions in the input schema (100% coverage), so the description adds no additional parameter meaning. The schema already documents that name identifies the rule and scope, action, and description are new values, 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 states a specific verb ('Modify') and a resource ('an existing rule'), making the action unambiguous. It clearly differentiates from sibling tools like df_rule_create, df_rule_delete, and df_rule_toggle, even without naming them.

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 offers no guidance on when to use this tool versus alternatives such as df_rule_toggle, df_rule_create, or df_rule_project_override. It merely restates the function, leaving an agent to infer usage from the tool name and schema.

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, so the description carries the burden. The verb 'list' signals a read-only operation and the parenthetical explains what kind of data is returned, but permissions, error conditions, or the need for the issue to exist are not disclosed. No contradiction with annotations exists.

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

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

The description is a single, well-structured sentence with a helpful parenthetical clarification. It is front-loaded, contains no filler, and every part contributes to understanding what the tool does.

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

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

For a simple one-parameter tool with no output schema, this description conveys the essential call intent and describes the semantic result: the states an issue can move to from its current state. It would benefit from explicitly stating the return format or whether transition IDs are provided, but the core is complete enough 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 input schema already fully documents the single required parameter issueKey with an example. The description adds the context that the transition list depends on the issue's current state, but it does not substantially enrich what the schema already provides, matching the baseline for high schema coverage.

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 ('Listar') and a specific resource ('las transiciones disponibles para un issue'), and clarifies the scope as the states reachable from the issue's current state. This clearly sets it apart from siblings like df_transition, which moves the issue, and df_issues, which lists issues.

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 that the tool should be used when one needs to know an issue's possible next states, but it does not explicitly mention alternatives or say that df_transition should be used to actually execute a transition. The usage context is understandable but not stated as guidance.

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

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

There are no annotations, so the description carries the behavioral burden. It discloses a key dual-mode behavior: actual execution only with confirm=true, and a preview otherwise. This goes beyond the schema and alerts the agent to the non-destructive default.

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

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

Two short sentences with no filler. The core action, execution requirement, and fallback preview behavior are all front-loaded and immediately actionable.

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

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

For a simple three-parameter mutation tool, the description plus the fully documented schema covers what is needed to invoke it correctly. It lacks details about the preview's return shape or permissions, but these are minor given the straightforward scope and no output 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 coverage is 100%, but the description adds meaning beyond the schema by specifying the effect of omitting confirm: it returns a preview. This complements the schema's 'true para ejecutar la transicion' and clarifies the confirm parameter's role.

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: 'Mover un issue a un nuevo estado' (move an issue to a new state). This clearly separates it from sibling tools like df_assign or df_comment by framing the operation as a state transition.

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 gives concrete invocation guidance: 'Requiere confirm: true para ejecutar. Sin confirm devuelve preview.' This tells the agent when the tool executes versus when it only previews, and explicitly states the required confirm flag. It does not discuss alternatives, but the context is clear.

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