Technology Convergence Disruption MCP Server

Technology convergence disruption intelligence — quantified across 14 live data sources and eight statistical models — now available as a Model Context Protocol server your AI agent calls directly. Connect Claude Desktop, Cursor, or any MCP-compatible client to detect cross-domain patent convergence 3-5 years before it reaches mainstream awareness, trace academic-to-commercial knowledge cascades, and score industries against the Christensen disruption framework from a single endpoint.

This server orchestrates parallel calls to USPTO and EPO patent databases, OpenAlex, Semantic Scholar, arXiv, Crossref, GitHub, Stack Overflow, Hacker News, NIH grants, job market data, EUIPO trademarks, ORCID researcher profiles, and company deep research. Each tool call gathers the appropriate data and feeds results through purpose-built statistical algorithms: bipartite projection cosine similarity for patent convergence, branching process models for knowledge cascades, log-logistic diffusion curve fitting for adoption velocity, Fiedler spectral clustering for skill transitions, and ARDL time-series regression for funding leading indicators.

What data can you access?

Why use the Technology Convergence Disruption MCP Server?

Strategy teams, venture capital analysts, and R&D directors typically spend weeks manually triangulating patent filings, academic citation trends, developer ecosystem signals, and labor market shifts to identify where disruption is forming. The data lives in a dozen separate databases — each requiring its own API account, rate-limit handling, and custom parsing logic. Cross-domain pattern recognition, the part that actually signals disruption 3-5 years early, demands statistical methods most teams lack time to implement.

This server automates the full pipeline. A single tool call gathers data from up to 14 sources in parallel, runs the appropriate statistical model, and returns structured output your AI agent can reason over immediately.

• Scheduling — run weekly patent convergence scans or monthly landscape reports to track technology trajectories over time
• API access — trigger any of the eight tools from Python, JavaScript, or any MCP-compatible HTTP client
• Parallel data collection — up to 14 actor calls run concurrently per request using Promise.all, cutting latency vs. sequential queries
• Monitoring — configure Apify alerts when runs fail or return unexpected output for production pipeline reliability
• Integrations — connect to Claude Desktop, Cursor, LangChain, LlamaIndex, Zapier, or any webhook-capable system

Features

• Bipartite patent convergence analysis — builds a bipartite graph B(patents, IPC codes), projects onto IPC subclass space, and computes temporal cosine similarity between adjacent 3-year windows. Returns up to 50 ranked convergence pairs with delta similarity, convergence acceleration, and estimated lead-time years.
• 8 IPC domain sections mapped — filings normalized across sections A through H (Human Necessities, Chemistry, Physics/Computing, Electricity/Electronics, etc.) for human-readable domain labels in all output.
• Branching process cascade model — computes branching ratio r = average patent citations per academic paper per topic. Supercritical (r > 1) signals explosive commercial adoption; subcritical (r < 1) indicates dying research lines. Cascade depth computed via log2 citation chain depth.
• Log-logistic diffusion curve fitting — fits F(t) = 1 / (1 + (t/alpha)^(-beta)) to GitHub star and Stack Overflow question time series using linearized OLS regression. Returns alpha (median adoption time), beta (steepness), velocity dF/dt, and acceleration d²F/dt².
• Fiedler spectral skill clustering — constructs a skill co-occurrence adjacency matrix from job postings (capped at 100 skills for tractable computation), computes graph Laplacian L = D - A, and extracts the Fiedler vector via deflated power iteration. Cluster sign partition identifies emerging vs. declining skill groups. Predicts convergence timing from cluster merger rate.
• Christensen disruption scoring — operationalizes the disruption framework as: score = convergence_velocity * market_size / (incumbent_response + patent_moat + talent_pool). Five Christensen factors decomposed per technology: new market creation, low-end entry, sustaining innovation gap, talent migration, and technology overshoot.
• ARDL funding leading indicator — fits an Autoregressive Distributed Lag model Y_t = alpha + sum(beta_i * Y_{t-i}) + sum(gamma_j * X_{t-j}) to NIH grant and patent time series. Computes long-run multiplier = sum(gamma) / (1 - sum(beta)) and error correction speed phi. Requires minimum 5 yearly observations.
• Technology landscape profiler — aggregates 7 sources in one parallel call (patents, OpenAlex, arXiv, GitHub, jobs, NIH grants, Hacker News) and classifies each technology by maturity stage: emerging, growing, mature, or declining based on patent count thresholds and year-over-year trend.
• Full disruption brief synthesis — runs all six analytical models, synthesizes results into sections with per-section confidence scores (0-1), data point counts, an executive summary, a time horizon estimate, and ranked strategic recommendations. Standard depth: 50 results per source; deep: 100+ per source.
• Spend limit enforcement — every tool call checks the per-event charge limit before execution. Runs stop cleanly when the budget ceiling is reached, never silently over-spending.
• Parallel actor orchestration — runActorsParallel dispatches all data source calls via Promise.all and returns results in index-aligned arrays for deterministic downstream assembly.

Use cases for technology disruption analysis

Strategic foresight and technology roadmapping

Corporate strategy teams need to identify technology convergence 3-5 years before it reaches mainstream awareness. Patent cosine similarity acceleration across IPC sections provides a quantitative leading indicator that is harder to manipulate than analyst consensus. Feed monthly convergence scans to your AI assistant and build a living technology roadmap grounded in patent network dynamics rather than industry conference hype.

Venture capital deal sourcing

Early-stage investors screening sectors need to distinguish genuine disruption from momentum. The Christensen disruption score decomposes market opportunity against incumbent defense strength — giving analysts a number to pressure-test their qualitative thesis before committing capital. Combine with the adoption velocity curve to identify technologies in the growth phase (penetration 10-50%) before they saturate and valuations peak.

Corporate R&D portfolio allocation

R&D directors allocating budgets across technology bets can use ARDL funding analysis to see which research areas historically translate to commercial patent activity and at what lag. A long-run multiplier above 2.0 for a given research area means every dollar of NIH grant funding has historically driven two-plus dollars of downstream commercial patent output. Prioritize investments with proven funding-to-commercialization conversion rates.

Workforce planning and skills forecasting

HR and talent strategy leaders planning skill acquisition need to know which skill clusters are merging before the job market fully prices in the transition. Spectral clustering on job posting co-occurrence data identifies emerging and declining skill groups with an estimated convergence timing in years. Use the output to plan hiring campaigns and reskilling programs ahead of the market signal.

Academic technology transfer offices

Research commercialization teams can use the knowledge cascade model to identify which research topics are approaching supercritical branching ratio (r approaching 1.0). Topics near the threshold are primed for patent licensing activity and startup formation. Inflection proximity scores help prioritize commercialization resource allocation across a research portfolio.

Competitive intelligence for technology incumbents

Established companies defending market positions can use disruption risk scores to quantify the threat from converging adjacent technologies. The incumbent defense metric — patent filing concentration (HHI), talent pool depth, and job posting volume — surfaces where defensive moats are thinnest relative to attacker convergence velocity, enabling targeted R&D or M&A response.

How to connect the Technology Convergence Disruption MCP Server

1. Get your Apify API token — go to Apify Console > Settings > Integrations and copy your token.
2. Add the server to your MCP client — paste the configuration below for Claude Desktop, Cursor, or your preferred client.
3. Run your first tool call — ask your AI assistant: "Detect technology convergence in quantum computing with 3-year temporal windows." Results return within seconds.
4. Explore the full suite — progress from convergence detection to knowledge cascade to disruption brief for increasing analytical depth.

MCP tools

Tool reference

detect_technology_convergence — Queries USPTO and EPO in parallel (up to 200 patents each), normalizes IPC codes to subclass level (4-character), builds per-window co-occurrence matrices via bipartite projection, and computes temporal cosine similarity between adjacent windows. Returns up to 50 convergence pairs ranked by delta similarity, top-10 converging domains, and average convergence rate.

trace_knowledge_cascade — Queries OpenAlex, Semantic Scholar, arXiv, Crossref, and USPTO in parallel. Matches paper titles against patent citation reference strings to compute per-topic branching ratios. Returns up to 30 topics ranked by inflection proximity score (cascade depth × log2(breadth + 1)), with regime classification: supercritical (r > 1), critical (0.8 ≤ r ≤ 1), or subcritical (r < 0.8).

measure_adoption_velocity — Queries GitHub (sorted by stars) and Stack Overflow for each search term. Aggregates Stack Overflow questions by calendar month. Fits a log-logistic diffusion curve via linearized OLS on log-transformed time series. Returns per-technology alpha, beta, current penetration [0,1], velocity dF/dt, acceleration d²F/dt², and phase classification.

map_skill_transitions — Queries job market data and supplements with Hacker News hiring discussions. Extracts technology terms from HN text via pattern matching. Caps the adjacency matrix at 100 skills for tractable Fiedler vector computation via deflated power iteration. Returns two spectral clusters with emerging and declining skill sub-lists, Fiedler gap eigenvalue, and convergence timing estimate in years.

score_disruption_risk — Queries USPTO, job market intel, and company deep research for each input technology. Derives convergence velocity from IPC section diversity (count of unique sections A-H, normalized to [0,1] over 8 sections). Computes HHI citation concentration from patent applicant distribution. Applies Christensen disruption formula and returns per-technology factor decomposition with composite score 0-100 and risk level.

predict_from_research_funding — Queries NIH grants, USPTO patents, and OpenAlex papers per research area. Aligns annual grant amounts and patent counts into time series from 2000 onward. Solves ARDL OLS coefficients via Gauss elimination with up to maxLag years. Requires at least 5 annual observations for model estimation. Returns long-run multiplier, error correction speed phi, and leading indicator ranking.

profile_technology_landscape — Runs 7 actor calls in a single parallel batch (patents, OpenAlex, arXiv, GitHub, job market, NIH grants, Hacker News) and classifies each sub-technology by maturity stage. Maturity thresholds: emerging < 10 patents; growing 10-50; mature 50-200; declining = year-over-year decline in filings. Includes cross-source composite scores.

generate_disruption_brief — Runs all 6 analytical models plus the landscape profiler in sequence. Gathers data from up to 14 sources concurrently. Synthesizes results into an executive brief with sections covering convergence, cascade, adoption, skills, disruption risk, and funding indicators — each with a confidence score (0-1) and data point count. Standard depth: 75 results per source; deep: 150 per source.

Input parameters

Input tips

• Start with detect_technology_convergence — it is the fastest tool and gives immediate signal on whether a technology is converging with adjacent domains before running the more compute-intensive models.
• Use windowYears: 5 for slow-moving fields — biotech and materials science patent cycles are longer than software. A 3-year window may miss meaningful signals; 5 years captures more co-occurrence history per window.
• Batch multiple technologies in score_disruption_risk — passing 5 technologies in one call is more efficient than 5 separate calls, since the disruption score normalization compares across the full technology set.
• Set maxLag: 2 for short ARDL datasets — if a research area has fewer than 10 years of NIH grant data, reduce maxLag to 2 to avoid rank deficiency in the OLS design matrix.
• Use depth: "deep" for generate_disruption_brief when completeness matters — standard depth completes in roughly 3-4 minutes; deep uses 150+ results per source and takes 6-8 minutes but produces higher-confidence cascade and convergence estimates.

Output example

detect_technology_convergence — quantum computing:

{
  "technology": "quantum computing",
  "pairs": [
    {
      "domainA": "G06N (Physics/Computing)",
      "domainB": "H01L (Electricity/Electronics)",
      "cosineSimilarity": 0.847,
      "deltaSimilarity": 0.0312,
      "convergenceAcceleration": 0.0089,
      "sharedPatentCount": 142,
      "leadTimeYears": 4
    },
    {
      "domainA": "G06N (Physics/Computing)",
      "domainB": "B82Y (Operations/Transport)",
      "cosineSimilarity": 0.721,
      "deltaSimilarity": 0.0241,
      "convergenceAcceleration": 0.0061,
      "sharedPatentCount": 87,
      "leadTimeYears": 6
    }
  ],
  "topConvergingDomains": [
    "G06N (Physics/Computing)",
    "H01L (Electricity/Electronics)",
    "B82Y (Operations/Transport)",
    "G06F (Physics/Computing)",
    "H04L (Electricity/Electronics)"
  ],
  "avgConvergenceRate": 0.0187,
  "bipartiteProjectionSize": 34,
  "temporalWindows": 7,
  "sourceCounts": { "uspto": 198, "epo": 176 }
}

generate_disruption_brief — large language models (excerpt):

{
  "technology": "large language models",
  "industry": "enterprise software",
  "executiveSummary": "LLMs show critical disruption risk (score 78/100) with supercritical academic cascade (avg branching ratio 1.34). Patent convergence accelerating between G06N and G06F. Skill cluster merger estimated 2.1 years. NIH/NSF funding long-run multiplier 3.2 — every $1M research grant historically yields $3.2M in downstream patent activity.",
  "timeHorizon": "18-30 months",
  "sections": [
    {
      "name": "Patent Convergence",
      "confidence": 0.82,
      "dataPoints": 312,
      "summary": "G06N/G06F cosine similarity delta +0.0312 per window, accelerating",
      "findings": ["IPC diversity: 7/8 sections active", "Lead time: 4 years on top pair"]
    },
    {
      "name": "Knowledge Cascade",
      "confidence": 0.74,
      "dataPoints": 840,
      "summary": "Supercritical branching ratio 1.34 across 22 topics",
      "findings": ["22 of 31 topics supercritical", "Max inflection proximity: 18.4"]
    }
  ],
  "recommendations": [
    "Accelerate R&D partnerships in G06N/G06F convergence zones",
    "Prioritize skill acquisition in emerging cluster: MLOps, RLHF, inference optimization",
    "Monitor ARDL long-run multiplier quarterly — currently 3.2x (high commercial translation)"
  ]
}

Output fields

detect_technology_convergence

trace_knowledge_cascade

measure_adoption_velocity

map_skill_transitions

score_disruption_risk

predict_from_research_funding

generate_disruption_brief

How much does it cost to run technology convergence analysis?

Each tool call charges a flat per-event fee. Platform compute costs are included. There are no subscription fees — you pay only for the analysis you run.

A complete analysis workflow — convergence scan + cascade trace + disruption brief — costs $0.27. Running a disruption brief daily on 5 technologies costs roughly $18/month. Compare this to analyst research tools at $500-2,000/month or bespoke consulting engagements at $10,000+.

You can set a maximum spending limit per run in the Apify console to control costs. The server stops cleanly when your budget ceiling is reached.

Connect via the API

Python

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")

# Start the MCP server actor in standby mode
run = client.actor("ryanclinton/technology-convergence-disruption-mcp").call(run_input={})

# Or call it directly via HTTP once the server is running
# POST https://technology-convergence-disruption-mcp.apify.actor/mcp
# with MCP JSON-RPC body and Authorization: Bearer YOUR_API_TOKEN
print(f"Server running at: https://technology-convergence-disruption-mcp.apify.actor/mcp")
print(f"Run ID: {run['id']}")

JavaScript

import { ApifyClient } from "apify-client";

const client = new ApifyClient({ token: "YOUR_API_TOKEN" });

// Start the server
const run = await client.actor("ryanclinton/technology-convergence-disruption-mcp").call({});

// The MCP endpoint is available at:
const mcpEndpoint = "https://technology-convergence-disruption-mcp.apify.actor/mcp";
console.log(`MCP endpoint: ${mcpEndpoint}`);
console.log(`Authorize with: Bearer YOUR_API_TOKEN`);

cURL (MCP tool call)

# Call detect_technology_convergence via MCP JSON-RPC
curl -X POST "https://technology-convergence-disruption-mcp.apify.actor/mcp" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "detect_technology_convergence",
      "arguments": {
        "technology": "quantum computing",
        "windowYears": 3,
        "maxPatents": 200
      }
    }
  }'

Claude Desktop configuration

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "technology-convergence-disruption": {
      "url": "https://technology-convergence-disruption-mcp.apify.actor/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_APIFY_TOKEN"
      }
    }
  }
}

Cursor configuration

Add to your Cursor MCP settings:

{
  "mcpServers": {
    "technology-convergence-disruption": {
      "url": "https://technology-convergence-disruption-mcp.apify.actor/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_APIFY_TOKEN"
      }
    }
  }
}

How the Technology Convergence Disruption MCP Server works

Phase 1 — Parallel data collection

Each tool call dispatches runActorsParallel, which wraps Promise.all over multiple ApifyClient.actor().call() invocations running simultaneously with 256 MB memory allocations. The generate_disruption_brief tool fires up to 14 actor calls in a single parallel batch — covering USPTO, EPO, OpenAlex, Semantic Scholar, arXiv, Crossref, NIH grants, GitHub, Stack Overflow, job market data, company research, Hacker News, EUIPO trademarks, and ORCID — and waits for all results before proceeding to scoring. Actor failures return empty arrays rather than throwing, so partial data still produces analysis.

Phase 2 — Data normalization

Raw actor output is normalized into typed internal records before scoring. Patent records are mapped to { id, title, abstract, ipcCodes[], filingDate, citations[], applicant, jurisdiction }. Academic papers are mapped to { id, title, topics[], citationCount, year, patentCitations }. This abstraction makes the scoring algorithms data-source-agnostic — the same bipartite projection runs identically whether the input came from USPTO, EPO, or a combination of both.

Phase 3 — Statistical scoring

Six purpose-built algorithms process the normalized data:

Bipartite projection convergence builds B^T * B co-occurrence matrices per temporal window, then computes pairwise cosine similarities between IPC subclass vectors across adjacent windows. Convergence pairs are ranked by delta similarity (change rate) and acceleration (second derivative of similarity). The lead time estimate uses windowYears / max(acceleration, 0.01).

Branching process cascade groups papers by topic and computes branching ratio r = total_patent_citations / paper_count per topic. The regime threshold (r = 1.0 for supercritical, r = 0.8 for critical) follows the standard epidemiological branching process model. Inflection proximity = cascadeDepth * log2(cascadeBreadth + 1) identifies topics closest to the commercial tipping point.

Log-logistic diffusion fitting linearizes F(t) = 1 / (1 + (t/alpha)^(-beta)) as log(F/(1-F)) = beta * log(t) - beta * log(alpha), then fits via OLS regression on GitHub star and Stack Overflow question time series. Alpha (median adoption time) is recovered as exp(-intercept / beta). Velocity and acceleration are computed analytically from the fitted parameters.

Fiedler spectral clustering builds a skill co-occurrence adjacency matrix from job posting co-mentions, computes the graph Laplacian L = D - A, and extracts the Fiedler vector via deflated power iteration: find dominant eigenvector v1, deflate as L' = L - lambda1 * v1 * v1^T, find dominant eigenvector of L' as the Fiedler vector. Skills are partitioned into two clusters by sign. Convergence timing is estimated from the cluster merger rate.

Christensen disruption scoring operationalizes the disruption score as: score = convergence_velocity * market_size / (incumbent_response + patent_moat + talent_pool). Convergence velocity is normalized IPC section diversity (unique A-H sections / 8). Patent moat uses Herfindahl-Hirschman Index (HHI) computed over patent applicant distribution.

ARDL funding indicator fits Y_t = alpha + sum_i(beta_i * Y_{t-i}) + sum_j(gamma_j * X_{t-j}) via Gauss elimination on the OLS normal equations. Long-run multiplier = sum(gamma) / (1 - sum(beta)). A multiplier above 1.0 means grant funding leads commercial patent activity; below 1.0 means the relationship is weak or negative.

Phase 4 — Output assembly and charging

Results are serialized to JSON via JSON.stringify(data, null, 2) and returned as MCP CallToolResult with a text content block. The Actor.charge() call happens before data collection — if the event limit is reached, the tool returns an error object immediately without executing the expensive parallel data collection.

Tips for best results

1. Pair detect_technology_convergence with score_disruption_risk — convergence detection tells you where domains are merging; disruption scoring tells you whether incumbents can defend. Running both on the same technology gives a complete offense/defense picture.
2. Use the Fiedler gap as a quality signal — a larger fiedlerGap eigenvalue in skill transition output indicates cleaner cluster separation and higher confidence in the emerging vs. declining classification. Values below 0.01 suggest insufficient skill co-occurrence data.
3. Interpret ARDL multipliers carefully on short series — the model requires at least 5 annual observations. Research areas with data only from 2020 onward will produce unreliable multipliers. Increase maxLag only when you have 8+ data points.
4. Run generate_disruption_brief with depth: "standard" first — at $0.12 per call, standard depth is sufficient for initial screening. Upgrade to deep only for technologies that pass the initial screen with high disruption scores.
5. Batch technologies for cross-comparison — the disruption score is normalized across all input technologies in a single score_disruption_risk call. Passing competing technologies together (e.g., ["LiDAR", "camera-only vision", "radar fusion"]) produces a relative ranking, not just absolute scores.
6. Schedule convergence scans monthly — patent filing patterns shift gradually. A single scan is a snapshot; monthly runs tracked over 6+ months reveal whether convergence is accelerating or decelerating.
7. Cross-validate cascade regime with adoption velocity — a supercritical branching ratio (r > 1) combined with a growth-phase adoption curve (penetration 10-50%) is the highest-confidence signal for near-term commercial disruption. Either signal alone is weaker.

Combine with other Apify actors

Limitations

• Patent data lag — USPTO and EPO publication data typically lags 12-18 months behind actual filing dates. Very recent convergence signals may not yet appear in the dataset.
• IPC matching accuracy — IPC code normalization uses the first 4 characters (subclass level). Fine-grained group-level distinctions (e.g., G06N 3/04 vs. G06N 3/08) are not resolved, which may merge distinct sub-technologies.
• Branching ratio title matching — knowledge cascade computation uses paper title string matching against patent citation references. Fuzzy matching is not implemented; variant titles reduce detected citation counts and may understate branching ratios.
• Fiedler vector stability — the spectral clustering uses deflated power iteration rather than full eigendecomposition. On dense adjacency matrices with near-equal second and third eigenvalues, the Fiedler vector may converge to a suboptimal partition.
• ARDL on short time series — research areas with fewer than 5 annual data points are excluded from ARDL estimation. Emerging research fields post-2020 will not produce funding leading indicator results.
• No JavaScript rendering — data collection uses API-based actors, not browser rendering. Company websites that require JavaScript for content may return incomplete data for market size proxies in disruption risk scoring.
• NIH grant bias — the funding leading indicator uses NIH grants as the primary research funding signal. Non-NIH-funded fields (defense technology, industrial R&D) will show artificially low multipliers. DARPA, NSF, and private funding are not captured.
• HN signal dilution — Hacker News data used for skill signals is discussion-weighted, not hiring-weighted. Niche technologies discussed heavily on HN may appear in skill clusters disproportionate to actual labor market demand.

Integrations

• Claude Desktop — add the server URL and API token to claude_desktop_config.json for conversational technology intelligence inside Claude
• Cursor — connect via MCP settings for technology disruption queries during code research and architecture work
• LangChain / LlamaIndex — call tools from agent pipelines for automated competitive intelligence workflows
• Apify API — trigger runs programmatically and retrieve results from the Apify dataset for integration into internal dashboards
• Webhooks — configure run-completion webhooks to push disruption brief results to Slack, Notion, or a custom endpoint
• Zapier — schedule weekly technology landscape scans and push results to Google Sheets, HubSpot, or email
• Make — build no-code automation workflows: trigger a disruption brief monthly and route high-risk findings to Slack or a CRM

Troubleshooting

Empty or near-empty pairs from detect_technology_convergence — this usually means the patent sources returned fewer than 2 results with usable IPC codes and filing dates. Verify the technology keyword is specific enough to return patent results (e.g., use "quantum error correction" rather than "quantum"). If USPTO returns data but EPO does not, check whether the EPO actor is currently available in your Apify account.

ARDL returns no leading indicators — the model requires at least 5 annual data points with non-zero grant and patent counts. For emerging fields, try reducing maxLag to 2 and ensure the research area string matches NIH grant terminology (e.g., "machine learning" rather than "AI" to match NIH grant abstracts more precisely).

Disruption score seems uniformly low across all technologies — the Christensen formula normalizes convergence velocity to [0,1] based on IPC section count (A-H). If the technology spans only 1-2 IPC sections, the score ceiling drops. Pass more specific sub-technologies (e.g., ["LiDAR sensor fusion", "solid-state LiDAR"]) rather than broad categories.

generate_disruption_brief times out on depth: "deep" — deep mode fires up to 14 parallel actor calls with 150 results each. If the run is hitting Apify's memory limit, reduce depth to "standard" or increase memory allocation to 512 MB in the actor settings.

Fiedler clustering returns single cluster — this occurs when the skill adjacency matrix has fewer than 2 connected skills. The actor caps at 100 skills to keep matrix operations tractable; if job posting data returns very few skills per posting, the graph may be too sparse for meaningful bipartition. Broaden the industry query string to capture more job postings.

Responsible use

• This server only accesses publicly available patent, academic, and labor market data through official APIs and registered data sources.
• USPTO, EPO, NIH grants, and academic databases are queried within their published terms of service.
• Disruption risk scores and convergence predictions are statistical estimates, not investment advice. Do not make financial or strategic decisions based solely on this output without human review.
• Do not use this server to generate misleading competitive intelligence reports or to make false claims about technology capabilities.
• For guidance on data use and web scraping legality, see Apify's guide.

FAQ

How does technology convergence detection work? The server builds a bipartite graph connecting patents to their IPC classification codes, projects it onto the IPC subclass space to create a co-occurrence matrix, and computes cosine similarity between IPC code vectors across 3-year temporal windows. Pairs where cosine similarity is increasing — and especially where the increase itself is accelerating — indicate cross-domain convergence. A lead time estimate of 4-6 years means the patent signal is running 4-6 years ahead of commercial mainstream adoption.

How many data sources does each tool call? Between 2 and 14 depending on the tool. detect_technology_convergence calls 2 (USPTO + EPO). trace_knowledge_cascade calls 5 (OpenAlex, Semantic Scholar, arXiv, Crossref, USPTO). generate_disruption_brief calls all 14 sources simultaneously. All calls within a tool run in parallel via Promise.all.

How accurate is the Christensen disruption score? The disruption score operationalizes the Christensen framework using observable proxies: IPC diversity for convergence velocity, HHI for patent moat, job posting volume for talent pool. It is a quantitative approximation, not a validated predictive model. Treat scores as relative rankings within a comparison set rather than absolute predictions. A score of 75+ (critical) means the attacker-side signals meaningfully outweigh the incumbent defense signals.

What is a supercritical branching ratio and why does it matter? A branching ratio r > 1 means each academic paper in a research topic generates, on average, more than one patent citation. In branching process theory, r > 1 produces explosive, super-exponential growth — the research is translating to commercial activity faster than it is being consumed. For technology transfer and venture investing, topics at r ≥ 1 are primed for rapid commercialization.

How long does a typical tool call take? Single tools (detect_technology_convergence, measure_adoption_velocity) complete in 30-90 seconds depending on actor response times. profile_technology_landscape and generate_disruption_brief with depth: "standard" typically complete in 3-4 minutes. Deep brief mode takes 6-8 minutes.

Can I schedule this server to run weekly analysis automatically? Yes. Use Apify's built-in scheduler to trigger runs on any cron schedule. The standby mode means the server is always warm and responds immediately to MCP connections. You can also configure a webhook to push results to Slack, Notion, or a Google Sheet when each run completes.

How is this different from traditional technology intelligence tools like Patsnap or Derwent Innovation? Traditional patent intelligence tools focus on patent search and visualization within the patent database. This server combines patent convergence analysis with academic cascade modeling, developer adoption curves, job market skill clustering, and research funding leading indicators — all synthesized in a single AI-callable tool. It is designed for AI agents to call programmatically, not for human analysts to browse.

Is it legal to scrape patent and academic data this way? Yes. This server queries official APIs: USPTO's PatentsView API, EPO's Open Patent Services, NIH's Reporter API, OpenAlex's public REST API, and other publicly documented endpoints. No web scraping or terms-of-service violations are involved. See Apify's guide on web scraping legality for broader context.

What happens if one of the 14 data sources is unavailable? Each actor call is wrapped in a try-catch that returns an empty array on failure. The scoring algorithms handle empty arrays gracefully — they return zero-value or minimal results for the affected dimension rather than throwing. The disruption brief will still produce output, with lower confidence scores reflecting the missing data source.

Can I use this server with an OpenAI-based agent or only Claude? Any MCP-compatible client can connect, including OpenAI-based agents that support the Model Context Protocol. The server speaks standard MCP JSON-RPC over HTTP at the /mcp endpoint. If your framework supports MCP server configuration (LangChain, LlamaIndex, CrewAI), you can integrate it directly.

How does the ARDL funding model predict disruption? The ARDL model fits a distributed lag regression between annual NIH grant funding (leading variable X) and annual patent filings (lagged outcome Y). The long-run multiplier (sum of gamma coefficients / error correction speed) quantifies how much commercial patent activity follows per dollar of research funding over time. A multiplier of 3.0 means $1 of grant funding historically predicts $3 of commercial patent output at the estimated lag.

What is the minimum data needed for meaningful results? detect_technology_convergence needs at least 5-10 patents with IPC codes and filing dates spanning 2+ temporal windows. trace_knowledge_cascade needs papers with citation counts and patents with reference lists. predict_from_research_funding requires 5+ annual data points. If a technology is too new to meet these thresholds, start with measure_adoption_velocity, which can produce a curve from as few as 5-10 GitHub repos.

Help us improve

If you encounter issues, you can help us debug faster by enabling run sharing in your Apify account:

1. Go to Account Settings > Privacy
2. Enable Share runs with public Actor creators

This lets us see your run details when something goes wrong so we can fix issues faster. Your data is only visible to the actor developer, not publicly.

Support

Found a bug or have a feature request? Open an issue in the Issues tab on this actor's page. For custom analysis workflows, enterprise integrations, or additional data source coverage, reach out through the Apify platform.