Access Versium's B2B2C identity graph directly through your AI agent. Generate targeted lead lists, enrich records with contact and firmographic data, validate emails, and size audiences — all through natural language. No manual exports or API coding required. Requires an active Versium REACH subscription with API access.
Scored across 20 tools
Each append tool targets a distinct data direction or type (B2B2C, C2B, contact, demographic, firmographic, IP-to-domain), and listgen tools split clearly by consumer versus business audience. Some overlap is possible between contact_append and demographic_append or b2b2c_append for unfamiliar users, but the descriptions provide enough boundary clarity.
Most tools follow a recognizable pattern: enrichment tools end in _append, listgen tools use b2b_listgen_* / b2c_listgen_*, and management tools use verb_noun forms like create_job, list_projects, and show_list. A few outliers like email_validation and job_status use noun-style names, but they are still consistent within their subdomain.
At 20 tools, the set is at the upper edge of the ideal range, but each tool maps to a distinct operation in the REACH platform: enrichment appends, listgen estimates/options, project/list management, job status, validation, and docs search. No tool feels redundant given the breadth of enrichment and audience-building workflows.
The set covers the core REACH workflow: enriching records across multiple domains, estimating and generating lists, checking job status, and managing projects and lists. It lacks update/delete operations for projects/lists and only offers sampled list previews rather than full export, but these are minor gaps that agents can work around.
Enrich a business contact in a marketing list with their consumer-side profile, so B2B audiences can be reached through consumer channels: with a LinkedIn URL or a name + city/state, append business email plus consumer mobile phone, consumer email, and consumer address data in a single match.
Use this tool when users ask for 'B2B2C', 'b2b2c', or 'Business to Business to Consumer' data.
**Tips for Best Results:**
- Provide a LinkedIn URL (format: linkedin.com/in/username) for the best match quality
- Alternatively provide first name, last name, city, and state together
- Choose one or more outputs; use `required_outputs` to return only records that matched those outputs| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5 digit ZIP code | |
| city | No | City name | |
| last | No | A person's last name | |
| No | A known email address for the contact | ||
| first | No | A person's first name | |
| state | No | Two-character state code (US) | |
| li_url | No | A LinkedIn URL (accepts https://www.linkedin.com/in/username, www.linkedin.com/in/username, or linkedin.com/in/username) | |
| address | No | Street address | |
| country | No | Two-character country code (currently only US data is supported) | |
| outputs | Yes | Contact data to return: business_email, consumer_mobile, consumer_email, consumer_address | |
| required_outputs | No | Subset of outputs a record must have to be returned | |
| cfg_max_emails_b2c | No | Maximum consumer email addresses to return per record | |
| cfg_max_phones_b2c | No | Maximum consumer phone numbers to return per record |
| Name | Required | Description |
|---|---|---|
| results | No | Records returned by the Operations API. Record fields pass through unchanged. |
| query_id | No | |
| warnings | No | |
| input_query | No | |
| num_matches | No | Number of matching queries. |
| num_results | No | Number of records returned. |
| match_counts | No | Sparse match counts. An absent key means zero. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral context beyond annotations: it explains the enrichment process, the role of required_outputs in filtering results, and the configurable maximum outputs (cfg_max_emails_b2c, cfg_max_phones_b2c). It does not contradict annotations and adds useful operational details, though it doesn't cover every edge case (e.g., error handling or rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, usage guidance, and a bulleted 'Tips for Best Results' section. It is slightly longer than necessary but every sentence adds value, and the tips are practical. The front-loading of the core purpose and usage condition is effective.
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 an output schema exists (per context signals), the description does not need to explain return values. It covers input options, output selection, configuration parameters, and the matching strategy. The description is complete enough for an agent to know how to invoke the tool correctly, including the US-only limitation (noted in the schema) and the required outputs behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter has a description. The description adds significant semantic value by explaining the two primary input modes (LinkedIn URL vs. name+city/state) and the purpose of required_outputs, which is not fully apparent from the schema alone. It also clarifies the relationship between outputs and required_outputs, making parameter usage unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: enriching a business contact with consumer-side profile data, specifying the resource (business contact) and the action (append consumer data). It also names the target use case (B2B2C) and the data types involved, making it distinct from the sibling tools like c2b_append or contact_append.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('when users ask for B2B2C...') and provides best-practice tips for input formats (LinkedIn URL vs. name+city/state). However, it does not mention when not to use it or name alternative tools, which would earn a 5. The usage context is clear but lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate business contact audience sizes with firmographic and role-based targeting using Versium's B2B Persona Audience Builder (B2B Listgen) API.
**Tips for Best Results:**
- Start with a single output type and add filters incrementally
- Combine geography with company size or industry filters for precise targeting
- Use title_seniority for leadership focus, or department for functional targeting
- Provide SIC codes when you need strict industry alignment
- To check values for fields with large, high-cardinality option sets, call the B2B Persona Listgen Options tool
- Toggle `cfg_b2cloc` to switch between business-location and home-location targeting| Name | Required | Description | Default |
|---|---|---|---|
| d_sic | No | Legacy 4-digit SIC codes | |
| d_zip | No | U.S. ZIP codes (5-digit codes) | |
| output | No | Campaign type specification. Must include exactly one: "email" or "oa". Email should almost always be used; OA can ONLY be used for audience targeting in ad platforms and will return hashed data | |
| d_naics | No | Raw 2- to 6-digit NAICS codes. Use the options tool to retrieve valid values | |
| d_state | No | U.S. states (2-letter codes) | |
| rd_role | No | Job roles. Use the options tool to retrieve valid values | |
| d_county | No | U.S. counties (full county names) | |
| cfg_b2cloc | No | Whether location filters apply to business location (0) or employee home location (1) | |
| max_records | No | Cap the number of records returned by the eventual list build | |
| d_city_state | No | U.S. City and state combinations, e.g. "Austin, TX" | |
| d_salesvolume | No | Company revenue range, in the format "min-max" (e.g. "100000-1000000" for $100K to $1M) | |
| rd_department | No | Job departments. Use the options tool to retrieve valid values | |
| d_numemployees | No | Company size range, in the format "min-max" (e.g. "100-50000") | |
| rd_title_seniority | No | Title seniority levels |
| Name | Required | Description |
|---|---|---|
| results | No | |
| query_id | No | |
| warnings | No | |
| input_query | No | |
| num_matches | No | |
| num_results | No | |
| match_counts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds valuable context by framing the operation as an estimate of audience sizes rather than a list build. It also discloses the cfg_b2cloc behavior for switching between business-location and home-location targeting, which is useful beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence and then organized into concise, scannable bullet tips. Each tip earns its place by providing actionable guidance for a complex 14-parameter tool, with no redundant 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?
Given the tool's complexity, the description is complete: it states the core purpose, offers filter selection strategies, points to the options tool for valid values, and clarifies location targeting behavior. The output schema and annotations cover return values and safety, so the description does not need to repeat those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds meaningful parameter guidance: it explains when to use title_seniority vs department, when to provide SIC codes, and how to interpret cfg_b2cloc. These tips go beyond the schema definitions by linking parameters to targeting strategies.
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: 'Estimate business contact audience sizes with firmographic and role-based targeting using Versium's B2B Persona Audience Builder (B2B Listgen) API.' This clearly distinguishes the tool from siblings like b2c_listgen_estimate (B2C) and b2b_listgen_options (options lookup).
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 'Tips for Best Results' section provides concrete guidance on when to use specific filters, such as using title_seniority for leadership focus, department for functional targeting, and SIC codes for strict industry alignment. It also explicitly directs users to call the B2B Persona Listgen Options tool for high-cardinality field values, though it does not explicitly contrast with the B2C sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return allowed option values for B2B Persona Listgen filter fields such as NAICS, department and role.
Use this tool when you need the valid values for large, high-cardinality fields too big to embed directly in tool schemas.
| Name | Required | Description | Default |
|---|---|---|---|
| field | No | The field for which options are requested | |
| limit | No | Maximum number of returned values. Optional; default 50 | |
| query | No | Case-insensitive substring to filter option values. Optional | |
| offset | No | Pagination offset. Optional; default 0 |
| Name | Required | Description |
|---|---|---|
| field | No | |
| query | No | |
| offset | No | |
| values | No | |
| returned | No | |
| next_offset | No | |
| total_matches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about high-cardinality fields but doesn't disclose pagination behavior or response format beyond what the schema implies. With annotations covering the safety aspects, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and every word earns its place. The first sentence states what it does, the second explains when to use it. No fluff.
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 an output schema, so return values are documented. The description covers purpose and usage context. With 100% schema coverage and good annotations, the description is complete enough for an agent to select and invoke the tool correctly. The only minor gap is not listing example field values, but that's not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are documented in the schema. The description adds the context that fields like NAICS are high-cardinality, which helps understand why the tool exists, but doesn't add parameter-specific meaning beyond the schema. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns allowed option values for B2B Persona Listgen filter fields, naming specific examples (NAICS, department, role). It distinguishes itself from the sibling b2c_listgen_options by specifying B2B, and the verb 'Return' is specific to the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this tool when you need the valid values for large, high-cardinality fields too big to embed directly in tool schemas,' which provides clear context for when to use it. It doesn't explicitly mention alternatives or when not to use it, but the context is sufficient given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate consumer audience sizes using Versium's Consumer Audience Builder (B2C Listgen) API. Supports the full configuration and demographic filter set
For fields with large, high-cardinality option sets (e.g. esthhldincome), use the Consumer Audience Options tool to retrieve available values
Any property restricted to `enum: ["Y"]` is enabled by sending `"Y"`. For example, pet owners who golf in Washington use `{"state":["WA"],"d_pets":"Y","d_golf":"Y"}`.
Call `b2c_listgen_options` with `field: "attribute_flags"` when you need the human-readable meanings of those flag names.
**Tips for Best Results:**
- Start with a single output type and add filters incrementally
- Combine geography with age, income, or lifestyle filters for precise targeting
- Leverage lifestyle and interest filters to reach specific consumer segments| Name | Required | Description | Default |
|---|---|---|---|
| d_age | No | Age range in years (single value or min-max, e.g., "35-45") | |
| d_lor | No | Length of residence in years (single value or range) | |
| d_zip | No | Array of 5-digit ZIP codes to filter by | |
| d_golf | No | ||
| d_news | No | ||
| d_pets | No | ||
| d_soho | No | ||
| d_state | No | Array of 2-letter state codes to filter by | |
| d_county | No | Array of county,state combinations (e.g., "King, WA") | |
| d_gender | No | Gender filter (M=Male, F=Female) | |
| d_travel | No | ||
| d_fishing | No | ||
| d_hunting | No | ||
| d_ownrent | No | Home ownership status codes (H=Owner, R=Renter, 9=Probable Owner) | |
| d_exercise | No | ||
| d_language | No | Language codes. See values in options tool | |
| d_networth | No | Estimated net worth range using codes. See values in options tool | |
| d_religion | No | Religion codes. See values in options tool | |
| d_shooting | No | ||
| d_auto_year | No | Automobile year range (single year or min-max) | |
| d_education | No | Education level codes: A=High School, B=College, C=Graduate, D=Technical/Vocational | |
| d_gardening | No | ||
| d_hhld_size | No | Household size range (1-9, e.g., "2-4"); 9 means 9 or more | |
| d_home_year | No | Year home was built (single year or range) | |
| d_magazines | No | ||
| d_refi_date | No | Refinance date or date range using YYYYMMDD format | |
| max_records | No | Cap the number of records returned by the eventual list build | |
| d_city_state | No | Array of city,state combinations (e.g., "Seattle, WA") | |
| d_home_value | No | Home value range. See values in options tool | |
| d_occupation | No | Occupation codes. See values in options tool | |
| d_weightloss | No | ||
| max_coverage | No | Request append processing for selected channels (must overlap required/optional fields) | |
| cfg_zipradius | No | Radius expansion (pseudo-miles) applied around supplied ZIP or city/state centers | |
| d_creditlines | No | Number of credit lines range (e.g. "0-5") | |
| d_electronics | No | ||
| d_ethnicgroup | No | Ethnic group codes. See values in options tool | |
| d_hhldveteran | No | ||
| d_loantovalue | No | Loan-to-value percentage as single value or range (0-100) | |
| d_motorcycles | No | ||
| d_refi_amount | No | Refinance amount in thousands (single value or range) | |
| d_senior_hhld | No | ||
| d_apparel_mens | No | ||
| d_creditrating | No | Credit rating range. See values in options tool | |
| d_donation_env | No | ||
| d_dwellingtype | No | Dwelling type codes (M=Multi Family, S=Single Family, U=Unknown) | |
| d_num_children | No | Number of children range (0-8, e.g., "2-3") | |
| d_singleparent | No | ||
| d_workingwoman | No | ||
| d_esthhldincome | No | Estimated household income range using codes. See values in options tool | |
| d_maritalstatus | No | Marital status codes (M=Married, S=Single, A=Married (Inferred), B=Single (Inferred)) | |
| d_mortgage_rate | No | Mortgage interest rate percentage (e.g., "6.75%", "10%") | |
| optional_fields | No | Optional contact fields to include when available | |
| required_fields | No | Required output contact fields. Must include at least one. Recommended to include address for estimate calls for geo info. IMPORTANT: Unlike the B2B Persona API, this field along with optional_fields are used to define output instead of the "output" parameter | |
| cfg_require_name | No | Set to true to require full names in the output | |
| d_apparel_womens | No | ||
| d_auto_makemodel | No | Auto make and model combo(s) (e.g. "Ford:Escape") | |
| d_mailorderbuyer | No | ||
| d_mortgage2_date | No | Second mortgage date in YYYYMMDD format | |
| d_mortgage2_rate | No | Second mortgage interest rate percentage | |
| d_refi_loan_type | No | Refinance loan type codes. See values in options tool | |
| d_refi_rate_type | No | Refinance rate type codes. A=Adjustable, B=Balloon, F=Fixed, U=Unknown | |
| cfg_require_email | No | Set to true to require email addresses in the output | |
| cfg_require_phone | No | Set to true to require phone numbers in the output | |
| contacts_per_addr | No | Maximum contacts per street address (0=unlimited, 1=one contact per address) | |
| d_cardholder_bank | No | ||
| d_donation_health | No | ||
| d_lifestyle_music | No | ||
| d_mortgage_amount | No | Mortgage amount in thousands (use values like "50" or "400") | |
| d_onlinepurchaser | No | ||
| d_political_party | No | Political party affiliation values | |
| d_youngadult_hhld | No | ||
| rcfg_phone_format | No | Set to 1 to prefix returned phone numbers with the country code | |
| d_donation_animals | No | ||
| d_home_improvement | No | ||
| d_investing_active | No | ||
| d_lifestyle_sports | No | ||
| d_military_history | No | ||
| d_mortgage2_amount | No | Second mortgage amount in thousands | |
| cfg_require_address | No | Set to true to require mailing addresses in the output | |
| cfg_zipradius_focus | No | Limits radius expansion to ZIP, city/state, or none | |
| d_donation_children | No | ||
| d_donation_intl_aid | No | ||
| d_donation_religion | No | ||
| d_donation_veterans | No | ||
| d_home_market_value | No | Home market value range. See values in options tool | |
| d_lifestyle_cooking | No | ||
| d_lifestyle_outdoor | No | ||
| d_lifestyle_reading | No | ||
| d_cardholder_upscale | No | ||
| d_donation_community | No | ||
| d_donation_political | No | ||
| d_home_purchase_date | No | Home purchase date in YYYYMMDD format | |
| d_lifestyle_antiques | No | ||
| d_mortgage_rate_type | No | Mortgage rate type codes. A=Adjustable, B=Balloon, F=Fixed, U=Unknown | |
| include_filter_attrs | No | Include selected filter attributes as columns in the final audience | |
| d_home_purchase_price | No | Home purchase price in thousands | |
| d_mortgage2_loan_type | No | Second mortgage loan type codes. See values in options tool | |
| d_mortgage2_rate_type | No | Second mortgage rate type codes. A=Adjustable, B=Balloon, F=Fixed, U=Unknown | |
| d_donation_unspecified | No | ||
| d_lifestyle_decorating | No | ||
| d_presence_of_children | No | ||
| d_donation_arts_culture | No | ||
| d_donation_env_wildlife | No | ||
| include_demo_categories | No | Demographic category summaries to include in the response. Recommended to include at least one with estimate calls for audience insights in the preview response | |
| d_lifestyle_arts_general | No | ||
| d_mortgage_purchase_date | No | Mortgage purchase date in YYYYMMDD format | |
| d_lifestyle_health_beauty | No | ||
| d_donation_political_liberal | No | ||
| d_donation_political_conservative | No | ||
| d_mortgage_purchase_loan_type_code | No | Mortgage purchase loan type codes. See values in options tool |
| Name | Required | Description |
|---|---|---|
| results | No | |
| query_id | No | |
| warnings | No | |
| input_query | No | |
| num_matches | No | |
| num_results | No | |
| match_counts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral detail beyond annotations, such as the uniform 'Y' flag convention and a concrete example showing how to combine filters. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but earns its length given the tool's 110 parameters. It front-loads the core purpose, then adds compactly organized behavioral guidance and tips in a scannable bullet list. Minor redundancy exists in 'Supports the full configuration and demographic filter set,' but overall it is well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool with 110 parameters, rich annotations, and an output schema. The description provides the essential operational context: where to look up option values, how to interpret Y flags, and how to approach filter construction. It does not explain everything, but the combination of schema, annotations, and description is adequate 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?
With only 53% schema description coverage, the description helps fill gaps: it explains the semantics of the many undocumented 'Y' enum parameters, points to the options tool for high-cardinality fields, and provides a working filter example. While not every parameter is individually described, the cross-cutting guidance substantially compensates for the schema's omissions.
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-resource pair: 'Estimate consumer audience sizes using Versium's Consumer Audience Builder (B2C Listgen) API.' This clearly distinguishes it from sibling tools like b2c_listgen_options and the B2B-focused b2b_listgen_estimate, and the consumer/B2C framing reinforces when it applies.
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 explicit routing guidance for related tools: use the Consumer Audience Options tool for high-cardinality values and call b2c_listgen_options for attribute flag meanings. It does not explicitly contrast with every sibling, like b2b_listgen_estimate or list-building tools, but the purpose and alternatives are largely clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return allowed option values for Consumer Audience Builder (B2C Listgen) fields
Use this tool when you need the valid values for large, high-cardinality fields too big to embed directly in tool schemas
| Name | Required | Description | Default |
|---|---|---|---|
| field | No | The field for which options are requested | |
| limit | No | Maximum number of returned values. Optional; default 50 | |
| query | No | Case-insensitive substring to filter option values. Optional | |
| offset | No | Pagination offset. Optional; default 0 |
| Name | Required | Description |
|---|---|---|
| field | No | |
| query | No | |
| offset | No | |
| values | No | |
| returned | No | |
| next_offset | No | |
| total_matches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about high-cardinality fields and why the options cannot be embedded in schemas. No contradictions exist between the description and 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 long, front-loaded with the core purpose, and contains no filler or redundant material. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only options lookup with full schema coverage, rich annotation coverage, and an output schema. The description explains both the core function and appropriate use, making it complete for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters already have complete descriptions in the input schema, so the description does not need to repeat parameter details. However, it also adds little beyond the schema; for example, it does not clarify which fields are valid or that `field` is semantically required despite the schema listing no required parameters.
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 and resource: 'Return allowed option values for Consumer Audience Builder (B2C Listgen) fields.' It clearly identifies the consumer/B2C scope, distinguishing it from the sibling b2b_listgen_options 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 explicitly states when to use the tool: 'Use this tool when you need the valid values for large, high-cardinality fields too big to embed directly in tool schemas.' It provides a clear context but does not explicitly mention alternatives or when not to use it, such as pointing to the B2B sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich consumer marketing records with business demographics for B2B segmentation. Match the record with a LinkedIn URL, or with first name, last name, and one of: email, phone, or city and state. Appends job title, seniority, department, business email, LinkedIn profile, and complete business information.
Use this tool when users ask for 'C2B', 'c2b', or 'Consumer to Business Person' data
**Tips for Best Results:**
- Provide full name and consumer email for best match quality
- LinkedIn URLs must be in format: linkedin.com/in/username
- Use `rcfg_require_email` to return only records with business email
- Use `rcfg_require_value` to filter by job title, department, or other attributes| Name | Required | Description | Default |
|---|---|---|---|
| city | No | A person's city | |
| last | No | A person's last name | |
| No | A valid consumer email address | ||
| first | No | A person's first name | |
| phone | No | A person's phone number | |
| state | No | A person's two-letter state code | |
| domain | No | A business domain | |
| li_url | No | A LinkedIn URL (accepts https://www.linkedin.com/in/username, www.linkedin.com/in/username, or linkedin.com/in/username) | |
| rcfg_max_time | No | Maximum allowed API run time (in seconds) | |
| rcfg_require_email | No | Returns only records with email (set to 1 to enable) | |
| rcfg_require_value | No | Field/value requirements in "Field=Value" format. Example: ["Title=Manager"] |
| Name | Required | Description |
|---|---|---|
| results | No | Records returned by the Operations API. Record fields pass through unchanged. |
| query_id | No | |
| warnings | No | |
| input_query | No | |
| num_matches | No | Number of matching queries. |
| num_results | No | Number of records returned. |
| match_counts | No | Sparse match counts. An absent key means zero. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about matching logic (LinkedIn URL or name+contact) and output fields, which clarifies what the tool returns. No contradiction with annotations exists; the words 'enrich' and 'appends' could be ambiguous, but annotations resolve that it is a read-only enrichment.
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 moderately detailed but well-structured: the main purpose is front-loaded, followed by the usage trigger and bulleted tips. Each section contributes relevant guidance; there is little fluff, though the LinkedIn URL format tip somewhat repeats the schema. Overall it is efficiently organized.
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 complexity (11 parameters, a complex anyOf requirement, and an output schema), the description covers the critical matching conditions and best practices well. It does not discuss error scenarios or rate limits, but the annotations and output schema handle safety and return structure. For this complexity, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, baseline is 3. The description adds significant value beyond the schema by explaining the acceptable matching combinations (anyOf: LinkedIn URL, or first/last plus email/phone/city+state) in plain language. It also clarifies the use of rcfg_require_email and rcfg_require_value with practical examples, which helps an agent select parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: enrich consumer marketing records with business demographics for B2B segmentation. It lists specific appended fields (job title, seniority, department, business email, LinkedIn profile) and distinguishes itself from siblings through the explicit C2B (Consumer to Business) focus. The name and title align with this purpose.
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 explicit trigger: 'Use this tool when users ask for C2B, c2b, or Consumer to Business Person data.' It also includes practical best-practice tips (e.g., provide full name and email for best match quality). However, it does not name sibling alternatives or explicitly state when not to use this tool, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich marketing contact records with mailing address, email, and phone for outreach and audience building
**Tips for Best Results:**
- Provide as many input fields as possible to improve match quality
- Use `indiv` match type when targeting a specific person
- Request one output type per call when optimizing for match quality (especially for phone outputs)
- Set `cfg_maxrecs` when more than one record is acceptable| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5 digit ZIP code | |
| city | No | City name | |
| last | No | Person's last name | |
| No | Email address to enrich | ||
| first | No | Person's first name | |
| phone | No | 10 digit phone number without formatting | |
| state | No | Two-character state code (US) | |
| address | No | Street address (line 1) | |
| outputs | Yes | Types of contact data to return. Choose at least one output type | |
| address_2 | No | Apartment or unit number | |
| match_type | No | Match at household (hhld) or individual (indiv) level | hhld |
| cfg_maxrecs | No | Maximum number of records to return | |
| cfg_required | No | Comma or semi-colon separated response fields that must be populated for a record to be returned | |
| rcfg_max_emails | No | Maximum number of emails per record (use with email_multiple) | |
| rcfg_exclude_domains | No | Domains to exclude from alternate email results |
| Name | Required | Description |
|---|---|---|
| results | No | Records returned by the Operations API. Record fields pass through unchanged. |
| query_id | No | |
| warnings | No | |
| input_query | No | |
| num_matches | No | Number of matching queries. |
| num_results | No | Number of records returned. |
| match_counts | No | Sparse match counts. An absent key means zero. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered and there is no contradiction. The description adds operational context around match quality and output cardinality, but it does not describe the actual lookup/return behavior or any additional side-effect considerations beyond what annotations already 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 purpose is stated in one front-loaded sentence, followed by four scannable bullet-point tips. There is no fluff, repetition, or redundant restating of the schema. Every sentence contributes actionable information, and the format is easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is 100% covered and an output schema exists, so many invocation details are already structured. The description adds useful operational tips, but given 20 siblings including several other append tools, it should explicitly state when contact_append is the right choice versus b2b2c, c2b, demographic, or firmographic append. It also omits the US-only scope that is visible in the 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?
All 15 parameters have rich schema descriptions, so the baseline is 3. The description adds meaningful usage semantics by explaining when to use indiv, how output type selection affects match quality, and when to raise cfg_maxrecs. This goes beyond the schema's structural descriptions without needing to compensate for any gaps.
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 starts with a specific verb ('Enrich') and a clear resource ('marketing contact records'), and names the output types (mailing address, email, phone). It is unmistakable what the tool does, but it does not explicitly contrast contact_append with the many sibling append tools, so it misses the 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 'Tips for Best Results' provide practical guidance on parameter usage: use indiv for a specific person, request one output type per call for phone match quality, and set cfg_maxrecs for multiple acceptable records. However, there is no guidance on when to choose this tool over sibling append tools like b2b2c_append or c2b_append, nor any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a B2B or B2C listgen job for the authenticated user.
Use `project_id` when possible. For charge-on-finish jobs, tell the user about usage and only submit `usage_consent_confirmed = true` after they consent. Read the `consent_required_job_types` meta field to know which job types require consent.| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Output list name | |
| config | Yes | Nested job config using the exact input shape documented by `b2b_listgen_estimate` or `b2c_listgen_estimate` for the selected job_type, without nesting or renaming fields. b2b_listgen requires `output`. b2c_listgen requires `required_fields`. max_records defaults to 10000 and may not exceed 50000. | |
| job_type | Yes | Selects the internal operation branch for the nested config payload | |
| project_id | No | Preferred project target when the user already has a project | |
| project_name | No | Fallback project name when the user wants MCP to create/find the project | |
| usage_consent_confirmed | No | Set to true to confirm the user has consented to usage charges. Required for job types that bill upon completion. |
| Name | Required | Description |
|---|---|---|
| job_id | No | |
| job_guid | No | |
| job_state | No | |
| list_name | No | |
| project_id | No | |
| job_operation | No | |
| output_list_id | No | |
| output_list_expires_at | No | ISO-8601 expiration timestamp for the output list |
| output_list_is_expired | No | Whether the output list has expired |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the agent knows this is a mutating, non-idempotent operation. The description adds important behavioral context: it creates a job for the authenticated user, may charge on finish, and requires explicit consent for certain job types. It doesn't contradict 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 compact and front-loaded with the core purpose. The usage guidance is packed into two sentences without fluff. Slight deduction for not structuring the consent guidance as a separate bullet, but it's still clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key operational details: authentication context, project_id preference, consent requirement, and config shape reference. The output schema exists, so return values are documented elsewhere. It could mention what happens after job creation (e.g., job_status polling) but that's covered by sibling 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 100%, so the schema already documents all parameters. The description adds value by explaining the consent flow (usage_consent_confirmed) and the relationship between config and the estimate tools' input shape. It also clarifies that b2b_listgen requires output and b2c_listgen requires required_fields, which goes 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 states a specific verb ('Create'), a resource ('B2B or B2C listgen job'), and the target user ('authenticated user'). It clearly distinguishes from sibling tools like b2b_listgen_estimate and b2b_listgen_options by focusing on job creation rather than estimation or options.
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 explicit usage guidance: use project_id when possible, only submit usage_consent_confirmed=true after user consent, and read consent_required_job_types meta field to know which job types require consent. This is actionable and distinguishes when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new REACH project for the authenticated user.
Use this tool when a user asks to create a project container before working with lists.
| Name | Required | Description | Default |
|---|---|---|---|
| project_name | Yes | Project name |
| Name | Required | Description |
|---|---|---|
| created_at | No | ISO-8601 creation timestamp |
| project_id | No | |
| project_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive behavior, lowering the burden. The description adds the auth context ('for the authenticated user') but does not disclose other behaviors like name uniqueness or error handling. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every word serves a purpose. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema present, the description covers purpose, usage trigger, and authentication context. There is no need to describe return values because the output schema exists.
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 provides 100% coverage of the single parameter ('Project name'). The description does not add significant additional meaning beyond calling it a 'project container,' so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new REACH project') and resource ('project'), and the addition of 'for the authenticated user' clarifies scope. It distinguishes itself from siblings like list_projects and show_project by being the create operation.
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 an explicit usage trigger: 'Use this tool when a user asks to create a project container before working with lists.' This provides clear context, though it does not explicitly mention alternatives 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.
Append consumer marketing records with household and lifestyle insights for audience segmentation, across demographic, financial, lifestyle, political, or full demographic categories
**Tips for Best Results:**
- Request only the insight categories you need to keep responses focused
- Combine name, location, and digital identifiers (email or phone) for higher match confidence
- Use `cfg_required` or `rcfg_require_value` to enforce must-have attributes in the response| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5 digit ZIP code | |
| city | No | City name | |
| last | No | Person's last name | |
| No | Email address to enrich | ||
| first | No | Person's first name | |
| phone | No | 10 digit phone number without formatting | |
| state | No | Two-character state code (US) | |
| address | No | Street address (line 1) | |
| outputs | Yes | Insight categories to return. Choose at least one category | |
| address_2 | No | Apartment or unit number | |
| match_type | No | Match at household (hhld) or individual (indiv) level | hhld |
| cfg_maxrecs | No | Maximum number of records to return | |
| cfg_required | No | Comma or semi-colon separated response fields that must be populated for a record to be returned | |
| rcfg_require_value | No | Field/value requirements in "Field=Value" format. Example: ["Language=Spanish"] |
| Name | Required | Description |
|---|---|---|
| results | No | Records returned by the Operations API. Record fields pass through unchanged. |
| query_id | No | |
| warnings | No | |
| input_query | No | |
| num_matches | No | Number of matching queries. |
| num_results | No | Number of records returned. |
| match_counts | No | Sparse match counts. An absent key means zero. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a non-destructive read. The description adds value by explaining that match confidence improves with combined identifiers and that required-attribute filtering is possible, but it doesn't disclose additional behavior like rate limits or response variability. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with the main purpose stated up front and a bulleted 'Tips for Best Results' section. It avoids redundancy with the schema and each sentence adds practical guidance. Slightly more verbose than necessary but still efficient.
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 14 parameters, a fully described schema, and an output schema, the description provides enough operational context: it lists available categories, explains match confidence factors, and points to filtering mechanisms. It does not explain response format, but the output schema covers that. Minor gaps like pagination are addressed by cfg_maxrecs in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds context for cfg_required and rcfg_require_value in the tips, and clarifies that combining identifiers boosts match confidence, which is useful but not extensive. Baseline for high coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool appends household and lifestyle insights to consumer marketing records for audience segmentation, listing the categories (demographic, financial, lifestyle, political, full demographic). It implies a consumer focus, distinguishing it from business-oriented siblings like b2b2c_append or firmographic_append, though it doesn't 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?
Provides actionable best-practice tips: limiting categories, combining identifiers for match confidence, and using cfg_required/rcfg_require_value to enforce attributes. However, it does not explicitly state when to choose this tool over sibling append tools (e.g., contact_append or c2b_append), leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Versium's official documentation for information about the web application or APIs.
Use this tool when a user has questions about how to use the Versium REACH platform.
**Usage Tips:**
- Use `docs_target: app` for questions about the Versium REACH web application
- Use `docs_target: api` for questions about Versium's data enrichment APIs
- Use `docs_target: both` (default) to search all documentation| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return per documentation source | |
| query | Yes | The search query to find relevant documentation | |
| docs_target | No | Which documentation to search: "app" for web application docs, "api" for API docs, or "both" | both |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate safety traits. The description adds useful contextual scope about searching official docs and defaulting to both doc sources. However, it does not add deeper behavioral detail such as response shape, pagination, or source behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose sentence, a usage context sentence, and three bullet usage tips. Every line adds practical value without irrelevant 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?
With an output schema, fully detailed annotations, and only one required parameter, the description does enough by stating the search domain and when to use the tool. It could be slightly more complete with explicit mention that search is read-only, but the annotations already provide that 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?
The input schema has 100% parameter coverage with descriptions and defaults. The description adds extra semantic value by explaining the meaning of 'app' vs 'api' docs_target choices in practical terms. This goes beyond the schema's basic enum documentation.
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 function: searching Versium's official documentation for web application or API information. This is specific and aligned with the tool name, and it is clearly distinct from all sibling tools, which handle data append, job, project, and list operations rather than documentation 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 explicitly states when to use the tool: 'Use this tool when a user has questions about how to use the Versium REACH platform.' It also provides concrete guidance for choosing docs_target values. It does not explicitly discuss alternatives or when not to use the tool, but the sibling context makes alternative use cases obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate email addresses and optionally get alternate valid emails using Versium's Email Validation API. Returns validation status, sub-status, and whether the email is valid for mailing.
**Tips for Best Results:**
- Provide a valid email address or MD5/SHA256 hashed email (HEM)
- Use `include_alternate` to get an alternate valid email if the input is invalid
- Provide additional contact info (name, address) to improve alternate email matching
- Use `rcfg_exclude_domains` to filter out unwanted email domains from alternates| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5 digit US ZIP code | |
| city | No | City name | |
| last | No | Person's last name (helps find alternate email) | |
| Yes | Email address to validate. Can also be an MD5 or SHA256 hashed email (HEM). | ||
| first | No | Person's first name (helps find alternate email) | |
| phone | No | 10 digit phone number | |
| state | No | US state two-letter abbreviation | |
| address | No | Street address (helps find alternate email) | |
| address_2 | No | Apartment or unit number | |
| rcfg_snake_case | No | Return response field names in snake_case instead of "Title Case With Spaces". | |
| include_alternate | No | Whether to include an alternate valid email in the response if the input email is invalid. | |
| rcfg_exclude_domains | No | Domains to exclude from alternate email results (e.g., aol.com, yahoo.com). Only applies when include_alternate is true. |
| Name | Required | Description |
|---|---|---|
| results | No | Records returned by the Operations API. Record fields pass through unchanged. |
| query_id | No | |
| warnings | No | |
| input_query | No | |
| num_matches | No | Number of matching queries. |
| num_results | No | Number of records returned. |
| match_counts | No | Sparse match counts. An absent key means zero. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals that the tool returns validation status and whether the email is valid for mailing, and explains the optional alternate-email behavior. However, it doesn't disclose error handling, rate limits, or any side effects, but for a read-only validation tool this is acceptable. It adds moderate value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear main line and a bulleted list of tips. It is front-loaded with the primary purpose guide. Each tip is relevant and adds value. Slightly long but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters and an output schema, the description covers enough context: it explains the core behavior, optional alternate email feature, and tips for better results. It doesn't delve into output format, but the output schema likely covers that. For a tool with this complexity, the description is adequate and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameters well (100% have descriptions), so the baseline is 3. The description adds value by clarifying the purpose of additional contact info ('improve alternate email matching') and explains how rcfg_exclude_domains works. This goes beyond schema descriptions, justifying a slightly higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Validate email addresses and optionally get alternate valid emails using Versium's Email Validation API.' It specifies the verb (validate), the resource (email addresses), and the API used aids in distinguishing it from sibling tools like data append tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Tips for Best Results' which provides practical usage guidance, such as using hashed emails, including additional contact info for better alternates, and filtering domains. While it doesn't explicitly state when not to use the tool or compare to alternatives, the context is clear enough for tool selection among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich business records with firmographics for account targeting and segmentation: company details, location, industry classifications, employee counts, and revenue data.
**Tips for Best Results:**
- Provide domain for fastest, most accurate results
- For business name searches, include complete address information or phone number
- Use `rcfg_require_value` to filter for specific industries or business characteristics| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | A 5 digit zip code | |
| city | No | A city name | |
| No | A valid business email address | ||
| phone | No | A valid 10 digit business phone number | |
| state | No | A US state two letter abbreviation | |
| domain | No | A business domain | |
| address | No | An address (street address line 1) | |
| business | No | A business name | |
| rcfg_max_time | No | Maximum allowed API run time (in seconds) | |
| rcfg_require_value | No | Field/value requirements in "Field=Value" format. Example: ["Industry=Technology"]. |
| Name | Required | Description |
|---|---|---|
| results | No | Records returned by the Operations API. Record fields pass through unchanged. |
| query_id | No | |
| warnings | No | |
| input_query | No | |
| num_matches | No | Number of matching queries. |
| num_results | No | Number of records returned. |
| match_counts | No | Sparse match counts. An absent key means zero. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is not expected to restate those. The description adds context about typical use cases (account targeting/segmentation) and tips that imply behavior (e.g., domain yields fastest results). However, it does not disclose potential limitations, such as behavior with incomplete inputs or whether results may vary. The bar is lower due to annotations, but the description adds only modest behavioral context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a clearly separated 'Tips for Best Results' section. Each sentence is purposeful and provides actionable guidance. The structure is easy to scan, and there is no redundant filler, though the tips could be seen as slightly verbose for some users.
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 10 optional parameters and an output schema exists. The description explains the overall function, provides strategic tips on parameter selection, and mentions filtering via rcfg_require_value. It does not elaborate on return formats (handled by output schema) or edge cases, but for a read-only enrichment tool with high schema coverage and annotations, the context is sufficiently complete for an agent to invoke it 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 all parameters are described in the schema. The description adds value by linking certain parameters to usage tips: domain for speed, address/phone for business name searches, and rcfg_require_value for filtering. This goes beyond the schema's basic field descriptions and helps the agent understand parameter interactions, though it doesn't cover every combination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to enrich business records with firmographic data such as company details, location, industry, employee counts, and revenue. The verb 'enrich' and resource 'business records' are specific, and the listed fields distinguish it from other append tools. However, it does not explicitly differentiate itself from sibling tools like b2b2c_append, though the term 'firmographic' inherently signals the data type.
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 actionable tips on how to get best results (e.g., provide domain for fastest results, include address/phone for business name searches, use rcfg_require_value for filtering). These are usage instructions but not guidance on when to choose this tool over alternatives like b2b2c_append or contact_append. There is no explicit 'when to use' or 'when not to use' statement, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover business domains and firmographic information from IP addresses using Versium's IP-to-Domain API. Accepts an IPv4 address and returns up to 3 associated business domains with details like company name, address, industry, employee count, and revenue.
**Tips for Best Results:**
- Provide a valid IPv4 address for best results
- Useful for identifying businesses from web traffic or server information
- Returns comprehensive firmographic data similar to domain-based lookups| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IPv4 address to query for associated business domains. | |
| rcfg_max_time | No | Maximum allowed API run time in seconds (optional). |
| Name | Required | Description |
|---|---|---|
| results | No | Records returned by the Operations API. Record fields pass through unchanged. |
| query_id | No | |
| warnings | No | |
| input_query | No | |
| num_matches | No | Number of matching queries. |
| num_results | No | Number of records returned. |
| match_counts | No | Sparse match counts. An absent key means zero. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds the output cardinality limit ('up to 3 associated business domains') and the range of returned firmographic attributes, which is useful beyond the annotations. It does not discuss edge cases like invalid IPs, but the schema pattern covers input format.
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 front-loaded with a clear one-sentence summary followed by a short tips section. The last bullet and IP-validity tip are somewhat redundant with earlier content, but the overall length is reasonable and 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?
For a simple 2-parameter lookup with a single required field, an output schema, and strong annotations, the description covers purpose, expected output, and practical use. It could be more complete by naming sibling alternatives or clearly scoping when not to use it, but 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?
Schema description coverage is 100% and both parameters (ip and rcfg_max_time) already have meaningful descriptions. The tool description adds no parameter-level detail beyond the schema, matching the baseline for high 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 uses a specific verb ('Discover') and resource ('business domains and firmographic information from IP addresses'), clearly distinguishing this from sibling append/list tools by the IP-to-domain lookup mechanism. It states the core action and result (up to 3 domains with firmographic details).
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 'Tips for Best Results' section gives clear use context: use for identifying businesses from web traffic or server information. It does not explicitly name alternatives or when-not-to-use scenarios, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an existing job after `create_job`.
Use this tool to poll progress, ETA, and output list readiness while a job is running or after it finishes.| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Positive integer job ID (must be ≥ 1) |
| Name | Required | Description |
|---|---|---|
| job_id | No | |
| job_guid | No | |
| list_url | No | |
| job_state | No | |
| created_at | No | ISO-8601 creation timestamp |
| finished_at | No | ISO-8601 completion timestamp |
| job_operation | No | |
| output_list_id | No | |
| est_sec_remaining | No | |
| output_file_ready | No | |
| progress_percentage | No | |
| output_list_expires_at | No | ISO-8601 expiration timestamp for the output list |
| output_list_is_expired | No | Whether the output list has expired |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, establishing it as a safe, non-mutating read. The description adds value by specifying what status includes (progress, ETA, output list readiness) and clarifies it works for both running and finished jobs. This complements rather than repeats 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 sentences, both purposeful. The first identifies the action and the prerequisite (after create_job), the second specifies use cases. No wasted words, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so return value details are unnecessary. The description states what status information is available and when to poll. It doesn't mention error handling (e.g., invalid job ID), but that's minor given the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter (job_id) with a description ('Positive integer job ID (must be ≥ 1)') at 100% coverage. The description adds no extra parameter meaning beyond the tool's purpose, 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 clearly states the tool checks the status of an existing job, specifically after create_job. It lists the concrete outputs (progress, ETA, output list readiness) and distinguishes it from creation and list-management siblings by focusing on polling existing 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?
It explicitly says to use it for polling progress, ETA, and output list readiness while a job is running or after it finishes. It doesn't mention when not to use it or name alternatives, but the context 'after create_job' implicitly excludes creation and other operations. Given the sibling list has no other status tool, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List REACH lists for the authenticated user.
Optionally filter by project or name prefix.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of returned lists | |
| search | No | Optional prefix search on list name | |
| project_id | No | Optional project ID to restrict results to a specific project |
| Name | Required | Description |
|---|---|---|
| lists | Yes | List summaries |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it returns lists for the authenticated user and supports optional filtering, but does not disclose pagination behavior, ordering, or what happens when no filters are provided. With annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main action and resource. The second sentence adds filter options concisely. No wasted words, though it could have been slightly more informative about behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with a full output schema and 100% parameter schema coverage, the description is adequate. It covers the core purpose and optional filters. It doesn't mention pagination or default behavior, but the output schema and annotations fill in much of the context. Slightly more detail on result ordering or default scope would push it higher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (limit, search, project_id) are already documented in the schema. The description mentions 'filter by project or name prefix' which maps to project_id and search, adding slight context but not much beyond the schema. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('REACH lists') and notes it is for the authenticated user. It distinguishes itself from siblings like show_list and preview_list by indicating it lists multiple lists, though it doesn't explicitly name alternatives. The title is redundant but the description adds clarity.
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: listing lists for the authenticated user, with optional filters. It does not explicitly state when to use this tool versus alternatives like show_list or preview_list, nor does it mention exclusions. The optional filters give some context but no direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List REACH projects for the authenticated user.
Use this tool to find the right project before calling `show_project`.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of returned projects | |
| search | No | Optional prefix search on project name |
| Name | Required | Description |
|---|---|---|
| projects | Yes | Project summaries. created_at is an ISO-8601 timestamp. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds limited behavioral context beyond the annotations, such as the 'REACH' qualifier and the fact that it's for the authenticated user, but it doesn't elaborate on pagination, rate limits, or other behaviors. It's not contradictory and adequately supports 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 remarkably concise, consisting of just two sentences. The first states the core action, and the second offers actionable guidance. No unnecessary words, perfectly front-loaded 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 simple read-only tool with two well-documented optional parameters, an output schema, and rich annotations, the description is complete. It explains the tool's purpose and provides a usage hint, covering all necessary aspects for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters ('Maximum number of returned projects' and 'Optional prefix search on project name'), giving 100% schema coverage. The description adds no additional parameter-level detail, which is acceptable as the schema already 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?
The description clearly states the verb ('List'), the resource ('REACH projects'), and the scope ('for the authenticated user'). It also differentiates from siblings by indicating its role in preparation for `show_project`, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use this tool to find the right project before calling show_project.' This gives contextual guidance for when to use it, though it does not explicitly exclude alternatives or mention contrast with other list-type tools (e.g., list_lists), keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview a sample of rows from a REACH list.
Use this tool to inspect the actual data rows in a list. Returns a row sample
from the list file. The optional `count` parameter is a hint for how many rows
to return; the actual number may differ depending on list type and backend
preview behavior. When omitted, the service default applies.| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Hint for number of rows to return (1–25). Actual rows may vary by list type. When omitted the service default is used. | |
| list_id | Yes | Positive integer list ID (must be ≥ 1) |
| Name | Required | Description |
|---|---|---|
| rows | No | |
| list_id | No | |
| list_url | No | |
| returned_rows | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral nuance beyond the annotations, including that the count parameter is only a hint, the actual row count may differ by list type and backend behavior, and a service default applies when omitted. This is helpful and consistent 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 concise and front-loaded with the primary purpose. It covers sample behavior, count variability, and default behavior in four short sentences. There is slight redundancy between 'Preview a sample of rows' and 'Returns a row sample', but no substantial waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only preview tool with full schema coverage and an output schema, the description context is appropriately complete. It explains the extent of the sample, the count limitations, and backend variability. It does not address all possible sibling distinctions, but that is not essential for using 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?
The schema already has 100% coverage for both list_id and count, including the hint-like nature of count. The description mostly paraphrases what the schema already states, reinforcing that count is a hint and varies, but it does not add additional meaning beyond the structured schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Preview a sample of rows from a REACH list' and further clarifies that it inspects the actual data rows. This specific verb-resource combination differentiates it from siblings like show_list, which likely shows list metadata or structure rather than row samples.
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 a concise use case: 'Use this tool to inspect the actual data rows in a list.' This provides clear context for when the tool is appropriate. It does not explicitly mention when not to use it or name alternatives, but the usage context is sufficient for a read-only preview tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show one REACH list and a summary of its latest job.
Use this tool when you already know the list ID and need full metadata plus job status.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | Positive integer list ID (must be ≥ 1) |
| Name | Required | Description |
|---|---|---|
| list | No | |
| job_summary | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=trueais, so the safety profile is covered. The description adds value by specifying the exact scope of the result – one list plus summary of latest job – which goes beyond the annotations. 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?
Two sentences, front-loaded with what it returns and when to use it. No wasted 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 one-parameter, read-only, idempotent tool with an output schema, the description plus annotations fully cover what an agent needs to know. It states scope, return content, and selection 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?
Input schema covers the single parameter with type, minimum, and a description that already conveys the list ID must be a positive integer. The description adds no extra semantics but none are needed at 100% 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?
States a specific verb ('Show') and resource ('one REACH list') plus what it returns ('summary of its latest job'). Distinguishes itself from sibling tools by requiring a known list ID and returning full metadata, which separates it from preview_list and list_lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use the tool: when the list ID is already known and full metadata plus job status is needed. It doesn't name the alternatives it excludes (e.g., list_lists, job_status), but the context is clear enough for an agent to route to it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show one REACH project and a small summary of its lists.
Use this tool when you already know the project ID and need counts plus a recent-list preview.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Positive integer project ID (must be ≥ 1) |
| Name | Required | Description |
|---|---|---|
| project | No | |
| list_summary | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm read-only, non-destructive, and idempotent behavior. The description adds detail about the output nature ('small summary', 'counts', 'recent-list preview'), giving further clarity without contradicting 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 concise, using two short sentences with no redundant information. It is well-structured and directly addresses the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (so return values need not be detailed), the description gives sufficient context about what the summary contains ('counts', 'recent-list preview'). It is complete enough for an agent to understand the tool's functional scope, though edge cases like error handling are not mentioned.
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 only parameter project_id is fully described in the schema with type and constraints. The description does not add extra semantic meaning beyond 'Positive integer project ID', so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: showing one REACH project and a summary of its lists. It distinguishes from sibling tools like list_projects by specifying a single project and the inclusion of list summaries.
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?
Explicit usage condition is given: 'Use this tool when you already know the project ID and need counts plus a recent-list preview.' This clearly indicates when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
contact_append1 field changedInput schema / properties / usage_consent_confirmedRemoved value: -{
- "description": "Required for email outputs after the user explicitly agrees to usage charges",
- "type": "boolean"
-}contact_append2 fields changedInput schema / properties / cfg_requiredAdded value: +{
+ "description": "Comma or semi-colon separated response fields that must be populated for a record to be returned",
+ "type": "string"
+}Input schema / properties / usage_consent_confirmedAdded value: +{
+ "description": "Required for email outputs after the user explicitly agrees to usage charges",
+ "type": "boolean"
+}create_job2 fields changedOutput schema / properties / output_list_expires_atAdded value: +{
+ "description": "ISO-8601 expiration timestamp for the output list",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / output_list_is_expiredAdded value: +{
+ "description": "Whether the output list has expired",
+ "type": [
+ "boolean",
+ "null"
+ ]
+}job_status2 fields changedOutput schema / properties / output_list_expires_atAdded value: +{
+ "description": "ISO-8601 expiration timestamp for the output list",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / output_list_is_expiredAdded value: +{
+ "description": "Whether the output list has expired",
+ "type": [
+ "boolean",
+ "null"
+ ]
+}list_lists2 fields changedOutput schema / properties / lists / descriptionPrevious value: -"List summaries. created_at is an ISO-8601 timestamp."New value: +"List summaries"Output schema / properties / lists / items / propertiesAdded value: +{
+ "created_at": {
+ "description": "ISO-8601 creation timestamp",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "expires_at": {
+ "description": "ISO-8601 expiration timestamp",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "file_ready": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "is_expired": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "latest_job_operation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_job_state": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "list_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "list_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "project_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "project_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "record_count": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+}show_list2 fields changedOutput schema / properties / list / properties / expires_atAdded value: +{
+ "description": "ISO-8601 expiration timestamp",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / list / properties / is_expiredAdded value: +{
+ "type": [
+ "boolean",
+ "null"
+ ]
+}b2c_listgen_estimate1 field changedInput schema / properties / d_hhld_sizeAdded value: +{
+ "description": "Household size range (1-9, e.g., \"2-4\"); 9 means 9 or more",
+ "pattern": "^[1-9]-[1-9]$",
+ "type": "string"
+}b2b2c_appendb2b_listgen_estimate1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "input_query": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "match_counts": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "num_matches": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "num_results": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "query_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "results": {
+ "properties": {
+ "estimated_credits": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "estimated_match_credits": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "estimated_record_count": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "estimated_records_available": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "estimated_time": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "estimated_time_in_seconds": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "preview": {
+ "items": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": "array"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "warnings": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}b2b_listgen_options1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "field": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "next_offset": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "offset": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "query": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "returned": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "total_matches": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "values": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}b2c_listgen_estimate54 fields changedInput schema / properties / d_apparel_mens / descriptionRemoved value: -"Set to \"Y\" to include households associated with men's apparel interest."Input schema / properties / d_apparel_womens / descriptionRemoved value: -"Set to \"Y\" to include households associated with women's apparel interest."Input schema / properties / d_cardholder_bank / descriptionRemoved value: -"Set to \"Y\" to include households associated with bank card ownership."Input schema / properties / d_cardholder_upscale / descriptionRemoved value: -"Set to \"Y\" to include households associated with upscale card ownership."Input schema / properties / d_donation_animals / descriptionRemoved value: -"Set to \"Y\" to include households associated with animal welfare donors."Input schema / properties / d_donation_arts_culture / descriptionRemoved value: -"Set to \"Y\" to include households associated with arts and culture donors."Input schema / properties / d_donation_children / descriptionRemoved value: -"Set to \"Y\" to include households associated with children's causes donors."Input schema / properties / d_donation_community / descriptionRemoved value: -"Set to \"Y\" to include households associated with community organization donors."Input schema / properties / d_donation_env / descriptionRemoved value: -"Set to \"Y\" to include households associated with environmental donors."Input schema / properties / d_donation_env_wildlife / descriptionRemoved value: -"Set to \"Y\" to include households associated with environmental or wildlife donors."Input schema / properties / d_donation_health / descriptionRemoved value: -"Set to \"Y\" to include households associated with health-related donors."Input schema / properties / d_donation_intl_aid / descriptionRemoved value: -"Set to \"Y\" to include households associated with international aid donors."Input schema / properties / d_donation_political / descriptionRemoved value: -"Set to \"Y\" to include households associated with general political donors."Input schema / properties / d_donation_political_conservative / descriptionRemoved value: -"Set to \"Y\" to include households associated with conservative political donors."Input schema / properties / d_donation_political_liberal / descriptionRemoved value: -"Set to \"Y\" to include households associated with liberal political donors."Input schema / properties / d_donation_religion / descriptionRemoved value: -"Set to \"Y\" to include households associated with religious donors."Input schema / properties / d_donation_unspecified / descriptionRemoved value: -"Set to \"Y\" to include households associated with unspecified cause donors."Input schema / properties / d_donation_veterans / descriptionRemoved value: -"Set to \"Y\" to include households associated with veteran support donors."Input schema / properties / d_electronics / descriptionRemoved value: -"Set to \"Y\" to include households associated with consumer electronics interest."Input schema / properties / d_exercise / descriptionRemoved value: -"Set to \"Y\" to include households associated with fitness and exercise interest."Input schema / properties / d_fishing / descriptionRemoved value: -"Set to \"Y\" to include households associated with fishing interest."Input schema / properties / d_gardening / descriptionRemoved value: -"Set to \"Y\" to include households associated with gardening interest."Input schema / properties / d_golf / descriptionRemoved value: -"Set to \"Y\" to include households associated with golf interest."Input schema / properties / d_hhldveteran / descriptionRemoved value: -"Set to \"Y\" to include households associated with veteran households."Input schema / properties / d_home_improvement / descriptionRemoved value: -"Set to \"Y\" to include households associated with home improvement interest."Input schema / properties / d_hunting / descriptionRemoved value: -"Set to \"Y\" to include households associated with hunting interest."Input schema / properties / d_investing_active / descriptionRemoved value: -"Set to \"Y\" to include households associated with active investing interest."Input schema / properties / d_lifestyle_antiques / descriptionRemoved value: -"Set to \"Y\" to include households associated with antiques interest."Input schema / properties / d_lifestyle_arts_general / descriptionRemoved value: -"Set to \"Y\" to include households associated with arts interest."Input schema / properties / d_lifestyle_cooking / descriptionRemoved value: -"Set to \"Y\" to include households associated with cooking interest."Input schema / properties / d_lifestyle_decorating / descriptionRemoved value: -"Set to \"Y\" to include households associated with decorating interest."Input schema / properties / d_lifestyle_health_beauty / descriptionRemoved value: -"Set to \"Y\" to include households associated with health and beauty interest."Input schema / properties / d_lifestyle_music / descriptionRemoved value: -"Set to \"Y\" to include households associated with music interest."Input schema / properties / d_lifestyle_outdoor / descriptionRemoved value: -"Set to \"Y\" to include households associated with outdoor recreation interest."Input schema / properties / d_lifestyle_reading / descriptionRemoved value: -"Set to \"Y\" to include households associated with reading interest."Input schema / properties / d_lifestyle_sports / descriptionRemoved value: -"Set to \"Y\" to include households associated with general sports interest."Input schema / properties / d_magazines / descriptionRemoved value: -"Set to \"Y\" to include households associated with magazine subscriptions."Input schema / properties / d_mailorderbuyer / descriptionRemoved value: -"Set to \"Y\" to include households associated with mail order purchasing activity."Input schema / properties / d_military_history / descriptionRemoved value: -"Set to \"Y\" to include households associated with military history households."Input schema / properties / d_motorcycles / descriptionRemoved value: -"Set to \"Y\" to include households associated with motorcycle interest."Input schema / properties / d_news / descriptionRemoved value: -"Set to \"Y\" to include households associated with current affairs engagement."Input schema / properties / d_onlinepurchaser / descriptionRemoved value: -"Set to \"Y\" to include households associated with online purchasing activity."Input schema / properties / d_pets / descriptionRemoved value: -"Set to \"Y\" to include households associated with pet ownership."Input schema / properties / d_presence_of_children / descriptionRemoved value: -"Set to \"Y\" to include households with children present"Input schema / properties / d_senior_hhld / descriptionRemoved value: -"Set to \"Y\" to include households associated with senior households."Input schema / properties / d_shooting / descriptionRemoved value: -"Set to \"Y\" to include households associated with shooting sports interest."Input schema / properties / d_singleparent / descriptionRemoved value: -"Set to \"Y\" to include households associated with single parent households."Input schema / properties / d_soho / descriptionRemoved value: -"Set to \"Y\" to include households associated with small office/home office households."Input schema / properties / d_travel / descriptionRemoved value: -"Set to \"Y\" to include households associated with travel interest."Input schema / properties / d_weightloss / descriptionRemoved value: -"Set to \"Y\" to include households associated with dieting and weight loss interest."Input schema / properties / d_workingwoman / descriptionRemoved value: -"Set to \"Y\" to include households associated with working women households."Input schema / properties / d_youngadult_hhld / descriptionRemoved value: -"Set to \"Y\" to include households associated with young adult households."Input schema / properties / rcfg_max_timeRemoved value: -{
- "description": "Maximum allowed API run time in seconds",
- "minimum": 0.1,
- "type": "number"
-}Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "input_query": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "match_counts": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "num_matches": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "num_results": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "query_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "results": {
+ "properties": {
+ "estimated_credits": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "estimated_match_credits": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "estimated_record_count": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "estimated_records_available": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "estimated_time": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "estimated_time_in_seconds": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "preview": {
+ "items": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": "array"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "warnings": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}b2c_listgen_options1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "field": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "next_offset": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "offset": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "query": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "returned": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "total_matches": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "values": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}c2b_append5 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "first",
+ "last",
+ "email"
+ ]
+ },
+ {
+ "required": [
+ "first",
+ "last",
+ "phone"
+ ]
+ },
+ {
+ "required": [
+ "first",
+ "last",
+ "city",
+ "state"
+ ]
+ },
+ {
+ "required": [
+ "li_url"
+ ]
+ }
+]Input schema / properties / cityAdded value: +{
+ "description": "A person's city",
+ "type": "string"
+}Input schema / properties / phoneAdded value: +{
+ "description": "A person's phone number",
+ "type": "string"
+}Input schema / properties / stateAdded value: +{
+ "description": "A person's two-letter state code",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "input_query": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "match_counts": {
+ "description": "Sparse match counts. An absent key means zero.",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "num_matches": {
+ "description": "Number of matching queries.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "num_results": {
+ "description": "Number of records returned.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "query_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "results": {
+ "description": "Records returned by the Operations API. Record fields pass through unchanged.",
+ "items": {
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "warnings": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}contact_append1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "input_query": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "match_counts": {
+ "description": "Sparse match counts. An absent key means zero.",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "num_matches": {
+ "description": "Number of matching queries.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "num_results": {
+ "description": "Number of records returned.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "query_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "results": {
+ "description": "Records returned by the Operations API. Record fields pass through unchanged.",
+ "items": {
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "warnings": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}create_job4 fields changedInput schema / properties / config / additionalPropertiesRemoved value: -falseInput schema / properties / config / descriptionPrevious value: -"Nested job config. Supply fields matching the selected job_type. b2b_listgen requires `output`. b2c_listgen requires `required_fields`. max_records defaults to 10000 and may not exceed 50000."New value: +"Nested job config using the exact input shape documented by `b2b_listgen_estimate` or `b2c_listgen_estimate` for the selected job_type, without nesting or renaming fields. b2b_listgen requires `output`. b2c_listgen requires `required_fields`. max_records defaults to 10000 and may not exceed 50000."Input schema / properties / config / propertiesRemoved value: -{
- "cfg_b2cloc": {
- "description": "Whether location filters apply to business location (0) or employee home location (1)",
- "enum": [
- 0,
- 1
- ],
- "type": "integer"
- },
- "cfg_require_address": {
- "description": "Set to true to require mailing addresses in the output",
- "type": "boolean"
- },
- "cfg_require_email": {
- "description": "Set to true to require email addresses in the output",
- "type": "boolean"
- },
- "cfg_require_name": {
- "description": "Set to true to require full names in the output",
- "type": "boolean"
- },
- "cfg_require_phone": {
- "description": "Set to true to require phone numbers in the output",
- "type": "boolean"
- },
- "cfg_zipradius": {
- "description": "Radius expansion (pseudo-miles) applied around supplied ZIP or city/state centers",
- "minimum": 0,
- "type": "number"
- },
- "cfg_zipradius_focus": {
- "description": "Limits radius expansion to ZIP, city/state, or none",
- "enum": [
- "zip",
- "citystate",
- "none"
- ],
- "type": "string"
- },
- "contacts_per_addr": {
- "description": "Maximum contacts per street address (0=unlimited, 1=one contact per address)",
- "minimum": 0,
- "type": "integer"
- },
- "d_age": {
- "description": "Age range in years (single value or min-max, e.g., \"35-45\")",
- "pattern": "^\\d{1,3}(-\\d{1,3})?$",
- "type": "string"
- },
- "d_apparel_mens": {
- "description": "Set to \"Y\" to include households associated with men's apparel interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_apparel_womens": {
- "description": "Set to \"Y\" to include households associated with women's apparel interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_auto_makemodel": {
- "description": "Auto make and model combo(s) (e.g. \"Ford:Escape\")",
- "items": {
- "pattern": "^[^:]+[:][^:]+$",
- "type": "string"
- },
- "type": "array"
- },
- "d_auto_year": {
- "description": "Automobile year range (single year or min-max)",
- "pattern": "^\\d{4}(-\\d{4})?$",
- "type": "string"
- },
- "d_cardholder_bank": {
- "description": "Set to \"Y\" to include households associated with bank card ownership.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_cardholder_upscale": {
- "description": "Set to \"Y\" to include households associated with upscale card ownership.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_city_state": {
- "description": "Array of city,state combinations (e.g., \"Seattle, WA\")",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "d_county": {
- "description": "County filters. For b2b_listgen use full county names. For b2c_listgen use county,state combinations (for example, \"King, WA\").",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "d_creditlines": {
- "description": "Number of credit lines range (e.g. \"0-5\")",
- "pattern": "^\\d-\\d$",
- "type": "string"
- },
- "d_creditrating": {
- "description": "Credit rating range. See values in options tool",
- "pattern": "^[A-H](-[A-H])?$",
- "type": "string"
- },
- "d_donation_animals": {
- "description": "Set to \"Y\" to include households associated with animal welfare donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_arts_culture": {
- "description": "Set to \"Y\" to include households associated with arts and culture donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_children": {
- "description": "Set to \"Y\" to include households associated with children's causes donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_community": {
- "description": "Set to \"Y\" to include households associated with community organization donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_env": {
- "description": "Set to \"Y\" to include households associated with environmental donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_env_wildlife": {
- "description": "Set to \"Y\" to include households associated with environmental or wildlife donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_health": {
- "description": "Set to \"Y\" to include households associated with health-related donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_intl_aid": {
- "description": "Set to \"Y\" to include households associated with international aid donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_political": {
- "description": "Set to \"Y\" to include households associated with general political donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_political_conservative": {
- "description": "Set to \"Y\" to include households associated with conservative political donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_political_liberal": {
- "description": "Set to \"Y\" to include households associated with liberal political donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_religion": {
- "description": "Set to \"Y\" to include households associated with religious donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_unspecified": {
- "description": "Set to \"Y\" to include households associated with unspecified cause donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_donation_veterans": {
- "description": "Set to \"Y\" to include households associated with veteran support donors.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_dwellingtype": {
- "description": "Dwelling type codes (M=Multi Family, S=Single Family, U=Unknown)",
- "enum": [
- "M",
- "S",
- "U"
- ],
- "type": "string"
- },
- "d_education": {
- "description": "Education level codes: A=High School, B=College, C=Graduate, D=Technical/Vocational",
- "items": {
- "enum": [
- "A",
- "B",
- "C",
- "D"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "d_electronics": {
- "description": "Set to \"Y\" to include households associated with consumer electronics interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_esthhldincome": {
- "description": "Estimated household income range using codes. See values in options tool",
- "pattern": "^[A-S](-[A-S])?$",
- "type": "string"
- },
- "d_ethnicgroup": {
- "description": "Ethnic group codes. See values in options tool",
- "items": {
- "pattern": "^[A-Z]$",
- "type": "string"
- },
- "type": "array"
- },
- "d_exercise": {
- "description": "Set to \"Y\" to include households associated with fitness and exercise interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_fishing": {
- "description": "Set to \"Y\" to include households associated with fishing interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_gardening": {
- "description": "Set to \"Y\" to include households associated with gardening interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_gender": {
- "description": "Gender filter (M=Male, F=Female)",
- "enum": [
- "M",
- "F"
- ],
- "type": "string"
- },
- "d_golf": {
- "description": "Set to \"Y\" to include households associated with golf interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_hhldveteran": {
- "description": "Set to \"Y\" to include households associated with veteran households.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_home_improvement": {
- "description": "Set to \"Y\" to include households associated with home improvement interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_home_market_value": {
- "description": "Home market value range. See values in options tool",
- "pattern": "^[A-S](-[A-S])?$",
- "type": "string"
- },
- "d_home_purchase_date": {
- "description": "Home purchase date in YYYYMMDD format",
- "pattern": "^\\d{8}$",
- "type": "string"
- },
- "d_home_purchase_price": {
- "description": "Home purchase price in thousands",
- "enum": [
- "1",
- "50",
- "100",
- "150",
- "200",
- "250",
- "300",
- "400",
- "500",
- "600",
- "700",
- "800",
- "900",
- "1000",
- "1100",
- "1200",
- "1300",
- "1400",
- "1500",
- "1600",
- "1700",
- "1800",
- "1900",
- "2000"
- ],
- "type": "string"
- },
- "d_home_value": {
- "description": "Home value range. See values in options tool",
- "pattern": "^[A-S](-[A-S])?$",
- "type": "string"
- },
- "d_home_year": {
- "description": "Year home was built (single year or range)",
- "pattern": "^\\d{4}(-\\d{4})?$",
- "type": "string"
- },
- "d_hunting": {
- "description": "Set to \"Y\" to include households associated with hunting interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_investing_active": {
- "description": "Set to \"Y\" to include households associated with active investing interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_language": {
- "description": "Language codes. See values in options tool",
- "items": {
- "pattern": "^[A-Z0-9]{2}$",
- "type": "string"
- },
- "type": "array"
- },
- "d_lifestyle_antiques": {
- "description": "Set to \"Y\" to include households associated with antiques interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_lifestyle_arts_general": {
- "description": "Set to \"Y\" to include households associated with arts interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_lifestyle_cooking": {
- "description": "Set to \"Y\" to include households associated with cooking interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_lifestyle_decorating": {
- "description": "Set to \"Y\" to include households associated with decorating interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_lifestyle_health_beauty": {
- "description": "Set to \"Y\" to include households associated with health and beauty interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_lifestyle_music": {
- "description": "Set to \"Y\" to include households associated with music interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_lifestyle_outdoor": {
- "description": "Set to \"Y\" to include households associated with outdoor recreation interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_lifestyle_reading": {
- "description": "Set to \"Y\" to include households associated with reading interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_lifestyle_sports": {
- "description": "Set to \"Y\" to include households associated with general sports interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_loantovalue": {
- "description": "Loan-to-value percentage as single value or range (0-100)",
- "pattern": "^\\d{1,3}(-\\d{1,3})?$",
- "type": "string"
- },
- "d_lor": {
- "description": "Length of residence in years (single value or range)",
- "pattern": "^\\d{1,3}(-\\d{1,3})?$",
- "type": "string"
- },
- "d_magazines": {
- "description": "Set to \"Y\" to include households associated with magazine subscriptions.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_mailorderbuyer": {
- "description": "Set to \"Y\" to include households associated with mail order purchasing activity.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_maritalstatus": {
- "description": "Marital status codes (M=Married, S=Single, A=Married (Inferred), B=Single (Inferred))",
- "items": {
- "enum": [
- "M",
- "S",
- "A",
- "B"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "d_military_history": {
- "description": "Set to \"Y\" to include households associated with military history households.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_mortgage2_amount": {
- "description": "Second mortgage amount in thousands",
- "enum": [
- "1",
- "50",
- "100",
- "150",
- "200",
- "250",
- "300",
- "400",
- "500",
- "600",
- "700",
- "800",
- "900",
- "1000"
- ],
- "type": "string"
- },
- "d_mortgage2_date": {
- "description": "Second mortgage date in YYYYMMDD format",
- "pattern": "^\\d{8}$",
- "type": "string"
- },
- "d_mortgage2_loan_type": {
- "description": "Second mortgage loan type codes. See values in options tool",
- "enum": [
- "5",
- "C",
- "F",
- "P",
- "S",
- "V",
- "W"
- ],
- "type": "string"
- },
- "d_mortgage2_rate": {
- "description": "Second mortgage interest rate percentage",
- "pattern": "^\\d{1,2}(\\.\\d{1,2})?%$",
- "type": "string"
- },
- "d_mortgage2_rate_type": {
- "description": "Second mortgage rate type codes. A=Adjustable, B=Balloon, F=Fixed, U=Unknown",
- "enum": [
- "A",
- "B",
- "F",
- "U"
- ],
- "type": "string"
- },
- "d_mortgage_amount": {
- "description": "Mortgage amount in thousands (use values like \"50\" or \"400\")",
- "enum": [
- "1",
- "50",
- "100",
- "150",
- "200",
- "250",
- "300",
- "400",
- "500",
- "600",
- "700",
- "800",
- "900",
- "1000"
- ],
- "type": "string"
- },
- "d_mortgage_purchase_date": {
- "description": "Mortgage purchase date in YYYYMMDD format",
- "pattern": "^\\d{8}$",
- "type": "string"
- },
- "d_mortgage_purchase_loan_type_code": {
- "description": "Mortgage purchase loan type codes. See values in options tool",
- "enum": [
- "5",
- "C",
- "F",
- "P",
- "S",
- "V",
- "W"
- ],
- "type": "string"
- },
- "d_mortgage_rate": {
- "description": "Mortgage interest rate percentage (e.g., \"6.75%\", \"10%\")",
- "pattern": "^\\d{1,2}(\\.\\d{1,2})?%$",
- "type": "string"
- },
- "d_mortgage_rate_type": {
- "description": "Mortgage rate type codes. A=Adjustable, B=Balloon, F=Fixed, U=Unknown",
- "enum": [
- "A",
- "B",
- "F",
- "U"
- ],
- "type": "string"
- },
- "d_motorcycles": {
- "description": "Set to \"Y\" to include households associated with motorcycle interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_naics": {
- "description": "Raw 2- to 6-digit NAICS codes. Use the options tool to retrieve valid values",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "d_networth": {
- "description": "Estimated net worth range using codes. See values in options tool",
- "pattern": "^[A-I](-[A-I])?$",
- "type": "string"
- },
- "d_news": {
- "description": "Set to \"Y\" to include households associated with current affairs engagement.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_num_children": {
- "description": "Number of children range (0-8, e.g., \"2-3\")",
- "pattern": "^[0-9](-[0-9])?$",
- "type": "string"
- },
- "d_numemployees": {
- "description": "Company size range, in the format \"min-max\" (e.g. \"100-50000\")",
- "type": "string"
- },
- "d_occupation": {
- "description": "Occupation codes. See values in options tool",
- "items": {
- "pattern": "^[A-Z]$",
- "type": "string"
- },
- "type": "array"
- },
- "d_onlinepurchaser": {
- "description": "Set to \"Y\" to include households associated with online purchasing activity.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_ownrent": {
- "description": "Home ownership status codes (H=Owner, R=Renter, 9=Probable Owner)",
- "items": {
- "enum": [
- "H",
- "R",
- "9"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "d_pets": {
- "description": "Set to \"Y\" to include households associated with pet ownership.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_political_party": {
- "description": "Political party affiliation values",
- "items": {
- "enum": [
- "REPUBLICAN",
- "DEMOCRAT",
- "LIBERTARIAN",
- "GREEN",
- "INDEPENDENT",
- "REFORM",
- "NO AFFILIATION"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "d_presence_of_children": {
- "description": "Set to \"Y\" to include households with children present",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_refi_amount": {
- "description": "Refinance amount in thousands (single value or range)",
- "pattern": "^\\d+(-\\d+)?$",
- "type": "string"
- },
- "d_refi_date": {
- "description": "Refinance date or date range using YYYYMMDD format",
- "pattern": "^\\d{8}(-\\d{8})?$",
- "type": "string"
- },
- "d_refi_loan_type": {
- "description": "Refinance loan type codes. See values in options tool",
- "enum": [
- "5",
- "C",
- "F",
- "P",
- "S",
- "U",
- "W"
- ],
- "type": "string"
- },
- "d_refi_rate_type": {
- "description": "Refinance rate type codes. A=Adjustable, B=Balloon, F=Fixed, U=Unknown",
- "enum": [
- "A",
- "B",
- "F",
- "U"
- ],
- "type": "string"
- },
- "d_religion": {
- "description": "Religion codes. See values in options tool",
- "items": {
- "pattern": "^[A-Z]$",
- "type": "string"
- },
- "type": "array"
- },
- "d_salesvolume": {
- "description": "Company revenue range, in the format \"min-max\" (e.g. \"100000-1000000\" for $100K to $1M)",
- "type": "string"
- },
- "d_senior_hhld": {
- "description": "Set to \"Y\" to include households associated with senior households.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_shooting": {
- "description": "Set to \"Y\" to include households associated with shooting sports interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_sic": {
- "description": "Legacy 4-digit SIC codes",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "d_singleparent": {
- "description": "Set to \"Y\" to include households associated with single parent households.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_soho": {
- "description": "Set to \"Y\" to include households associated with small office/home office households.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_state": {
- "description": "Array of 2-letter state codes to filter by",
- "items": {
- "pattern": "^[A-Z]{2}$",
- "type": "string"
- },
- "type": "array"
- },
- "d_travel": {
- "description": "Set to \"Y\" to include households associated with travel interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_weightloss": {
- "description": "Set to \"Y\" to include households associated with dieting and weight loss interest.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_workingwoman": {
- "description": "Set to \"Y\" to include households associated with working women households.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_youngadult_hhld": {
- "description": "Set to \"Y\" to include households associated with young adult households.",
- "enum": [
- "Y"
- ],
- "type": "string"
- },
- "d_zip": {
- "description": "Array of 5-digit ZIP codes to filter by",
- "items": {
- "pattern": "^\\d{5}$",
- "type": "string"
- },
- "type": "array"
- },
- "include_demo_categories": {
- "description": "Demographic category summaries to include in the response. Recommended to include at least one with estimate calls for audience insights in the preview response",
- "items": {
- "enum": [
- "b2cDemographic",
- "b2cHouseFinAuto",
- "b2cLifestyleInterest",
- "b2cPoliticalDonor",
- "firmographic"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "include_filter_attrs": {
- "description": "Include selected filter attributes as columns in the final audience",
- "type": "boolean"
- },
- "max_coverage": {
- "description": "Request append processing for selected channels (must overlap required/optional fields)",
- "items": {
- "enum": [
- "email",
- "phone",
- "phone_multiple",
- "phone_mobile",
- "phone_multiple_mobile",
- "oa"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "max_records": {
- "description": "Cap the number of records returned by the eventual list build",
- "minimum": 1,
- "type": "integer"
- },
- "optional_fields": {
- "description": "Optional contact fields to include when available",
- "items": {
- "enum": [
- "address",
- "email",
- "phone",
- "phone_multiple",
- "phone_mobile",
- "phone_multiple_mobile",
- "oa"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "output": {
- "description": "Campaign type specification. Must include exactly one: \"email\" or \"oa\". Email should almost always be used; OA can ONLY be used for audience targeting in ad platforms and will return hashed data",
- "items": {
- "enum": [
- "email",
- "oa"
- ],
- "type": "string"
- },
- "maxItems": 1,
- "minItems": 1,
- "type": "array"
- },
- "rcfg_max_time": {
- "description": "Maximum allowed API run time in seconds",
- "minimum": 0.1,
- "type": "number"
- },
- "rcfg_phone_format": {
- "description": "Set to 1 to prefix returned phone numbers with the country code",
- "enum": [
- 1
- ],
- "type": "integer"
- },
- "rd_department": {
- "description": "Job departments. Use the options tool to retrieve valid values",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "rd_role": {
- "description": "Job roles. Use the options tool to retrieve valid values",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "rd_title_seniority": {
- "description": "Title seniority levels",
- "items": {
- "enum": [
- "Owner/President",
- "C-Level",
- "VP/Sr. Executive",
- "Director",
- "Manager",
- "Non-Manager"
- ],
- "type": "string"
- },
- "type": "array"
- },
- "required_fields": {
- "description": "Required output contact fields. Must include at least one. Recommended to include address for estimate calls for geo info. IMPORTANT: Unlike the B2B Persona API, this field along with optional_fields are used to define output instead of the \"output\" parameter",
- "items": {
- "enum": [
- "address",
- "email",
- "phone",
- "phone_multiple",
- "phone_mobile",
- "phone_multiple_mobile",
- "oa"
- ],
- "type": "string"
- },
- "minItems": 1,
- "type": "array"
- }
-}Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "job_guid": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "job_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "job_operation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "job_state": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "list_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "output_list_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "project_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}create_project1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "created_at": {
+ "description": "ISO-8601 creation timestamp",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "project_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "project_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}demographic_append1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "input_query": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "match_counts": {
+ "description": "Sparse match counts. An absent key means zero.",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "num_matches": {
+ "description": "Number of matching queries.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "num_results": {
+ "description": "Number of records returned.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "query_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "results": {
+ "description": "Records returned by the Operations API. Record fields pass through unchanged.",
+ "items": {
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "warnings": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}docs_search1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "results": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}email_validation1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "input_query": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "match_counts": {
+ "description": "Sparse match counts. An absent key means zero.",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "num_matches": {
+ "description": "Number of matching queries.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "num_results": {
+ "description": "Number of records returned.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "query_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "results": {
+ "description": "Records returned by the Operations API. Record fields pass through unchanged.",
+ "items": {
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "warnings": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}firmographic_append1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "input_query": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "match_counts": {
+ "description": "Sparse match counts. An absent key means zero.",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "num_matches": {
+ "description": "Number of matching queries.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "num_results": {
+ "description": "Number of records returned.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "query_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "results": {
+ "description": "Records returned by the Operations API. Record fields pass through unchanged.",
+ "items": {
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "warnings": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}ip_to_domain_append1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "input_query": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "match_counts": {
+ "description": "Sparse match counts. An absent key means zero.",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "num_matches": {
+ "description": "Number of matching queries.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "num_results": {
+ "description": "Number of records returned.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "query_id": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "results": {
+ "description": "Records returned by the Operations API. Record fields pass through unchanged.",
+ "items": {
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "warnings": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}job_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "created_at": {
+ "description": "ISO-8601 creation timestamp",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "est_sec_remaining": {
+ "type": [
+ "integer",
+ "number",
+ "null"
+ ]
+ },
+ "finished_at": {
+ "description": "ISO-8601 completion timestamp",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "job_guid": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "job_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "job_operation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "job_state": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "list_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "output_file_ready": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "output_list_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "progress_percentage": {
+ "type": [
+ "integer",
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}list_lists1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "lists": {
+ "description": "List summaries. created_at is an ISO-8601 timestamp.",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "lists"
+ ],
+ "type": "object"
+}list_projects1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "projects": {
+ "description": "Project summaries. created_at is an ISO-8601 timestamp.",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "projects"
+ ],
+ "type": "object"
+}preview_list1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "list_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "list_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "returned_rows": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "rows": {
+ "items": {
+ "items": {
+ "type": [
+ "string",
+ "integer",
+ "number",
+ "boolean",
+ "object",
+ "array",
+ "null"
+ ]
+ },
+ "type": "array"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}show_list1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "job_summary": {
+ "properties": {
+ "latest_job_created_at": {
+ "description": "ISO-8601 creation timestamp",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_job_finished_at": {
+ "description": "ISO-8601 completion timestamp",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_job_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "latest_job_operation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_job_state": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "list": {
+ "properties": {
+ "created_at": {
+ "description": "ISO-8601 creation timestamp",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "file_ready": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "list_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "list_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "list_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "project_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "project_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "record_count": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "source": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}show_project1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "list_summary": {
+ "properties": {
+ "processing_lists": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "recent_lists": {
+ "items": {
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "total_lists": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "project": {
+ "properties": {
+ "created_at": {
+ "description": "ISO-8601 creation timestamp",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "favorite": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "project_id": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "project_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "updated_at": {
+ "description": "ISO-8601 update timestamp",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+}b2b_listgen_estimateb2b_listgen_optionsb2c_listgen_estimateb2c_listgen_optionsc2b_appendcontact_appendcreate_jobcreate_projectdemographic_appenddocs_searchemail_validationfirmographic_appendip_to_domain_appendjob_statuslist_listslist_projectspreview_listshow_listshow_project
Add one secure layer between your agents and this server.