MDataAccess

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions that the request is 'paid' and that it only 'prepares' a request, but it does not clarify whether charges occur immediately, what side effects happen, or what the output represents relative to the tool name 'enrich_company'.

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 one tight sentence with no filler. The key qualifiers ('paid', 'when a company name or domain is known') are front-loaded and every word contributes.

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 paid operation with no annotations, the description is too thin. It leaves ambiguity between 'prepare a request' and actually performing enrichment, and it does not help an agent decide between this and sibling tools beyond the company-name/domain condition.

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

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

Schema description coverage is 0%, so the description must compensate. It maps 'company name' to the name parameter and 'domain' to the website parameter, which is helpful, but it does not explain URL formatting, whether either parameter is preferred, or the consequences of providing both.

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 ('Prepare a paid company enrichment request') on a specific resource ('company') with an input condition ('when a company name or domain is known'). It implicitly distinguishes from person-focused siblings like enrich_person, 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 gives clear use context: call this when a company name or domain is known. It does not mention exclusions or directly contrast with siblings such as search_companies or find_lead, but the condition is actionable enough for basic 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that the operation is paid, which is an important consequence, but it does not clarify whether enrichment is actually performed or only staged, what side effects occur, or what permissions or limitations apply. 'Prepare a request' is vague about the tool's real effect.

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. The key concept—paid person enrichment—is front-loaded, and the trigger condition is stated efficiently. The brevity costs are related to completeness, not structure.

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 output schema covers return shape, but for a paid tool with four optional parameters and no annotations, significant gaps remain: the role of company, whether the enrichment is executed or only prepared, and how multiple identifiers interact. An agent would still need to infer too much to invoke it confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It gives meaning to name, email, and linkedin_url by framing them as identifiers sufficient to trigger enrichment, and the 'or' implies at least one is needed. However, it omits the company parameter entirely and provides no format or combination guidance.

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 operation—preparing a paid person enrichment request—and gives the triggering identifiers (email, LinkedIn URL, or name), which helps distinguish it from sibling tools like enrich_company or search_people. The verb 'prepare' is slightly indirect, but the resource and scope are 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?

It provides a clear invocation context: use this tool when an email, LinkedIn URL, or name is known. However, it does not explicitly mention when not to use it or point to alternatives such as search_people for free lookups or enrich_company for company 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It mentions 'paid request' implying a cost or side effect, but it does not explain what 'preparing a request' entails, whether it actually sends the request, what data is returned, or any rate limits or authentication needs. This is a significant transparency gap for a tool that appears to involve a financial or external action.

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 with no filler or redundancy. It front-loads the core action. However, it is under-specified rather than efficiently structured; the brevity comes at the cost of missing behavioral and contextual details, but the dimension is about conciseness and structure, which is acceptable here.

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 an output schema, return values need not be described, but the description still fails to cover critical usage context. It does not explain when to use the tool, what a 'paid request' implies, or how the parameters should be provided. With two required parameters and no annotations, the description is insufficient for an agent to call the tool correctly without additional context.

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 only references 'company' and 'function' without adding any detail about formats, examples, or constraints. The agent knows the two parameters exist but nothing beyond their names. The description does not compensate for the missing schema documentation, so parameters remain underspecified.

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 ('prepare a paid request') and a specific target ('one senior decision-maker at a known company and function'). It distinguishes from siblings like search_people and find_lead by emphasizing the paid-request and known-company context, though it doesn't explicitly name a sibling alternative. The verb 'prepare' is slightly ambiguous versus the tool name 'find', but the overall intent is 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 implies the tool should be used when a company and function are already known, but it does not explicitly state when to use this tool over siblings like find_lead or search_people. There are no exclusions, prerequisites, or alternative routing. An agent would have to infer the appropriate context from the 'known company and function' phrasing, which is weak guidance.

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

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

No annotations are provided, so the description bears the full burden. It does disclose the significant behavior that this is a 'paid request,' implying a cost or side effect. But it leaves ambiguous whether the request is merely prepared or actually executed/purchased, and offers no detail on authorization, reversibility, or rate limits. This is a meaningful transparency gap for a paid 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?

The description is a single concise sentence with no filler. The core purpose is front-loaded, and every word adds meaning. It could include more detail, but as a structure it is tight and efficient, just missing some information that would make it more valuable.

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 paid operation with no annotations and no output schema details, the description is under-specified. It does not explain what happens after the request is prepared, what a 'compact sales-ready lead' entails, or how this tool relates to siblings like enrich_company or find_decision_maker. An agent cannot fully determine side effects, return semantics, or invocation prerequisites from this 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?

With 0% schema description coverage and only parameter names, the description must compensate. It does map the two parameters to 'known company and function,' providing a basic conceptual link. However, it gives no format, examples, or acceptable values, and does not clarify what 'function' means in this context (e.g., job function vs. business function). This is insufficient compensation for the low schema coverage.

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

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

The description states a specific action – 'Prepare a paid request' – and a specific resource: 'one compact sales-ready lead at a known company and function.' This clearly distinguishes it from siblings like search_people or find_decision_maker by focusing on a sales-ready lead rather than search or specific roles. However, 'prepare a paid request' is slightly ambiguous about whether the tool returns the lead or just creates a request, preventing 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 phrase 'at a known company and function' implies the tool is appropriate when the user already has these two inputs and wants a sales-ready lead. This gives clear context for when to use it. It does not explicitly name alternatives or state when not to use it, so it lacks the exclusions needed for a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It meaningfully discloses that the operation is paid, that it works on public URLs only, and that output is cleaned text. It does not mention rate limits, authentication, or failure behavior, but for a simple one-parameter read tool the most important behavioral trait—cost—is stated.

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 sentence with no filler. The critical constraints—paid, public, known URL, clean text—are packed in efficiently, and the most decision-relevant modifier ('paid') appears early.

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 low-complexity tool with only one parameter and an output schema available, so the description does not need to explain return structure. It covers the core prerequisites: the target must be a known public webpage, and the call is paid. Missing details like error handling or cost specifics are minor gaps for a simple fetch-style 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?

The input schema provides zero description for the single 'url' parameter, so the description must compensate. It adds useful context by specifying the URL must be for a known public webpage and that the result is clean text. However, it does not clarify expected URL format, whether the URL should be fully qualified, or how status codes/errors are handled, leaving some ambiguity for the agent.

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 resource (webpage URL) and action (read clean text), which clearly identifies what the tool does. The phrase 'Prepare a paid request' slightly obscures whether the tool actually performs the read or merely stages a request, but the tool name and 'to read clean text' make the intent understandable. The sibling tools are all about people/companies, so there is no real overlap to distinguish against.

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 you have a known public webpage URL and want clean text. It does not explicitly discuss when not to use it or provide alternative tools, though none of the listed siblings obviously compete with reading a webpage. The 'paid request' warning is useful context for cautious use, but there is no explicit guidance about avoiding unnecessary calls or handling non-public URLs.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden. It usefully discloses that the operation is paid and that the API returns exactly one company, but it does not describe side effects, billing behavior beyond 'paid', failure modes, or rate-limit implications.

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 with no filler. The core purpose is front-loaded, and the exact-one-returned caveat is a necessary behavioral detail stated 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 single-parameter tool with an output schema, the description covers the essential operational facts: paid nature, PDL SQL, company scope, and single-result behavior. It lacks explicit comparison to siblings like search_people and enrich_company, but the core context an agent needs to invoke it is present.

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 zero description coverage for the sql parameter, so the description must compensate. It adds that the parameter holds a PDL SQL company-search query, which is meaningful, but it gives no syntax details, examples, or supported SQL constructs. This is partial but not complete compensation for an undocumented parameter.

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

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

The description identifies a specific action (prepare a paid PDL SQL company-search request) and the resource being searched (companies), and it adds the key constraint that exactly one company is returned. It is clearly separated from search_people by the 'company-search' scope, though it does not explicitly name sibling 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 gives clear context: use this tool for company search via PDL SQL, and expect exactly one company in the result. It does not spell out when not to use it or point to alternatives like search_people or enrich_company, so it stops short of full routing guidance.

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

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

With no annotations, the description must carry behavioral disclosure. It does disclose that the request is paid and that exactly one profile is returned, which are useful operational facts. However, it leaves ambiguity about whether the tool actually executes the search or only prepares the request, and it does not mention error behavior, invalid SQL, or rate limits.

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

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

The description is just two sentences with no filler, and each sentence carries useful information: the request's nature and the single-profile result. The phrasing 'Prepare a paid PDL SQL person-search request' is slightly awkward but still compact and 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?

For a one-parameter tool with an output schema, the main missing pieces are parameter semantics and execution behavior. An agent still does not know how to construct a valid PDL SQL query or whether invoking the tool immediately triggers a paid call, so the description is not fully sufficient 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 is 0%, so the description must compensate for the undocumented 'sql' parameter. It adds that the SQL is PDL SQL and person-focused, but it does not explain the expected query grammar, required fields, or constraints, leaving the agent with only a partial understanding of the parameter.

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

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

The description identifies a person-search request and notes that exactly one profile is returned, so an agent can tell it targets people rather than companies. It does not clearly differentiate from person-focused siblings like enrich_person, find_lead, or find_decision_maker, and 'prepare a request' is an indirect way to describe the action.

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 search_people versus alternatives such as enrich_person or search_companies. The description provides no conditions, exclusions, or context that would help an agent decide between sibling tools.

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