generect-mcp

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

No annotations provided, so description must disclose behavior. Mentions 'Find & verify' implying read-only, and 'resolved in one call' for batch, but lacks details on rate limits, verification process, or side effects.

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

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

Two sentences, front-loaded with purpose, minimal waste. Every sentence adds essential 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?

No output schema, so description should explain return values (e.g., emails, verification status). It only states 'Find & verify work email(s)' without specifying output format, error handling, or success criteria.

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

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

Schema coverage is 100%, baseline 3. Description adds value by explaining single vs batch modes, giving domain format example, and clarifying that candidates require first_name/last_name/domain.

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?

Description clearly states 'Find & verify work email(s) from name + company domain', specifying action and resource. Differentiates between single-person and batch modes, distinguishing from 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?

Explicitly instructs to provide a single person via first_name/last_name/domain or a batch via candidates, clarifying when to use each mode. No explicit exclusions, but context is 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?

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to explain what data constitutes a 'Lead', default inclusion behavior for the optional data flags (posts/comments), error handling for invalid URLs, or rate limiting.

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 four-word description is front-loaded and contains no fluff, but it is undersized for a 6-parameter tool with complex behavioral flags, leaving significant gaps that require elaboration on usage patterns.

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 6 parameters controlling data inclusion and no output schema, the description lacks necessary context about return structure, default behaviors for optional fields, and how the boolean flags affect the response payload.

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%, establishing a baseline score of 3. The description adds no supplemental context for the boolean flags (e.g., performance implications of including posts) or timeout parameter, but the schema adequately documents each parameter's basic purpose.

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 'Get Lead by LinkedIn URL' is tautological, essentially restating the tool name. While it identifies the action (Get) and resource (Lead), it fails to specify the scope of data returned or distinguish this direct lookup from the sibling search_leads tool.

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

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

No guidance is provided on when to use this specific lookup versus the sibling search_leads tool, nor are prerequisites (like URL format requirements) or optimal use cases mentioned.

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

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

No annotations are provided, so the description carries the full burden. It discloses that deep mode consumes a credit and performs a live API probe. It does not mention other traits like read-only nature or rate limits, but the default mode is cheap, and the description is adequately transparent for a liveness 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?

Two sentences, no redundancy. The first sentence states the core purpose, the second elaborates on the deep mode. Every word earns its place.

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 covers the two modes and key side effects (credit consumption). With no output schema, it does not specify return format, but for a liveness check the expected response is simple. The optional parameters are explained in the schema, and the description fills gaps about 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 coverage is 100% with parameter descriptions. The tool description adds value by explaining that deep consumes a credit and verifies the token end-to-end, enriching the schema definition. The url parameter notes a default public profile in the schema, which is useful. The timeout parameter is clear enough.

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 ('confirm' and 'probe') and resource (MCP server, Generect API). It distinguishes two modes (default liveness check and deep probe) and is distinct from sibling tools which involve emails, leads, and companies.

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 when to use deep:true (for end-to-end token verification at credit cost) but does not explicitly state when not to use it or mention alternatives among siblings (though none are comparable). The context is clear for typical use.

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 full burden and discloses validation (HTTP 400 on unknown names), headcount lag, and fallback behavior. It could mention rate limits or response structure but is adequate.

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 with front-loaded purpose and brief behavioral notes. Every sentence adds value, no waste.

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 19 parameters and nested objects, the description does not explain return structure, pagination, or error handling beyond HTTP 400. Lacks completeness for a complex tool but the schema covers parameter details.

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

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

Schema coverage is 100%, so baseline is 3. The description adds general behavioral context (validation, headcount lag) but no per-parameter meaning beyond schema 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 title and description clearly state 'Search for companies matching an Ideal Customer Profile,' which is a specific verb-resource combination. It distinguishes itself from sibling tools like search_leads or generate_email.

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 validation behavior and headcount lag but does not explicitly state when to use this tool over search_leads or other alternatives. No exclusions or prerequisites are 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, the description fully carries behavioral disclosure. It explicitly states non-deterministic results, no stable ordering, return data limitations (no emails), and pagination behavior. This is comprehensive for 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 a single paragraph that front-loads the key purpose and caveat. It is relatively concise given the complexity, though a bit dense.

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

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

Given 28 parameters and no output schema, the description provides a solid overview of key behaviors and constraints. It covers main aspects like non-determinism, pagination, and data limitations, though some parameter interactions could be clarified.

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 covers 100% of parameters with descriptions, so baseline is 3. The description adds value by contextualizing exclude_ids and compact mode, but does not significantly enhance per-parameter meaning beyond 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 it searches for leads matching an Ideal Customer Profile, with a specific verb and resource. It distinguishes itself from siblings by explicitly noting it returns no emails/phones and directing to generate_email for email resolution.

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 clear guidance on when to use (search for leads) and when not to use (for emails). Offers pagination advice via exclude_ids and mentions non-deterministic results. Could explicitly differentiate from get_lead_by_url but still strong.

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