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

No annotations exist, so the description carries the full load and does most of it: it discloses session-dependent result breadth (~30 most recent unauthenticated), that filters default from the master profile, and that results carry an applied/already-applied indicator. Pagination behavior and result shape are left unstated, which keeps it short of a 5.

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 ordered by importance: what/where, then session behavior, then default-filter semantics. Every clause carries information an agent needs and there is no filler.

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

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

Given 11 optional parameters, no annotations and no output schema, the description covers the risky parts well: auth state changes results, defaults are inherited from the master profile, and results flag existing applications. It stops short of describing what a returned offer record looks like or how pagination interacts with the ~30-item unauthenticated cap.

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 73% and the description mainly restates what the schema already says about remoto and sin_visa_eeuu (defaults from preferencias.modalidad and datos_personales.pais). It clarifies the effective filtering consequence of those defaults, which is mild added value, but says nothing about orden, pagina, por_pagina, tipo or con_salario beyond their schema entries.

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 ("Busca ofertas") plus the exact source and scope: Work at a Startup, Y Combinator companies, mostly English and US-based. That scope immediately separates it from detalle-de-oferta (needs an id) and mis-postulaciones (already-applied list), so an agent can pick it 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?

Explains the two operating modes clearly: with a session it searches all offers with filters and flags prior applications; without a session it only returns the ~30 most recent. It does not name a sibling to use instead (e.g. detalle-de-oferta for a single posting, evaluar-encaje for fit scoring), so routing is implicit rather than explicit.

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

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

With no annotations, the description carries the full burden and does the key thing: it declares read-only behavior explicitly ('No modifica nada') and enumerates the comparison dimensions. It stops short of stating permissions or output/return structure, but the safety profile is 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?

Front-loaded with the verb and scoped in a single informative sentence plus a short read-only disclaimer. The parenthetical field list is dense but every item earns its place as a comparison dimension.

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, no-output-schema tool, the description conveys what it compares and that it returns a list of corrections. It is nearly complete; only the exact return shape and any auth/data-freshness expectations are missing.

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 schema baseline applies (4). The description does not need to document parameter meaning and correctly stays focused on 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?

Specific verb 'compara' with two clear resources (candidate profile vs master profile) and an enumerated set of fields (años, ciudad, remoto, enlaces, fechas, habilidades). An agent can tell this is a diff/audit tool distinct from siblings like ver-mi-perfil or construir-perfil-maestro, though it doesn't explicitly name the siblings it is not.

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?

'lista lo que conviene corregir' implies the use case (find discrepancies to fix), but there is no explicit when-to-use clause, no exclusions, and no named alternative such as ver-perfil-maestro or construir-perfil-maestro.

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 load and does well: it discloses the crucial non-side-effect ('No guarda nada') and the persistence path via a sibling. It explains return behavior per input mode. Minor gap: no mention of permissions or failure modes (e.g., unreadable PDF).

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 core purpose and the no-save caveat come early, and the per-mode details follow logically. Slightly packed into one paragraph, but no sentence is 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?

No output schema exists, yet the description describes what is returned for each invocation mode, and it clarifies the persistence boundary relative to a sibling. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3; the description adds value by explaining the effect of each input type—a PDF yields extracted text plus schema and JSON rules, while a LinkedIn URL only triggers export instructions. This meaningfully augments the schema prose.

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 (creates) and resource (master profile), with inline definition of what that profile is ('fuente única de tus datos'). It explicitly distinguishes itself from guardar-perfil-maestro by noting that this tool does not persist anything.

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 scopes usage to 'when it doesn't yet exist' and clearly routes the follow-up action to guardar-perfil-maestro after confirmation. It also spells out three invocation modes (no args, PDF, LinkedIn URL) so the agent knows what each input yields.

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 behavioral burden. "Devuelve" plus a detailed field list implies a read-only, comprehensive fetch, but it says nothing about auth requirements, what happens with an unknown slug, or whether the offer list is truncated/paginated — real gaps for a no-annotation 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?

One front-loaded sentence that earns its length, since the field enumeration is what tells the agent whether this tool covers its information need. No filler or repetition of the tool name.

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

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

With no output schema and no annotations, the description usefully enumerates the returned payload, which is the key missing structured information. A brief note on failure behavior for bad slugs would close the remaining 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?

Single parameter with 100% schema description coverage, where the schema already explains the slug format and the /companies/<slug> URL alternative. Baseline would be 3, and the description corroborates that the identifier resolves to one startup, so no meaning is lost.

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 Spanish verb ("Devuelve") plus the exact resource, then enumerates the returned fields (YC batch, description, size, founders, stack, hiring, open offers). This clearly separates it from detalle-de-oferta, which covers a single offer rather than the whole company. It stops short of naming any 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?

Usage is only implied: an agent can infer it should be called when company-level context is needed, but there is no statement of when to prefer buscar-ofertas or detalle-de-oferta, and no prerequisite (e.g. requiring a valid slug or session) is mentioned.

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

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

With no annotations, the description carries the burden, and it does well by disclosing the full contents of the response (salary, equity, visa, interview process, application questions). It omits error behavior for an invalid id and any auth/session requirement, keeping it from a 5.

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 led by the verb, with the payload enumerated compactly. The field list is long but each item conveys what the caller gets back, which is needed since no output schema exists.

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?

Because there is no output schema, enumerating the returned fields in the description is exactly the right compensation and it is done thoroughly. Missing only failure modes (invalid id, access restrictions) to be fully complete.

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

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

Schema description coverage is 100% and the single parameter already documents that it accepts a numeric id or a full URL. The description adds nothing about the parameter, 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 ('Devuelve') and resource ('la oferta completa') and enumerates the returned fields, which makes it distinguishable from buscar-ofertas and detalle-de-empresa. It stops short of explicitly naming those siblings as alternatives, so a 4 rather than 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?

Usage is only implied: the agent can infer this is the single-offer detail lookup to use after a search. There is no explicit 'use this when...' guidance, no exclusion of buscar-ofertas, and no note about prerequisites such as being logged in.

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 cookies and credentials are never shown, which is meaningful privacy behavior, but it does not explicitly state read-only/no-side-effect behavior, auth prerequisites, or what happens when no session exists.

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

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

The description is two efficient sentences: the primary status/count purpose is front-loaded, followed by a relevant privacy note. There is no wasted material.

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 zero-parameter tool with no output schema, the description covers the core return concepts: session validity and weekly application count, plus a privacy guarantee. It could say more about the exact return shape or behavior when no session is active, but it is largely 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 tool has zero parameters, so there are no parameter semantics for the description to clarify. The baseline for a zero-parameter 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?

The description states a specific verb and resource set: it indicates whether a Work at a Startup session is active and how many applications remain this week. This clearly distinguishes it from iniciar-sesion, which would initiate a session rather than report status and quota.

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 what the tool does but does not say when to use it versus iniciar-sesion or other siblings, nor when not to use it. The agent must infer its role as a pre-check from the purpose alone.

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

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

With no annotations, the description does real work: it discloses the full rule set evaluated, the conditional salary check, and the categorical output including motivos. What it omits is the operational side — whether it is read-only, what happens if no master profile exists (error vs partial evaluation), and whether the evaluation is deterministic. Those gaps matter for a no-annotation 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 tight sentences: the criteria enumeration is front-loaded and the return contract closes it. Every listed criterion earns its place because it tells the agent what the verdict will be based on, though the run-on enumeration is dense rather than scannable.

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 naming the three verdict values and mentioning motivos, which is what the agent needs to interpret the result. For a one-parameter tool this is nearly complete; the missing prerequisite (an existing master profile) is the one real hole.

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 already documents that it accepts a numeric id or a workatastartup.com job URL. The description adds nothing about that parameter. Baseline 3 applies when the schema carries the full burden.

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 (compara la oferta con el perfil maestro) and enumerates the exact criteria checked — modalidad, país, visa, tipo de empleo, experiencia, salario, tecnologías, inglés — plus the three possible verdicts. It is clearly distinct in substance from detalle-de-oferta (raw offer data) and comparar-perfil, though it never names a sibling to route against.

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 this is the pre-application screening step, and the description does flag one conditional rule (salary is only checked if preferencias.salario_minimo_usd_anual is declared). But there is no explicit 'use when' / 'use instead of', and no statement that a master profile must already exist (construir-perfil-maestro / guardar-perfil-maestro are siblings that would matter).

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 provided, the description carries the full burden and discloses useful behavior: it opens a visible Chromium browser, supports manual login via email link, password, or Google, auto-saves if an existing session is present, stores cookies in the MCP data folder, and closes the window. It does not cover what happens if the user fails to log in within the timeout, but overall it is transparent about the key side effects.

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 front-loaded with the main action, then covers session auto-save and cookie/cleanup behavior in three tight sentences. Every sentence contributes useful information without 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 browser-based interactive login tool with no output schema and only one optional parameter, the description gives enough context to invoke it correctly: what browser opens, what the user does, how sessions are persisted, and that the window closes. It could be more complete by describing timeout failure behavior or expected return, but it is largely 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?

The single optional parameter 'espera_max_segundos' has complete schema description coverage (100%), so the schema already documents its meaning, range, and default. The description adds no additional parameter semantics, making the baseline 3 appropriate.

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

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

The description states a specific action and resource: opening a Chromium-based browser at the Y Combinator login so the user can authenticate manually. It is clear what the tool does, but it does not explicitly differentiate itself from the sibling tool 'estado-de-sesion' or other session-related tools.

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

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

The description implies the tool is used when the user needs to log in manually, and it notes that an existing MCP browser session will save automatically. However, it does not explicitly state when to use this tool versus alternatives such as checking session status with 'estado-de-sesion', nor does it give exclusions or preconditions.

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; 'Lista' plus the enumerated fields make clear this is a read-only, user-scoped retrieval of application data. It does not disclose authentication requirements, ordering, pagination/limits, or what happens when the user has no applications, which are the remaining behavioral gaps.

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

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

One front-loaded sentence that names the resource first and then the returned content; every clause adds substance rather than restating the name. Slightly dense with parentheticals ('y si les respondiste'), 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?

With no parameters, no annotations and no output schema, the description's enumeration of returned fields effectively substitutes for an output schema and tells the agent exactly what it will get. Nothing needed to invoke it correctly (it takes no arguments) is missing.

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; baseline 4 applies. The description correctly implies a single, argument-free call covering the whole application history.

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 clearly bounded resource ('las empresas a las que te postulaste en Work at a Startup'), then enumerates what the listing contains (fecha, ofertas, respuestas, cupo semanal, fundadores que escribieron primero). This is inherently distinguishable from sibling read tools like buscar-ofertas (search available offers) or detalle-de-empresa (single company), since the scope is the user's own application history.

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 usage (review your application status and inbound founder outreach), but the description never says when to pick this over buscar-ofertas or detalle-de-oferta, nor states preconditions such as being logged in. Usage is inferable rather than 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: it discloses irreversibility, quota consumption, and the confirmation gate. It does not say what the call returns on success (application id, status) or what happens on failure, which leaves a gap for a destructive, quota-limited mutation.

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, then cost/irreversibility, then the confirmation rule, then the one-at-a-time constraint. Every sentence carries decision-relevant information, though the description is dense enough to read as a block rather than a scannable structure.

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 the side effects an agent needs before a destructive, quota-limited write: cost, irreversibility, confirmation requirement, and batching of message plus answers. Missing only the return/outcome behavior, which matters more here because there is no output schema to fall back on.

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 five parameters are already documented, including the exact `confirmacion` format and the meaning of `abierto_a_reubicacion`. The description restates the confirmation format and the required user approval for message/answers but adds no syntax or edge-case 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?

Names a specific verb (envía) and resource (la postulación), and spells out what it submits: the message plus answers in a single request. It is clearly distinct from siblings like proponer-respuestas or preguntas-de-postulacion, which prepare the pieces this tool consumes.

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 preconditions (explicit user confirmation for that specific offer, exact format "POSTULAR <id>") and the constraints (one offer at a time, no automatic retries). It also gives the cost trade-off (1 of 5 weekly applications), which lets an agent judge whether to call it now.

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 declares the session requirement and explicitly marks the tool as non-mutating ("No envía nada"), and it discloses the concrete return payload including the 5-applications-per-week limit. It doesn't cover error behavior for an invalid offer id, but the read-only and auth profile is 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?

One dense sentence with a parenthetical, front-loaded with the core verb and ending with the key read-only guarantee. Every clause carries distinct information (session, quota, message, questions), though the enumeration is packed tightly.

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 and no annotations, the description covers the essential ground: auth requirement, return content, quota, and non-mutating status. Only edge-case behavior (invalid or nonexistent offer) is left 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 as a numeric id or workatastartup.com job URL. The description adds nothing about the parameter, so the baseline 3 applies since the schema does all the work.

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

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

The description opens with a specific verb-resource pair ("Lee cómo se postula") and enumerates exactly what is returned: application status, the 5-per-week quota, the mandatory founder message, and the company's questions with their options and limits. This goes well beyond the name "preguntas-de-postulacion," which only mentions questions. The closing "No envía nada" implicitly separates it from the apply sibling.

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

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

A precondition is stated ("requiere sesión"), which correctly routes an unauthenticated agent toward iniciar-sesion. The phrase "No envía nada" implies that actually submitting belongs to postular-a-oferta, but that alternative is never named and no explicit when-not condition is 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 burden and does well: it discloses that the tool never invents data and never sends anything, which tells the agent this is a safe, non-mutating draft generator. It also surfaces the classification outcome categories (respaldada, requiere_confirmacion, sin_respaldo). It does not say whether drafts are persisted or what the response shape is, so it is 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?

One dense but well-ordered sentence: action and outputs first, constraint sentence second. Every clause (language, source, classification) carries information; 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 single-parameter tool with no annotations and no output schema, the description covers purpose, inputs source, output categories, and safety constraints. Minor gaps remain around prerequisites (must the master profile pre-exist?) and whether results are stored for postular-a-oferta to use.

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

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

Schema description coverage is 100% and the single parameter (oferta, numeric id or workatastartup URL) is fully documented in the schema. The description adds no parameter-level detail, so 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 specific verbs and outputs: drafts a message to founders and answers to application questions, in English, from the master profile, and classifies each answer. This is clearly distinguishable from siblings like preguntas-de-postulacion or evaluar-encaje, 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?

Usage is implied by 'a partir del perfil maestro' (i.e., use it after the master profile exists), but there is no explicit when-to-use/when-not guidance and no alternative tool is named for related tasks like fetching questions or submitting the application.

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 read-only, self-scoped operation by listing returned fields, but it doesn't state behavior when no profile exists, whether authentication is required, or that no mutation occurs.

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 scope first, followed by the field enumeration. The long list of fields earns its place as a stand-in for an output schema, though it is dense.

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 parameters, the description's enumeration of returned profile sections is exactly the missing information an agent needs. It stops short of noting edge cases like an empty or unset profile.

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 and there is nothing for the description to clarify. It correctly avoids inventing input 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?

States a specific verb ('Lee') and a scoped resource ('tu perfil de candidato en Work at a Startup'), then enumerates the exact profile sections covered. It clearly separates the candidate profile from other resources, though it doesn't explicitly distinguish itself from the sibling ver-perfil-maestro (master profile).

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 framing 'tu perfil' implies this is for reading the caller's own profile, but there is no explicit when-to-use, when-not-to-use, or reference to the alternative (ver-perfil-maestro, comparar-perfil). Usage is left to inference from the name and description.

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.