This server acts as a thin client to the Disruption Intelligence API, giving AI agents access to commercial disruption signals through free and paid tools:
Free Tools:
Check API Health: Verify the hosted Disruption Intelligence API is operational.
Fetch Discovery Metadata: Retrieve public documents including API indices, LLM info, OpenAPI specs, and x402 well-known metadata.
Inspect x402 Payment Challenges: Make an unpaid request to a paid endpoint and return structured payment challenge metadata without settling any payment.
Search Ripple Inventory: Retrieve counts, freshness, and unlock pricing for Ripple signals.
Paid Tools:
Analyze Territory Disruption: Query disruption signals for a US ZIP code within a specified radius.
Search Company Context: Find company information using a text query.
Get Company Risk Summary: Retrieve intelligence and risk data for a specific company.
Get Event Severity: Determine the severity of a disruption event.
Get Event Company Intel: Retrieve company-specific intelligence related to a disruption event.
Get Event Timeline: Fetch the timeline for a specific disruption event.
Get Ripple Signal Summaries: Retrieve summaries after payment settlement.
Generate a Ripple Report: Produce a full Disruption Intelligence Ripple Report.
Unlock Ripple Sector Impacts: Access downstream sector impacts and spend categories for a specific Ripple Signal.
Get Industry Classification: Retrieve NAICS fields, derivation method, confidence level, and source text for paid event-level responses.
Paid endpoints return structured x402 payment challenges by default without settling payments.
AI-native commercial disruption intelligence for MCP clients and x402-powered agents.
Disruption Intelligence MCP gives AI agents access to commercial disruption signals through an MCP server backed by the hosted Forgemesh API. It supports WARN/layoff intelligence, company context, geospatial territory disruption, location-only Ripple Index cards, Ripple Signals, Ripple Paths, Disruption Intelligence Ripple Reports, x402 payment challenge inspection, and economic signal workflows without exposing private scoring logic, ingestion systems, schemas, or infrastructure.
This package is a thin client around the hosted API:
https://disruption.forgemesh.io
Architecture:
Agent/MCP client -> this MCP server -> hosted Disruption Intelligence API
The MCP package does not contain engine internals, scoring logic, ingestion architecture, database schema, private topology, wallet addresses, or secrets.
npm install -g @forgemeshlabs/disruption-intelligence-mcpPublished package:
https://www.npmjs.com/package/@forgemeshlabs/disruption-intelligence-mcp
Source repo:
https://github.com/forgemeshlabs/disruption-intelligence-mcp
Local development:
npm install
npm run build
node dist/index.jsRelated MCP server: databid
Example config:
{
"mcpServers": {
"disruption-intelligence": {
"command": "npx",
"args": ["@forgemeshlabs/disruption-intelligence-mcp"],
"env": {
"DISRUPTION_API_BASE": "https://disruption.forgemesh.io"
}
}
}
}See examples/claude-desktop-config.json.
Tool | Endpoint | Cost behavior |
|
| Free |
|
| Free |
| Unpaid request to a paid endpoint | Returns x402 challenge metadata |
|
| Paid; challenge-first by default |
|
| Paid; challenge-first by default |
|
| Paid; challenge-first by default |
|
| Paid; challenge-first by default; paid output includes confidence-rated |
|
| Paid; challenge-first by default; paid output includes confidence-rated |
|
| Paid; challenge-first by default |
|
| Compatibility tool name; free Ripple inventory counts and unlock pricing only |
|
| Paid at $0.01; challenge-first by default; returns location-only Ripple index cards |
|
| Compatibility tool name; paid at $0.10; challenge-first by default; returns Ripple Signals after settlement |
|
| Compatibility tool name; paid at $0.25; challenge-first by default; returns a Disruption Intelligence Ripple Report after settlement |
|
| Compatibility tool name; paid at $0.15; challenge-first by default; returns Ripple Paths after settlement |
Free Ripple search is intentionally inventory-only. It returns counts, freshness, and unlock pricing without exposing commercial angles, evidence categories, source mix, signal IDs, company names, or raw source records.
get_ripple_index unlocks a low-cost location-only index for choosing where to dig next. It can return signal IDs, event IDs, regions, states, signal types, freshness/depth/confidence/score bands, and unlock URLs, while withholding company names, employee counts, commercial angles, sector names, spend areas, source records, and impact paths.
Paid Ripple endpoints expose distilled commercial intelligence. get_gold_signals returns Ripple Signal summaries, confidence bands, compact evidence labels, and Ripple Path inventory with an unlock endpoint. get_gold_sector_impacts unlocks the deeper operational map for one signal, including downstream spend categories such as fuel, food service, uniforms, maintenance, IT, logistics, office supplies, telecom, insurance, legal, cleaning, travel, and related vendor categories.
Paid event-level API responses now include industry_classification when event context is available. The hosted API returns the industry label, NAICS fields when present, derivation method, confidence level, source text when relevant, and a coverage note. The MCP remains a thin client: it does not infer industries locally and does not rewrite hosted WARN data.
Default mode is safe and non-settling. Free endpoints return API data directly. Paid endpoints are requested without payment credentials, so the hosted API can return an x402 402 Payment Required challenge.
When payment is required, this MCP returns structured payment instructions and challenge metadata instead of dumping an upstream error. It does not require a private key and does not settle payments.
Future paid execution should be opt-in and delegated to a trusted wallet or payment client.
DISRUPTION_API_BASE=https://disruption.forgemesh.ioNo wallet private key is required or accepted by this package. Paid endpoint calls return x402 challenge metadata for an external wallet or payment client to settle.
API docs and product context:
https://github.com/forgemeshlabs/disruption-intelligence
Hosted API:
https://disruption.forgemesh.io
This repository is an agent-facing thin client wrapper around the hosted API. It intentionally excludes engine code, scoring formulas, ingestion internals, database details, operational topology, wallet addresses, private keys, and secrets.
Thin wrapper for GET /territory/:zip/disruption?radius=. Paid endpoint; returns x402 challenge in default non-settling mode.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | US ZIP code to analyze. | |
| radius | No | Search radius in miles. Defaults to 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool is a paid endpoint and returns a 402 challenge in default non-settling mode, which is critical behavioral information not captured in the schema. However, does not describe behavior on successful payment or other edge cases.
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 concise sentences that front-load the endpoint and then add key context about payment. 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?
Covers endpoint, parameters, and an important behavioral aspect (402 challenge). Lacks description of success response format, but given it's a thin wrapper, the description is reasonably complete for a simple tool.
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 both parameters (zip and radius). Description adds that radius is in miles but does not go beyond what schema already provides. Baseline score 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?
Clearly states it's a thin wrapper for a specific GET endpoint with ZIP and radius parameters, and mentions it's a paid endpoint that returns a 402 challenge. Distinguishes from sibling tools which are for different purposes.
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?
Implies usage for analyzing territory disruption with a ZIP code, mentions paid endpoint and 402 challenge, but does not provide explicit guidance on when to use vs alternatives or how to handle the payment challenge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the hosted Disruption Intelligence API health endpoint. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It only states the tool is a health check and free, but omits details like what response format to expect, any rate limits, or authentication requirements.
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?
Extremely concise with one sentence front-loaded with the core action. No unnecessary 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 zero-parameter health check tool, the description is adequate but lacks context on what the response contains (e.g., status, uptime). With no output schema, more detail would help an agent understand the return value.
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?
There are zero parameters, so baseline is 4. The description adds no parameter info, which is fine since none exist.
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 the verb 'check' and specifies the resource 'hosted Disruption Intelligence API health endpoint', making the purpose highly clear. It is distinct from sibling tools which focus on territory analysis, risk, 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?
No guidance on when to use this tool versus alternatives. Only mentions 'Free' but no context on prerequisites, when to call the health endpoint, or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Thin wrapper for GET /companies/:id/intelligence. Paid endpoint; returns x402 challenge in default non-settling mode.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Company identifier accepted by the hosted API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the paid endpoint and the 402 challenge behavior, which is valuable. However, it does not describe the success response, side effects, or that it is a read-only operation. The 'thin wrapper' implies pass-through, but more transparency on normal behavior is needed.
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 core purpose. No wasted words; every sentence adds value. 'Thin wrapper' is efficient. Excellent conciseness.
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 low complexity (1 parameter, no output schema). The description covers the paid endpoint and error behavior but omits the success return type or structure. Without an output schema, the description should briefly state what the tool returns on success (e.g., risk summary data). This gap prevents a higher score.
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% because the 'id' parameter has a description in the schema. The description adds no extra meaning beyond 'Company identifier accepted by the hosted API.' This is adequate but not enriched. 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 identifies the tool as a wrapper for GET /companies/:id/intelligence, which fetches a company risk summary. It distinguishes from siblings like 'get_event_company_intel' and 'search_company_context' by specifying the endpoint and mentioning payment requirements. However, it could more explicitly state the functional purpose (e.g., 'retrieves risk summary').
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 lacks guidance on when to use this tool versus alternatives. It mentions the paid nature and default non-settling mode but does not compare with siblings like 'search_company_context' or 'get_event_company_intel'. No explicit when-to or when-not-to use advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch free discovery metadata from index.json, llms.txt, openapi.json, and x402 well-known metadata. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavioral traits. It states the tool fetches metadata, implying a read-only operation, but does not mention side effects, authentication, rate limits, or error conditions. Minimal disclosure.
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?
Description is two sentences and 19 words, very concise. The repeated 'free' is slightly redundant, but overall front-loads the key action and sources.
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 zero-parameter tool with no output schema, the description is fairly complete in naming the sources. However, it does not describe the return format or behavior when sources are missing, leaving some ambiguity.
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 has no parameters, so baseline score is 4. Description does not need to add parameter semantics, and it correctly lists the metadata sources as static endpoints.
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?
Description specifies the verb 'Fetch' and the resource 'discovery metadata' from specific well-known sources (index.json, llms.txt, openapi.json, x402). Purpose is clear but does not explicitly distinguish it from sibling tools that may also fetch metadata, such as inspect_x402_challenge.
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?
No guidance on when to use this tool versus alternatives. The word 'free' hints at no cost but does not clarify prerequisites, context, or contradictions with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Thin wrapper for GET /events/:id/company-intel. Paid endpoint; enriched paid responses include event industry_classification with method, confidence, and coverage_note. Returns x402 challenge in default non-settling mode.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Event identifier accepted by the hosted API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden. It discloses key behaviors: it is a paid endpoint, enriched responses include specific fields, and it returns an x402 challenge in default non-settling mode. This provides useful transparency beyond a basic GET call.
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 brief (two sentences) and efficiently conveys the endpoint, paid nature, enriched response details, and x402 behavior. Every sentence adds value, though the second sentence could be slightly more concise.
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 parameter and no output schema, the description provides sufficient context: it identifies the endpoint, reveals payment requirements, and notes special response fields. It lacks details on how to access enriched responses or handle the x402, but overall it is adequate.
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% for the single parameter 'id', which is described as 'Event identifier accepted by the hosted API.' The description adds that it's a thin wrapper for GET /events/:id/company-intel, confirming the id maps to the event ID in the URL. This adds marginal value beyond the schema, 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 ('get') and resource ('company intel for an event') and specifies the underlying endpoint. However, it does not distinguish from sibling tools like 'get_company_risk_summary' or 'inspect_x402_challenge', which may cause confusion.
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?
No explicit guidance on when to use this tool versus alternatives. Mentions it is a paid endpoint and returns x402 in default mode, but does not explain how to handle those conditions or compare with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Thin wrapper for GET /events/:id/severity. Paid endpoint; enriched paid responses include industry_classification with method, confidence, and coverage_note. Returns x402 challenge in default non-settling mode.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Event identifier accepted by the hosted API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it is a paid endpoint, enriched responses include industry_classification fields, and returns a 402 challenge in default non-settling mode. This adds useful context beyond the input schema, though it omits describing the basic severity output.
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, no unnecessary words. It is front-loaded with the wrapper nature and then details. Could be slightly more concise but 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 the simple input and lack of output schema, the description covers the paid nature, enriched fields, and a potential error response. However, it does not explain the standard return value (e.g., severity level) or what 'default non-settling mode' means, leaving some 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 only parameter (id). The description does not add extra meaning beyond the schema's 'Event identifier accepted by the hosted API.'
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 it retrieves severity for an event via a thin wrapper for GET /events/:id/severity. The verb and resource are clear, but it does not explicitly differentiate from sibling tools like get_event_company_intel or get_event_timeline.
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?
No guidance on when to use this tool versus alternatives. It mentions it's a paid endpoint and the response behavior, but does not specify prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Thin wrapper for GET /events/:id/timeline. Paid endpoint; returns x402 challenge in default non-settling mode.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Event identifier accepted by the hosted API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full responsibility. It reveals the tool is a thin wrapper, paid, and that the default mode returns a x402 challenge. This is helpful but lacks explicit status on read-only nature or what happens on success.
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, clear sentence with no redundancy. It front-loads the purpose and adds critical caveats efficiently.
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 GET wrapper with no output schema, the description covers the essential behavioral aspects (paid, x402). However, it omits the expected return structure on success or error handling, leaving gaps for an agent.
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 coverage of the single 'id' parameter, the description adds no extra meaning beyond the generic 'event identifier.' The baseline is 3, and the description does not raise it.
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 as a thin wrapper for an HTTP GET endpoint to retrieve an event timeline. The reference to 'paid endpoint' and x402 challenge distinguishes it from siblings like inspect_x402_challenge.
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 mentions it's a paid endpoint and may return a challenge, providing context for when to use. However, it doesn't explicitly state when to use this tool over alternatives like inspect_x402_challenge or under what conditions to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compatibility tool for GET /ripple/brief. Paid endpoint currently priced at $0.25; returns a Disruption Intelligence Ripple Report, challenge-first by default.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Optional commercial angle, company, region, or industry search query. | |
| limit | No | Maximum delivered signals to include. Hosted API caps this at 10. | |
| scope | No | Brief scope. Defaults to all on the hosted API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals it is a paid endpoint ($0.25) and uses 'challenge-first by default', which are useful behavioral traits. However, with no annotations, more details about side effects, rate limits, or response size would improve transparency.
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 sentence. While concise, it omits important context, making it under-specified rather than efficiently informative.
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 absence of an output schema and the complexity of sibling tools, the description fails to explain what a 'Ripple Report' contains or how it compares to outputs of get_gold_signals and similar tools. It leaves the agent guessing.
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 parameters are already described. The description adds no additional semantic information beyond the schema's parameter 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 states it returns a Disruption Intelligence Ripple Report and mentions the endpoint, making the purpose clear. However, it does not differentiate from sibling tools like get_gold_signals, which might also return report-like data.
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?
No guidance on when to use this tool versus alternatives. The description lacks context about when to prefer get_gold_brief over other get_gold_* or analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compatibility tool for GET /ripple/signals/:id/sector-impacts. Paid endpoint currently priced at $0.15; returns Ripple Paths with deep operational spend and downstream sector impacts for one signal, challenge-first by default.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Ripple signal UUID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool is paid and 'challenge-first', which are key behaviors. But it omits details like whether it's read-only, idempotency, or error conditions. The pricing is helpful, but overall transparency is moderate.
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, no fluff. First sentence identifies the endpoint, second adds key context (pricing, return type, behavior). Could arguably be more concise by removing 'Compatibility tool for' which adds little, but overall 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 no output schema, the description should explain return structure more thoroughly. It mentions 'Ripple Paths with deep operational spend and downstream sector impacts' but lacks detail on format or size. The pricing and challenge-first info are good, but completeness is average for a tool with one parameter.
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 a concise description for the single parameter 'id' ('Ripple signal UUID.'). The description adds no additional meaning beyond what the schema provides, meeting the baseline for high 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 explicitly states the tool returns 'Ripple Paths with deep operational spend and downstream sector impacts for one signal', clearly identifying the verb (returns) and resource (sector impacts for a signal). It distinguishes from siblings like 'get_gold_signals' which returns signals themselves.
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 mentions 'Paid endpoint currently priced at $0.15' and 'challenge-first by default', providing context on when to use (if willing to pay) and a behavioral condition. However, it does not explicitly guide when to use this vs alternatives like 'get_gold_brief' or 'search_gold_inventory', nor does it say 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.
Compatibility tool for GET /ripple/signals. Paid endpoint currently priced at $0.10; returns Ripple Signals and Ripple Path inventory, challenge-first by default.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Optional commercial angle, company, region, or industry search query. | |
| limit | No | Maximum signals to return. Hosted API caps this at 10. | |
| state | No | Signal state to request. Defaults to gold. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral context: pricing ($0.10), ordering (challenge-first by default), and that it returns both signals and inventory. However, it does not disclose idempotency, side effects, or rate limits. The description adds value beyond the endpoint name but lacks full transparency.
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 sentence that efficiently conveys the tool's purpose, pricing, and default behavior. No unnecessary words, though it could be structured as two sentences for clarity.
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 has 3 optional parameters and no output schema, the description is adequate but not complete. It explains default ordering and pricing but does not describe the return format or pagination. The term 'compatibility tool' is ambiguous.
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 the description does not need to add much. It repeats the q parameter description from the schema but does not add new meaning for 'limit' or 'state'. The tool description does not 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 clearly states the tool is for getting Ripple Signals and Ripple Path inventory, with a specific verb ('get') and resource ('gold signals'). It distinguishes from siblings like 'get_gold_brief' and 'search_gold_inventory' by focusing on signals and inventory retrieval.
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 retrieving signals) but does not explicitly state when to use it versus alternatives like 'search_gold_inventory' or 'get_gold_brief'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Thin wrapper for GET /ripple/index. Paid endpoint currently priced at $0.01; returns location-only Ripple index cards with signal IDs, bands, and unlock URLs while withholding companies, employee counts, commercial angles, and impact paths.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Optional region, state, or broad signal search query. | |
| limit | No | Maximum index cards to return. Hosted API caps this at 25. | |
| scope | No | Index scope. Defaults to all on the hosted API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the transparency burden. It discloses that the endpoint is paid ($0.01), that only location-only cards are returned, and that specific fields are withheld. This goes well beyond a generic wrapper description, though it does not mention rate limits, pagination, or error behavior.
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, information-dense sentence that front-loads the HTTP method and endpoint, then efficiently lists pricing, included fields, and excluded fields. No redundancy or filler words are present.
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 tool with three optional parameters and no output schema, the description adequately conveys the return payload (signal IDs, bands, unlock URLs) and the notable cost. While it could mention pagination or response structure, the schema already notes the limit cap, and the description is sufficiently complete for a thin wrapper.
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 descriptive entries for q, limit, and scope, so the baseline is 3. The description does not elaborate on parameter semantics beyond what the schema already provides, which is acceptable given the high 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 clearly identifies the tool as a thin wrapper for GET /ripple/index and specifies exactly what it returns (location-only Ripple index cards with signal IDs, bands, unlock URLs) while withholding companies, employee counts, commercial angles, and impact paths. This distinct scope separates it from sibling tools like get_gold_signals or search_company_context, which focus on different data.
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?
Usage is implied: if you need location-only Ripple index data, this is the tool. However, it does not explicitly state when to prefer this over alternatives, nor does it mention any exclusions or conditions where another sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an unpaid request to a paid endpoint and return the structured x402 payment challenge. Does not settle payment.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | No | Paid endpoint path to inspect. Defaults to /territory/77001/disruption?radius=50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool does not settle payment, which is a key behavioral trait. However, without annotations, it should also mention authentication needs, rate limits, or what happens if the endpoint is not paid. The description provides minimal additional behavioral context beyond the main action.
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 extremely concise, using two sentences and 17 words. It front-loads the primary action and immediately clarifies the key constraint (does not settle payment). Every sentence is necessary and 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?
For a simple tool with one parameter and no output schema, the description is fairly complete. It covers purpose and the main behavioral constraint. However, it could be improved by explaining the structure of the returned challenge or additional behavior when the endpoint is invalid, but given the simplicity, it is adequately 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?
Schema description coverage is 100%, so baseline is 3. The description adds context about the default endpoint value, but does not significantly enhance understanding beyond what the schema already provides. No new meaning is added.
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: making an unpaid request to a paid endpoint to return a structured x402 payment challenge. It specifies the action (inspect), resource (x402 challenge), and a key constraint (does not settle payment), which effectively distinguishes it from sibling tools that focus on analysis, metadata, or status.
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 inspecting payment challenges without settling, but it lacks explicit guidance on when to use this tool versus alternatives like 'analyze_territory_disruption' or 'get_company_risk_summary'. No exclusions or when-not-to-use scenarios are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Thin wrapper for GET /companies/search?q=. Paid endpoint; returns x402 challenge in default non-settling mode.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Company search query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the endpoint, payment requirement, and x402 challenge response. Without annotations, this partially fulfills transparency. Missing details on success response, rate limits, or behavior changes when settled.
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 concise sentences with no filler. The first states purpose, the second critical behavioral notes. Every word 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 one parameter, no output schema, and no annotations, the description covers core functionality and a key failure mode. However, it lacks output structure details, which would help an AI agent anticipate the response format.
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?
Only parameter 'q' is documented in the schema with a basic description. The tool description adds no additional meaning beyond what the schema already provides. Schema coverage is 100%, 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?
Description clearly identifies the tool as a search wrapper for companies via the specified endpoint, distinguishing it from sibling tools like get_company_risk_summary. The verb 'search' and resource 'companies' are explicit, but 'thin wrapper' is vague.
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?
Mentions cost and potential 402 error, which are important usage conditions. However, it does not explicitly state when to use this tool over siblings (e.g., for raw search before risk summary) or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compatibility tool for free inventory-only Ripple Signal search. Returns counts and unlock pricing without revealing signal details.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Optional commercial angle, company, region, or industry search query. |
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 discloses that the tool returns counts and pricing without revealing details, but it does not discuss side effects, permissions, rate limits, or any other behavioral traits. The term 'Compatibility tool' is vague.
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 sentence that is concise and to the point. It communicates the key purpose and output without unnecessary words, though it could be more front-loaded by starting with the core action.
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 optional parameter and no output schema, the description covers the basic purpose and output. However, it lacks behavioral details and error handling, which would be important for an agent to use it effectively.
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. The description adds context about the tool's overall function (free inventory-only search) but does not add specific parameter-level information beyond what the schema already provides.
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: returning counts and unlock pricing for free inventory-only Ripple Signal search. It also hints at differentiation by noting it does not reveal signal details, which distinguishes it from sibling tools like get_gold_signals.
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 (free inventory-only search) and suggests not revealing signal details, but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools target distinct resources (territory, company, event, gold, metadata) with clear descriptions, but many paid endpoints share identical challenge-return behavior, which could cause confusion if agents rely on response patterns.
All names use snake_case with a consistent verb_noun pattern (e.g., get_company_risk_summary). Minor inconsistency: some use 'gold' as an infix rather than suffix, but it's not disruptive.
13 tools cover the main areas of the API: status, metadata, territories, companies, events, ripple reports, and payment handling. This is well-scoped for a specialized intelligence service.
Covers querying and discovery well, but lacks tools for settling x402 payments or managing data (no create/update/delete). The workflow is incomplete without external payment handling.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Let AI agents query data and act across all your business apps via MCP.
Intelligence subscription protocol for AI agents. Scored, filtered AI intelligence signals via MCP.
Paid token risk and security intelligence for AI agents over MCP with x402 payments.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/forgemeshlabs/disruption-intelligence-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
