Tomba MCP Server

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the operation's safety and open schema. The description adds 'current' and an 'including' list, but does not disclose additional behavioral traits such as authentication requirements or caching behavior. No contradiction with 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?

A single front-loaded sentence that states the action, target, and key fields with no filler or redundancy. It is appropriately sized for the tool's simplicity.

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 no-parameter, read-only tool with an output schema and readOnly/openWorld annotations, the description is nearly complete. The main shortfall is the lack of any pointer to the overlapping sibling 'usage_info', which would help an agent select correctly among the many siblings.

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 tool has zero parameters and the schema coverage is 100%, so there is no parameter vocabulary for the description to clarify. The description's content list refers to output, not inputs, and the zero-parameter baseline 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 names a specific verb ('Get'), resource ('current Tomba account information'), and content scope (plan, credits, usage limits), so the core purpose is clear. However, it does not differentiate from the sibling 'usage_info', which could overlap on credits and usage limits.

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 given about when to choose this tool over alternatives, particularly the similarly named 'usage_info'. An agent must infer that account_info covers account-level details rather than usage statistics.

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 basic safety profile is known. The description adds no behavioral context beyond restating the purpose, such as potential failure modes, whether results may be missing, or how the optional webhook affects execution.

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 short sentences with no filler. The core action is front-loaded, and the second sentence adds a useful application context 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 simple two-parameter tool with a read-only annotation and an output schema, the description covers the essential purpose and use case. It does not mention limitations or compare with sibling tools, but these are not strictly required for an agent to invoke this 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?

Schema coverage is 100%, so the input schema fully documents both 'url' and 'webhook_url'. The description refers to the URL concept but adds no extra parameter-level meaning 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 action ('Find the email address'), the resource ('an article's author'), and the input ('from a given URL'). It is specific enough for an agent to understand what the tool does, though it does not explicitly distinguish itself from similar siblings like mpp_author_finder 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?

The description provides an intended use case ('Useful for outreach to content creators and journalists'), which gives some contextual guidance. However, it does not explain when to prefer this tool over alternatives such as email_finder or person_enrichment, and it offers no exclusions or conditions.

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 communicate that this is a non-destructive, open-ended lookup. The description adds that logo and domain information is returned, but does not disclose behaviors such as result limits, matching behavior, or whether the API expects partial or full company names.

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 purpose and immediately states the additional data returned. Every word contributes value, and there is no redundant or filler content.

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 (one required parameter, no nested objects, output schema present) and the readOnly/openWorld annotations, the description covers the essentials. It could be slightly more complete by explaining the autocomplete behavior or the nature of the output, but the core calling context is sufficiently clear.

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 only defines a required 'query' string with no description, and schema coverage is 0%. The description's phrase 'autocomplete company names' indicates that the query refers to a company name or partial name, providing some semantic context, but it does not fully clarify the expected input format or matching rules.

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 clear action ('autocomplete company names') and specifies the retrieved data ('logo and domain information'), making the tool's purpose identifiable. It does not explicitly contrast with sibling tools like companies_search or domain_search, but its function is specific enough to be distinguished.

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 the tool is for interactive autocomplete/typeahead scenarios rather than general company search or enrichment, but it does not state any explicit when-to-use guidance or alternatives. There is no mention of when not to use this tool versus the many related 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no further behavioral context such as rate limits, data freshness, or failure modes, and 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?

At six words, the description is extremely concise and front-loads the core purpose ('Combined person and company enrichment'), with no filler 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?

Despite having an output schema and only one simple parameter, the description lacks enough detail to help an agent decide between combined_enrichment and its related single-purpose siblings; it would benefit from one sentence on when to use this combined call. The basic input requirement is clear, and the output schema covers return values, so this is a moderate 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 schema contains a single email field with format and pattern, and schema description coverage is 0%. The description's 'by email' merely restates the parameter name and adds no new semantic detail, so it does little to compensate for the lack of 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 description 'Combined person and company enrichment by email' clearly states the operation (combined enrichment) and the resource (person+company data via email). It distinguishes from siblings like person_enrichment and company_enrichment through the word 'Combined' and the 'by email' scope, though it lacks an explicit verb.

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

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

The word 'Combined' implies this tool should be used when both person and company enrichment are needed in one call, but the description never explicitly states when to choose it over person_enrichment or company_enrichment, nor does it mention any exclusions. Usage guidance is only implied, not 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?

Annotations already carry readOnlyHint=true and openWorldHint=true, so there is no safety contradiction or hidden side effect. The description adds little behavioral detail beyond the operation itself, but with annotations present the bar is lower and no extra caveats are required.

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

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

Two short sentences, front-loaded with the core search action. No wasted words, and the filter scope is stated before the outreach rationale.

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 search tool with a rich input schema, read-only annotations, and an output schema, a high-level description is largely sufficient. It doesn't explain pagination or webhook behavior, but those are documented in the schema and output schema, so no critical selection information is missing.

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

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

Schema description coverage is 100%, and the schema documents page, query, filters, and webhook_url, including a summary of the filter fields. The descrition only says 'name, industry, country, and more', adding no semantic detail 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?

States a specific verb ('Search') and resource ('companies in the Tomba database'), and lists common filters. It is clearly a company-list search tool, though it doesn't explicitly distinguish itself from sibling tools like domain_search or company_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?

Gives a clear use context: finding target companies for outreach. It doesn't name alternatives or state when not to use it, but the outreach-prospecting context is enough to route an agent to a broad company search.

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 need not restate safety. It does add some behavioral context by listing the types of data returned, but it omits caveats such as partial results when a domain isn't found, data freshness, or the fact that social profiles may not always be present. No contradiction exists.

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 names the action, the input key, and the result fields without any filler. It earns its place and wastes no tokens.

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 that this is a one-parameter, read-only tool with a full output schema and open-world annotation, the description is largely complete: it identifies what to pass, what kind of data to expect, and that results are not constrained to a closed list. The main gap is the lack of explicit guidance for choosing this tool over the many sibling enrichment/search tools.

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: it documents the domain parameter, its pattern, and a concrete example ('stripe.com'). The description only repeats that the lookup is by domain and contributes no additional semantic detail beyond 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 a specific verb ('Find'), a resource ('company data'), and the lookup key ('by domain'), and enumerates the data categories returned (industry, size, location, social profiles). It does not explicitly differentiate from sibling tools like companies_search or combined_enrichment, but the intent is 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 phrase 'by domain' implies the input condition for using the tool, and the surrounding context suggests you should call it when you have a company domain and need enrichment data. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative tools are named, leaving selection among the many enrichment siblings to inference.

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

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

The annotations only include openWorldHint, so the description carries most of the behavioral disclosure burden. It does not clearly state that this is a write/create operation, what side effects occur, or whether flags are created, updated, or replaced. 'Report' is vague about the actual mutation 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 front-loaded sentence with zero filler. It communicates the core purpose efficiently and has 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 and output schema cover field structures and return shape, the description leaves important context unstated: the write nature of the tool, the meaning of the flag fields, and any constraints around when flagging is appropriate. This is a notable gap for a mutation 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 for explaining flag_type, value, reason, and comment. The phrase 'incorrect data' loosely maps to the flagging concept but does not clarify what value represents or how to choose among the enum options. Minimal semantic value is added.

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 action ('report') and resource ('incorrect data') with a clear purpose ('for credit recovery'), avoiding tautology with the tool name. It does not explicitly differentiate from sibling tools, but the intent is clear enough for selection.

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

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

It provides clear context: use this tool when reporting incorrect data in the credit recovery flow. It does not name alternatives or state when not to use it, but the purpose is specific enough to guide appropriate usage.

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

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

Apart from the open-world annotation, the description adds no behavioral disclosure: no duplicate handling, no mention that this mutates data, no side effects, no prerequisites. 'Add' implies a write, but the description does not go beyond what the tool name already conveys.

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 with no filler and the verb/object are front-loaded. It is concise, though it could have used its brevity to add parameter or behavior context.

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 low-complexity create tool with an output schema, the description is minimally viable alongside the parameter schema. However, it omits side-effect and duplicate-email behavior, and the open-world annotation leaves open questions an agent may need answered before invoking.

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

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

Schema description coverage is 0% and the description compensates only by mapping 'list' to list_id; it does not explain email, first_name, last_name, company, or position, nor which fields are required beyond what the schema shows. With six parameters, this is insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact action ('Add') and object ('a new lead to a list'), which clearly distinguishes it from read/list tools like list_leads and from create_flag. No ambiguity about the tool's core function.

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 action phrase implies the tool is for inserting a lead into a list, but it gives no explicit guidance on when to prefer it over alternatives or when not to use it. For a simple creation tool the usage context is reasonably clear, but it is not 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, reducing the burden on the description. The description adds that results include metadata about each contact, but it does not disclose behavioral nuances such as pagination boundaries, the meaning of 'all' given page/limit controls, or asynchronous delivery via webhook_url. It neither contradicts nor meaningfully extends 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 front-loaded sentence that communicates the core action and result shape without padding. The only minor redundancy is 'specific domain or company' followed by 'given company domain', which slightly dilutes precision but does not materially harm clarity.

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 8 optional parameters and zero required parameters, the description is thin on operational context: it does not explain whether at least one of domain/company is required, how they relate, or when features like webhook_url or enrich_mobile should be used. The rich parameter schema and output schema mitigate this somewhat, but the description itself does not fully equip an agent to call the tool correctly in varied situations.

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 input schema already documents all 8 parameters. The description adds no extra meaning about how parameters interact, which of domain vs. company is preferred, or when filters should be used; the baseline score of 3 is appropriate because the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Search') and resource ('all email addresses associated with a specific domain or company'), and clearly indicates the return payload is a list with contact metadata. This is identifiable among many sibling search tools, but it does not explicitly name or contrast any sibling, so it falls short of a 5.

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

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

No guidance is given about when to use this tool versus alternatives like email_finder, email_count, or mpp_domain_search. There are no exclusion criteria, prerequisites, or hints about which of the 8 optional parameters should be supplied, leaving the agent to infer appropriate usage.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety guarantees. It adds a little context by specifying the nature of the check, but it does not describe output format, edge cases, or any other behavioral details 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 a single clear sentence with no filler. The key action and subject are front-loaded, making it easy to parse quickly.

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 lookup with an output schema and annotations already provided, the description covers the essential semantics. It could be slightly more complete by naming possible outcomes, but the output schema likely handles that.

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 fully documents the single domain parameter with an example and a pattern. The description does not add meaningful detail beyond what the schema provides, 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 ('Check') and clearly names the resource and purpose: determining if a domain is a webmail provider or disposable email service. It is not a tautology, and while it does not explicitly name sibling tools, its intent is distinct from related tools like email_verifier or domain_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 description implies the use case: call this when you need to know whether a domain is webmail or disposable. However, it provides no explicit guidance about when not to use it or which sibling tool might be a better alternative, so usage guidance is only 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 annotations already declare readOnlyHint=true and openWorldHint=true, covering the basic safety profile. The description adds the domain-scoped counting behavior and the pre-search use case, but does not disclose further behavioral details such as whether the count is approximate, cached, or rate-limited.

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 with no filler. The action and scope are front-loaded, and the second sentence offers a practical use case in minimal words.

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 tool with an output schema, the description covers the essential purpose and usage context. Minor gaps remain: it does not clarify whether the count is exact or estimated, nor does it address the similar mpp_email_count sibling.

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%: the single 'domain' parameter has a type, pattern, and descriptive example. The description's mention of 'a specific domain' adds no additional meaning 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 states a specific verb ('get the count') and a clear resource (email addresses for a specific domain), which directly explains what the tool does. It also distinguishes itself from search tools by framing the count as useful before a full domain 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 description gives clear context: use this to estimate potential reach before performing a full domain search. It implies an alternative approach (domain_search) but does not explicitly name it or state when not to use this tool.

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 supply readOnlyHint=true and openWorldHint=true, so the read-only safety profile is established outside the description. The description adds context about the nature of the returned data, but it does not disclose further behavioral traits such as response variability, rate limits, or data source caveats. There is no contradiction with 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, focused sentence that states the action, the object, and the expected enrichment fields. It contains no filler, repetition, or unnecessary detail, and each phrase 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?

Given that this is a one-parameter read-only tool with a full input schema and an output schema, the description covers the essential purpose and result categories well. It would be slightly more complete if it mentioned when to choose combined_enrichment or person_enrichment, but nothing critical is missing for correct invocation.

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

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

Schema coverage for the only parameter is 100%, and the schema already provides a description, format, and pattern for 'email'. The tool description adds no additional semantic meaning beyond restating that it is an email address, 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 uses a specific verb 'enrich' with a clear resource ('an email address') and lists the enrichment output categories (name, position, company details, social profiles). It is clear and informative, but it does not explicitly differentiate this tool from siblings like person_enrichment, company_enrichment, or combined_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 the tool is used when you have an email address and want additional person/company information. However, it provides no explicit guidance on when to choose this tool over alternatives such as combined_enrichment or person_enrichment, and it names no exclusions or alternative routing.

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 readOnly and openWorld; the description adds meaningful behavioral context on top of that by revealing the method ('generates and verifies') and, importantly, the probabilistic nature of the result ('most likely email format'), so the agent knows the output is a best-effort guess rather than a confirmed address. The description is consistent with the annotations; no contradiction.

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 totaling roughly 27 words, with the core purpose front-loaded and the second sentence earning its place by adding the uncertainty caveat. No fluff, no repetition of schema content, no tangential detail.

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?

Adequate for a lookup tool: an output schema exists so the description need not explain return values, and annotations cover safety and open-world behavior. However, it leaves gaps — all seven parameters are optional and the description gives no hint about invocation constraints, domain-versus-company alternation, or how to route around the overlapping email_* sibling cluster.

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 every parameter is already documented and the baseline is 3. The description contributes only a mild combinatorial hint — name plus either company name or domain — but does not clarify the relationship between domain and company or full_name versus first_name/last_name beyond what the schema already says.

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 ('Find'), a specific resource ('email address of a specific person'), and the needed inputs (name plus company domain or company name) — clearly more than a tautology. However, it does not explicitly distance itself from closely related siblings like email_enrichment, email_verifier, or email_format, so an agent must infer the distinction.

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 offered for when to choose this tool over its near-neighbors. With siblings such as email_enrichment, email_verifier, email_format, and email_sources in the same toolset, the description gives no routing criteria and no exclusions (e.g., 'if you already have an email, use email_verifier'), leaving the agent to decide on its own.

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 safe read-only and open-world nature is covered. The description adds no additional behavioral context such as confidence levels, completeness caveats, or output variability, but it does not contradict the annotations either.

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, clear, front-loaded sentence with no filler. It conveys the essential purpose 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 one-parameter read-only tool with an output schema and annotations covering safety and open-world behavior, the description is largely sufficient. Minor gaps remain around what 'format patterns' concretely returns, but the existing structured metadata compensates for most of this.

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 domain parameter already includes an example and format. The description adds little semantic value beyond referencing 'a specific domain', so the 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 clearly states the verb ('Get') and resource ('email format patterns') with a specific scope ('used by a specific domain'). It distinguishes the tool's purpose from siblings like email_finder or email_sources by focusing on format patterns, though it does not explicitly name 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 implies the tool is for retrieving format patterns for a given domain, but gives no explicit guidance on when to use it over email_finder, email_sources, or other related sibling tools. No exclusions, prerequisites, or alternative routing are provided.

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 mark the tool as read-only and open-world, so the safety profile is covered. The description adds the 'found on the web' context, but provides no detail on result sources, pagination, or limitations. There is no contradiction with 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, front-loaded sentence with no redundancy. It communicates the essential purpose in minimal words, which is ideal for an agent scanning tool descriptions.

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 lookup with an output schema and annotations, the description is largely sufficient for calling the tool correctly. The main missing element is usage guidance relative to siblings, which affects selection but not invocation.

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

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

The single required parameter `email` is self-evident from the tool name and description, and the schema provides format and pattern constraints. However, the description adds no additional semantic detail about the parameter beyond naming it, and schema description coverage is 0%.

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 and resource: find where an email address was found on the web. This clearly conveys the core function, though it does not explicitly differentiate it from sibling tools like email_finder or 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?

No guidance is provided about when to use this tool versus siblings such as email_finder, email_enrichment, or domain_search. The description only states what it does, not when it should be chosen 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=true, so the safety profile is covered. The description adds meaningful behavioral context by stating that it checks three specific aspects and does not send an email. This goes beyond the annotations and gives an agent confidence about side effects and scope.

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 short sentences with no filler. It front-loads the primary action, then lists the verification checks and the notable non-side-effect. Every sentence earns its place and the structure is easy to parse quickly.

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 output schema exists and annotations cover read-only behavior, the description is nearly complete. It explains what the tool verifies and that it is non-intrusive. It does not mention asynchronous webhook behavior or mobile enrichment, but those are covered by the input schema descriptions, so no critical gap remains.

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 input schema already documents the email, webhook_url, and enrich_mobile parameters. The description does not add extra meaning for any parameter, which is acceptable because the schema carries the full burden. 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 states a specific verb and resource: 'Verify if an email address is valid and deliverable.' It also details the exact checks performed (format, domain validity, mailbox existence), distinguishing it from sibling tools like email_finder, email_format, and email_enrichment. This is unambiguous and immediately tells an agent what the tool is for.

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 makes the core use case clear: validating an email address without sending an email. It does not explicitly name alternative tools or exclusions, but the wording strongly implies when it should be used. A small improvement would be an explicit contrast with email_finder or email_enrichment.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. However, the description adds little beyond the word 'recent'; it does not disclose ordering, retention limits, filtering behavior, or whether this only returns logs for the current API key/workspace.

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 with no filler. It is front-loaded with the verb and resource, and every word contributes to the basic purpose.

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, read-only, has zero required parameters, and has an output schema, so an agent can make a basic call without trouble. But the vague 'recent' and complete lack of parameter semantics leave clear gaps in understanding log scope and pagination.

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 needed to compensate for the undocumented 'page' and 'limit' parameters. It does not mention pagination, defaults, ranges, or how these parameters affect results, adding no semantic value beyond the schema's bare type declarations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('API request logs'), so an agent can infer what the tool returns. However, it does not explicitly distinguish this from potentially similar sibling tools like 'usage_info', so it stops short of a 5.

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

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

There is no guidance on when to use get_logs versus alternatives, no mention of prerequisites, and no exclusions. The phrase 'recent API request logs' gives some context but no actionable usage direction.

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 is consistent with the readOnlyHint and openWorldHint annotations but adds no behavioral detail beyond the basic extraction. It does not mention asynchronous behavior via webhook_url, optional mobile enrichment, rate limits, or any caveats about data availability.

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, with the primary action front-loaded in the first sentence. The second sentence adds a minor expansion from email to contact information but is not essential, so it loses a point.

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 rich schema, complete parameter descriptions, an output schema, and read-only/open-world annotations. Given those structured metadata sources, the description is mostly sufficient; the main gap is lack of guidance on choosing among similar siblings, which is already covered under usage guidelines.

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%, with all three parameters (url, webhook_url, enrich_mobile) already documented. The description provides no additional parameter-level meaning, so the baseline 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 states a specific verb ('Find') and resource ('email address associated with a LinkedIn profile URL'), making the core purpose clear. The second sentence broadens it to 'contact information' but does not explicitly distinguish from sibling tools like email_finder or mpp_linkedin_finder, so it does not fully earn a 5.

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

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

The intended usage is implied: call this when you have a LinkedIn profile URL and need the associated email. However, there is no explicit when-to-use or when-not-to-use guidance, and no comparison to alternative sibling tools such as email_finder or mpp_linkedin_finder.

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, covering the safe read-only nature of the operation. The description adds that flags have status and credit refund information, but does not disclose pagination behavior, data scope, or any other behavioral details beyond the structured 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, concise sentence that front-loads the main action and resource. Every word adds value, and there is no redundant or misleading content.

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 list tool with an output schema and read-only annotations, the description is mostly sufficient: it names the resource and the returned categories. It lacks only minor guidance about pagination and this is a safe read operation, so no critical information is missing for correct invocation.

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

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

Schema description coverage is 0%, and the description does not mention 'page' or 'limit' at all. The parameter names and schema constraints provide some meaning, but the description does not compensate for the complete lack of parameter documentation in 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 states a specific action ('List'), a clear resource ('submitted data flags'), and the key information returned ('status and credit refund information'). This clearly differentiates it from the sibling create_flag, which is the only closely related 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?

The description implies this tool is for viewing existing flags rather than creating them, which distinguishes it from create_flag. However, it does not explicitly state when to use this tool versus alternatives or mention any exclusions or limitations.

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 only needs to add context beyond those. It adds the scope 'all' but does not disclose potential concerns like pagination, response size, or authentication requirements. No contradiction with annotations, but the added behavioral detail is thin.

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 clear sentence with no filler words. It is front-loaded with the action and resource, making it immediately scannable.

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 has no parameters, an output schema covers return values, and annotations establish the read-only nature, the description fully covers what an agent needs. Nothing critical is missing for invoking this 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?

There are zero parameters and schema description coverage is 100%, so there is no parameter-level information the description must provide. The baseline for 0 params is 4, and the description correctly avoids inventing unnecessary parameter details.

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 'List all API keys for the account' uses a specific verb and resource, making the tool's purpose unmistakable. It also implicitly distinguishes itself from sibling tools like list_flags and list_leads by explicitly naming API 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 gives no guidance about when to use this tool versus alternatives, and it does not mention any exclusions or prerequisites. There is no reference to sibling tools or decision criteria, leaving the agent to assume the only 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=true, and the description does not contradict this. The description adds minimal behavioral context beyond the domain-filter scoping; it does not mention pagination behavior or return characteristics, but the read-only hint covers the safety profile.

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 short sentence with no filler, and the core action is front-loaded. Every word earns its place, making it highly efficient even if sparse in detail.

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 presence of an output schema and the readOnlyHint annotation covers return values and safety, and the domain filter is stated. However, with 0% parameter description coverage and no sibling differentiation or pagination context, the definition is only minimally complete for an agent navigating many similar tools.

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

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

Schema description coverage is 0%, so the description must compensate for missing parameter documentation. It clarifies that domain is an optional filter, but it says nothing about page or limit semantics, leaving two of three parameters unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource—'List leads'—and adds an optional domain filter that clarifies scope. It is distinguishable from sibling tools like create_lead or list_flags, though it does not explicitly contrast with similar search tools like domain_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?

There is no guidance on when to use list_leads versus alternatives such as domain_search, companies_search, or create_lead. The optional domain filter is the only contextual hint, and no exclusions, prerequisites, or conditions are provided.

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, so the safety profile is covered. The description adds the summary nature of the result (count by country), but does not explain details such as whether counts are approximate, whether all employees are included, or how country assignment works. It adds modest value beyond 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, front-loaded sentence with no filler. It conveys the essential operation, object, and scope efficiently.

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 with an output schema and annotations, the description is mostly complete. However, slight ambiguity around 'location count' (number of employees per country vs. number of locations per country) means a bit more context could improve clarity without bloating the 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 coverage is 100% with a clear description and pattern for 'domain'. The tool description merely repeats 'for a domain' and adds no additional semantic meaning. Baseline 3 is appropriate because the schema already documents the parameter fully.

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 and resource: 'Get employees location count by country for a domain.' It clearly identifies the operation and input domain, though it does not explicitly differentiate from sibling tools like email_count or domain_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?

There is no guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. The description simply states what it does without contextual placement among the many 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?

Annotations already mark the tool readOnly and openWorld, so the bar is lower. The description adds genuinely useful behavior beyond annotations: the request is pay-per-request and requires no API key. There is no contradiction with 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 short sentences that front-load the purpose and then state the key operational caveats: MPP, pay-per-request, and no API key. There is no filler, repetition, or irrelevant detail.

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

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

For a one-parameter tool with full schema coverage, read-only/open-world annotations, and an output schema, the description covers everything needed to select and call the tool correctly: what it does, its input, its payment model, and its auth requirements. No critical context is missing.

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

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

The input schema already describes the only parameter, url, at 100% coverage as 'The URL of the article or blog post'. The description echoes that the URL should point to an article or blog post, but adds little parameter-specific meaning 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 uses a specific verb ('Find') and a clear resource ('email address of the author of a blog post or article'), which makes the tool's purpose unmistakable. It also identifies this as the MPP variant by naming the protocol, helping to separate it from siblings like 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 gives clear operational context: use this tool when you need an author's email for an article/blog post and want pay-per-request access via MPP without an API key. It does not explicitly exclude alternatives or say 'use X instead', but the context is sufficient for practical routing.

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?

Read-only and open-world intent are already in annotations; the description adds valuable behavioral context beyond them, namely that calls are metered/pay-per-request and that authentication uses an InFlow buyer key rather than an API key. It does not detail result pagination or rate limits, but that is a minor gap 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 two sentences with no filler. The core purpose is front-loaded, and the second sentence adds operationally relevant cost/auth details in a compact dash-separated clause.

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

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

With a full output schema, 100% parameter coverage, and read-only/open-world annotations, the description is largely complete. It covers purpose, cost, and auth; it would be slightly stronger if it clarified that a domain is effectively the key input despite all parameters being optional.

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 schema already documents all six optional parameters. The description does not add meaning beyond the 'domain' parameter, which is acceptable but not value-adding; 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 names a specific verb and resource ('Search for all email addresses associated with a specific domain') and ties it to MPP with pay-per-request terms. The behavior is clear, but it does not explicitly contrast with the sibling domain_search or mpp_email_finder, so differentiation relies on inference.

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 concrete invocation context: it is pay-per-request, requires no API key, and needs only an InFlow buyer key. This is clear guidance on when the tool is the right payment/auth path, though it stops short of naming alternatives or stating when not to use it.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context by disclosing the pay-per-request billing model and the lack of an API key requirement, which are not visible in 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 focused sentence that front-loads the operation and resource, then efficiently adds the key MPP and billing context. No words are wasted.

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

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

For a simple tool with one fully documented parameter, read-only annotations, and an output schema present, the description covers the essential context: what is counted, the domain scope, the protocol, the cost model, and authentication. Nothing critical is missing.

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

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

The input schema fully describes the single 'domain' parameter with a pattern and description, so schema coverage is 100%. The description only restates that the count is 'for a specific domain', adding no new parameter-level detail beyond 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 a specific verb ('get') and resource ('count of email addresses available for a specific domain'), and adds the MPP context. It is understandable and distinct from generic counting, though it does not explicitly name the sibling 'email_count' as an alternative.

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 through 'using MPP', 'Pay-per-request', and 'no API key required', suggesting this is for MPP-based billing. However, it does not explicitly state when to use this tool instead of non-MPP siblings like 'email_count'.

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 value beyond annotations by disclosing that each request costs money and that no API key is required. However, it does not address failure modes, whether invalid emails still incur charges, rate limits, or what the open-world hint implies about result completeness.

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 zero filler: the core function is front-loaded in the first sentence, and the second packs the cost and auth model compactly. Every clause 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 tool with an output schema and read-only annotations, the description adequately covers function, cost, and auth requirements. The main gap is that among 37 siblings — including the near-identical email_enrichment — there is no explicit statement distinguishing when the MPP variant should be selected over the standard one; the agent must infer it from the payment model.

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% — the schema already documents the email parameter with format, pattern, and a description ('The email address to enrich'). The tool description restates the enrichment concept but adds no new syntax, validation, or formatting semantics beyond what the schema provides, so the 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 uses a specific verb ('enrich') with a clear resource (an email address) and states the expected output (detailed contact and company information). The MPP mention separates it from the non-prefixed sibling email_enrichment, but it does not explicitly contrast with mpp_email_finder or mpp_email_verifier — though their verbs do convey different jobs.

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 pay-per-request and no-API-key facts are a genuine usage signal: they tell an agent this MPP variant is the metered alternative to sibling tools that require a key or subscription. However, no alternative is named and no when-to-use vs when-not-to-use guidance is given, so the selection logic is left mostly to inference.

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

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

Annotations already cover read-only and open-world intent, so the description only needs to add context; it adds a cost warning ('Pay-per-request') and an authentication fact ('no API key required'). Rate-limit and error details are absent, but the most important operational trait is disclosed.

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

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

Two short sentences deliver the core action, input pattern, protocol, cost model, and auth model without wasted words. The most decision-relevant 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?

With five parameters, none marked required, and an output schema present, the definition is mostly complete, but the missing required-input combination (e.g., which name field and whether domain, company, or both) is a real gap. An agent could under-specify the request or incur an unintended charge.

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 every parameter has an individual description and the baseline is 3. The description's 'name and company domain' phrase does not clarify whether full_name replaces or complements first_name/last_name, nor whether domain and company are both needed, though schema-level descriptions cover each field's basic meaning.

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 concrete action ('Find a person's email address'), the required input pattern ('name and company domain'), and the mechanism ('using MPP'). It also distinguishes itself from the non-MPP sibling 'email_finder' by noting 'Pay-per-request, no API key required.'

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

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

It clearly signals when this variant is appropriate: pay-per-request and no API key needed. It does not explicitly name alternative tools or provide a 'when not to use' condition, so it stops short of a full routing guide.

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 baseline is lower. The description adds meaningful operational behavior: it is pay-per-request and requires no API key, which helps an agent anticipate cost and authentication expectations before invoking the tool.

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

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

A single, front-loaded sentence that states the action, the resource, the protocol context, and the key operational constraints. There is no filler or redundant restatement of the tool name.

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 verification tool, the description covers the core action, payment model, and authentication requirement. It does not describe the return format or exact deliverability semantics, but the low complexity and existing annotations make this adequate.

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 documents the single parameter with a description, format, and regex pattern, so coverage is essentially 100%. The description restates the purpose ('verify if an email address is valid') but adds no new parameter-specific semantics beyond what the schema 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 opens with a specific verb and resource: 'Verify if an email address is valid and deliverable.' It clearly distinguishes this from sibling tools like mpp_email_finder and mpp_email_enrichment because it is about verification, not discovery or 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 does not state when to use this tool versus alternatives. It gives operational context (pay-per-request, no API key required) but no explicit guidance on when to choose it over mpp_email_finder or mpp_email_count, or when not to use it.

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

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

Annotations already cover readOnlyHint and openWorldHint, so the bar is lower. The description adds genuinely new behavioral information: the operation incurs a per-request cost and requires no API key. There is no contradiction with 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?

A single dense sentence front-loads the action and resource, expands the MPP acronym, and conveys cost/auth context. Every phrase adds value with no 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 one-parameter lookup with an output schema and readOnly/openWorld annotations, the description fully covers the action, input, payment model, and authentication requirement. Nothing essential for invoking the tool correctly is missing.

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

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

Schema description coverage is 100% and the only parameter, url, is already described as 'The LinkedIn profile URL.' The description merely repeats that notion in prose and adds no format validation, examples, or additional parameter nuance.

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 and resource ('Find a person's email address from their LinkedIn profile URL') plus the distinct delivery mechanism ('using MPP'), which separates it from the sibling linkedin_finder and other enrichment tools. The action and input are 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 clear, decision-relevant context: 'Pay-per-request, no API key required.' This tells an agent when the MPP variant is appropriate, though it stops short of explicitly naming when not to use it or which sibling to prefer instead.

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 carry readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond the annotations by disclosing the payment model and the lack of an API key requirement. 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?

Two concise sentences: the first front-loads the verb, resource, and supported inputs; the second conveys the unique billing and authentication characteristics. Every sentence earns its place 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 tool with an output schema, zero required parameters, and fully described schemas, the description covers the core use case and the MPP-specific nuances. It could be more explicit about requiring exactly one of the three lookup keys, but the 'or' phrasing and the presence of a schema with all-optional properties provide adequate context for most agents.

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 individual parameters are already documented. The description restates the lookup types at a high level but adds no detail about precedence, combination rules, or formatting beyond what the schema already provides. 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 uses a specific verb ('Find'), names the resource ('phone numbers'), and enumerates the three supported lookup keys (email, domain, LinkedIn profile). It also differentiates from sibling tools by naming the protocol (MPP) and the pay-per-request/no-API-key model, so an agent can distinguish it from plain phone_finder and mpp_phone_validator.

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 this tool: when you want pay-per-request lookups without an API key. However, it never explicitly contrasts it with alternatives like phone_finder or mpp_phone_validator, nor does it state that only one of email/domain/linkedin should be supplied. The guidance is present but largely 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 does not need to repeat safety behavior. It adds value by disclosing that the operation is pay-per-request and requires no API key, which is important operational context not captured by 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?

Two concise sentences front-load the core action and result, then add the commercial/auth caveat. There is no filler or repetition of schema 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?

For a one-parameter read-only tool with an output schema and safety annotations, the description covers the essential context: what it validates, what it returns, the protocol, cost model, and auth requirement. It only lacks explicit sibling differentiation, which is a minor 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 schema has 100% coverage of the single phone parameter, including format, pattern, and E.164 requirement. The description adds no parameter-level detail, 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 states a specific action ('Validate a phone number'), a concrete result ('get carrier and location details'), and identifies the distinguishing protocol ('using MPP'), which differentiates it from the plain phone_validator sibling. The purpose is immediately clear.

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 useful contextual cues — pay-per-request and no API key required — which imply when this variant might be preferred. However, it never explicitly states when to use this tool instead of phone_validator or mpp_phone_finder, nor gives 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, and the description adds meaningful behavioral context beyond them: the cost model ('Pay-per-request') and authentication requirement ('no API key required'). These are useful traits that an agent needs to know before invoking the tool, and there is no contradiction with 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 short sentences with no filler. The primary purpose is front-loaded, and the payment/auth details are placed second for helpful context without bloating the description.

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 lookup with an output schema and annotations, the description covers the essential call context including billing and auth. It does not explain what 'similar' means or define result limits, but the output schema is likely to cover return structure, so the missing details are minor.

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% and the single 'domain' parameter already has a clear description in the schema. The tool description does not add significant extra meaning beyond restating the domain as the input, so the 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 resource ('domains similar to a given domain'), and explicitly identifies the MPP protocol, which distinguishes it from the sibling similar_finder. The purpose is immediately clear and not a tautology.

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 context about the billing model and authentication ('Pay-per-request, no API key required'), which implies a reason to prefer this tool over non-MPP siblings, but it does not explicitly state when to use it versus alternatives or any exclusions. The usage guidance is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the main behavioral traits. The description adds the type of data returned, which is mildly useful, but does not discuss limitations, data freshness, or any other behavioral nuances beyond what annotations provide.

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 efficient sentence with no wasted words. The verb is front-loaded and the rest of the sentence adds specific, useful detail about the expected output.

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 lookup with an output schema and annotations, the description is mostly sufficient. However, it does not steer the agent away from overlapping sibling tools like email_enrichment or combined_enrichment, which is a notable gap in a list of nearly 40 tools.

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 describes the email format via pattern/format but has no description for the parameter. The description only says 'by email', adding minimal semantic value about the parameter's role. With 0% schema description coverage, more compensation was expected.

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 a specific action ('Find person data by email') and names the resource and key output fields (name, position, company, social profiles). It is distinct from company/domain tools, but does not explicitly differentiate itself from closely related siblings like email_enrichment or combined_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?

Usage is only implied: the agent can infer it should be used when it has an email and wants a person's details. There is no explicit when-to-use/when-not-to-use guidance or mention of alternatives, despite a large sibling list containing similar enrichment 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?

The readOnlyHint and openWorldHint annotations already cover the safety profile and data availability. The description adds 'when available' and clarifies returns include direct and company numbers, but it doesn't disclose asynchronous behavior when webhook_url is provided. There is no contradiction with 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, focused sentence with an active verb and no filler. It front-loads the purpose and adds relevant output context efficiently.

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

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

With zero required parameters in the schema, the description should explicitly state that at least one of email, domain, or linkedin must be provided. It also omits that webhook_url changes delivery to asynchronous. These operational gaps prevent full completeness, though the output schema and annotations cover much of the rest.

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 each parameter is already documented. The description only restates the lookup categories in prose and doesn't clarify interactions between parameters, mutual exclusivity, or the effect of full or webhook_url.

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 purpose: finding phone numbers via email, domain, or LinkedIn profile. It also specifies what kind of results are returned (direct and company numbers). It doesn't distinguish itself from siblings like mpp_phone_finder or phone_validator, which prevents a top score.

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: when an agent has an email, domain, or LinkedIn profile and needs associated phone numbers. However, it doesn't explicitly say when not to use it, nor does it mention alternatives such as phone_validator for verification tasks.

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 safety profile is clear. The description adds meaningful details about the return content (carrier, line type, country, validity). It does not contradict annotations, but it also does not disclose caveats such as data availability by region, external lookup behavior, or potential variability, which would have been valuable 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?

The description is two short sentences with no filler. It leads with the primary action, states the resource, and enumerates the useful output fields. Every sentence 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 tool with one required parameter, a fully documented input schema, an output schema, and read-only annotations, the description is largely sufficient. The only missing element is a brief note about when carrier/line type may not be available or how this differs from phone_finder for discovery use cases.

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 documentation with a regex pattern, a description, and an example format for the 'phone' parameter. The description does not add additional parameter-level meaning beyond what is already in the schema, 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 clearly states the tool validates a phone number and lists the specific information returned: carrier, line type, country, and validity. This is a clear verb+resource description. However, it does not explicitly distinguish itself from sibling tools like phone_finder or mpp_phone_validator, so it falls short of full 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 use case is implied: use this tool when you need to validate a phone number or retrieve metadata about it. However, there is no explicit guidance on when to choose this over alternatives such as phone_finder, nor 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?

The annotations already cover read-only and open-world behavior, lowering the description's burden. The description adds useful context that results are based on industry, size, and other factors, but it does not disclose data sources, ranking logic, pagination, or result variability beyond what openWorldHint already implies.

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, front-loaded with the action and result, with no filler or repetition of the title. Every clause contributes 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?

For a one-parameter, read-only tool with an output schema and annotations, this description is nearly complete: it states what to do, what is returned, and the similarity criteria. It could be improved by pointing to mpp_similar_finder or noting limitations, but nothing critical is missing for basic invocation.

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

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

Schema description coverage is 100%, and the input schema already gives a meaningful description for the single domain parameter. The tool description mostly restates the schema's intent and adds no extra guidance about domain syntax or edge cases.

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') with a clear resource ('companies similar to a given domain') and states the output type ('a list of competitor or similar businesses'). It is distinct from domain_status and domain_search, though it does not differentiate from the sibling mpp_similar_finder or clarify its relationship to companies_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 'for a given domain' establishes a clear precondition: call this tool when the agent has a domain and wants similar companies. However, there are no explicit exclusions or named alternatives, so it stops short of the top tier.

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 safe-read and open-world nature is covered. The description adds that results include tech-stack categories, but doesn't discuss potential gaps, accuracy limits, or reliance on publicly observable data. This is acceptable but not rich behavioral 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?

The description is a single focused sentence that leads with the core verb and object, then gives typical return categories. Every word contributes to understanding the tool, 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?

This is a simple one-parameter read-only tool with full schema coverage, an output schema, and clear annotations. The description explains the return content sufficiently; no critical call-time information is missing.

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

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

Schema description coverage is 100%, so the domain parameter is already well documented. The description does not add any parameter-level detail beyond what is in 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 states a specific action and resource: 'Discover the technologies used by a website.' It also clarifies scope by listing CMS, frameworks, analytics, and more. It does not explicitly differentiate from sibling tools, but none of the siblings obviously compete with this function.

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 what technologies a website runs on. It does not mention exclusions or alternatives, but there are no obvious sibling tools that provide the same capability.

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 consistently describes a read-only operation. It adds useful scope context by specifying 'across all endpoints' and indicates a snapshot of current usage, which goes slightly beyond the structured 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 concise sentence that immediately names the action and the resource. No filler or redundant repetition of the tool name exists.

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 parameterless read-only tool with an output schema provided, the description is sufficient for an agent to understand when and how to call it. No additional behavioral or return-value details are necessary given the annotations and 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 tool has zero parameters, and the description correctly adds no parameter-specific details. There is nothing for the description to clarify beyond what the empty schema already communicates.

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 a specific action ('Get') and a well-defined resource ('current API usage statistics across all endpoints'). It does not explicitly differentiate from siblings like account_info or get_logs, but the resource is specific enough that an agent can infer the tool's role.

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 the tool should be used when current API usage statistics are needed, but it provides no explicit guidance about when to use this tool versus alternatives, nor any exclusions. With many sibling tools present, explicit routing would be more helpful.

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