Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Big Technology Podcast MCP Search for episodes about AI regulation"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Search 488 episodes of Big Technology Podcast transcripts directly from Claude. Get instant access to tech insights, news, and commentary from Alex Kantrowitz and his guests.
Created by Ranjan Roy, co-host of Big Technology Podcast šļø
This repository contains everything you need:
ā Complete MCP server code
ā 488 podcast transcripts (13.9MB)
ā Full documentation and setup guides
ā Ready to use immediately!
No need to source transcripts separately - they're included with permission.
Related MCP server: YouTube Knowledge Base
Clone and install:
git clone https://github.com/ranjanroy/big-tech-mcp.git
cd big-tech-mcp
npm install
npm run buildYou're done! The transcripts are already included.
For Claude Desktop:
Open Claude Desktop settings
Go to Settings ā Connectors ā Add custom connector
Add a local connector pointing to your installation
Or add to your claude_desktop_config.json:
{
"mcpServers": {
"big-tech-transcripts": {
"command": "node",
"args": ["/path/to/big-tech-mcp/dist/index.js"],
"env": {
"BIG_TECH_TRANSCRIPTS_PATH": "/path/to/transcripts.json"
}
}
}
}For Claude Code CLI:
# From the big-tech-mcp directory
claude mcp add -t stdio big-tech-transcripts "node dist/index.js"Then restart Claude Code.
Set up for hosted deployment:
# Copy transcripts to the project
cp ../transcripts.json ./
# Build the project
npm install
npm run build
# Run in server mode
npm run start:sseDeploy to Render.com (or similar):
The included render.yaml provides configuration
Set MCP_MODE=sse environment variable
Upload transcripts.json to your server
Connect from Claude.ai:
Go to Settings ā Connectors ā Add custom connector
Enter your server URL: https://your-server.com/mcp
Click Add and enable the connector
Deploy as a remote server (Option 2 above)
Go to Settings ā Apps ā Enable Developer Mode
Click Create App
Add a name and paste the URL: https://your-server.com/mcp
Save and start using it!
Once connected, try asking Claude things like:
"What has been said about AI regulation on Big Technology Podcast?"
"Search for episodes about OpenAI and Microsoft"
"What are the latest discussions on antitrust and big tech?"
"Find episodes featuring Mark Warner or other politicians"
"What do tech leaders say about content moderation?"
"Search for insights on the future of social media"
Tool | Description |
| Search all 488 episodes by topic/keyword |
| Get full transcript for a specific episode by title |
| List all available episodes with dates |
| Get the most recent episodes |
The server loads your transcripts.json file, indexes the episodes using FlexSearch for fast full-text search, and exposes four MCP tools that Claude can use to search and retrieve content.
# Install dependencies
npm install
# Build TypeScript
npm run build
# Run locally (stdio mode)
npm start
# Run as HTTP server
npm run start:sse
# Development mode (build + run)
npm run devbig-tech-mcp/
āāā src/
ā āāā index.ts # Main server and MCP tool definitions
ā āāā loader.ts # Transcript loading and processing
ā āāā search.ts # FlexSearch indexing and search logic
āāā public/ # Static files (icons, etc.)
āāā transcripts.json # Your podcast transcripts (not included)
āāā package.json
āāā tsconfig.json
āāā README.mdThe server expects a JSON file with this structure:
[
{
"podcast_title": "Big Technology Podcast",
"episode_title": "Episode Title Here",
"date": "2025-01-15",
"episode_description": "Description here",
"full_transcript": "Full transcript text...",
"url": "https://podscripts.co/podcasts/...",
"scraped_at": "2025-01-15T12:00:00Z"
}
]BIG_TECH_TRANSCRIPTS_PATH: Path to your transcripts.json file (local mode)
MCP_MODE: Set to sse for HTTP server mode, omit for stdio mode
PORT: Port for HTTP server (default: 3000)
Transcripts Included with Permission
This repository includes 488 podcast transcripts from the Big Technology Podcast. These transcripts are shared with permission as Ranjan Roy is a co-host of the show.
Usage:
ā Personal use and research
ā Building AI tools and applications
ā Sharing and forking this repository
ā¹ļø Transcripts remain property of Big Technology / Alex Kantrowitz
Podcast: Big Technology Podcast by Alex Kantrowitz
Co-host & MCP Creator: Ranjan Roy
MCP Server Code: MIT License (open source)
Transcripts: Included with permission
Built with: Model Context Protocol
Inspired by: akshayvkt/lenny-mcp
Code: MIT License - See LICENSE for details
Transcripts: Included with permission from Big Technology Podcast. Property of Alex Kantrowitz / Big Technology.
Get the full transcript for a specific episode by title. Use this when you want to dive deeper into a specific episode conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | The episode title or partial title (e.g., 'Mark Warner', 'OpenAI') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must communicate behavior. It states that the tool returns the full transcript and identifies a target by title, which is useful. However, it does not disclose behavior for ambiguous or missing titles, response format, or pagination/truncation.
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 with the core action front-loaded in the first sentence. The second sentence adds usage context but is slightly generic ('dive deeper'), so it is concise but not maximally sharp.
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 single-parameter lookup tool, the description plus schema covers the key invocation details: what to pass and what to expect back. It is not fully complete because there is no output schema and no note on how ambiguous partial-title matches are resolved, but complexity is low.
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%: the title parameter is already described with type, partial-match indication, and examples. The description only says 'by title,' adding no new parameter-level semantics, so the baseline 3 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?
Description names a specific action ('Get the full transcript') and target ('a specific episode by title'), which clearly sets it apart from sibling list/search tools. The phrase 'full transcript' plus 'specific episode' gives the agent a precise mental model of the tool's output.
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 second sentence gives an explicit when-to-use signal: 'Use this when you want to dive deeper into a specific episode conversation.' It does not explicitly name sibling alternatives or when-not-to-use cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most recent episodes from the Big Technology Podcast. Use this to see the latest tech news and discussions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recent episodes to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of indicating behavior. 'Get' signals a read operation and 'most recent' implies recency ordering. However, it does not disclose what fields are returned, whether it only returns metadata, pagination behavior, or any limitations beyond the optional limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with the core function front-loaded and the use case stated immediately. There is no redundant or filler 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?
This is a simple tool with one optional parameter and no output schema, and the description provides enough context for basic invocation. It could be more complete by noting that this returns episode summaries or metadata rather than transcripts, or by differentiating from list_episodes more explicitly, but the current level 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?
The input schema already documents the only parameter, limit, including its default value of 10, so schema coverage is 100%. The description adds no additional semantic detail about the parameter, so it does not elevate beyond the baseline.
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 a specific verb ('Get') with a clear resource ('the most recent episodes from the Big Technology Podcast') and adds the intended content scope ('latest tech news and discussions'). It sufficiently differentiates from siblings such as list_episodes by emphasizing recency.
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 states when to use the tool: to see the latest tech news and discussions from this podcast. It does not name alternatives or exclusions, but the use case is clear enough for an agent to select this tool for recent-episode retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available episodes in the Big Technology Podcast archive. Use this to see what topics and guests are available to search.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it only partially meets it. It discloses scope ('all available episodes') but says nothing about return format, ordering, pagination, episode metadata fields, or whether the response could be large. Since there is no output schema to compensate, the agent is left guessing about what the tool actually returns.
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 with zero waste. The purpose is front-loaded in the first sentence, and the second sentence earns its place by adding a usage context. Every word contributes value, and the description is appropriately sized for a zero-parameter tool.
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 list tool, the description is nearly complete for invocation purposes: the agent knows what the tool does and why to call it. The main gap is the absence of any return-value description, and since no output schema exists, a brief note on what the response looks like would have made it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema properties object, so there is nothing the description needs to explain. Per the rubric, 0 params earns a baseline of 4. The description appropriately adds no redundant parameter information because none exists.
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 a specific verb ('List') and resource ('all available episodes in the Big Technology Podcast archive'), making the tool's function immediately clear. The qualifier 'all available' implicitly contrasts with the sibling get_recent_episodes, though it never names alternatives explicitly. A 5 would require explicit sibling differentiation, so this lands just below.
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 second sentence, 'Use this to see what topics and guests are available to search,' gives a clear use case for the tool as a discovery step before searching. However, it provides no exclusions, no reference to alternatives like search_transcripts or get_episode, and no guidance on when this tool would be the wrong choice. The usage context is implied rather than explicitly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across all Big Technology Podcast transcripts for tech insights and news. Returns relevant excerpts from episodes with titles and dates. Use this to find what tech leaders and experts have said about specific topics like AI, regulation, big tech companies, social media, privacy, antitrust, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10) | |
| query | Yes | The search query - use keywords related to the tech topic you want insights on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It discloses that this is a search operation over all transcripts and that the result will be excerpts with episode titles and dates. It does not detail ranking or matching semantics, but for a read-only search tool the core behavioral guarantees are clearly stated.
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 with no filler. The first sentence states scope and output; the second gives usage guidance with examples. The most important information is front-loaded.
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 search tool with no output schema and no annotations, the description covers the essential expectations: what is searched, what is returned, and what kinds of queries to make. It stops short of explaining result ordering or what happens when no matches are found, but the limit parameter and the 'relevant excerpts' phrasing make the tool reasonably complete for agent use.
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 baseline is 3. The description adds value by providing concrete example topics for the query parameter ('AI, regulation, big tech companies, social media, privacy, antitrust'), helping the agent craft better searches. It does not add much about limit, but the schema already documents that.
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 a specific verb and resource: 'Search across all Big Technology Podcast transcripts' and states what is returned: 'relevant excerpts from episodes with titles and dates.' This clearly distinguishes the tool from siblings like get_episode and list_episodes, which are about retrieving episode metadata rather than searching transcript content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: 'Use this to find what tech leaders and experts have said about specific topics like AI, regulation, big tech companies, social media, privacy, antitrust, etc.' It gives clear context for use, though it does not explicitly state when not to use it or name alternatives. This fits the 'clear context, no exclusions' level.
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.
v1.0.0get_episodeget_recent_episodeslist_episodessearch_transcriptsScored across 4 tools
Each tool has a clearly distinct role: searching transcripts, retrieving a full episode by title, listing all episodes, and listing recent episodes. The only slight overlap is between list_episodes and get_recent_episodes, but their descriptions make the difference understandable.
All tool names follow a consistent verb_noun pattern using snake_case: search_transcripts, get_episode, list_episodes, get_recent_episodes. The naming is predictable and easy to infer.
Four tools is well-scoped for a podcast archive server. It covers browsing, searching, and retrieving transcript content without unnecessary bloat.
The tool surface fully covers the core podcast workflow: discover episodes, see recent ones, search across transcripts, and retrieve full transcripts. No significant missing operations are apparent for this domain.
Search and ask the podcasts you follow inside Claude, with the exact quote and timestamp.
Search and analyze 50,000+ hours of business podcast transcripts, entities, and speakers.
Search and read AI summaries of 75,000+ podcast episodes across 130+ mostly long-form shows.
Search 4M+ podcasts & YouTube, transcribe any episode, search transcripts, generate AI lessons.
