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 the dry-run default, that writes go through a backup in ~/.magneto/respaldos/, and critically that only ids listed in eliminar_ids are deleted. What is not stated is what the response looks like beyond a 'plan' or what happens if a section is empty.

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 dense sentences, front-loaded with the dry-run behavior before the write mode. Every clause carries operational value ('antes → después', backup path, delete scoping). Slightly packed with Spanish technical detail, but nothing is wasted.

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 3-param, no-annotation mutation tool, this covers the essential gaps: dry-run default, safe-write backup, and delete scoping. The lack of an output schema is partly offset by describing the plan as 'antes → después', though more on the save response could help.

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% (seccion enum has no schema description), so the description meaningfully compensates: 'aplicar=true respalda... y guarda' explains semantics beyond the type, and 'Solo borra los ids indicados en eliminar_ids' clarifies the delete scope. Useful added meaning over 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 and resource: 'Actualiza una sección de la hoja de vida desde el perfil maestro'. An agent can infer this derives a CV section from the master profile. It does not name a specific sibling for contrast, but the source relationship to perfil maestro implies a distinction from guardar-perfil-maestro/construir-perfil-maestro.

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

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

The description explains the two modes explicitly: without 'aplicar' it returns a plan to show the user, and with aplicar=true it backs up and saves after user confirmation. The 'para mostrarlo al usuario' and 'tras la confirmación del usuario' give clear workflow conditions, but no sibling alternatives are named.

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 disclose genuinely non-obvious behavior: optional auth with a session-dependent extra field, and the important caveat that Magneto does not publish modality per offer (the filter is portal-level, inferred from text in detail). It omits rate limits and pagination limits, keeping it below a 5, but the modality gotcha is valuable behavioral context.

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

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

Three dense sentences with the core purpose front-loaded, then auth behavior, then the modality caveat. No filler, though the modality sentence is syntactically dense enough to require a second 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?

With 8 parameters, no annotations, and no output schema, the description should sketch what a search result looks like and mention pagination (pagina/por_pagina exist but are unexplained). It covers purpose and one data caveat well but leaves the result shape undiscussed, which matters given the absence of an 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 50%, so half the parameters (orden, pagina, por_pagina, contrato) are undocumented in both schema and description. The description partially compensates for modalidad by explaining that the filter is portal-derived and defaults from profile preferences, but adds nothing for the other four parameters.

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

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

States a specific verb+resource+site: "Busca ofertas en Magneto (magneto365.com, Colombia)", which is clearly distinct from sibling tools like mis-postulaciones or detalle-de-oferta. It does not explicitly name a sibling to avoid, but the search purpose is unmistakable.

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 context ("Funciona sin sesión; con sesión indica si ya te postulaste") which tells an agent it can be called unauthenticated and what extra info login unlocks. However it never states when to use this vs detalle-de-oferta, postular-a-oferta, or evaluar-encaje, and gives no 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 the shape of the output (missing, outdated, extra, recommended fixes), which is helpful, but it never says whether the operation is read-only or whether it changes anything, nor what 'corregir en la web' actually triggers. That ambiguity is a real gap 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?

A single, front-loaded sentence that enumerates the four output categories with no padding. The trailing clause 'lo que conviene corregir en la web' is slightly vague but does not waste much space.

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, the description should describe return values, and it does list the four comparison categories. However, it omits prerequisites (existing CV/profile), the source of the 'perfil maestro', and whether the result is advisory only, leaving gaps for a tool that performs a multi-source comparison.

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

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

The input schema has zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. The description correctly implies the tool is parameterless, operating implicitly on the session user's data.

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: it compares the user's Magneto CV against the master profile and enumerates gaps, outdated items, extras, and fixes. This is clearly distinguishable from siblings like listar-mis-cv or ver-perfil-maestro. It stops short of naming those siblings, but the comparison scope is unique enough for an agent to tell it apart.

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

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

Usage is implied rather than stated: an agent can infer this is for auditing one's CV against the master profile, but there is no explicit 'use this when / not when' guidance, no mention of prerequisites (e.g., that a CV and master profile must already exist), and no reference to any alternative tool.

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

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

No annotations are supplied, so the description carries the full burden, and it does: it declares the tool has no side effects ("No guarda nada"), names the sibling that performs the write, and describes the response contents (extracted text, standard schema, JSON rules) despite there being no output schema. For a non-persisting draft tool, that covers the traits an agent actually 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 sentences, purpose front-loaded, and every sentence carries information: what it creates, what to ask for, what each input yields, and what it does not do. No filler or restated metadata.

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 five optional params, no annotations, and no output schema, the definition covers the critical facts: no persistence, the save sibling, and the shape of the returned material. It remains silent on the texto and desde_portal paths and on failure modes (invalid PDF, unavailable LinkedIn URL), which keeps it from being 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%, so the structured field documentation already carries the baseline. The description adds conditional behavior for cv_pdf and linkedin_url (and mentions the photo in the no-args flow), but says nothing about how the texto or desde_portal parameters behave or how inputs combine — a partial supplement rather than full compensation.

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") and adds a scoping clause ("cuando aún no existe") that makes it distinguishable at a glance from ver-perfil-maestro, actualizar-perfil, and guardar-perfil-maestro. An agent can tell what it produces (a draft/schema) versus what it persists 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?

Gives the use condition (only when the master profile doesn't exist yet), the behavior for each input mode ("Con un PDF...", "con solo la URL..."), the zero-argument path, and explicitly routes saving to guardar-perfil-maestro after user confirmation. That is a real when-to-use / when-not / alternative mapping rather than implied 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the returned content and flags that 'modalidad' is inferred rather than raw data, which is real value-add. It says nothing about behavior when the offer is not found, whether the data is live or cached, or any auth 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?

One front-loaded sentence with a concrete field list and zero filler. Every clause carries information an agent can use.

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 must convey the return shape, and it does so by enumerating the fields. Only error/not-found behavior and freshness are missing, which are minor for a single-offer read 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% and the single 'oferta' parameter is documented in detail (id, slug, or URL, as returned by buscar-ofertas). The description itself adds no parameter information, 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 (devuelve la descripción completa de una oferta) and enumerates the fields returned, so an agent can tell it fetches full detail for one offer. It does not name the sibling it complements (buscar-ofertas), which the schema does instead, so the differentiation is only 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?

There is no explicit when-to-use statement or exclusion; the implication is that this is the follow-up to a search result for a single offer, reinforced only by the word 'completa'. Usage is inferable but never stated.

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

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

With no annotations, the description does meaningful work: it discloses the 24-hour token lifetime and explicitly guarantees that no tokens or cookies are ever returned, which is exactly the kind of behavioral constraint an agent needs. It stops short of saying whether the call is side-effect free or whether it refreshes/extends the session, so it is good but not fully transparent.

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

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

A single compact sentence, front-loaded with the primary answer (session validity) and followed by the secondary payload and the security guarantee. Nothing is padded or redundant.

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

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

For a parameterless, read-only status check with no output schema and no annotations, the description covers the essential facts: what it reports, the token horizon, and what it will never expose. The absence of any hint about the returned shape (boolean vs. message, how CV state is represented) is the only 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?

The tool takes zero parameters and the schema is trivially empty, so there is nothing for the description to clarify; baseline 4 applies. No misleading parameter expectations are introduced.

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 check: whether a Magneto session is active and the state of the 'hoja de vida', which an agent can distinguish from 'iniciar-sesion' (which presumably starts a session). It is clear but never names a sibling explicitly or clarifies the boundary with 'ver-mi-perfil' / 'listar-mis-cv', which also expose profile/CV state.

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?

Usage is only implied: an agent can infer it should call this to check login status before authenticated operations, but the description never says when to use it, when not to, or how it relates to 'iniciar-sesion'. No prerequisites or ordering guidance 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 provided, the description carries the full behavioral burden. It usefully discloses the comparison criteria and the three possible result labels, but it does not state whether the operation is read-only, whether it requires an existing master profile or login, or whether any state is modified.

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 efficiently states the comparison basis and the possible outputs. It is dense but appropriate for the tool's scope, with no redundant 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 one-parameter computation tool with no output schema, the description explains the outcome categories and the comparison criteria reasonably well. It still omits important context such as whether a master profile must already exist, whether authentication is required, and what the "motivos" structure contains.

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 the single parameter at 100% coverage, including valid forms such as id, slug, or URL and a concrete example. The description does not add further syntax or formatting details beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description names a specific action ("Compara") and the resources involved: the offer versus the master profile and its preferences. It also states the returned outcome labels, so the agent can understand what the tool produces without opening a schema. It does not explicitly distinguish itself from the sibling tool "comparar-perfil", which is the main remaining 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 the tool is used to evaluate whether an offer fits the stored profile and preferences. However, it does not explicitly say when to use it instead of siblings such as "comparar-perfil" or "detalle-de-oferta", nor does it state prerequisites such as needing a saved master profile or an authenticated session.

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 substantial work: it discloses that a real browser window opens, that a human must complete authentication (email code, Google, Microsoft, LinkedIn), that the token is written to the MCP data folder, and that the window closes afterward. These are meaningful side effects an agent could not infer from the schema. It stops short of saying whether the call blocks until the user finishes or what happens on timeout.

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 sentences, front-loaded with the action and the browser types, then the fast-path for an existing session, then the persistence/cleanup outcome. Dense with no filler, though the parenthetical list of auth providers is marginal 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 tool with no annotations and no output schema, the description covers the side effects and auth mechanics well, but never indicates what the call returns (success flag, token location, error on timeout) — an agent cannot tell how to detect failure versus a user who simply walked away. The absence of a check-first recommendation relative to estado-de-sesion is also a gap for a session-initiating 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?

The single parameter has 100% schema description coverage including default (300 s) and the 30–900 bounds, so the schema does the heavy lifting and the baseline 3 applies. The description adds nothing about the wait parameter even though it is directly relevant to the blocking browser flow it describes.

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 opens a Chromium-based browser at the Magneto login page so the user can authenticate manually, then persists the token. The auth-flow nature clearly separates it from data-retrieval siblings like buscar-ofertas or listar-mis-cv. It never names estado-de-sesion, so the boundary with that sibling 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?

Usage is implied rather than stated: the note that an existing session 'se renueva sola en segundos' hints the tool is safe to call when already logged in, and the manual-login framing implies it is the entry point of the auth flow. There is no explicit 'use this when X, use estado-de-sesion when Y' routing, and no prerequisite stating whether a check-first step is advised.

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 and no output schema, the description carries the full disclosure burden and falls short: it doesn't say what "muestra" returns (file, URL, parsed text), what happens when no CV is attached, or whether a session is required. The name implies a list ("listar") while the description implies a single attached CV, adding ambiguity.

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 action front-loaded and no filler. It is efficient, though its brevity is arguably part of the under-specification problem captured elsewhere.

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 trivial zero-param read tool this may be sufficient, but with no output schema and no annotations, the agent has no idea what the returned payload looks like, which is the tool's entire value. A clause about the returned CV representation would close the 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?

Zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. The description correctly implies no input is required.

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 has a clear verb+resource combination ("Muestra el CV adjunto") and distinguishes itself from the write-oriented sibling subir-cv. It does not explicitly name or contrast any sibling, but the read/display intent versus upload is inferable from verb choice.

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 call this versus alternatives such as ver-mi-perfil or ver-perfil-maestro, which likely also surface CV-related info. No prerequisites (e.g., session/auth or a previously uploaded CV) 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 full burden. It implies a per-user read ("tus") but says nothing about authentication requirements, whether results are paginated, how many records per page, ordering, or what the status field contains. Only "con su estado" gives any behavioral hint.

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 tightly written sentence with zero padding; no wasted words. It is perhaps under-sized for a tool whose only parameter is undocumented, but nothing in it is dispensable.

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 list tool this is borderline: no output schema and no annotations, so the description should at least state pagination behavior, result shape/ordering, and the login requirement. It provides none of these, leaving the single parameter entirely opaque.

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

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

There is one parameter ("pagina") with 0% schema description coverage — undocumented in both the schema and the description. The description says nothing about paging, page size, or defaults, so the coverage gap is not compensated.

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 ("Lista") and a specific resource ("tus procesos (postulaciones)"), clarified with the Spanish/English gloss and the Magneto context. It is inferably distinct from listar-mis-cv, though it never names that sibling to draw the contrast 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?

There is no when-to-use guidance, no mention of alternatives such as listar-mis-cv (CVs) or detalle-de-oferta, and no note about prerequisites like being logged in. The agent must infer everything from the 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 usefully discloses that it is a single-shot submission with no retry logic and a strict confirmation gate. It still omits what an agent most needs for a mutation with real-world consequences: irreversibility/withdrawal, duplicate-application behavior, and what happens on partial 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?

Three dense sentences, front-loaded with the action and then the hard confirmation constraint. Every sentence carries a rule; 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 an irreversible, annotation-free mutation with no output schema, the description covers the confirmation gate and retry ban but says nothing about failure modes or what the call returns. It is adequate but leaves real gaps for a consequential write 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 coverage is 100%, so all three parameters are already documented, including the confirmacion format and the optional respuestas array. The description reinforces the exact 'POSTULAR <id>' confirmation and that answers are optional but adds no format or constraint 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?

States a specific verb and resource: it submits the application together with questionnaire answers in a single request. An agent can distinguish it from preparers like proponer-respuestas or readers like mis-postulaciones from the description alone, though no sibling is named 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?

Preconditions are clear (user must have explicitly approved THAT offer, one offer per call, no automatic retries), which implies when to call it. However, it never names alternatives or points to the preparatory tools (preguntas-de-postulacion, proponer-respuestas) that must precede 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?

With no annotations, the description carries the full load and does well: it declares the tool read-only ("No envía nada"), flags the session/auth requirement, and describes the state it inspects before applying. It stops short of saying what happens when the session is missing or the offer id is invalid.

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 that front-loads the verb and the resource, then packs the return contents and the non-mutating guarantee without a wasted clause.

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?

No output schema exists, and the description compensates by enumerating the returned fields (applied state, extra data, questionnaire with options and limits). Only error behavior for an invalid offer or expired session is unaddressed.

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% and the single `oferta` parameter is already documented there with accepted forms (id, slug, URL). The description adds no format or validation detail beyond the schema, 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 ("Lee") plus the exact resource ("cómo se postula a la oferta") and then enumerates what it returns: applied status, extra-data requirement, and filter questionnaire fields with options and limits. The closing "No envía nada" cleanly separates it from the sibling postular-a-oferta, which does submit.

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?

"requiere sesión" gives an explicit prerequisite, and "No envía nada" implies the read-before-write workflow with postular-a-oferta and proponer-respuestas. It never names those siblings or states an exclusion outright, so the routing is clear but left partly 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 behavioral burden. It discloses two important traits — no invented data and no sending — and explains the classification labels, but it does not clarify authentication needs, persistence, or the exact response shape.

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. It establishes the action, source, classification, and safety constraint in one pass.

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 tool with no output schema and no annotations, the description covers the core behavior and safety constraints well. It is slightly incomplete on prerequisites and how it relates to preguntas-de-postulacion, but nothing essential 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?

The single parameter 'oferta' is fully documented in the schema, including id/slug/URL and its relation to buscar-ofertas. The description adds no extra meaning beyond that, so the baseline of 3 is appropriate for 100% 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?

States a specific verb and resource — proposing answers to the filter questionnaire — and names the source (master profile) plus the classification output. The final clause 'nunca envía nada' implicitly separates it from sibling postular-a-oferta, so an agent can tell what this tool does and does not do.

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?

Usage is implied: it is for answering the filter questionnaire from the master profile and explicitly not for sending anything. However, it never states when to call it versus preguntas-de-postulacion or postular-a-oferta, nor does it spell out prerequisites such as having a master profile.

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 discloses key behavior: Magneto stores only one CV and replaces the current one, and without applying it only previews the effect. It does not cover permissions, authentication, or return details, but the core mutation and dry-run semantics are clear.

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 concise sentences, front-loaded with the action and key constraint. It is efficient, though the parenthetical about cv_pdf adds slight ambiguity.

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

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

The description covers the essential upload, replace, and dry-run behavior, which is important for a mutation tool with no annotations. However, without an output schema, it does not explain what the preview returns or any permission requirements, leaving some 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 50%; version is already documented in the schema, and the description adds context about multiple versions. The description also clarifies aplicar as a dry-run toggle, compensating for the missing schema description, but it does not fully explain all parameter behavior.

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: uploading a PDF CV to the master profile. It is distinguishable from siblings such as listar-mis-cv and subir-foto, though it does not explicitly contrast with 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 upload/replace use case is implied, and the dry-run behavior is mentioned, but there is no explicit guidance on when to use this tool versus alternatives like listar-mis-cv or when not to use it.

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

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

With no annotations at all, the description carries the full burden and does meaningful work: it discloses the accepted formats (JPG/PNG), a 5 MB size limit, the source field, and dry-run behavior when not applying. It omits whether an existing photo is overwritten and what authentication or profile state is required.

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, no filler, with the resource and constraints front-loaded before the dry-run caveat. Slightly dense parenthetical for formats and size but nothing wasted.

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?

No annotations and no output schema mean the description must be self-sufficient; it covers inputs and the preview mode but not the default value, overwrite behavior, error cases, or what a successful preview returns. Adequate to call, not fully sufficient to predict results.

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

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

Schema coverage is 0% and the single parameter 'aplicar' is never named, but the phrase 'sin aplicar' conveys its semantics well enough for an agent to set it. The default when the parameter is omitted (0 required parameters) is left unspecified, which is the main 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?

States a specific verb+resource: it takes the photo at datos_personales.foto of the master profile and sets it as the profile picture. The resource (foto de perfil) is distinct from sibling upload tools like subir-cv, though the description never names or contrasts them 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?

'Sin aplicar solo muestra lo que haría' implies the preview/dry-run path exists, but the agent must infer it is the thing to call before committing. No guidance on when to prefer this over ver-mi-perfil or subir-cv, and no prerequisites (e.g. needing a master profile or active session).

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. 'Lee' clearly signals a read-only operation, and the field list discloses what is returned, but it does not mention authentication requirements, behavior when no profile exists, or whether the data is live 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?

One front-loaded sentence with the verb first and a compact enumeration of returned fields. Every element earns its place, and there is no filler.

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

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

For a zero-parameter read tool with no output schema, the description usefully enumerates the return contents. It could still say more about auth requirements or behavior when the profile is absent, but the core call context 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 takes zero parameters and the schema is empty, so there is no parameter semantics to explain. This is the expected baseline for a no-argument read 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?

States a specific verb ('Lee') and resource ('tu hoja de vida actual en Magneto') and enumerates the returned fields. It does not explicitly differentiate itself from nearby siblings such as ver-perfil-maestro or listar-mis-cv, so it stops short of a 5.

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 reading the current profile but gives no when-to-use guidance, no exclusions, and no mention of alternatives like ver-perfil-maestro or listar-mis-cv. An agent must infer when this tool is preferable to those siblings.

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.