Tomba MCP Server

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

Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds no extra behavioral context such as async behavior (despite webhook_url being in the schema) or limitations. It doesn't contradict annotations, so a neutral score of 3 is appropriate.

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 a front-loaded purpose statement and a meaningful use case. No filler or redundant information, 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?

For a simple 2-parameter tool with no output schema, the description covers the core function and intended use. It doesn't explain return format or edge cases, but the purpose implies the output. A bit more detail on async behavior could improve it, but it's mostly 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 coverage is 100%—both 'url' and 'webhook_url' have descriptions. The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is warranted.

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 a specific verb+resource: 'Find the email address of an article's author from a given URL.' This clearly distinguishes it from sibling tools like email_finder by specifying the URL as input and the author's email as output.

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 a clear use case: 'Useful for outreach to content creators and journalists,' which implies when to use the tool. However, it doesn't explicitly name alternative tools or state when not to use it, 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, indicating a safe, read-only, non-exhaustive search. The description adds the database source and outreach purpose but no additional behavioral traits. With annotations covering the safety profile, this is appropriate.

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, focused sentence that front-loads the primary action and purpose. There is no wasted wording, and it is appropriately concise for the tool's scope.

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 has a complex filter schema and no output schema, yet the description gives sufficient context for basic use. It omits mention of pagination and the webhook parameter, though these are fully documented in the schema. For this complexity, slightly more guidance could help, but it is not severely incomplete.

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 100% parameter description coverage, including the nested filter structure. The description highlights key filter dimensions (name, industry, country) but adds no syntax or format details beyond the schema, so the baseline of 3 is correct.

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 searches for companies in the Tomba database, a specific verb and resource. It also mentions filtering by name, industry, country, and more, distinguishing it from sibling tools like email_finder or similar_finder.

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 context: finding target companies for outreach. This implies when the tool should be used. However, it does not explicitly mention alternatives or exclusions, but the context is sufficient without being misleading.

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 description doesn't need to repeat those safe-read and incompleteness aspects. It adds the return detail of 'metadata about each contact,' but does not disclose pagination behavior, webhook async processing, or rate-limiting implications. This is acceptable given the annotations but lacks richer operational 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?

Two sentences convey the core function and return type without redundancy. Every phrase is purposeful, and the description is front-loaded with the action and target, making it easy to scan.

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 read-only tool with 8 optional parameters and no output schema, the description gives a basic return expectation but doesn't cover important context like recommended use of domain vs. company, pagination, or webhook usage. The schema documents individual parameters well, and annotations cover safety, so the description is minimally viable but leaves some operational gaps.

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 descriptions cover all 8 parameters, but the description adds meaning by implying that 'domain' and 'company' are alternative search keys ('or company') and emphasizes the scope of 'all email addresses.' This clarifies the tool's primary usage beyond the isolated parameter descriptions, though it doesn't address optional filters or pagination parameters explicitly.

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 explicitly states the action (search) and resource (email addresses for a domain/company), and the scope 'all email addresses' distinguishes it from sibling tools like email_finder which typically target individual contacts. The phrasing 'specific domain or company' clarifies the two primary search keys.

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 when to use the tool (need emails for a domain/company) but provides no explicit guidance on when not to use it or how it compares to similar siblings such as email_enrichment or email_verifier. The intended use case is clear from context, but alternatives are not mentioned or excluded.

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 and openWorldHint, covering the safety profile. The description adds value by disclosing that the tool returns a count (not a list) and frames it as a reach estimate, which goes beyond annotation hints. No contradictions exist.

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 exactly two sentences: the first states the function clearly, the second provides the usage context. No fluff, well front-loaded with 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?

For a one-parameter count tool with read-only annotations, the description covers action, use case, and the parameter is fully documented in the schema. No output schema exists, but a count's return type is self-evident from the description. The tool is fully contextualized.

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 fully documents the single `domain` parameter with a pattern and example, giving 100% coverage. The description only echoes 'specific domain' without adding syntax or constraints beyond the schema, so it earns the baseline 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 opens with 'Get the count of email addresses available for a specific domain', a specific verb + resource + scope that clearly defines the tool's function. It distinguishes itself from sibling search tools like domain_search by framing this as a count/reach estimation rather than a full search.

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 phrase 'Useful for estimating the potential reach before performing a full domain search' gives clear usage context and implicitly positions this as a pre-flight check relative to domain search. It does not explicitly name alternatives or exclusions, so it stops 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 indicate read-only and open-world behavior, so the main added value is the disclosure of output contents (name, position, company details, social profiles). It does not discuss failure modes, data completeness, or permission requirements, but these are less critical given the annotations.

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, well-structured sentence with all words earning their place. It is front-loaded and free of 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 simple one-parameter tool, the description covers the tool's purpose and the main return content. There is no output schema, but the listed enrichment categories give sufficient context; some explicit usage guidance would improve completeness.

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 covers the single `email` parameter completely with a clear format and description. The tool description adds no further parameter-specific semantics, so a baseline score 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's function with a specific verb ('enrich') and resource ('email address'), and lists concrete output categories (name, position, company, social profiles). This distinguishes it from sibling tools like email_verifier or email_finder.

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 context is implied rather than explicit: the tool is appropriate when you have an email and need person/company details. However, it does not mention when to prefer this over email_finder, email_verifier, or other sibling tools, nor any exclusions.

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 and openWorldHint, so safety and external-data implications are covered. The description adds that it 'uses various techniques to generate and verify the most likely email format', which gives some insight into its heuristic and verification approach. However, it does not provide deeper behavioral details (e.g., fallback behavior, confidence, rate limits).

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, both purposeful. The first states the core function, and the second gives method context. No unnecessary words or repetition. It is front-loaded with the key 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?

The description is adequate for a read-only, open-world tool with a fully documented schema. It clearly states the input conditions and expected outcome (email address). However, with no output schema and 7 optional parameters, a bit more detail on return format or how the optional parameters (e.g., webhook_url, enrich_mobile) affect results would enhance completeness. Still, it does not leave major gaps.

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 each parameter is documented. The description adds meaning by grouping parameters: it explicitly says 'name and company domain or company name', which clarifies the primary inputs and the combination needed. This goes beyond the individual property 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 clearly states the tool's purpose: finding a specific person's email address given their name and company domain or company name. It uses a specific verb ('Find') and resource ('email address'), and distinguishes itself from sibling tools like email_verifier (which verifies known emails) and email_enrichment (which enriches existing data).

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 for when to use the tool: when you have a person's name and their company domain/name. It does not explicitly mention alternatives or exclusions, but the context is strong enough to guide an agent toward this tool for this use case.

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 and openWorldHint, so no mutation disclosure is needed. The description adds behavioral value by specifying that no email is sent and listing the verification checks, providing context beyond the annotations.

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 with no waste. The main action and scope are front-loaded in the first sentence, and the second sentence adds specific verification details 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?

The tool has no output schema, so the description should clarify return behavior, but it does not mention the result format. However, it covers the main purpose, verification checks, and non-sending behavior, making it fairly complete for a low-complexity 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 100%, so the baseline is 3. The description does not add meaning beyond the schema for webhook_url or enrich_mobile, but it does clarify the email verification criteria, which slightly enhances the email parameter.

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 'Verify if an email address is valid and deliverable,' using a specific verb and resource. It further details the checks (format, domain validity, mailbox existence), clearly distinguishing it from sibling tools like email_finder and email_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 description implies usage for verification of an existing email address, and 'without sending an email' clarifies a key context. However, it does not explicitly name alternatives or state when not to use this tool, so it lacks full 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds no behavioral context beyond restating the purpose. It does not mention limitations such as private profiles, the asynchronous webhook option, or how enrichment works, which would be useful for agents.

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 and no filler. The structure is clean and 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?

Given the simple tool with full schema coverage and solid annotations, the description is adequate but incomplete. It lacks usage guidance and does not mention the asynchronous option or the enrichment capability, leaving some gaps for an agent deciding how to invoke the 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 100%, so all three parameters (url, webhook_url, enrich_mobile) are already described. The description adds minimal meaning beyond 'LinkedIn profile URL' and 'contact information', and does not explain the webhook or enrichment parameters, so it stays at the baseline.

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 finds email addresses associated with a LinkedIn profile URL, which is specific and distinguishes it from sibling tools like email_finder (which typically uses names/domains). The verb 'Find' plus the resource 'email address associated with a LinkedIn profile URL' makes the 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?

Usage is implied: you would use this tool when you have a LinkedIn profile URL and need its email. However, it does not explicitly mention alternatives like phone_finder for phone numbers or email_finder for other lookup methods, nor does it provide exclusions (e.g., when not to 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?

The description adds behavioral context beyond the readOnlyHint annotation by disclosing the pay-per-request model and the lack of API key requirement. This is useful for setting agent expectations about cost and authentication, though it does not cover error handling or rate limits.

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, front-loaded sentence that immediately conveys the action, target, and key constraints. Every word contributes value with no redundancy 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?

For a simple one-parameter, read-only finder tool, the description covers the essential purpose and payment/auth context. The absence of an output schema is mitigated by the implication that the email address is returned, though it could be more explicit about what happens on success or failure.

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 sole parameter 'url' is already fully described in the schema (100% coverage), and the description does not add any additional format, example, or usage nuance beyond what the schema provides. 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 identifies the tool's action (find the email address of the author) and resource (article or blog post URL). It mentions MPP and pay-per-request, which helps distinguish it from non-MPP siblings, but it does not explicitly differentiate from the sibling tool 'author_finder'.

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 usage for scenarios requiring MPP payment and no API key, but it does not explicitly state when to use this tool over alternatives or provide exclusions. The context is informative but not prescriptive.

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 provide readOnlyHint and openWorldHint, and the description adds valuable behavioral context: the pay-per-request cost model and the authentication requirement (only an InFlow buyer key). This goes beyond what annotations state, though it does not detail other behaviors like pagination or rate limits.

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, front-loaded sentence that communicates purpose, payment model, and authentication requirement with zero redundancy. 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, combined with comprehensive schema descriptions and readOnly/openWorld annotations, gives sufficient context for a search tool with optional filters. It lacks an explicit return format or pagination note, but the core purpose and cost model are clearly conveyed.

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 100% parameter coverage with descriptions for all six parameters. The tool description does not add any additional parameter-specific semantics beyond what the schema already provides, so baseline 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's function with a specific verb ('Search') and resource ('all email addresses associated with a specific domain using MPP'). The MPP designation and pay-per-request model distinguish it from non-MPP sibling tools like 'domain_search' and 'email_finder'.

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 for when to use this tool: pay-per-request, no API key required, only an InFlow buyer key. This implies usage when the user lacks an API key or prefers pay-per-request, but it does not explicitly name alternative tools or exclusions.

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?

While annotations already declare readOnly and openWorld hints, the description adds valuable operational context: it is pay-per-request and requires no API key. It also clarifies the MPP protocol, which is not present in annotations and helps the agent anticipate costs and auth behavior.

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 sentence that efficiently conveys the tool's function and key operational caveats. It is front-loaded with the action and contains no redundant information, 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 tool is simple: one parameter, no output schema, and clear annotations. The description covers the core function, protocol, payment model, and auth requirement. Combined with the schema and annotations, this is sufficient for an agent to understand and invoke the tool 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?

The input schema covers 100% of the parameter description, including the domain pattern. The tool description adds no extra meaning about the parameter beyond what the schema already provides, so the baseline score 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 'get[s] the count of email addresses available for a specific domain', specifying both the action and resource. The inclusion of 'using MPP' distinguishes it from sibling tools like email_count, making the 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 no explicit guidance on when to choose this tool over alternatives such as email_count. It mentions pay-per-request and API key requirements, but these are operational details rather than usage criteria, leaving the agent without direction on tool 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?

Annotations already declare readOnlyHint and openWorldHint, so the bar is lower. The description adds valuable behavior beyond annotations: it discloses that the tool operates on a pay-per-request basis and requires no API key, which are important cost/auth behaviors. This additional context meaningfully enriches the annotation-only picture.

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, concise sentence that front-loads the main action and includes relevant differentiators (MPP, pay-per-request, no API key). Every phrase earns its place with no fluff 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?

For a simple one-parameter tool with readOnly/openWorld annotations and no output schema, the description adequately covers purpose, cost model, and authentication. It could optionally mention what specific 'contact and company information' fields are returned, but that omission is minor given the tool's simplicity and the lack of output schema.

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 provides 100% coverage for the single parameter 'email' with a description ('The email address to enrich') and format/pattern validation. The description's mention of 'email address' adds no extra semantic meaning beyond what the schema already conveys, so the baseline 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 action ('Enrich an email address') and the specific resource ('email address') plus the type of output ('detailed contact and company information'). It distinguishes itself from sibling tools by mentioning MPP (Machine Payments Protocol) and the unique 'pay-per-request, no API key required' characteristic, which sets it apart from non-MPP alternatives.

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 key differentiator ('pay-per-request, no API key required') that helps decide when to use this tool over others, but it does not explicitly state when NOT to use it or mention specific alternative tools. The usage context is implied rather than explicit, so it meets the minimum viable guideline but lacks clear exclusion criteria.

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 indicate readOnlyHint and openWorldHint. The description adds useful behavioral context about payment ('Pay-per-request') and authentication ('no API key required'), which are not captured in annotations. It does not contradict annotations and provides additional transparency beyond 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?

The description is a single, concise sentence that front-loads the primary purpose and includes key operational details. Every word adds value, 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?

Although the schema covers parameters and annotations cover safety, the description lacks context on parameter optionality and the relationship between company and domain. It does not explain how to combine name fields or what happens if multiple are provided. With no output schema, the description should clarify expected return behavior, but it only says 'find email address,' which is somewhat implied. This is adequate but with clear gaps.

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 all five parameters are documented. The description mentions 'name and company domain' but does not clarify the distinction between 'company' and 'domain' or how first_name/last_name/full_name relate. It adds minimal semantic value beyond the schema, so baseline 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's function: 'Find a person's email address given their name and company domain using MPP.' It specifies the resource (email address) and the required inputs (name and company domain), and it distinguishes from the sibling 'email_finder' by mentioning the MPP protocol and pay-per-request model.

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 context (pay-per-request, no API key) but does not explicitly state when to use this tool instead of alternatives like email_finder or email_verifier. It implies usage for MPP-based email lookup but lacks clear 'when not to use' or alternative 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?

Annotations already indicate readOnlyHint=true, and the description adds the pay-per-request cost behavior and lack of API key requirement, which are important operational details beyond the annotations. It does not disclose return format or potential delays, but the added cost context is valuable.

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, concise sentence that immediately states the tool's function and key differentiators. No wasted words, and the critical information is 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?

The tool is simple with only one parameter and no output schema. The description covers purpose and cost model, but it does not mention what the response/return value looks like (e.g., boolean status or detailed report), which is a gap given the absence of an output schema.

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 a description for the email parameter. The tool description adds the concept of 'deliverable' which gives more context to what verification means, but it does not add any specific parameter-level semantics beyond what the schema already provides.

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: verifying if an email is valid and deliverable. It also distinguishes itself from siblings by mentioning MPP and the pay-per-request model, which differentiates it from the non-MPP email_verifier.

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 context about the payment model ('Pay-per-request, no API key required') which implies when to use this tool, but it does not explicitly mention alternative tools (e.g., email_verifier) or provide exclusions. Usage is inferred rather than clearly 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 goes beyond annotations by disclosing the pay-per-request nature and the lack of API key requirement. This is valuable behavioral context not present in the readOnlyHint/openWorldHint annotations. It does not contradict annotations, and for a tool with annotations this level of additional disclosure is solid.

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, front-loaded sentence that directly states the tool's purpose and key differentiators. Every word earns its place, 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?

For a simple one-parameter tool with no output schema, the description covers the core purpose, input, and a critical operational detail (pay-per-request). It does not mention what happens on invalid URLs or whether charges apply for failures, but the overall context is sufficient for basic 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?

Schema description covers the single parameter fully ('The LinkedIn profile URL'), and the description repeats this context. With 100% schema coverage, the description adds no new semantic detail beyond what the schema already provides, so a 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 uses a specific verb ('Find') and a clear resource ('a person's email address from their LinkedIn profile URL'). It explicitly differentiates from sibling tools by mentioning MPP and the pay-per-request model, which sets it apart from the non-MPP 'linkedin_finder' and other finders.

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 when to use it: when you have a LinkedIn profile URL and need an email address via MPP. It provides clear context (pay-per-request, no API key) that helps an agent decide, but it does not explicitly name alternatives or state exclusions (e.g., when not to 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?

The annotations already provide readOnlyHint=true and openWorldHint=true. The description adds meaningful context by disclosing the pay-per-request billing model and the lack of an API key requirement, which are important operational behaviors not captured in the annotations. It does not contradict the annotations.

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, well-structured sentence that leads with the core action and then provides the key context (MPP, pay-per-request, no API key). There is no redundant or gratuitous text.

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?

While the tool is relatively simple, the description lacks guidance on the requirement that at least one of email/domain/linkedin be provided, and it does not describe the return format or behavior of 'full' mode. Since there is no output schema, description should compensate, but it leaves some operational gaps.

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 descriptions cover 100% of parameters, and the description restates the input types (email, domain, LinkedIn) without adding new semantic details. It also does not clarify parameter combinations or the meaning of 'full' beyond the schema, so it meets the baseline but adds no extra 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's function: finding phone numbers via email, domain, or LinkedIn profile. It also names the MPP protocol, distinguishing it from potential alternative tools. This is a specific verb+resource+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 implies usage by mentioning 'Pay-per-request, no API key required,' which suggests a context where payment per call is acceptable and API keys are not needed. However, it does not explicitly contrast with sibling tools like phone_finder or state when not to use this tool, so guidance is implied rather than explicit.

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 behavioral context beyond annotations by disclosing the pay-per-request cost and lack of API key requirement, which are important operational traits not captured in structured fields.

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, information-dense sentence that front-loads the primary action ('Validate a phone number') and includes key differentiators (carrier/location details, payment model, auth requirement). 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?

For a single-parameter, read-only validation tool, the description is largely complete: it states the purpose, a key output dimension (carrier and location), and the payment/auth model. It does not describe the response structure, but the low complexity and strong annotations reduce the need for deeper elaboration.

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%, and the 'phone' parameter has a description and pattern in the schema. The tool description does not add further parameter semantics, so the baseline of 3 applies; the schema carries the explanatory burden.

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 'Validate a phone number and get carrier and location details', which is a specific verb+resource. However, it does not explicitly distinguish this MPP variant from the sibling 'phone_validator', relying only on the MPP prefix and pay-per-request mention to imply a difference.

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 usage context by mentioning 'Pay-per-request, no API key required', which suggests a usage trade-off compared to non-MPP siblings. However, it does not explicitly state when to use this tool versus alternatives like 'phone_validator' or 'mpp_phone_finder', leaving the guidance implicit.

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 adds useful behavioral context beyond the readOnlyHint annotation by disclosing the pay-per-request model and lack of API key requirement. It does not contradict the annotations and provides additional information about cost and authentication.

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 concise sentence that immediately states the core purpose, then adds relevant contextual details. Every word earns its place; 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?

Given the simple parameter set, presence of readOnly and openWorld hints, and lack of output schema, the description adequately covers what the tool does and its payment/auth model. It does not explain output format, but the purpose makes that obvious.

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 the single parameter 'domain' with a clear description, and the tool description adds nothing beyond that. With 100% schema coverage, the baseline score 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 finds domains similar to a given domain, using a specific verb and resource. It does not explicitly differentiate from the sibling 'similar_finder' tool, but the MPP prefix and mention of the protocol imply a distinct payment model.

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 usage context by mentioning MPP and pay-per-request, which suggests this is a paid alternative to similar tools. However, it does not explicitly state when to choose this tool over siblings like 'similar_finder' or other MPP variants, so guidance remains implicit.

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 and openWorldHint, so the description gains credit for adding that results may include direct and company numbers 'when available'. This adds some behavioral context, but it does not disclose rate limits, authentication needs, or asynchronous behavior, keeping it at a baseline 3.

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 concise sentences, immediately states what the tool does, and includes only essential information. There is no fluff or repetition of schema details.

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 read-only lookup tool with clear annotations and well-described parameters, the description is largely complete. It covers the main input types and gives a sense of output (direct and company numbers), though it omits details about async webhook behavior or how to interpret missing results, which the schema partially addresses.

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 the baseline is 3. The description adds no extra meaning beyond what the schema already provides for each parameter; it merely labels the search sources, which the schema already explains.

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 tool finds phone numbers associated with email, domain, or LinkedIn profile, which is a specific verb+resource. It clearly distinguishes from phone_validator (validation vs. lookup), but does not differentiate from mpp_phone_finder, so it loses a point for incomplete sibling differentiation.

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 usage for phone number discovery when you have an email, domain, or LinkedIn URL. However, it does not explicitly state when to use this tool over alternatives like phone_validator or mpp_phone_finder, and provides no exclusions or alternative 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?

Annotations already declare readOnlyHint=true, and the description adds specific behavioral details by listing the returned data: carrier, line type, country, and validity. This goes beyond the annotation, though it does not disclose potential errors or rate limits, which keeps it a step below a perfect score.

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, front-loaded sentence that efficiently conveys the action and expected outputs. There is no redundant information, and every word contributes 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 tool with a single parameter and no output schema, the description sufficiently explains the return values, including validity, carrier, line type, and country. It gives the agent enough context to know what to expect from the call without requiring an output schema.

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 fully documents the phone parameter with a detailed description, pattern, and format recommendation, achieving 100% coverage. The tool description adds no additional parameter information, so the baseline score of 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 uses a specific verb 'validate' and resource 'phone number', clearly stating the returned information (carrier, line type, country, validity). It distinguishes itself from siblings like phone_finder, which focuses on finding numbers, by indicating this tool works on an existing number.

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 usage for validating a provided phone number, but it does not explicitly state when to use this tool over alternatives such as phone_finder or when not to use it. The context is clear but lacks explicit exclusions or alternative recommendations, placing it at the 'implied usage' level.

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 readOnlyHint and openWorldHint annotations already cover safety and determinism. The description adds that results are based on industry, size, and 'other factors,' but leaves 'other factors' vague and does not disclose potential limitations like result limits or data sources.

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, and contains no redundant or filler words. Every sentence contributes meaning.

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 finder with no output schema, the description adequately conveys the purpose, input, and basic return type ('Returns a list'). It lacks detailed result shape or volume, but openWorldHint compensates for expected variability. The simplicity of the tool makes this description nearly 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 fully documents the 'domain' parameter with a pattern and example, so the description adds no new meaning. The description simply restates that a domain is the input, matching the schema's coverage.

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 ('Find') and clearly identifies the resource ('companies similar to a given domain'). It distinguishes the tool from sibling finders by focusing on company similarity rather than emails, authors, or phone numbers.

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 usage for finding competitor or similar businesses based on a domain, but it does not explicitly state when to prefer this tool over alternatives like companies_search or mpp_similar_finder, nor does it mention any exclusions or prerequisites.

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 provide readOnlyHint and openWorldHint, and the description does not contradict these. It adds useful context about the return content (CMS, frameworks, analytics) but omits details like response format, data freshness, or coverage limitations.

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, focused sentence that front-loads the primary action and value. Every word contributes to understanding without redundancy 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?

For a simple one-parameter, read-only tool, the description adequately covers purpose and output categories. The lack of an output schema makes 'and more' slightly vague, but the overall description is sufficient for basic 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 schema fully describes the single 'domain' parameter with format and example. The description adds no extra semantic meaning for the parameter beyond saying it analyzes a website, so it does not improve on 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: 'Discover the technologies used by a website.' It specifies the resource (website) and the return value (tech stack including CMS, frameworks, analytics, and more), which distinguishes it from sibling tools that focus on author, email, phone, or company data.

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 clear context for when to use the tool—when you need to know a website's tech stack. However, it does not explicitly state exclusions or alternatives, such as suggesting a different tool for domain registration details or contact info.

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