Intelica MCP Server provides competitive intelligence for autonomous AI agents, delivering structured JSON market analysis of URLs or company descriptions. Key capabilities:
Analyze a single competitor (analyze_competitor, $0.05–$1.00 USDC): Submit a URL or text to get structured insights including company positioning, target customers, value propositions, detected competitors, unique differentiators, battlecard, market score, and brand tone. Supports 10 specialized modes: competitive, sales_enablement, fundraising, partnership, acquisition, market_entry, crypto_protocol, venture_screening, regulatory_compliance, and risk_assessment. Supports optional HTML output and cache bypass.
Batch analyze up to 10 competitors in parallel (batch_analyze, $0.20 USDC flat): More cost-effective than individual calls for analyzing multiple entities simultaneously.
Free demo analysis (demo_analyze, free): Limited analysis for short text descriptions (max 300 characters) — useful for testing before using paid features.
Check pricing & configuration (get_pricing, free): Retrieve live pricing, payment wallet address, network (Base or Solana mainnet), asset (USDC), and protocol (x402) details.
Payment is handled via USDC on Base or Solana mainnet using the x402 protocol — no accounts or API keys required.
Competitive intelligence for autonomous AI agents — pay $0.05–$1.00 USDC per analysis via x402. No accounts, no API keys.
Analyze any URL or company description and get structured JSON with market positioning, competitors, moat scoring (IMI), and an executable action plan — all in one call.
{
"trace_id": "uuid-v4",
"span_metadata": { "service.name": "intelica", "intelica.latency_ms": 1240, "..." },
"intelica_moat_index": 0.72,
"decision_recommendation": { "action": "partner", "confidence_score": 0.85, "risk_level": "medium" },
"action_plan": {
"objective": "Structure partnership with Stripe within 21 days",
"steps": [
{ "step": 1, "action": "Run partnership analysis", "owner": "bd", "deadline_days": 7, "tool_hint": "POST /intel mode=partnership" },
{ "step": 2, "action": "Define integration surface", "owner": "product", "deadline_days": 14 }
],
"sop_version": "1.0"
},
"next_action_trigger": { "recheck_in_days": 21, "pulse_available": true }
}Related MCP server: hyperd-mcp
# 1. Get a free trial key (5 calls)
curl https://api.intelica.dev/api-keys/trial
# 2. Analyze any company
curl -X POST https://api.intelica.dev/intel \
-H "X-API-KEY: ikey_trial_..." \
-H "Content-Type: application/json" \
-d '{"text": "Stripe payment API for developers", "mode": "competitive"}'npx -y @smithery/cli install @teodorofodocrispin-cmyk/intelica-mcphttps://api.intelica.dev/mcpTransport: HTTP JSON-RPC 2.0. Tools: intel_analyze, intel_batch, intel_demo.
Mode | Price | Model |
Standard (competitive, market_entry, fundraising…) | $0.05 USDC | claude-haiku |
Elite (regulatory_compliance, venture_screening, risk_assessment…) | $1.00 USDC | claude-sonnet |
Batch (up to 10 companies) | $0.20 USDC | claude-haiku |
Trial | Free (5 calls) | claude-haiku |
x402 — autonomous USDC on Base or Solana (agents pay per call, no setup)
X-API-KEY — pre-loaded USDC balance (best for pipelines)
Trial key — 5 free calls, no wallet: GET https://api.intelica.dev/api-keys/trial
trace_id — UUID v4 per request for log correlation
span_metadata — OpenTelemetry-compatible (Datadog, Honeycomb, Grafana-ready)
action_plan — SOP with actionable steps, owners, deadlines per decision
decision_recommendation — enter / avoid / monitor / acquire / partner
next_action_trigger — tells agents when to re-call
sources_cited — verified URLs for every claim
Competitive Graph — 3,744+ companies benchmarked
Analyzes a competitor's URL or text description and returns structured competitive intelligence as JSON.
Cost: $0.05 USDC per call, paid automatically via x402 on Base mainnet. Response time: 2-5 seconds (first call), <1 second (cached within 6 hours).
Returns a JSON object with these fields:
company_or_product (str): Identified name of the company or product
positioning_summary (str): 2-3 sentence description of market positioning
target_customer (str): Primary customer segment being targeted
core_value_props (list[str]): Top 3 value propositions
user_pain_points (list[str]): Top 3 problems users experience
detected_competitors (list[str]): Up to 6 detected competitors
unique_angle (str): One specific differentiator or exploitable gap
tone (str): Brand tone — "professional", "casual", "technical", or "aggressive"
confidence (str): Analysis confidence — "high", "medium", or "low"
Parameters:
url: Full URL of the product or company to analyze (e.g. "https://notion.so"). The server fetches and parses the page automatically.
text: Raw text description to analyze (alternative to url). Minimum 50 characters for reliable results.
context: Optional context about your own product or use case. Example: "I'm building a note-taking app for developers." Providing context improves the relevance of unique_angle.
At least one of url or text is required.
Example usage:
analyze_competitor(url="https://linear.app")
analyze_competitor(text="Figma is a collaborative design tool for product teams")
analyze_competitor(url="https://notion.so", context="Building a wiki tool for engineers")
Note: Results are cached for 6 hours. Repeated calls for the same input return instantly at the same price.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| text | No | ||
| context | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses cost, response time, caching, and output structure. It also specifies constraints like minimum text length and the need for at least one of url or text.
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?
Well-structured with sections and bullet points, but slightly verbose. Could be tightened without losing 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?
Covers all aspects: input options, constraints, output fields, caching, cost, and timing. No gaps given the tool's complexity and presence of output schema.
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 0%, but the description explains each parameter in detail, including examples, conditions (e.g., minimum 50 chars for text), and the optional context parameter. Adds substantial meaning beyond the schema types.
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 analyzes a competitor's URL or text description and returns structured competitive intelligence. While it doesn't explicitly differentiate from sibling tools, the purpose is specific and unambiguous.
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 examples, caching behavior, and required input conditions. However, lacks when-not-to-use or direct comparison to alternatives like batch_analyze.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyzes up to 10 competitors in parallel in a single call.
Cost: $0.20 USDC flat for the entire batch (regardless of item count), paid automatically via x402 on Base mainnet. More efficient than calling analyze_competitor 10 times ($0.50 USDC).
Each item in the batch is processed in parallel, so total time is similar to a single analysis (2-5 seconds) regardless of batch size.
Returns a JSON object with:
results (list): Array of analysis results, one per item
id (str): The id you provided, or the item index as string
source (str): The url or "provided_text"
analysis (object): Same structure as analyze_competitor output
cached (bool): Whether this result was served from cache
total (int): Number of items processed
cached (int): Number of items served from cache
response_ms (int): Total processing time in milliseconds
price_paid_usdc (str): Total price paid ("0.20")
Parameters:
items (list[dict]): List of up to 10 analysis requests. Each item can have:
url (str, optional): URL to analyze
text (str, optional): Text description to analyze
context (str, optional): Your product context for relevance
id (str, optional): Identifier to track items in the response
Example usage: batch_analyze(items=[ {"url": "https://notion.so", "id": "notion"}, {"url": "https://coda.io", "id": "coda"}, {"text": "Obsidian is a local-first note-taking app", "id": "obsidian"}, ])
Best for:
Due diligence: analyze all competitors in a market in one call
Weekly monitoring: check 5-10 competitors every Monday
Market mapping: build a full competitive landscape in seconds
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: parallelism, flat cost ($0.20), payment method (x402 on Base mainnet), caching behavior, and return structure. It covers performance (2-5 seconds), item limits, and cost comparison, leaving no ambiguity about how the tool behaves.
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 lengthy but well-structured with clear sections (cost, performance, returns, parameters, example, best for). The core purpose is front-loaded. Minor redundancy (e.g., repeated cost mention) prevents a 5, but it earns its length.
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 low parameter count (1), rich output schema, and absence of annotations, the description covers all necessary context: inputs, outputs, behavior, cost, timing, and use cases. No gaps are apparent.
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 0%, but the description thoroughly documents each parameter in 'items': url, text, context, id, with types, optionality, and an example. This adds full semantic meaning beyond the bare-bones 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 starts with 'Analyzes up to 10 competitors in parallel in a single call,' which provides a specific verb (analyzes), resource (competitors), and scope (up to 10, parallel, single call). It distinguishes from sibling 'analyze_competitor' by highlighting efficiency and cost benefits, making the purpose crystal clear.
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 compares to 'analyze_competitor' and includes a 'Best for' section listing scenarios like due diligence and weekly monitoring. It lacks explicit when-not-to-use or alternatives beyond the sibling, but the comparison and use cases provide strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a free competitive intelligence analysis on a short text description.
No payment required. Limited to 300 characters of text input. Does not support URL fetching (use analyze_competitor for URLs). Results may be cached from previous calls.
Returns the same JSON structure as analyze_competitor:
company_or_product, positioning_summary, target_customer, core_value_props, user_pain_points, detected_competitors, unique_angle, tone, confidence
Parameters:
text (str): Text description of the product or company to analyze. Maximum 300 characters. For longer texts or URL analysis, use analyze_competitor (paid, $0.05 USDC).
Example usage: demo_analyze(text="Linear is a fast project management tool for software teams") demo_analyze(text="Stripe is a payment processing platform for developers")
Note: This is a demonstration endpoint. For production agent workflows, use analyze_competitor or batch_analyze with x402 payment.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavioral traits: free, 300 char limit, no URL support, caching, return structure. This is thorough for a simple tool.
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?
Well-structured with sections, bullet points, and examples. Every sentence adds value; no redundancy. The length is appropriate for the content.
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?
Despite no annotations and a single parameter, the description covers purpose, usage, limitations, alternatives, caching, and return fields. It is complete for both human and agent understanding.
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 has 0% coverage (no description for 'text'), but the description fully explains the parameter: type (string), purpose, max length (300 chars), and provides two examples. This compensates completely.
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 runs a free competitive intelligence analysis on a short text description, specifying the resource (text analysis), verb (run analysis), and scope (free, 300 chars). It also distinguishes from siblings like analyze_competitor (paid, URLs) and batch_analyze.
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?
Explicitly provides when to use (free, short texts) and when not to use (URLs, longer texts), with clear alternatives (analyze_competitor, batch_analyze). It also mentions caching and payment requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns current pricing, available endpoints, network configuration, and wallet addresses for the Intelica API.
Free to call — no payment required.
Returns a JSON object with:
single (object): Pricing for POST /intel (single analysis)
price (str): "$0.05 USDC"
max_items (int): 1
batch (object): Pricing for POST /batch (batch analysis)
price (str): "$0.20 USDC"
max_items (int): 10
demo (object): Pricing for POST /demo (free demo)
price (str): "free"
limit (str): "300 chars, no URL"
network (str): Payment network in CAIP-2 format ("eip155:8453" = Base mainnet)
pay_to (str): EVM wallet address receiving payments
asset (str): Payment asset ("USDC")
protocol (str): Payment protocol ("x402")
Use this tool to:
Verify current prices before making calls
Get the wallet address for manual payment verification
Confirm network and asset configuration
Example usage: get_pricing()
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it's free to call and details the return structure with examples. This adds significant behavioral context beyond the empty schema.
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 well-structured with bullet points and clear sections. While slightly verbose with full output examples, it remains focused and front-loads the purpose. Could be trimmed slightly.
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 parameters and no annotations, the description is fully complete. It explains the entire JSON output structure with types and example values, leaving no ambiguity for the 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?
Zero parameters, so baseline is 4. The description does not need parameter elaboration. Schema coverage is 100% vacuously.
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 returns pricing, endpoints, network config, and wallet addresses. It distinguishes itself from analysis sibling tools by being informational. The verb 'get' and resource 'pricing' are specific.
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 lists explicit use cases: verify prices, get wallet address, confirm network/asset. No exclusions are needed since it's a unique informational tool. The guidance is clear but could mention when not to use (e.g., no pricing needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0analyze_competitorbatch_analyzedemo_analyzeget_pricingAll four tools have clear, non-overlapping purposes: single paid analysis, batch analysis, free demo analysis, and pricing info. No ambiguity between them.
Most names follow a verb_noun pattern (analyze_competitor, get_pricing), but 'batch_analyze' and 'demo_analyze' place the verb after a modifier, creating a minor inconsistency.
With 4 tools, the server covers its core domain of competitive analysis without bloat, though a few more specialized tools (e.g., trend analysis) might be expected for completeness.
The tool surface covers all essential operations: single and batch analysis, a free trial, and pricing information. No obvious gaps for its stated purpose.
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
Pay-per-call crypto market intelligence for AI agents. USDC on Base via x402.
x402-paid analytics, market intelligence, research, and LLM inference for AI agents.
Pay-per-call (x402/USDC-Base) web + crypto data tools for AI agents: audit, extract, crypto, DeFi.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/teodorofodocrispin-cmyk/intelica-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
