Leadgen MCP

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, any potential impact on the target website, rate limits, or error handling. Crawling a website implies network access but lacks details such as whether it follows robots.txt, timeouts, or maximum crawl depth consequences. This is insufficient transparency for a tool that interacts with external sites.

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 appropriately brief and well-structured. The purpose is stated in the first sentence, followed by clear arg descriptions. Every sentence serves a purpose with 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?

The tool is relatively simple with two parameters, but since there is no output schema, the description should clarify what the return value looks like. It mentions extracting emails, phone numbers, and social profiles but does not describe the format, whether it's a list or object, or how pages are aggregated. It also lacks any mention of errors or limits beyond max_pages. This is adequate but has clear gaps for a fully self-contained description.

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 fully compensates by explaining both parameters: website is the URL to crawl with examples, and max_pages is the maximum number of pages with a range (1-20). This adds meaningful context beyond the bare schema properties and helps the agent construct valid inputs.

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 action: 'Crawl a website and extract emails, phone numbers, and social profiles.' This clearly defines the tool's function and scope, distinguishing it from sibling tools like lookup_business or lookup_domain, which imply lookup operations rather than crawling.

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 explicit guidance on when to use this tool versus the sibling tools. It does not mention alternative tools or describe scenarios where this tool is preferred. The only implicit guidance is that it's for crawling websites, but there is no exclusionary language or context for selection.

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 transparency burden. It discloses meaningful behavioral details: the data source is a local snapshot, name queries use an FTS5 index and are diacritic-insensitive, and digit queries match CUI exactly with prefix fallback. These details go beyond basic purpose and help the agent anticipate behavior, though it omits return format and safety statements.

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 concise and well-structured: a one-line summary, then data source and query behavior, then parameter definitions. Every sentence adds value 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 two-parameter lookup tool with no output schema, the description covers the essential context: purpose, data source, matching behavior, and parameter meaning. It is slightly incomplete by not describing the response shape or edge-case behavior, but given the tool's simplicity and the presence of detailed query semantics, 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 input schema has no property descriptions (0% coverage), but the description's Args section fully compensates by explaining query as either a company name or CUI and max_results with a valid range (1-100). This adds critical semantics beyond the raw schema types.

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 with a specific verb ('Search') and resource ('Romanian business registry ... for companies'), distinguishing it from sibling tools like lookup_director and lookup_domain by its focus on companies. It also names the official data source, reinforcing its scope.

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 establishes a clear context for when to use the tool (company lookups in the Romanian registry) and explains query types, but it does not explicitly mention alternatives or exclusion conditions relative to sibling tools. This is clear context without explicit guidance, so 4.

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 key behaviors: it searches the ONRC reprezentanti table via a ranked FTS5 index, is diacritic-insensitive ('popescu' matches 'POPESCU'), and returns companies with director names and roles. Since no annotations are provided, this detail bears the full burden of behavioral transparency.

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 compact, starting with the main purpose in the first sentence, followed by technical context and an Args list. All sentences add value 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?

Given the tool's simplicity (2 params, no output schema), the description adequately covers the key aspects: purpose, search behavior, and return value. It lacks details on result ordering or error handling, but these are not critical for this usage.

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 provides no descriptions for params (0% coverage), but the description fully explains both: 'name' is defined with an example and the purpose; 'max_results' states the range (1-100) and meaning. This adds significant semantics beyond the schema's type/default.

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: 'Find Romanian companies by director or legal representative name.' It specifies the resource (companies) and search criterion (director name), distinguishing it from sibling tools like lookup_business or lookup_domain.

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 comparison with alternatives or guidance on when to use this tool versus other lookup tools. It describes the search mechanism and return values, but does not mention exclusions or refer to sibling tools.

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 must carry the burden. It enumerates the included lookup components (WHOIS, DNS, SPF/DMARC), which adds some behavioral context, but it does not disclose response format, network implications, or error behavior. This is moderate value beyond the plain purpose.

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 compact, well-structured docstring: a single summary line followed by an args list. No redundant text, and every sentence adds necessary information. It is front-loaded with the primary action.

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 lack of output schema and annotations, the description covers the operation and parameters clearly. However, it does not explicitly state the return value structure or any limitations such as rate limits or latency. For a straightforward 3-parameter lookup tool, this is a minor but acceptable gap.

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

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

The Args section in the description thoroughly explains each parameter beyond the schema. For example, include_dns is described as 'Include DNS records (A, MX, NS, TXT, etc.)' and include_security as 'Include SPF/DMARC email-security check'. Since schema coverage is 0%, this completely compensates and significantly enriches parameter understanding.

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 clear imperative: 'Perform WHOIS + DNS + SPF/DMARC lookup for a domain.' This specifies the exact resources and operations, distinguishing it from sibling tools like extract_contacts and lookup_business.

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 does not explicitly state when to use this tool vs alternatives or mention any exclusions. Usage is implied by the tool name and description, but there is no direct guidance, so it falls in the 'implied usage' category.

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 full responsibility. It discloses the data source (official Ministry of Finance open data, loaded locally by load_financiare.py), that values are RON integers from the latest annual filing(s), and that it's paid-tier. However, it does not mention error handling, pagination, or explicitly confirm read-only behavior (though 'Return' implies it).

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 starts with the purpose, then gives data source context, tier differentiation, and a clean Args section. It is not overly verbose, but every sentence adds value (source, currency, tier).

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?

There is no output schema, so the description should explain what the tool returns. It only says 'annual financial statements (MFP data)' without specifying fields, structure, or whether it's a single object or list. It mentions RON integers but leaves the response format largely undefined for a paid-tier enrichment tool.

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

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

Schema description coverage is 0%, so the description must compensate. It does so with an Args section explaining 'cui' as a Romanian tax identification number and providing an example ('2816464'), which fully clarifies the parameter's meaning beyond the bare 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 states the specific action ('Return a Romanian company's annual financial statements (MFP data)') and names the resource (MFP data from the Ministry of Finance). It also clarifies it is the paid-tier financial enrichment, distinctly different from the sibling lookup tools (contacts, business, director, domain).

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 differentiates the free tier (returns registry identity) from this paid-tier financial enrichment, giving clear context for when to use it. It does not name sibling tools directly, but the financial scope implies this is the go-to tool for financial statements rather than the other lookup categories.

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