MachineSignal Discovery
Server Details
Read-only B2B Italy discovery, local order preparation and aggregate general demand mapping.
- 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
Score is being calculated. Check back soon.
Available Tools
6 toolscheck_buyer_fitCheck MachineSignal buyer fitRead-onlyIdempotentInspect
Evaluate only coarse, non-personal eligibility facts. It does not create an order or validate an ACT entitlement.
| 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 |
get_product_catalogGet MachineSignal product catalogRead-onlyIdempotentInspect
Return the canonical B2B Italy product catalog and permanent safety boundaries. This tool is read-only and accepts 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. |
get_purchase_requirementsGet controlled purchase requirementsRead-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 |
get_synthetic_exampleGet a synthetic MachineSignal output exampleRead-onlyIdempotentInspect
Return an approved synthetic preview at the correct DEC or ACT scale. No real company data is used.
| 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 |
map_business_needMap a general B2B Italy business needARead-onlyIdempotentInspect
Map any structured B2B Italy business need, including needs unrelated to current MachineSignal products. It accepts only closed semantic fields, records ephemeral aggregates and never creates a product or order.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Commercial scope is limited to Italy. | |
| 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 buyers are in scope. | |
| 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 | |
| persists_data | Yes | |
| mapping_status | Yes | |
| need_signature | Yes | |
| product_created | Yes | |
| free_text_accepted | Yes | |
| buyer_data_accepted | Yes | |
| existing_product_fit | Yes | |
| checkout_url_returned | Yes | |
| potential_product_gap | Yes | |
| provider_call_enabled | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly (true), idempotent (true), not destructive. The description adds that it accepts only closed semantic fields and records ephemeral aggregates, providing context 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?
The description is two sentences, with the first clearly stating the purpose and scope, and the second adding key constraints. No extraneous 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?
Given 10 parameters (6 required) with full schema descriptions and an output schema (not shown but present), the description is sufficient. It hints at the ephemeral nature of the result. Could mention idempotency more explicitly, but annotations cover that.
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 descriptions for all parameters. The description adds 'only closed semantic fields' which aligns with the many enums but doesn't provide new parameter-level semantics 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 clearly states the action (map a business need), scope (B2B Italy, not limited to current products), and distinguishes from product/order tools. This aligns with the sibling tools to differentiate usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: for mapping needs not related to products, and explicitly states it never creates a product or order. However, it does not explicitly mention alternative tools or exclusion scenarios beyond 'unrelated' needs.
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?
Annotations already declare readOnlyHint and idempotentHint. The description adds value by stating 'accepts no buyer data' and 'never creates an order,' reinforcing the non-mutating behavior beyond 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 two sentences, front-loaded with key outcomes, and contains no redundant information. Every sentence 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 simple parameter set, rich annotations, and existence of an output schema (not shown), the description covers the tool's purpose, constraints, and behavior sufficiently. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage and includes a const for product_code. The description mentions '17 required fields' but these refer to the template output, not the parameter. It adds minimal new meaning 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 explicitly states it returns a template for MS-DEC-250, mentions specific outputs, and clarifies it does not create orders. This clearly distinguishes it from sibling tools like check_buyer_fit or get_product_catalog.
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 notes that the tool accepts no buyer data and never creates an order, implying it is for preparatory use. However, it does not explicitly state when to use it over alternatives or provide 'when-not' guidance.
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!