Italian B2B Lead Scoring, Ranking & JSON Decisions
Server Details
Score and rank a buyer-supplied Italian B2B lead list into up to 250 explained JSON decisions.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 6 of 6 tools scored.
Each tool addresses a distinct step: buyer fit check, catalog, requirements, example, need mapping, and order prep. No overlap.
All names follow a consistent verb_noun pattern in snake_case (check, get, map, prepare), with clear and predictable actions.
Six tools is a reasonable count for a pre-sales product research server, though the server name suggests scoring tools are missing.
The server lacks the core tool to actually score or rank leads; it only covers preparatory steps, leaving a major gap for the claimed purpose.
Available Tools
6 toolscheck_buyer_fitCheck MachineSignal buyer fitARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'Coarse non-personal facts only' and the warning in parameter descriptions about not sending free text or buyer data, which enriches the behavioral context. 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 consists of two efficient sentences: the first captures the primary purpose and conditions, the second adds safety context. No superfluous words; every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, 3 enums, output schema exists but not shown), the description covers the key use case and behavioral constraints. It could be improved by explicitly noting that the country parameter should be 'IT' for Italian buyers, but the schema handles that implicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The tool description further clarifies how parameters interconnect (e.g., 'Italian' implies country='IT', 'B2B' ties to customer_type, 'existing company' ties to has_existing_company_list). This adds meaning beyond the schema alone.
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 'Check' and the specific resource (buyer fit for MS-DEC-250), along with key conditions (Italian, B2B, existing company list). It also implicitly distinguishes from sibling tools like prepare_order_intent by focusing on eligibility rather than order creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (checking eligibility before order), but does not explicitly state when not to use it or mention alternatives. The directive 'it creates no order' hints at its safe, non-committal nature, but lacks explicit exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_catalogGet MachineSignal product catalogARead-onlyIdempotentInspect
Find an API product to score, classify, rank and prioritize an existing Italian B2B company or lead list into up to 250 explained JSON decisions. Returns the canonical catalog and permanent safety boundaries; read-only and no buyer data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| service | Yes | |
| version | Yes | |
| products | Yes | |
| resources | Yes | Canonical public MachineSignal resources. |
| boundaries | Yes | Permanent safety boundaries of the public MCP discovery server. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds context about permanent safety boundaries, no buyer data, and return of explained JSON decisions, which is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first action-oriented, second adds safety context. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0 parameters, comprehensive annotations, and an output schema (mentioned), the description provides enough context for the agent to select and invoke correctly, including constraints (Italian B2B, up to 250 decisions) and return type.
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?
No parameters exist, so schema coverage is 100%. Per guidelines, baseline is 4 for 0 params; description does not need to add parameter info.
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 it returns the 'MachineSignal product catalog' and its purpose for scoring/classifying/ranking B2B companies. It distinguishes itself from siblings by focusing on the catalog itself, though it does not explicitly contrast with tools like 'get_purchase_requirements'.
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 use before other tools by saying 'Find an API product to score...', and notes it is read-only with no buyer data, suggesting safe usage. However, it lacks explicit guidance on when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_purchase_requirementsGet controlled purchase requirementsARead-onlyIdempotentInspect
Explain the machine-origin purchase prerequisites without accepting an order, returning checkout data or calling a provider.
| Name | Required | Description | Default |
|---|---|---|---|
| product_code | Yes | Product whose controlled machine-origin purchase requirements should be returned. |
Output Schema
| Name | Required | Description |
|---|---|---|
| boundaries | Yes | Permanent safety boundaries of the public MCP discovery server. |
| order_policy | Yes | |
| product_code | Yes | |
| customer_scope | Yes | |
| legal_resources | Yes | |
| ready_to_prepare | Yes | |
| input_requirement | Yes | |
| machine_onboarding | Yes | |
| checkout_url_returned | Yes | |
| recommended_next_tool | No | |
| mcp_order_tool_exposed | Yes | |
| recommended_next_arguments | No | |
| next_step_after_preparation | No | |
| authoritative_order_protocol | Yes | |
| buyer_data_must_remain_local | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds extra transparency by explicitly stating that no order is accepted, no checkout data is returned, and no external provider is called. This aligns with annotations and provides further behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the main action and includes clarifying details. Every phrase earns its place with no 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?
Given the presence of an output schema (not needing return-value explanation), a single well-described parameter, and supportive annotations, the description covers all necessary aspects. It is complete for an informational tool with low complexity.
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% coverage with a clear description for the only parameter. The tool description does not add new information about the parameter beyond what the schema already provides, so it meets the baseline without extra contribution.
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 'Explain' and the resource 'machine-origin purchase prerequisites'. It explicitly distinguishes itself from siblings by listing what it does NOT do (accept orders, return checkout data, or call a provider), making its purpose distinct.
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 implicitly explains when to use the tool (to explain prerequisites) and clarifies that it is not for actual ordering. However, it does not explicitly contrast with sibling tools or state when to choose this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_synthetic_exampleGet a synthetic MachineSignal output exampleARead-onlyIdempotentInspect
Preview the JSON produced when MachineSignal scores, classifies, ranks and prioritizes an Italian B2B lead list. Uses approved synthetic data only and creates no order.
| Name | Required | Description | Default |
|---|---|---|---|
| product_code | Yes | Product whose approved synthetic output preview should be returned. |
Output Schema
| Name | Required | Description |
|---|---|---|
| example | Yes | Approved synthetic product preview; never real buyer or company data. |
| boundaries | Yes | Permanent safety boundaries of the public MCP discovery server. |
| canonical_example_url | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context: 'Uses approved synthetic data only and creates no order'. This clarifies data source and confirms no side effects, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose. Every sentence adds value—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 simple tool with one enum parameter and an output schema, the description is complete. It explains purpose, data source, and side effects. No need to describe return values since 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?
Schema coverage is 100% and includes a description for the single parameter. The tool description does not add additional meaning about the parameter beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Preview' and the resource 'JSON produced when MachineSignal scores... an Italian B2B lead list'. It distinguishes from siblings which focus on checking fit, catalog, etc.
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 for previewing synthetic output, but does not explicitly state when to use versus alternatives or when not to use. No sibling differentiation is mentioned in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
map_business_needMap a general B2B business need for product researchARead-onlyIdempotentInspect
Map any structured B2B business need from Italy or a foreign market for aggregate product research. Italy remains the only commercial sales scope; foreign signals are research-only. The tool accepts only closed semantic fields and never creates a product or order.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Legacy 1.2.0 compatibility for Italian demand. Omit it when origin_market is supplied. | |
| urgency | No | How soon the capability would be useful; defaults to exploratory. | |
| recurrence | No | Whether the need is one-off, recurring or continuous; defaults to unknown. | |
| budget_band | No | Optional coarse willingness-to-pay band in EUR; never send payment data. | |
| need_action | Yes | Primary action the machine wants the capability to perform. | |
| need_domain | Yes | Broad business domain of the requested capability; use other only when none applies. | |
| need_object | Yes | Business object or subject on which the action should operate. | |
| customer_type | Yes | Only business demand is observed; this does not expand commercial eligibility. | |
| origin_market | No | Self-declared coarse origin bucket used only for aggregate research; defaults to UNKNOWN_NOT_DECLARED. Foreign buckets never enable sales. | |
| desired_output | Yes | Machine-readable or operational result the buyer wants. | |
| existing_product_fit | No | Whether an existing MachineSignal product appears to fit; defaults to unknown. |
Output Schema
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| boundaries | Yes | Permanent safety boundaries of the public MCP discovery server. |
| signal_type | Yes | |
| order_created | Yes | |
| origin_market | Yes | |
| persists_data | Yes | |
| mapping_status | Yes | |
| need_signature | Yes | |
| product_created | Yes | |
| free_text_accepted | Yes | |
| buyer_data_accepted | Yes | |
| market_verification | Yes | |
| existing_product_fit | Yes | |
| checkout_url_returned | Yes | |
| potential_product_gap | Yes | |
| provider_call_enabled | Yes | |
| commercial_eligibility | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds key behaviors: never creates a product or order, and clarifies territorial scope for research vs commercial use.
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?
Three concise sentences front-load the core purpose, then add scope constraints. No unnecessary words, each sentence adds value.
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 11 parameters, an output schema exists, and annotations cover safety, the description adequately adds key constraints (scope, non-creation). Could mention that mapping implies aggregate research only, but overall sufficient.
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 baseline is 3. The description ('accepts only closed semantic fields') adds minimal value beyond the schema's detailed enumerations and descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps structured B2B business needs for product research, with specific scopes (Italy or foreign). It distinguishes from siblings like prepare_order_intent by noting it never creates a product or order.
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 clear context on when to use (mapping needs for research) and when not (never creates products/orders), and limits commercial scope to Italy. Lacks explicit references to sibling tools but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prepare_order_intentPrepare a local MS-DEC-250 order-intent templateARead-onlyIdempotentInspect
Return the canonical endpoint, OpenAPI, 17 required fields and a locally fillable MS-DEC-250 template. It accepts no buyer data and never creates an order.
| Name | Required | Description | Default |
|---|---|---|---|
| product_code | Yes | Entry product whose order-intent template should be prepared locally without submitting it. |
Output Schema
| Name | Required | Description |
|---|---|---|
| boundaries | Yes | Permanent safety boundaries of the public MCP discovery server. |
| instructions | Yes | |
| product_code | Yes | |
| order_created | Yes | |
| order_openapi | Yes | |
| persists_data | Yes | |
| submit_method | Yes | |
| order_endpoint | Yes | |
| required_fields | Yes | |
| accepts_buyer_data | Yes | |
| idempotency_header | Yes | |
| preparation_status | Yes | |
| request_schema_ref | Yes | |
| local_fill_template | Yes | |
| static_order_openapi | Yes | |
| checkout_url_returned | Yes | |
| provider_call_enabled | Yes | |
| validation_profile_url | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations (readOnlyHint, idempotentHint, destructiveHint) by stating 'It accepts no buyer data and never creates an order,' which provides key behavioral context not in annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the most important information (what it returns), and no unnecessary words. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, good annotations, output schema exists), the description fully covers the tool's purpose, behavior, and limitations. No gaps.
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% for the single parameter (product_code with const and description), so the description does not need to add parameter details. Baseline 3 is appropriate; no extra semantic value from description.
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 that it returns a canonical endpoint, OpenAPI, required fields, and a fillable template for MS-DEC-250. It uses a specific verb 'return' and resource 'MS-DEC-250 order-intent template', distinguishing it from siblings like 'check_buyer_fit' which check fit, not prepare templates.
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 'It accepts no buyer data and never creates an order', which guides when not to use it. However, it does not explicitly state when to use it or name alternatives, leaving room for clearer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!