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

With no annotations at all, the description carries the full burden and does so well: it discloses the dry-run return shape, the backup destination (~/.elempleo/respaldos/) on write, the destructive scope constrained to eliminar_ids, and the safety rule that seguridad_social data must never be assumed. That is exactly the mutation-risk context an agent needs.

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?

Dense but front-loaded: the primary action and the dry-run default come first, followed by backup and deletion constraints. Slightly packed with clauses in a single block, but every sentence carries distinct operational information.

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

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

For a mutation tool with no annotations and no output schema, the description covers the return plan, backup behavior, deletion scope, and a data-handling rule. It is nearly complete, missing only per-section expectations for the enum values and how the returned plan is shaped structurally.

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 67%, with the enum for 'seccion' undocumented in the schema itself. The description adds value beyond the schema by clarifying that agregar/aplicar is a confirm-then-save gate, that eliminar_ids is the sole deletion scope, and that seguridad_social must use supplied data — though it does not map the remaining enum sections.

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

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

States a specific verb and resource ('Actualiza una sección de la hoja de vida desde el perfil maestro'), which implicitly distinguishes it from perfil-maestro siblings like guardar-perfil-maestro or ver-perfil-maestro. It does not name any sibling explicitly, so apart from that routing nuance the purpose is clear.

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

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

Explicitly states the two modes: without 'aplicar' it returns the exact plan (antes → después) to show the user, and with aplicar=true it backs up and saves after user confirmation. This gives the agent the when-to-use dry-run vs. when-to-write condition rather than leaving it to inference.

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 tool works without login and, when authenticated, indicates whether the user has already applied, but it omits pagination behavior, result format, and other read-operation details.

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 compact sentences with the core purpose front-loaded. Every sentence adds relevant information and there is no wasted text.

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

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

For a 7-parameter search tool with no annotations and no output schema, the description is too sparse. It explains session behavior but leaves parameter usage and return-value expectations largely undocumented.

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

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

Schema description coverage is only 43%, and the description does not compensate by explaining parameters. Several parameters, including fecha, pagina, contrato, and por_pagina, receive no clarifying meaning from either the description or schema descriptions.

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

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

The description uses a specific verb and resource: "Busca ofertas en elempleo.com (Colombia)". It clarifies the site and country, so the agent can distinguish it from application-status or profile tools, though it does not explicitly name a sibling alternative.

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 implies the tool is for searching job offers and notes that it works without a session while adding applied-status context with a session. However, it does not state when to use this versus siblings like detalle-de-oferta or evaluar-encaje, nor does it give exclusions.

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 that the tool performs a comparison and returns categories of gaps, which implies a read-only audit, but it does not explicitly say whether anything is modified, what permissions are needed, or what the response looks like.

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 wasted wording. The core action and the output categories are front-loaded.

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

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

For a zero-parameter tool with no output schema, the description is mostly complete: it says what is compared and what kinds of results are listed. It could add prerequisites such as needing both an elempleo CV and a master profile, but the essential behavior is covered.

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

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

The tool has zero parameters, so there is no parameter semantics to explain. Baseline is 4 for a no-parameter tool; the description does not need to compensate for any schema gaps.

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

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

States a specific verb and resource: it compares the elempleo CV with the master profile and lists missing, outdated, and extra items. This distinguishes it from sibling tools such as ver-perfil-maestro, ver-mi-perfil, and actualizar-perfil because it is an audit/diff operation rather than a view or update.

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 purpose implies when to use it: to check one's CV against the master profile. However, it does not explicitly name alternatives like ver-mi-perfil or actualizar-perfil, nor does it state exclusions or prerequisites. Usage is inferable but not guided.

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 and does well on the critical point: 'No guarda nada' makes clear this is a non-persisting drafting tool and that persistence is delegated to guardar-perfil-maestro. It also discloses input-dependent behaviour (PDF yields extracted text + schema + rules; URL-only yields export instructions). It does not mention file-size limits, supported PDF edge cases, or what happens with unexpected/mixed inputs, leaving some behavioural 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?

Front-loaded with the action and precondition, then branches by argument type and closes with the no-persistence caveat. Dense but every clause carries information; the multi-clause sentences are slightly heavy but not padded.

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?

Five optional parameters, no annotations and no output schema. The description covers the two main input paths and the non-persistence contract, which is what an agent most needs. It leaves the foto, texto and desde_portal parameters behaviourally undocumented and gives no indication of what a returned draft looks like structurally, so a small gap remains.

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 the baseline is 3, but the description adds meaning beyond the schema by explaining what each input path produces (PDF → extracted text, standard schema, assembly rules; linkedin_url alone → how to export the profile). It does not explain texto, foto, or desde_portal behaviourally, so it is not fully compensating.

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

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

States a specific verb and resource ('Crea el perfil maestro') plus a precise precondition ('cuando aún no existe'), and explicitly distinguishes the operation from the sibling guardar-perfil-maestro, which it names. An agent can tell it apart from the write-side sibling without opening either 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?

Gives explicit when-to-use (profile does not yet exist) and then branches guidance by input: with no arguments it says what to ask the user for; with a PDF it describes the derived output; with only a LinkedIn URL it explains the export path. It also names the follow-up tool and the condition for it ('tras la confirmación del usuario').

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: 'Devuelve' implies a safe read, and the field list partially compensates for the absent output schema. However, it says nothing about whether a session/login is required (siblings like iniciar-sesion exist), or what happens for an invalid or expired offer id.

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 front-loaded sentence with zero filler, and the useful payload (the returned field list) comes immediately after the verb. It is appropriately sized for a simple detail getter, though it could spend one more clause on routing.

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 with no output schema, enumerating the returned fields is the right move and mostly covers the return-value gap. The remaining holes are usage routing against buscar-ofertas and any auth/error behavior, which leaves it 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 single parameter has 100% schema description coverage including a concrete example (1886772014), so the schema does the work. The description only implies the parameter selects one offer and adds no format or constraint detail beyond it.

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

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

Names a specific verb ('Devuelve') and resource ('una oferta') and enumerates the fields returned (requisitos, salario, contrato, modalidad, ciudad), so the agent knows this is a single-offer detail lookup rather than a search. It does not explicitly contrast itself with buscar-ofertas, so sibling differentiation is only implicit through 'descripción completa'.

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 statements of when to use this instead of buscar-ofertas, nor any prerequisite such as first obtaining the numeric id from a search tool. The detail-vs-list distinction is inferable but never stated, and no exclusions or error conditions are given.

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

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

With no annotations, the description must carry the behavioral load; it does disclose one meaningful trait — 'Nunca muestra cookies' — a security/privacy guarantee. However, it does not state that it is a read-only probe, nor what the session/CV states can be, leaving gaps for an unannotated 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?

Two short sentences, front-loaded with the primary purpose, and the cookie disclaimer earns its place as a privacy note. No filler.

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

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

For a zero-parameter status tool this is nearly sufficient, but with no output schema the description should say what values 'sesión válida' and 'estado de la hoja de vida' can return (e.g. logged-in/out, CV complete/missing) so an agent can interpret the result.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate and it correctly implies a parameterless status check.

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?

Names a specific check: whether an elempleo session is valid plus the state of the 'hoja de vida'. This is clearly distinguishable from iniciar-sesion (which starts a session) and from perfil/CV tools, though 'estado de la hoja de vida' remains slightly ambiguous (completeness? upload status?).

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 statement of when to call this versus iniciar-sesion or ver-perfil-maestro, and no prerequisites (e.g. 'call before postular-a-oferta to verify login'). Usage is only inferable from the tool name and the word 'Indica'.

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?

Since no annotations were provided, the description carries the full behavioral burden. It successfully discloses critical operational behavior: the output is not just a boolean but a structured categorical rating (encaja, encaja_parcial, no_encaja) alongside explanatory reasons, which is vital for agent decision-making.

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

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

The description is a single, dense sentence that packs all necessary information—input function, comparison scope, and output format—without any wasted words. It is highly efficient.

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

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

Given that there are no structured annotations or output schemas, the description is remarkably complete. It defines the complex business logic, the data points used for the evaluation, and the precise possible return values, making it fully sufficient for a cognitive 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 coverage is 0%, so the description must compensate entirely. The tool requires only one parameter, 'id,' but the description fails to clarify whether this 'id' refers to the job offer being evaluated or the master profile against which the offer is being tested.

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 purpose is perfectly clear: it compares an job offer against a master profile. It specifies the comparison criteria (modality, salary, tech, English) and the three possible qualitative outcomes (encaja, encaja_parcial, no_encaja), setting it apart from general comparison 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 usage is implied, meaning the agent knows it is used for evaluating fit. However, it does not explicitly state the necessary prerequisites, such as 'must be called after an offer has been fetched' or 'must have a previously constructed profile,' which would raise the score.

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 load and does so well: it discloses the default write path, copies of foto/CV as side effects, the no-overwrite default, the sobrescribir:true escape hatch, and the backup taken on overwrite. That is exactly the destructive-behavior context an agent needs.

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?

Four dense sentences with the primary action front-loaded and no filler; the parenthetical default path slightly interrupts flow but is not wasteful.

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?

Covers side effects, overwrite policy, and the approval gate for a mutation tool with no output schema. The remaining gap is that it references an 'esquema estándar' without saying how the agent should obtain or verify that schema before building the nested perfil object.

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 the baseline is 3; the description adds real meaning beyond the schema by explaining the overwrite-with-backup semantics of sobrescribir and the default location of perfil. It does not clarify the shape of the nested perfil object.

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

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

States a specific verb pair (validate + save) on a specific resource (perfil maestro) and names the default destination file. This is clearly the persistence step, distinguishable from construir-perfil-maestro and ver-perfil-maestro in the sibling 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?

Gives an explicit precondition: 'Llamar solo después de que el usuario apruebe el contenido', which effectively tells the agent when not to call it. No sibling alternatives are named, so it falls short of the top score.

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 and does well: it discloses that a visible browser window opens, that human interaction is required, and that cookies are persisted to the MCP data folder as a side effect. It omits what happens when espera_max_segundos is exhausted (failure mode, whether the window is left open) and whether the call blocks until detection.

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

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

Two sentences, both load-bearing: the first establishes the action and the manual-interaction constraint, the second establishes the completion side effect. The most decision-relevant constraint (manual login required) is front-loaded.

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

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

For a tool with no annotations and no output schema, the description covers the essential flow and the persistent side effect. The remaining gap is timeout behavior and what the agent gets back on success vs. timeout, which matters for an operation that can run up to 15 minutes.

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 single parameter (espera_max_segundos, default 300, range 30-900) is fully documented in the schema. The description adds nothing about the timeout parameter or what reaching it means, 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?

States a specific verb and resource — opens a Chromium-based browser at the elempleo login page — plus the outcome (saves cookies, closes window). An agent can tell what it does immediately, but it never names the sibling estado-de-sesion, which is the natural adjacent tool, so sibling differentiation is left implicit.

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 parenthetical '(hay reCAPTCHA y verificación en dos pasos)' implies why this tool exists — manual login is unavoidable — which gives implied usage context. However there is no explicit 'use this when not authenticated', no 'check estado-de-sesion first', and no stated conditions under which the tool should be avoided.

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. "Lista" implies a read-only operation, but the description does not say whether an authenticated session is required, what happens when no CVs are attached, or how results are shaped.

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 short sentence with the key information front-loaded and zero filler. It is efficient, though slightly under-specified rather than overly wordy.

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-param read tool with no output schema, the description is minimally adequate, but it leaves the return shape (file names, URLs, counts?) and empty-state behavior entirely unexplained.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool 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?

States a specific verb + resource ("Lista los archivos de CV adjuntos") and the scope ("mis", user's own, in elempleo). It is clearly distinct from the write-side sibling subir-cv, though the description never names siblings explicitly.

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

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

No indication of when to call this versus alternatives such as ver-mi-perfil or mis-postulaciones, and no prerequisites stated. A reader must infer usage purely from the name and the word "adjuntos".

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 behavioral context. It discloses the status categories returned (en proceso, vencida, eliminada), but does not state authentication requirements, pagination behavior, or how results are scoped beyond the possessive 'tus'.

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 definition is a single front-loaded sentence with zero waste. It states the core action and returned statuses efficiently.

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

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

For a simple read-only list tool with no output schema, the description states the resource and status values adequately. However, it omits parameter semantics and any annotation-level behavioral context, leaving notable gaps for an agent to infer.

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

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

Schema description coverage is 0%, and the description never mentions the 'pagina' or 'por_pagina' parameters. It does not explain pagination or the allowed page-size options (20, 50, 100), so it fails to compensate for the undocumented parameters.

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

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

The description states a specific verb ('Lista') and resource ('tus postulaciones') in the elempleo context, and names returned status categories. It clearly identifies what the tool does, though it does not explicitly contrast itself with related siblings such as preguntas-de-postulacion or buscar-ofertas.

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 when-to-use conditions, prerequisites, or alternatives. It only implies viewing one's own applications, leaving the agent to infer when this tool should be chosen over sibling tools.

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

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

With no annotations, the description carries the burden and does well: it discloses the destructive/irreversible nature implicitly via the confirmation gate, forbids retries and batch calls. It stops short of describing outcome on failure or duplicate applications, but the key behavioral constraints are surfaced.

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

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

Three short sentences, zero filler, with the actionable constraint (confirmation format) front-loaded after the purpose statement.

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-param mutation tool with no annotations and no output schema, the description covers the critical safety gate, single-shot semantics and retry prohibition. Minor gaps remain around failure handling, but overall adequate 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 coverage is 75% and already documents nota, adjunto_id and confirmacion. The description adds real value by specifying the exact literal format 'POSTULAR <id>' and tying it to the specific offer id, reinforcing the cross-parameter constraint with the schema-documented confirmacion param.

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

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

States a specific verb+resource ('Envía la postulación') so the agent knows this submits an application, which no other sibling does. It does not explicitly contrast with siblings like 'mis-postulaciones' or 'responder-cuestionario', but the mutating, terminal action is unambiguous.

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

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

Gives explicit conditions: requires user's explicit confirmation for THAT specific offer, one offer at a time, no automatic retries. This is clear guidance on when and how to call it, though it doesn't mention alternatives for gathering questions/answers before applying.

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 does disclose the auth requirement (session) and that nothing is submitted, which are useful behavioral facts beyond the schema. It says nothing about failure modes, e.g. whether the form is unavailable, the user already applied, or the offer is closed — meaningful gaps for a session-gated read.

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 whose core action comes first, followed by the returned fields and a short disambiguating clause. No filler.

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

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

With no output schema and no annotations, the description usefully enumerates the returned data, which is the main missing piece. The remaining gap is the untyped id parameter and edge-case behavior, but the tool is simple enough that the definition is close to sufficient.

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

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

One required parameter (id) at 0% schema coverage, so the description must compensate. "de la oferta" implies id is the offer identifier, which is partial compensation, but the parameter is never named or constrained (e.g. must be an offer id from buscar-ofertas/detalle-de-oferta).

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?

Specific verb + resource ("Lee el formulario de postulación de la oferta") followed by an enumeration of exactly what is retrieved: tipo de postulación, nota, CVs disponibles, formularios adicionales. The closing "No envía nada" distinguishes it from the write sibling postular-a-oferta without opening either 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?

States a concrete prerequisite ("requiere sesión") and clarifies the read-only nature with "No envía nada", which implies applying belongs to postular-a-oferta. It stops short of naming that alternative explicitly, so the routing is inferred rather than spelled out.

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, and it does disclose meaningful traits: it will not fabricate data and will not send anything, and it surfaces items needing user confirmation. That is real behavioral context, but permissions, whether the draft is persisted, and what the response contains are left unstated.

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, no filler, with the core action and the key safety constraint both front-loaded. Every clause carries information.

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

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

For a single-parameter, no-output-schema tool the description is mostly adequate: it conveys the output is a drafted note plus flagged items. The unexplained "id" parameter and the absence of any indication of what the draft is tied to leave a real gap.

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

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

Schema description coverage is 0% and there is a single required integer parameter "id" that the description never mentions or explains. The agent cannot tell from the definition whether that id refers to a session, an application, or a profile, so the description does not compensate for the schema gap.

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

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

The description names a concrete verb ("Redacta") and a concrete artifact ("la nota al empleador"), plus its source ("a partir del perfil maestro"), so an agent can tell it produces draft text rather than sending it. It is clear on its own, though it does not explicitly contrast itself with near siblings like responder-cuestionario or postular-a-oferta.

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 "señala lo que requiere confirmación del usuario" and "nunca... envía nada" imply this is a pre-submission drafting step, which hints at when to reach for it. However, no alternative tool is named and no condition is given for choosing this over responder-cuestionario or postular-a-oferta, so usage must be inferred.

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 does disclose the key behavioral safeguard — a confirmation gate whose token must match 'CUESTIONARIO <id>' and answers must be user-approved — but says nothing about whether submission is final/irreversible, whether it can be retried, or what happens to the application state afterward.

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

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

Two sentences, front-loaded with the action and the triggering state, with the safety constraint second. No filler, though the confirmation-format sentence duplicates schema text rather than using the space for something new.

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-required-parameter mutation with no annotations and no output schema, the description covers the purpose and the confirmation gate but leaves the agent guessing about the result (success shape, resulting application state) and about retry/already-submitted behavior.

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

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

Schema coverage is 75%, so the baseline is 3. The description adds a genuine constraint on 'respuestas' (provenance/confirmation by the user) that the schema does not state, but the 'confirmacion' format it repeats verbatim is already in the schema, and 'id' and 'url' are not mentioned at all.

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

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

States a specific verb and resource ('Envía el cuestionario de filtro') and anchors it to a concrete trigger state ('requiere_cuestionario') that follows postular-a-oferta. It does not explicitly contrast with the sibling proponer-respuestas, which handles the drafting/confirmation side, so the boundary between them is left implicit.

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

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

Gives a clear trigger condition (only after applying, when state is 'requiere_cuestionario') plus a hard prerequisite: answers must come from the user or be confirmed by them. It stops short of naming the alternative tool (proponer-respuestas) or stating what to do if the questionnaire was already sent.

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 usefully discloses the preview-only behavior when aplicar is false and the optional replacement, but it omits whether an upload duplicates or overwrites existing CVs when no reemplazar_id is given, and says nothing about permissions or irreversibility of replacement.

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 dense sentence plus a short preview clause, with the source and destination front-loaded. No filler, though the parenthetical about cv_pdf makes the opening slightly heavy.

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 and no output schema, the description should say more about the default of aplicar and what the preview returns. It covers the main flow adequately but leaves an agent guessing on duplicate/overwrite behavior and the dry-run output shape.

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 67% and the description adds real meaning: cv_pdf source, version selection when multiple versions exist, and the dry-run meaning of aplicar. reemplazar_id is only cross-referenced to listar-mis-cv, leaving its exact semantics largely to 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?

States a specific verb (sube) and resource (CV en PDF del perfil maestro) plus the destination (archivos de empleo) and the replace option. An agent understands exactly what is uploaded and from where, though no sibling is named explicitly to differentiate it.

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?

'Sin aplicar solo muestra lo que haría' conveys the dry-run/preview mode, and 'opcionalmente reemplaza uno existente' indicates the replace path. However, it gives no explicit when-to-use versus alternatives (e.g. listar-mis-cv is only referenced inside the schema) and no prerequisites.

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

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

With no annotations, the description does real work: it discloses validation limits (JPG/PNG/GIF, max 3 MB) and a dry-run mode that is non-destructive. It omits whether an existing photo is overwritten, what permissions or session state are required, and what happens on validation 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?

One front-loaded sentence with the action, target, constraints, and dry-run caveat; no filler or redundancy.

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

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

For a mutation tool with no annotations and no output schema, the description covers the input constraints and preview behavior but leaves the agent guessing about overwrite semantics, required session/profile state, and the success response.

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

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

Schema coverage is 0%, so the description must carry the single parameter. 'Sin aplicar solo muestra lo que haría' effectively documents the 'aplicar' boolean as a preview/commit switch, but it never states the default value or the semantics of explicitly setting it to true.

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

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

States a specific verb ('Sube') plus the exact resource and source field ('la foto indicada en datos_personales.foto del perfil maestro'), and adds format/size constraints. This clearly separates it from subir-cv by resource type, though it never names that sibling explicitly.

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

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

The second clause explains that without 'aplicar' the tool only previews, which implies the safe-vs-commit usage pattern. However, there is no explicit when-to-use guidance, no mention of prerequisites (logged-in session, existing master profile) and no reference to the alternative 'subir-cv'.

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 does disclose what the read returns (the enumerated profile sections), which implies a non-destructive read, but it says nothing about authentication/session requirements, what happens if the profile is empty or incomplete, or how errors surface.

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 front-loaded sentence with the verb and resource first and the returned sections as a compact trailing list. Nothing is wasted and nothing needs to be re-read.

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

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

For a zero-parameter read tool with no output schema, naming the sections returned is the essential information and it is present. The one meaningful gap is the implied session/auth prerequisite, which matters because a sibling tool handles login.

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 takes zero parameters, so the schema is trivially complete and the baseline applies. There is nothing the description could add on parameter 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?

Specific verb ('Lee') plus a specific resource ('tu hoja de vida actual en elempleo'), with the returned sections enumerated (perfil, experiencia, formación, cursos, idiomas, redes, habilidades, archivos). It is clear what the tool returns, but it never distinguishes itself from the sibling 'ver-perfil-maestro', and the word 'actual' is the only hint about the difference.

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 on when to call this versus the many profile-related siblings (ver-perfil-maestro, construir-perfil-maestro, comparar-perfil, actualizar-perfil). There are also no stated prerequisites, even though 'iniciar-sesion' and 'estado-de-sesion' in the sibling list imply a session is 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?

No annotations are provided, so the description carries the burden; "Muestra" signals a read-only operation and it discloses that the response is diagnostic (ubicación, cumplimiento de esquema, pendientes). It does not say what happens when no master profile has been built yet, nor whether anything is mutated or cached.

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 front-loaded sentence with no filler, listing the three outputs compactly. Slightly under-specified rather than verbose, which is the correct failure mode here.

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 params and no output schema, the description must convey the return shape, and it names three components (ubicación, cumplimiento del esquema estándar, pendientes). Missing only edge-case behavior (no profile present) and the form of the report.

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 takes zero parameters, so there is no parameter semantics to explain; baseline for a no-param tool applies. Schema coverage is 100% and trivially complete.

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

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

Specific verb ("Muestra") plus resource ("perfil maestro") and it enumerates the three things returned: location, standard-schema compliance, and pending confirmations. It does not differentiate itself from near-siblings like ver-mi-perfil or comparar-perfil, so an agent must guess which viewer to pick.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as construir-perfil-maestro (when none exists) or actualizar-perfil (when something is pending). The read-only intent is only implied by "Muestra".

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