Italian B2B Lead List Scoring, Ranking & JSON Decisions

Check MachineSignal buyer fit

check_buyer_fit

Read-onlyIdempotent

Check whether an Italian B2B buyer with an existing company, domain, CRM or lead list can use MS-DEC-250 to score, rank and prioritize up to 250 records. Coarse non-personal facts only; it creates no order.

Input Schema

TableJSON Schema

Name	Required	Description
`country`	Yes	Two-letter country code, for example IT.
`primary_need`	No	Optional non-personal demand category used only in ephemeral aggregate counters; never send free text or buyer data.
`customer_type`	Yes	Buyer type. MachineSignal accepts B2B only.
`requested_product_code`	No	Product being considered. Defaults to the entry product MS-DEC-250.
`has_existing_company_list`	Yes	Whether the buyer already has a company, domain, CRM or lead list to evaluate.

Output Schema

TableJSON Schema

Name	Required	Description
`reason`	Yes
`eligible`	Yes
`boundaries`	Yes	Permanent safety boundaries of the public MCP discovery server.
`fit_status`	Yes
`reason_code`	Yes
`next_resource`	No
`ready_to_prepare`	Yes
`checkout_url_returned`	No
`recommended_next_tool`	No
`requested_product_code`	Yes
`recommended_next_arguments`	No
`next_step_after_preparation`	No
`buyer_data_must_remain_local`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the check uses coarse non-personal facts only and creates no order, which aligns with and supplements the annotations. It doesn't contradict any annotation.

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?

Single sentence that is front-loaded with the core action and scope. Every word contributes value: verb, target audience, constraints, and outcome. No unnecessary elaboration.

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?

Given the output schema exists, the description need not detail return values. It covers the main check purpose and constraints. For a simple eligibility check with 5 parameters and clear annotations, the description is sufficiently complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides. The overall purpose context is helpful, but no param details are enriched.

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 checks if an Italian B2B buyer with existing company data can use MS-DEC-250 for scoring/ranking/prioritizing records. It uses a specific verb ('check') and resource ('buyer fit'), distinguishing it from siblings like get_product_catalog or prepare_order_intent.

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 implies when to use: when determining if a buyer can use the product. It doesn't explicitly state when not to use or name alternatives, but sibling tool names provide enough context for differentiation. A clear context is provided, though exclusions are missing.

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

All Italian B2B Lead List Scoring, Ranking & JSON Decisions 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

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct function: buyer fit check, catalog retrieval, purchase requirements, synthetic example, business need mapping, and order intent preparation. No two tools have overlapping purposes, making it clear to an agent which tool to use for each task.

Naming Consistency5/5

All six tools follow a consistent verb_noun snake_case pattern (e.g., check_buyer_fit, get_product_catalog). The naming is uniform and predictable, aiding agent selection.

Tool Count4/5

With 6 tools, the count is reasonable for a focused server. However, the server name 'B2B Lead Scoring' suggests tools for scoring leads, but the actual tools are more about product catalog and order preparation, creating a slight mismatch in perceived scope.

Completeness2/5

For a lead scoring server, critical tools such as score_lead, get_lead_score, or lead_ranking are missing. The existing tools cover pre-sales steps but not the core scoring functionality, leaving significant gaps for the stated purpose.

Resources

Need Help?