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

Annotations already declare readOnlyHint=false, openWorldHint=true and non-idempotent, and the description is consistent with them. It adds genuinely useful context beyond the annotations: the call is asynchronous and returns a task_id that must be polled via get_task_result, plus a URL format constraint. Remaining gaps (cost, latency, whether repeated calls spawn duplicate tasks) are minor.

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

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

Three short sentences, with the core capability front-loaded and the hard requirement (URL scheme) placed before the follow-up instruction. No filler; only the stray line breaks and the omission of the second parameter keep it from being exemplary.

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?

An output schema exists, so return values need no explanation, and the description still names the task_id/follow-up flow that an agent must act on. For a 2-parameter async tool this is nearly complete; only the undocumented language parameter and lack of any indication of task duration leave a gap.

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

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

Schema description coverage is 0%, so the description must compensate for two params. It does clarify the required url (must include http:// or https://), but the optional language parameter is never mentioned; its meaning and the impact of the 'es' default are left entirely to the field name.

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 (analyze a website) and enumerates what is extracted: contacts (emails, phones, social), business data and services. That scope is distinguishable from the LinkedIn- and lead-search siblings, though it never explicitly contrasts 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 line 'Devuelve un task_id para get_task_result' usefully routes the agent to the required follow-up sibling, which is real guidance. However, there is no statement of when to choose this over lookup_linkedin_profile or search_leads, nor any prerequisite beyond the URL scheme.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the purpose (checking balance before jobs) but does not mention whether balance data is real-time, cached, or tied to specific authentication scopes.

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

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

Two short sentences, front-loaded with what the tool returns and followed by when to use it. Every sentence earns its place with no repetition or filler.

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

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

With an output schema covering return values, no parameters, and annotations covering read-only safety, the description supplies the remaining essential context: what account data it exposes and when to call it. A minor gap is not clarifying data freshness or account scope.

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 are zero parameters, so parameter semantics have no gaps to fill. The description correctly does not waste space discussing inputs, and the baseline for a parameterless tool is 4.

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 identifies the resource as the ExtractorLead credit balance and subscription status, which is more specific than the generic name 'get_account'. It is distinguishable from sibling tools, which are all lead/search/enrichment operations, though it uses a noun phrase rather than an explicit verb.

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 explicitly says to use this before launching any job to check whether there is enough balance, giving a clear usage context. It does not name exclusions or alternative tools, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and an output schema exists, so the description's main contribution is the 15-minute link expiry and the JSON format — genuinely useful operational context. It does not say whether the job must be complete, what happens if the link expires, or whether links are single-use.

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; the expiry, scope, and format arrive in the right order. It is arguably too terse for a tool with an undocumented parameter, but nothing in it 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 one-parameter read tool with annotations and an output schema, the description covers the essentials: what the link is for, its lifetime, and its format. The main missing piece is the relationship to get_bulk_results and the state the job must be in.

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 lone task_id parameter is undocumented in the schema. The phrase 'del trabajo' implies task_id identifies the job whose leads are downloaded, which is a partial but not complete compensation — format, source of the id, and whether it is the enrichment job or a task id are left unclear.

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: produce a temporary link to download all leads from a job in JSON. The scope ('todos los leads del trabajo') is clear, but nothing distinguishes it from the adjacent get_bulk_results, which an agent could reasonably pick instead.

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: download everything in bulk rather than paging through results. There is no statement of when to prefer this over get_bulk_results, nor any precondition such as the job having finished.

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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds a real constraint beyond the schema: per_page is capped at 200 (schema only says default 50). It does not explain pagination termination, ordering, or whether the job must be finished first.

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 what it returns, then the pagination cap, then the alternative. No waste, though it is arguably under-filled given the undocumented parameters.

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?

An output schema exists so return values need not be explained, but with 5 parameters at 0% schema coverage and only one parameter described, an agent cannot know how to build a filtered or matched query. The definition is not complete enough for correct invocation.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate and largely does not. Only per_page gets meaning; the two enums (only: all/with_phone/with_email/with_both and match: all/exact/related) and the semantics of page/task_id are left entirely unexplained.

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 concrete verb+resource: returns enriched leads from a bulk job, paginated. This distinguishes it from get_bulk_status (which reports job state) and get_bulk_download_link (which exports), though it never names those siblings explicitly as alternatives beyond the download link.

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 one explicit routing rule: for large lists, offer get_bulk_download_link rather than paginating everything into the conversation. Clear context, but no guidance on when to use this versus get_bulk_status or preview_bulk_enrichment, and no preconditions on task_id state.

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?

Annotations already cover read-only and open-world safety, so the description earns credit for adding what annotations cannot: it never returns the lead list, exposes the phase lifecycle, and discloses that phone resolution can take roughly an hour. It does not explain whether the call blocks or how wait_seconds changes the blocking behavior, which is the one behavioral trait left undisclosed.

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

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

The scoping constraint is front-loaded in the first clause, followed by the phase vocabulary and then actionable guidance; every sentence carries information. Line breaks fragment the text slightly but nothing is 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?

An output schema exists, so return-shape explanation is rightly omitted, and the lifecycle/latency context is well covered. However, for a polling tool whose entire risk is over-waiting, leaving wait_seconds semantics undocumented is a real gap in what an agent needs 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 description coverage is 0% for two parameters, so the description must carry the load — but it says nothing about task_id or wait_seconds (default 30). An agent cannot tell from any source whether wait_seconds makes the call long-poll for up to N seconds, which directly interacts with the advice not to wait in a loop. The only mention of 'partial=true' refers to a parameter of get_bulk_results, not of this 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 exactly what is returned (progress counters of a bulk job) and explicitly rules out the adjacent resource ('nunca la lista'), which is the main ambiguity versus the sibling get_bulk_results. The enumerated phase values make the resource concrete enough for an agent to recognize 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?

Gives explicit routing: read decided leads via get_bulk_results when partial=true, and for phase=awaiting_phones it prescribes a concrete action (notify the user and re-poll later) with an explicit prohibition on waiting in a loop. This is when/when-not guidance with a named alternative, not just implied usage.

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?

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuine behavioral context: the terminal state yields a summary plus an Excel link, and row retrieval is paginated with a hard cap of 200. It omits what wait_seconds does (whether the call blocks/polls), which is the main remaining behavioral unknown.

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

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

Two short sentences, front-loaded with the core purpose, then the pagination flag. Dense and waste-free, though the semicolon-chained phrasing and mixed language make it slightly harder to parse than it needs to be.

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?

An output schema exists, so the return shape needn't be explained, and the description does note the summary/Excel-link payload. However, for a 5-parameter tool with zero schema descriptions, leaving wait_seconds and task_id semantics unstated is a real gap in an otherwise adequate definition.

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 carry all parameter meaning, and it only clarifies include_rows and references offset/limit with a 200-row cap. task_id, the limit default of 50, and especially wait_seconds (default 30, likely a blocking wait) are left entirely undocumented.

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 resource and verb-equivalent ('Estado del relleno de lista') and adds what the caller gets at completion: a summary and a link to the edited Excel. It is clearly distinguishable from start_list_enrichment and preview_list_enrichment, though it never explicitly contrasts itself with get_bulk_status or get_task_result.

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 as a status-polling call; there is no explicit statement of when to use this versus get_bulk_status or get_task_result. The one real guideline given is conditional: set include_rows=true if you want the actual rows back.

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?

Annotations only say readOnlyHint and openWorldHint, so the description adds real behavioral value: it reveals long-polling semantics (wait_seconds waits up to 50s), the complete status state machine (PENDING | PROCESSING | COMPLETED | FAILED | CANCELLED), and that the leads list is paginated. The only nuance left untouched is what happens on FAILED/CANCELLED, whether the result expires, and the tension between the schema default of 30 and the stated 50s cap.

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 core capabilities are front-loaded in the opening line, with the parameter notes following as tight bullets — no wasted prose. The status-enum line is oddly appended after bullets that reference parameters, so the ordering is slightly jumbled, but the whole thing stays short.

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?

An output schema exists, so return values needn't be re-explained, and the description covers the non-obvious pieces: polling behavior, state machine and pagination. It leaves one practical gap: it never states that task_id comes from the response of the producing tools, which is the key link in the workflow.

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 carry the load, and it does: wait_seconds is defined as a poll-until-done delay with a 50s ceiling, and offset/limit are explained as pagination of the leads list. Only task_id is left undefined, and its meaning is self-evident from the tool's framing.

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 verb-and-resource pair (estado y resultado) and enumerates the exact producer tools it applies to: search_leads, lookup_linkedin_profile and analyze_website. That scope makes it distinguishable from the other siblings at a glance. What it doesn't do is explicitly contrast itself with the bulk/list status tool family (get_bulk_status, get_list_enrichment).

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 list of producer tools tells the agent which tasks this tool follows up, which implies a polling workflow after an async call. However, it never says when to prefer it over the sibling polling tools (get_bulk_status, get_bulk_results, get_list_enrichment), which are the closest alternatives in the same toolbox. Usage is inferred rather than 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?

The description discloses the async task_id return, which explains why readOnlyHint=false despite the 'obtains' framing — the call enqueues work rather than returning data inline, so this is not an annotation contradiction. It also names the payload fields (email, phone, professional data). It omits cost/credit implications and what happens on a failed lookup, which for an openWorldHint tool would be useful.

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

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

Three short lines: what it returns, the input format, and the async handoff. Each sentence carries distinct, actionable information with no repetition of the title or schema.

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

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

For a one-parameter tool with an output schema, the description covers the three things an agent needs: the data it produces, the exact input format, and the required follow-up call to get_task_result. Nothing essential to a correct invocation 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?

Schema description coverage is 0% and the single parameter has no description, so the description must compensate — and it does by giving the exact accepted format: https://www.linkedin.com/in/<usuario>/. That is the most valuable piece of information for this tool. It doesn't state what happens for non-canonical URLs or whether company pages are accepted.

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 retrieves email, phone and professional data for ONE LinkedIn profile. The emphasized 'UN perfil' implicitly contrasts with the bulk/list enrichment siblings, though no sibling is named explicitly. An agent can still tell this is the single-profile lookup versus the bulk 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?

Explains the async workflow: the call returns a task_id and the result must be collected with get_task_result, which is a genuine usage instruction that prevents the agent from expecting a direct payload. It does not explicitly say when to prefer this over start_bulk_enrichment or preview_list_enrichment, so the bulk/single split remains inferential.

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?

Annotations already flag readOnlyHint/openWorldHint, and the description adds genuinely new behavioral facts: no credits are charged, hard cap of 5000 rows, file_path only works on a local server, and a per-delivered-contact price table (2/3/4/0 credits). That pricing and capacity context is exactly what an agent needs and cannot get from the 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?

Front-loaded with the no-charge guarantee and the ordering rule, then organized into clearly labeled blocks (Entrada / Opciones / Precio). It runs long, but nearly every line adds operational value; only the pricing sentence could be trimmed slightly.

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?

An output schema exists, yet the description still names the key return fields to show the user, and it covers input formats, limits, pricing, and the hand-off to start_bulk_enrichment. Nothing an agent needs to invoke this correctly 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?

Schema coverage is 0%, so the description carries the full burden and does: it enumerates accepted lead fields and Spanish header aliases, explains file_path formats (CSV/XLSX, Sales Navigator export), and defines each enum value's business meaning (all_contact_info vs phone_info vs email_info, strict vs related) plus the 1..10 range for related_per_company.

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 (validate a list, compute max cost) plus the crucial scope caveat that nothing is charged, and explicitly contrasts with start_bulk_enrichment. An agent can immediately tell this is the dry-run/quote step of a two-step bulk flow.

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

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

'Úsalo SIEMPRE antes de start_bulk_enrichment' gives an explicit ordering rule naming the alternative, and it also tells the agent what to surface to the user (rows_accepted, max_credits, available_credits). No inference required about when to call 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?

Annotations declare readOnlyHint=true and openWorldHint=true, and 'NO cobra' is consistent with the read-only profile. The description adds useful context about preserving the user's columns and returning detected columns, gaps, cost and tope_sugerido, but adds nothing beyond annotations about external calls, limits or auth.

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-loads the purpose and the no-charge guarantee, then adds distinguishing behavior and a parameter edge case. Trimmed but each sentence carries meaningful information; only the line break/casing is slightly awkward.

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?

Output schema exists so return values need minimal explanation, and annotations cover the safety profile. Description still communicates the preview semantics, column preservation, and one non-obvious parameter, making it largely complete—only the leads/file_path selection and wants_phone are 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 description coverage is 0%, so the description must compensate. It explicitly explains phone_for_all ('buscar teléfono también en filas que ya traen uno... centralitas'), which is genuinely valuable, and implies leads/file_path via 'lista propia (CRM, Excel)'. However, wants_phone and the relationship/choice between leads and file_path remain undocumented.

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: analyzes a user's own list (CRM/Excel) and quotes the cost of filling gaps, explicitly noting it does not charge. It distinguishes itself from bulk enrichment ('A diferencia del enriquecimiento masivo'), though it does not name the sibling tools it complements (preview_bulk_enrichment / start_list_enrichment).

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?

Makes clear this is a preview/quote step and that no charge occurs, which implies it should precede an actual enrichment run. However, it never names the tool to call to execute (start_list_enrichment) nor clarifies when to use leads vs file_path, leaving selection 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?

Discloses three things annotations cannot convey: it consumes credits, it is asynchronous and returns only a task_id, and it should not be called without user confirmation. Annotations already mark it non-read-only and non-idempotent, and the description's cost + async + confirmation notes complement rather than repeat them.

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-sentence purpose line followed by a scannable bullet per parameter, then two workflow sentences. No filler, and the cost warning plus confirmation request are placed where they will be read before invocation.

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 6-parameter, non-idempotent, credit-consuming search it covers the cost, the parameter space, the async return contract and the confirmation requirement. An output schema exists, so it correctly does not restate the return shape beyond naming task_id and the retrieval 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 coverage is 0%, so the description must carry the whole burden and it does: every one of the six parameters is explained with the constraint that matters (lead_count range 1..500 with default 25, country as 2-letter ISO only for linkedin+phones, niche and location with concrete examples). It adds meaning well beyond the bare enum and type declarations.

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?

Opens with a specific verb+resource: 'Busca leads nuevos de un nicho en una zona', which tells an agent exactly what the tool produces. There is no sibling that competes for the same job (the other tools are enrichment, lookup and task-retrieval operations), so differentiation is implicit rather than stated, which is why this sits at 4 rather than 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?

Gives explicit conditional guidance for the two decision-heavy parameters: channel 'linkedin' for B2B roles/companies vs 'instagram'/'tiktok' for creators and local businesses, and country only when 'linkedin'+'phones'. It also states a workflow prerequisite ('Pide confirmación al usuario antes de llamarla') and routes the follow-up to get_task_result, so both when-to-use and what-to-do-next are covered.

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?

Adds substantial context beyond annotations: credits are consumed, per-contact pricing for delivered data, the 5000-row cap, and the constraint that file_path only works on a local server. Annotations declare non-read-only and non-idempotent, and the description is consistent with that while explaining real consequences.

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-loads cost before anything else, then the precondition, then inputs and options in short labeled blocks. The pricing line is terse and high-value rather than 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?

An output schema exists so return values need not be spelled out, yet the description still names task_id and the status tool for polling. With the credit model, row cap, input shape and enum semantics all covered, nothing needed to invoke it correctly 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?

Schema coverage is 0%, so the description carries the full burden and does: it enumerates accepted lead fields (including Spanish headers), the one-of leads/file_path input rule, the exact meaning and default behavior of each contact_info enum value, strict vs related match semantics, the 1..10 range for related_per_company, and require_mobile.

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 concrete verb+resource ('Lanza el enriquecimiento de una lista de personas') and immediately signals cost and the returned task_id, which differentiates it from preview_bulk_enrichment and get_bulk_status. It never distinguishes itself from the sibling start_list_enrichment, so an agent given a saved list cannot tell which launcher applies.

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 precondition: only after preview_bulk_enrichment and with user confirmation, which is a real gate most definitions omit. It also routes follow-up to get_bulk_status. The exclusion is incomplete in that start_list_enrichment/preview_list_enrichment are never named as the alternative path.

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?

The annotations already declare readOnly=false, idempotent=false and openWorld=true; the description adds the genuinely non-obvious fact that the call burns credits up to credit_cap, which is valuable context. However, it does not warn that repeated launches create new jobs (non-idempotent) or that credit spend is irreversible once under way, which is the main behavioral risk of this tool.

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

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

Two short paragraphs, front-loaded with the action and the cost implication, with the parameter note in its own block. Every sentence carries information; no filler or repetition of the title.

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?

An output schema exists, so return values need not be explained, but for a non-idempotent job-launcher that spends the user's credits, the definition omits how the list is supplied (leads array vs file_path) and what the phone-related flags do. That is a substantial gap given 0% schema description coverage.

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% across 5 parameters, and the description only explains credit_cap (with useful guidance on where the value comes from). The four remaining inputs — leads, file_path, wants_phone, phone_for_all — are completely undocumented, and the mutually exclusive nature of leads vs file_path is left entirely to inference.

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: launching the gap-filling ('relleno de huecos') of a list, and names the concrete objects it interacts with (credit_cap, preview_list_enrichment, get_list_enrichment). It is clearly distinguishable from its siblings, though the phrase 'relleno de huecos de una lista' is somewhat idiomatic and leaves the nature of the enrichment implicit.

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

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

Gives explicit operational routing: read the suggested cap from preview_list_enrichment when the user has not specified one, and poll progress with get_list_enrichment. It stops short of stating when NOT to use it (e.g. bulk vs list enrichment, or re-launching an already-running job).

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