Versium REACH

Create Job Mcp Tool

create_job

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`job_id`	No
`job_guid`	No
`job_state`	No
`list_name`	No
`project_id`	No
`job_operation`	No
`output_list_id`	No

TDQS

A4.4/5.0

Behavior4/5

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

The annotations are minimal (all false), so the description carries the burden of disclosing behavioral traits. It discloses that the job is created for the authenticated user, that charge-on-finish jobs require consent and usage_consent_confirmed, and that the consent_required_job_types meta field determines which types need consent. This adds meaningful operational context beyond the annotations, though it doesn't detail side effects or error handling.

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

Conciseness5/5

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

The description is three concise sentences, front-loaded with the primary purpose, followed by actionable usage notes. No wasted words; every sentence adds operational value.

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

Completeness4/5

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

The tool has 6 parameters, a nested config, and a complex consent workflow. The description addresses key contextual elements: project_id preference, consent handling for charge-on-finish jobs, the meta field for consent requirements, and directing users to estimate tools for config shape. It does not explain the output format, but an output schema exists, which shifts that responsibility. Given the complexity and available structured information, the description is adequately complete.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by giving operational guidance: prioritizing project_id over project_name, the exact workflow for consent (tell user, then confirm), and the need to consult the consent_required_job_types meta field. It also reinforces that config must match the shape from estimate tools. This enriches parameter usage beyond mere descriptions.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Create a B2B or B2C listgen job for the authenticated user.' It identifies the specific verb (create), the resource (listgen job), and the B2B/B2C scope. It also distinguishes this from sibling estimate/options tools by referencing 'listgen job' and focusing on creation rather than estimation.

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

Usage Guidelines4/5

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,' and for charge-on-finish jobs, instructs to inform the user about usage and only set usage_consent_confirmed after explicit consent. It also directs the reader to read the consent_required_job_types meta field. While it doesn't explicitly say when not to use this tool versus sibling tools, the context of it being the creation step and the guidance for consent makes the usage context clear.

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

All Versium REACH tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: list generation (B2B vs B2C), enrichment (contact, demographic, firmographic, C2B, IP-to-domain), project/list management, job lifecycle, and validation. No two tools appear to do the same thing, so an agent can reliably select the correct one.

Naming Consistency5/5

All tool names follow the verb_noun pattern consistently, using verbs like list, show, create, preview, search, validate, append, and estimate. Even the segmented append tools (c2b_append, contact_append, demographic_append, firmographic_append, ip_to_domain_append) follow the same pattern with clear noun modifiers. No mixed conventions or vague verbs.

Tool Count4/5

With 19 tools, this is on the higher side but still well-scoped for a data enrichment and list-building platform. The count covers distinct functional areas (audience estimation, enrichment, job/project management, list inspection, documentation) without unnecessary bloat. It feels slightly heavy but each tool earns its place.

Completeness4/5

The tool surface covers the core workflows: estimating audiences, creating and monitoring jobs, managing projects and lists, and enriching records with various data types. Minor gaps exist, such as no explicit delete/update operations for projects or lists, and no direct file download for list contents (though preview_list and show_list provide partial coverage). These are non-blocking gaps that agents can work around.

Resources

Need Help?