analyze_websiteExtract emails, phone numbers, social profiles, business details, and services from a website URL to enrich lead lists and fill contact data gaps.
Analiza una web: contactos (emails, teléfonos, redes), negocio y servicios.
url debe incluir http:// o https://. Devuelve un task_id para get_task_result.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| language | No | es |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does 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.