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

With no annotations, the description carries the burden of disclosing behavior. It reveals that the tool validates routes against the OpenAPI spec, acts as a fallback, and has a multipart/form-data nuance. It does not mention authentication, rate limits, or error handling, but for a generic API passthrough these are secondary. The disclosed behaviors are meaningful and not obvious from the schema alone.

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, each earning its place: the first states the core function, the second gives usage context and exclusions, the third warns about a critical parameter misuse. Information is front-loaded and the warning is an appropriate last note. No filler or redundancy.

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

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

Given the tool is a generic API caller with no output schema and no annotations, the description covers the essential usage aspects: what it does, when to use it, how to discover routes, and a key parameter pitfall. It does not enumerate all possible endpoints, but that would be impractical; the reference to the OpenAPI spec and sibling discovery tool suffices. Slightly more detail on auth/errors could push it to 5, but it is complete for its intended breadth.

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 60% (only body and ruta have explicit descriptions), so the description adds value by clarifying the 'form' vs 'body' distinction and giving an example ruta ('/v2/requests'). It does not explain 'metodo' or 'query', but their meanings are largely inferable from names and enum values. Overall, the description compensates for the schema's gaps without re-stating what is already clear.

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

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

The description clearly states it 'Llama cualquier endpoint de la API de Pandapé validando la ruta contra el spec OpenAPI' – a specific verb (calls), resource (any Pandapé API endpoint), and distinguishing scope (validates against OpenAPI). It also explicitly contrasts with named sibling tools, positioning itself as the catch-all fallback. This fully distinguishes it from the sibling 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?

Provides explicit when-to-use guidance: 'Úsalo para lo que no cubren las tools con nombre' and lists example resource types. It also directs users to 'Descubre rutas con pandape_endpoints' for route discovery and warns about multipart/form-data requiring 'form' instead of 'body'. This gives clear decision-making context and avoids ambiguity with specialized 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?

With no annotations provided, the description carries full behavioral burden. It discloses the cookie-based session requirement (PANDAPE_CV_URL + PANDAPE_COOKIE(_FILE)), states that the official API does not expose CVs, and explains the return value (local path). This gives the agent sufficient context about authentication and operational constraints.

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, each earning its place: purpose, required environment/limitation, and use cases. No redundant wording, front-loaded with the main action. Excellent conciseness and 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?

Given the tool's complexity (custom auth, unofficial behavior, specific output), the description covers all essential aspects: what it does, prerequisites, limitations, when to use vs. alternatives, and return format. Even without an output schema, the description states the local path return.

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 parameters are already well documented in the schema. The description adds no parameter-specific detail, but it doesn't need to; the schema already explains idMatch, idCandidato, and nombreArchivo. Baseline 3 is appropriate because the description does not add semantic value beyond the structured field descriptions.

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

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

The description opens with a specific verb and resource: 'Descarga el documento del CV (PDF) de un candidato' (Downloads the CV PDF document of a candidate). It clearly distinguishes itself from siblings by noting that the official API doesn't expose the CV and that pandape_revisar_candidatos provides structured CV data, while this tool gets the original document.

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?

Explicit usage guidance is provided: 'Para clasificar candidatos por criterios normalmente NO lo necesitas' (for criteria-based screening you normally don't need it) and 'Usa esto cuando necesites el documento original' (use this when you need the original document). It also names the alternative tool pandape_revisar_candidatos.

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 burden of behavioral disclosure. It discloses key behaviors: verifies credentials, token, and performs a real test call ('una llamada real de prueba'). While it doesn't explicitly confirm read-only behavior or describe the output format, it provides meaningful transparency about what the tool actually does beyond a generic 'check'.

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, action-focused sentence that immediately states the verb and purpose. It is concise, well-structured, and every part adds value: what is verified, the specific components (credentials, token, real call), and the usage priority.

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 diagnostic tool with no output schema or annotations, the description is largely complete. It explains the purpose, what is checked, and when to use it. It could enhance completeness by briefly stating what the result looks like or how to interpret the diagnostic, but that is not critical for selection and 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 tool has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameter meaning, and no additional parameter context 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 uses a specific verb 'Verifica' (verifies) and clearly identifies the resource: configuration and connectivity with the Pandapé API, including credentials, token, and a real test call. This distinguishes it from sibling tools like pandape_listar_vacantes or pandape_revisar_candidatos, which focus on data operations rather than diagnostics.

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

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

The description gives explicit usage guidance: 'Úsalo primero si algo falla' (Use it first if something fails), clearly indicating when to invoke this tool. It lacks explicit statements about when not to use it or named alternatives, but the diagnostic context and 'primero' make the intended usage clear.

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

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

No annotations are provided, so the description carries the full burden. It clearly indicates a read operation ('Lista') and adds context about being the unique official API exposure. However, it lacks details on error handling, authentication requirements, or behavior with invalid IDs, which are not covered elsewhere.

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 concise sentences that convey purpose, scope, and a unique caveat without any waste. Every word contributes meaningful information.

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

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

For a simple list operation with one parameter, the description covers the main behavior and result type (download links). It does not describe output structure or pagination, but given the simplicity and the explicit mention of links, it is mostly complete. A fuller description would mention error cases or empty result behavior.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the concept of a pre-colaborador, which clarifies the meaning of idPreColaborador, but does not explicitly discuss where to find the ID or any validation rules. The description adds some context beyond the raw schema.

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

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

The description clearly states the tool lists documents of a pre-colaborador (candidate in hiring process) with download links. It also distinguishes from siblings by noting this is the only case where the official API exposes documents.

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 this is the only tool for accessing documents, which indirectly tells the agent when to use it. It could be improved by explicitly stating when not to use it or naming alternative tools, but the 'only case' phrasing provides strong 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?

Since no annotations are supplied, the description must disclose behavior on its own. It discloses the return format (método, ruta, parámetros, content-type) and uses 'Explora' and 'Devuelve', which imply a read-only operation. However, it omits any statement about side effects, authentication, or response size limits, leaving some uncertainty for a tool with no annotation safety hints.

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 exceptionally concise, using two sentences to convey purpose, scope, output, and usage guidance. It front-loads the main action, includes a useful enumeration of covered categories, and ends with a clear pointer to the sibling tool. Every sentence earns its place with no redundancy.

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

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

Given its simplicity (one optional filter parameter, no output schema), the description is quite complete. It explains the domain coverage (68 routes across many entity types), the returned fields, and how to apply the result with pandape_api. Missing only explicit mention of how the optional filter works (covered by the schema) and any pagination behavior, but these are not critical for a catalog listing 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 only parameter 'buscar' has a complete schema description (100% coverage) explaining its filtering behavior and providing examples. The tool description itself does not mention this parameter, but per the rubric, high schema coverage yields a baseline of 3. The description adds no extra meaning beyond the schema.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Explora el catálogo de endpoints de la API de Pandapé'. It distinguishes itself from sibling tools like pandape_api (which executes calls) by focusing on exploration and listing the returned data (method, route, parameters, content-type).

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

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

The description provides clear context that this is a discovery tool and explicitly directs the user to use its result with pandape_api ('Usa el resultado con pandape_api'). However, it does not explicitly state when not to use it or compare it to alternative sibling tools, so it falls short of a perfect 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?

Sin anotaciones, la descripción asume la responsabilidad de indicar que se trata de una operación de solo lectura mediante el verbo 'Lista'. Además, detalla los campos que devuelve (IdVacancyFolder, nombre, orden), lo que proporciona transparencia sobre el resultado. No menciona permisos o errores, pero para una operación de listado simple es suficiente.

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

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

La descripción consta de dos oraciones claras y directas. La primera presenta la acción y el objeto, y la segunda justifica su utilidad. No hay palabras redundantes ni información superflua, cumpliendo con los criterios de brevedad y estructura front-loaded.

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

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

Dada la simplicidad de la herramienta (1 parámetro, sin esquema de salida), la descripción cubre adecuadamente qué hace, qué devuelve y para qué sirve. Aunque podría incluir un ejemplo o aclarar el orden de los resultados, la mención de 'orden' como campo y el contexto de uso la hacen suficiente para que un agente la seleccione y ejecute.

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

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

El esquema ya cubre el 100% del parámetro idVacante y su descripción ('IdVacancy de pandape_listar_vacantes') es informativa y referencia a otra herramienta. La descripción del tool no añade información sustancial sobre el parámetro más allá del contexto general de la vacante. Se otorga el puntaje base de 3 por la cobertura completa del esquema.

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

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

La descripción utiliza un verbo específico ('Lista') y un recurso concreto ('las etapas del pipeline (VacancyFolders) de una vacante'), además de especificar los campos devueltos (IdVacancyFolder, nombre y orden). No menciona explícitamente herramientas hermanas, pero al indicar que es necesario para filtrar y mover candidatos, se distingue claramente de herramientas como pandape_mover_candidato.

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

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

La frase 'Necesario para filtrar candidatos y para moverlos' ofrece contexto directo sobre cuándo utilizar esta herramienta: como prerequisito para acciones de filtrado o movimiento. Aunque no enumera alternativas o excepciones, sí establece un caso de uso claro y diferenciado de las herramientas hermanas.

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 only lists returned fields and does not disclose pagination behavior, default page size, or how the estado filter works. This leaves key behavioral traits undocumented.

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

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

The description is a single, compact sentence that gets straight to the point. It is well-structured and free of unnecessary detail.

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

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

For a simple listing tool with no output schema, the description lists the return fields, which is useful. However, it omits any mention of the filtering and pagination parameters that are available, relying solely on the schema to convey this. This is adequate but not comprehensive.

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 description adds no information about parameters, while schema coverage is 50%. It fails to compensate for the undocumented 'pagina' and 'porPagina' parameters, and it does not even mention that filtering by estado is possible.

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

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

The description clearly states the tool's verb and resource: 'Lista las vacantes de la empresa' (lists the company's vacancies) and enumerates the returned fields. This distinguishes it from sibling tools that operate on candidates or CVs.

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

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

The description provides no guidance on when to use this tool vs alternatives, no context about filtering by estado or idVacante, and no mention of exclusions. It only states what it does, not when to choose 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 burden of disclosing behavioral traits. It clearly flags the operation as 'ESCRITURA' (write), mandates user confirmation, and requires PANDAPE_READONLY=0. This covers the essential safety and prerequisite context, though it does not detail side effects or reversibility.

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

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

Two sentences, front-loaded with the core purpose, then a concise safety instruction. No redundant information, perfectly sized for the tool's complexity.

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

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

For a write operation with no output schema, the description captures the essential purpose, the mutation nature, and a critical confirmation requirement. It doesn't explain return values or error handling, but those are less critical for a move action. It would benefit from mentioning the motivo requirement for discard stages, but the schema covers that.

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

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

The schema already describes 60% of parameters (motivo, etapaOrigen, etapaDestino). The description adds little about parameters beyond implying the move action. idMatch and idVacante remain undocumented, but they are reasonably self-explanatory given the context. Without high schema coverage, the description does not fully compensate, but it is adequate.

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 exactly what the tool does: 'Mueve un candidato de una etapa del pipeline a otra' (moves a candidate from one pipeline stage to another). This is a specific verb+resource+target, clearly distinguishing it from sibling tools like viewing candidates or listing vacancies.

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 its use (when you need to move a candidate) but does not explicitly discuss when to use it versus alternatives or provide exclusion criteria. It does include a usage caveat about confirming with the user and the PANDAPE_READONLY=0 requirement, but these are more about execution prerequisites than alternatives.

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 must carry the behavioral burden. It conveys that the tool lists data without side effects, but it does not disclose behavior around invalid IDs, output format, or read-only guarantees. This is adequate for a simple list tool but not richly 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?

The description is two sentences, front-loaded with the action ('Lista') and resource, followed by a motivational use case. No wasted words; every sentence adds value.

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

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

For a single-parameter list tool with no output schema, the description gives enough context to understand what the tool does and why. It could mention response format or error handling, but that is not critical for such a straightforward operation.

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

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

The schema only defines idVacante as an integer with no description. The description references 'en una vacante' (in a vacancy), which implies idVacante is the vacancy identifier. This adds meaning beyond the schema, though not with explicit parameter naming.

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

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

The description clearly states the tool 'lists the eliminator questions configured in a vacancy' using a specific verb and resource. It is distinct from sibling tools like pandape_etapas_vacante (stages) or pandape_revisar_candidatos (review candidates), making its purpose unambiguous.

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

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

The description provides a clear use case: 'useful to know what was filtered before evaluating CVs.' It implies when to use the tool but does not explicitly mention alternatives or exclusions, so it earns a 4 rather than a 5.

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

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

With no annotations, the description carries the full transparency burden. It discloses not only the returned data structure but also intentional omissions (sensitive data) with rationale, and provides evaluation instructions (cite evidence, note insufficient CV). This is rich 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?

The description is well-structured: it opens with the core purpose, lists returned data, explains omissions, and ends with evaluation guidance. Though longer than average, every sentence contributes valuable information, and the structure aids scanning.

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?

Despite having no output schema, the description enumerates the structured CV fields in detail, which substitutes for an output schema description. It also provides evaluation criteria instructions and mentions what is intentionally excluded, making it contextually complete for practical 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?

The input schema already documents all 4 parameters with full descriptions (100% coverage). The description does not add parameter-level details beyond the schema; it confirms that idVacante selects the vacancy, but that's implied. Baseline of 3 is appropriate.

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

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

The description clearly states the tool fetches candidates (matches) for a vacancy with structured CV data, enumerating the specific fields returned. It also differentiates itself by noting contact info is in pandape_ver_candidato, distinguishing its scope from siblings.

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

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

The description provides clear context: use for evaluating candidates against criteria, and explicitly directs users to pandape_ver_candidato for contact details, which serves as an alternative. It doesn't explicitly state when not to use the tool beyond that, but enough guidance 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 burden of disclosing behavior. It adds useful context by stating the output is 'sin filtrar' (unfiltered) and includes contact information (email and phones), which signals sensitivity. However, it does not explicitly mention that the tool is read-only (though 'ver' implies it) or describe any side effects, error behavior, or handling of sensitive data. The description adds some transparency but lacks depth.

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

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

The description is two sentences, front-loaded with the core purpose, and every sentence delivers value. The first sentence states what it does, the second gives usage guidance. No redundant words or filler, making it highly concise and well structured.

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

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

This is a simple tool with 2 parameters, no output schema, and no annotations. The description covers the purpose and usage context, which is good, but it does not mention what the response contains beyond 'detalle completo' (vague) and contact info. It also omits any edge cases, such as what happens if idMatch is invalid, or the optional parameter behavior. Given the lack of output schema, the description should have provided a bit more about the return structure, but the core information is present.

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%: only incluirCuestionarios has a description. The tool description does not explicitly explain idMatch, but the phrase 'de una candidatura' implies it identifies a specific application, which provides minimal context. The description adds no additional meaning for the boolean parameter, but that is already covered in the schema. Given the low description coverage and the lack of parameter details, this is a borderline case, but the implicit reference to the candidate ID keeps it at a 3.

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

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

The description clearly states that the tool provides 'Detalle COMPLETO y sin filtrar de una candidatura' (complete and unfiltered detail of an application), with a specific resource (candidatura). It distinguishes itself from siblings by mentioning 'sin filtrar' and 'incluido el contacto', and explicitly contrasts with batch review ('no para revisar en lote'). This makes its purpose 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?

It gives explicit guidance: 'Úsalo cuando ya decidiste avanzar con alguien concreto, no para revisar en lote.' This tells the agent exactly when to use this tool and when not to, implying an alternative for batch review (likely pandape_revisar_candidatos). This is clear and direct.

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

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

With no annotations provided, the description carries the behavioral transparency burden. It discloses the authentication method (web session/cookies), the lack of API credential requirement, and the output purpose (returns idMatch). However, it does not describe the response structure, pagination behavior, or error conditions, leaving notable gaps for a tool without an output schema.

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

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

The description is three sentences, tightly focused, and front-loaded with the action and resource. Every sentence adds value: purpose, authentication context, output usage, and parameter sourcing. There is no fluff or repetition.

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

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

For a simple single-parameter list tool, the description covers the essential workflow: what it lists, how authentication works, how to identify the parameter, and what to do with the output. It is slightly incomplete because it does not describe the return format or list size, but given the low complexity and the direct pointer to pandape_web_cv, it is reasonably complete.

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

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

The schema already covers the parameter with a basic description, and the main description adds meaningful detail by explaining how to find idVacante from the ATS URL (/Company/Match/Matches/<idVacante>). This goes beyond the schema's generic description and provides actionable location guidance.

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

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

The description clearly states the tool's function: 'Lista los candidatos de una vacante' (lists candidates for a vacancy) using a specific scope (web session/cookies). It distinguishes itself from sibling tools by explicitly mentioning the web-session mechanism and by noting it returns idMatch values for later use with pandape_web_cv.

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

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

The description provides clear context: use when you have web session cookies and no API credentials, and use it to obtain idMatch values before reading CVs with pandape_web_cv. However, it does not explicitly state when not to use this tool compared to other sibling tools like pandape_api, so it stops short of full alternative/exclusion 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?

With no annotations provided, the description carries the full burden. It discloses that it uses cookies/web session, reads the full CV as text, and that personal data is involved and should be treated as sensitive. It also specifies evaluation behavior (cite evidence, state when CV is insufficient), which adds useful context beyond a bare read operation.

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

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

The description is three sentences, each earning its place: purpose, usage context, evaluation guidance, and data-sensitivity reminder. It is front-loaded with the core action and contains 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 tool with no output schema, the description is quite complete: it says what is returned (CV as text), when to use it, and how to handle the content. It does not mention error cases like a missing CV, but given the simplicity, the provided context is 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?

Schema description coverage is 100%: the single idMatch parameter is already described as 'idMatch de pandape_web_candidatos'. The tool description does not add further parameter meaning, so it neither helps nor hurts beyond the schema. Baseline 3 applies.

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

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

The description clearly states the verb and resource: 'Lee el CV COMPLETO de un candidato como texto' (read the complete CV as text). It also distinguishes itself from sibling tools like pandape_web_descargar_cv by specifying web-session usage and by positioning itself as the route for reviewing candidates without API credentials.

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

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

The description explicitly says when to use it: 'Es la vía para revisar candidatos por criterios cuando aún no tienes credenciales de API' (it's the way to review candidates by criteria when you don't yet have API credentials). It does not name specific alternative tools, but the condition is clear and distinguishes it from API-based workflows.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool uses a web session, saves an HTML file locally, and returns a local path. However, it does not clarify side effects (e.g., whether the file persists, overwrites, or requires specific authentication state) beyond mentioning 'session', leaving some behavioral 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?

The description is highly concise, consisting of two sentences that front-load the main action and provide necessary context about the format limitation. There is no fluff or redundancy, making it easy to parse.

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

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

The description provides essential information about the return value (local path) and the format limitation, but lacks details such as file naming behavior, exact session requirements, or error handling. Given the tool's moderate complexity, the description is adequate but not fully complete.

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

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

Schema description coverage is only 50% (idMatch is undocumented in the schema), and the description does not mention any parameters. It does not compensate for the missing idMatch documentation, leaving the agent to infer its meaning. The nomeArchivo parameter is documented in the schema, but the description adds no additional value.

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

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

The description clearly states the tool saves the printable HTML view of a candidate's CV via web session and returns the local path. It specifies the verb ('Guarda'), resource ('vista imprimible del CV'), and differentiates from siblings like pandape_descargar_cv by emphasizing the HTML/PDF distinction.

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 ATS limitation (no PDF binary) and implies this tool is the web-based alternative for obtaining CV content. Though no sibling is explicitly named, the context provides clear reasoning for when to use this tool. It lacks an explicit 'when not to use' but the coverage is good.

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