Which integrations are available for this server?

Provides tools for searching and retrieving Stack Overflow questions, answers, and related content via the Stack Exchange API. Includes advanced search filters, HTML-to-Markdown conversion, and rate limit management.

How do I use StackOverflow MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@StackOverflow MCP Server search for Python async questions" 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.

StackOverflow MCP Server

by NoTalkTech

Overview Schema Related Servers Score Discussions

Python

Remote

StackOverflow MCP Server

npm version License: MIT

A Model Context Protocol (MCP) server that provides seamless access to StackOverflow's programming Q&A database using the FastMCP framework.

Quick Start

Using with Cursor (Recommended)

Add this configuration to your Cursor MCP settings:

{
  "mcp_servers": {
    "stackoverflow": {
      "command": "npx",
      "args": [
        "-y",
        "@notalk-tech/stackoverflow-mcp",
        "--api-key", "your_stackoverflow_api_key"
      ]
    }
  }
}

Using NPX

# Run directly (no installation required)
npx @notalk-tech/stackoverflow-mcp

# With API key
npx @notalk-tech/stackoverflow-mcp --api-key your_key

# Skip installation prompts
npx -y @notalk-tech/stackoverflow-mcp

Using Python Module

# Direct execution
python -m stackoverflow_mcp

# With uv (recommended)
uv run python -m stackoverflow_mcp --api-key your_key

Related MCP server: stack-overflow-mcp-light

🎯 Features

🔍 Advanced Search: Search by keywords, tags, accepted status, score threshold, and date ranges
📖 Question Details: Get detailed content with automatic HTML-to-Markdown conversion
🏷️ Tag-based Search: Convenient tag-only search (proxies to main search)
💡 Related Questions: Discover related and linked questions for deeper exploration
⚡ Rate Limit Management: Intelligent retry, backoff, and auto-switching between authenticated/unauthenticated access
🔐 API Authentication: Full support for StackOverflow API keys with automatic quota tracking
📦 Unified Response Format: All tools return consistent {success, data, meta} structure
🚀 Auto-deployment: NPX-compatible with automatic Python environment setup

🔑 Getting Your API Key

To use this MCP server with higher rate limits, you'll need a StackOverflow API key:

Steps

Register Your Application
- Visit https://stackapps.com/applications/register
- Log in with your Stack Exchange account
- Fill in application details (name, description, OAuth domain)
- Submit the registration
Generate Your API Key
- Go to your application management page
- Click "Generate a new API key"
- Copy and save the generated key securely

Rate Limits

Without API key: 300 requests/day per IP
With API key: 10,000 requests/day

For read-only operations (searching and retrieving Q&A), a simple API key is sufficient. OAuth is only needed for write operations.

Learn more: https://api.stackexchange.com/docs/authentication

⚙️ Configuration

Create a .stackoverflow-mcp.json file in your working directory:

{
  "stackoverflow_api_key": "your_api_key_here",
  "log_level": "CRITICAL"
}

The server auto-discovers config files in this order:

.stackoverflow-mcp.json
stackoverflow-mcp.config.json
config/stackoverflow-mcp.json
.config/stackoverflow-mcp.json

Command Line Options

--working-dir DIRECTORY    Working directory (auto-detect if not specified)
--api-key TEXT             StackOverflow API key
--version                  Show version and exit
--help                     Show help message

🌐 Available Tools

Once running, the MCP server provides these tools:

search_questions: Search StackOverflow questions by keywords with optional filters — tags, accepted_only, min_score, from_date, to_date
search_by_tags: Convenience wrapper for tag-only search (proxies to search_questions)
get_question: Get detailed question content with optional answer limiting (max_answers) and automatic HTML-to-Markdown conversion
get_answers: Fetch answers independently without re-fetching the question body
get_related: Discover related and linked questions for further exploration

Resource

stackoverflow://status: Server status including version, authentication state, rate limit status, and queue statistics

📋 Prerequisites

Node.js 14.0.0 or higher
Python 3.12 or higher
uv (recommended) or pip

The NPX wrapper automatically handles Python package installation and environment setup.

🚀 Development

Local Setup

git clone https://github.com/NoTalkTech/stackoverflow-mcp.git
cd stackoverflow-mcp

# Install dependencies
npm install
pip install -e .

# Run in development mode
npm start

Project Structure

stackoverflow-mcp/
├── cli.js                          # NPX wrapper (Node.js)
├── package.json                    # NPM package configuration
├── pyproject.toml                  # Python package configuration
├── src/stackoverflow_mcp/          # Python MCP server
│   ├── __main__.py                 # Python module entry point
│   ├── main.py                     # CLI and server management
│   ├── server.py                   # MCP server implementation (5 tools + resource)
│   ├── config.py                   # Server configuration management
│   ├── logging.py                  # Logging configuration
│   └── stackoverflow_client.py     # StackOverflow API client (rate limiting, caching, content formatting)
└── tests/                          # Test files

Testing

# Run all tests
.venv/bin/python -m pytest tests/ -v

# Test npm package
npm test

🤝 Contributing

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

🆘 Support

Issues: GitHub Issues
Documentation: GitHub README

🙏 Acknowledgments

Model Context Protocol for the MCP specification
StackOverflow for providing the API
The open-source community for inspiration and contributions

Made for the developer community

Available Tools

5 tools

get_answersA

Get answers for a specific StackOverflow question.

Fetches only answers without re-fetching the question body.
Use this when you already have the question context and just need the responses.

Args:
    question_id: StackOverflow question ID
    max_answers: Maximum number of answers to return (1-50)
    sort: Sort order (votes, creation, activity)
    convert_to_markdown: Convert HTML content to markdown

ParametersJSON Schema

Name	Required	Default
`sort`	No	votes
`max_answers`	No
`question_id`	Yes
`convert_to_markdown`	No

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that only answers are fetched (not question body), which is a key behavioral trait. However, it does not mention potential rate limits, authentication requirements, or pagination behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise with clear sections: a title line, a purpose sentence, usage guidance, and a structured Args list. No redundant information. Could be slightly more compact but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description provides adequate information for invocation: purpose, when to use, and parameter details. However, it lacks description of return format or example usage, which would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so description must compensate. It adds meaning for each parameter: specifies question_id type, max_answers range (1-50), sort order options (votes, creation, activity), and convert_to_markdown purpose. This significantly enhances schema understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get answers for a specific StackOverflow question' and distinguishes from sibling tools like 'get_question' by noting it fetches only answers without re-fetching the question body.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this when you already have the question context and just need the responses', providing clear when-to-use guidance. Also specifies constraints like max_answers range (1-50) and sort order options.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_questionA

Get detailed information about a specific question.

Args:
    question_id: StackOverflow question ID
    include_answers: Whether to include answers
    max_answers: Maximum number of answers to include (1-20)
    convert_to_markdown: Convert HTML content to markdown

ParametersJSON Schema

Name	Required	Description	Default
`max_answers`	No
`question_id`	Yes
`include_answers`	No
`convert_to_markdown`	No

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only lists parameters. It does not disclose behavioral traits such as safety (read-only), error handling (missing ID), rate limits, or return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the main purpose. No redundant sentences, but it could be more structured (e.g., bullet points) for faster scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters and no output schema, the description covers parameters but lacks information about the return structure (e.g., what fields are returned) and error handling. This is a moderate gap for a retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds meaningful explanations for all four parameters (e.g., 'Maximum number of answers to include (1-20)'). This compensates well, though defaults and interactions are not explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves detailed information for a specific question, using a specific verb-resource pair. It distinguishes from siblings like get_answers (answers only) and get_related (related questions).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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 like search_questions or get_answers. Context is implied (when you have a question ID) but not stated, and no exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_relatedA

Find related and linked StackOverflow questions for discovery.

Returns lightweight summaries (titles, scores, tags) — no HTML bodies.
StackExchange does not support pagination on these endpoints.

Args:
    question_id: StackOverflow question ID to find related content for
    include_linked: Whether to also include explicitly linked questions

ParametersJSON Schema

Name	Required	Description	Default
`question_id`	Yes
`include_linked`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It states that results are lightweight summaries (no HTML bodies) and that StackExchange does not support pagination on these endpoints. This is important behavioral context beyond basic functionality. It implicitly indicates read-only behavior (fetching related content). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise, with three short paragraphs covering purpose, return content summary, and pagination constraint, followed by parameter descriptions. Each sentence adds value; there is no redundancy. The parameter descriptions could be integrated inline, but the structure is clear and not verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema or annotations, the description provides adequate context: what it returns (titles, scores, tags), the pagination limitation, and parameter meanings. However, it could be improved by explicitly stating that the output is a list of items or by noting any authentication requirements. Still, it sufficiently enables an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, meaning the input schema only provides types and titles but no descriptions. The description's Args section provides meaningful natural language explanations for both parameters: question_id is 'StackOverflow question ID' and include_linked clarifies 'Whether to also include explicitly linked questions'. This adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool finds related and linked StackOverflow questions for discovery. It specifies the verb 'find' and the resource 'related and linked StackOverflow questions'. The name and description distinguish it from sibling tools like get_questions (single question) or search_questions (query-based search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates the tool is for discovery of related content, but does not explicitly state when to use it over alternatives like search_questions or search_by_tags. It provides no guidance on when not to use it or under what conditions another tool would be preferable. The context is clear but not prescriptive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_by_tagsA

Search StackOverflow questions by programming tags.

Args:
    tags: List of tags to search for (e.g., ['python', 'async'])
    limit: Maximum number of results (1-50)
    page: Page number for pagination (minimum 1)
    sort: Sort order (activity, votes, creation, relevance)
    site: Site name to search in (e.g., stackoverflow, serverfault, askubuntu)

ParametersJSON Schema

Name	Required	Default
`page`	No
`site`	No	stackoverflow
`sort`	No	activity
`tags`	Yes
`limit`	No

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits like authentication needs, rate limits, or error handling. It only describes parameters without behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and structured as a docstring with Args. It is front-loaded with the main purpose and parameter details. However, the Pythonic format may be less familiar to some agents.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains all parameters but lacks information about return format, pagination behavior beyond page parameter, and error handling. Given the number of parameters and no output schema, it is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the schema: it defines tag format with examples, constrains limit (1-50) and page (minimum 1), enumerates sort values, and gives site examples. Schema coverage is 0%, so the description fully compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches StackOverflow questions by programming tags, with a specific verb and resource. It distinguishes from siblings like search_questions by focusing on tag-based filtering.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 does not mention when to prefer this over search_questions or other siblings, nor does it provide exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_questionsA

Search StackOverflow questions by keywords.

Supports combined keyword + tag search. When searching by tags only,
pass an empty string for query.

Args:
    query: Search query keywords (empty string for tag-only search)
    limit: Maximum number of results (1-50)
    page: Page number for pagination (minimum 1)
    sort: Sort order (relevance, activity, votes, creation)
    site: Site name to search in (e.g., stackoverflow, serverfault, askubuntu)
    tags: Filter by tags (list of tag names)
    accepted_only: Only return questions with an accepted answer
    min_score: Minimum score threshold
    from_date: Earliest creation date (Unix timestamp)
    to_date: Latest creation date (Unix timestamp)

ParametersJSON Schema

Name	Required	Default
`page`	No
`site`	No	stackoverflow
`sort`	No	relevance
`tags`	No
`limit`	No
`query`	Yes
`to_date`	No
`from_date`	No
`min_score`	No
`accepted_only`	No

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It mentions combined keyword+tag search behavior but omits details on rate limits, authentication, or result handling. The parameter descriptions are thorough but not behavioral.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a clear one-liner purpose, a secondary usage note, and a bulleted parameter list. It is concise and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description does not explain the return value format or structure, which is critical since no output schema exists. It also lacks details on pagination behavior or how to handle results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description fully carries the burden. It provides a complete parameter list with meaningful explanations for all 10 parameters, including usage nuances like 'empty string for tag-only search' for query and 'list of tag names' for tags.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches StackOverflow questions by keywords, and explicitly mentions combined keyword+tag search. It differentiates from siblings like search_by_tags by explaining how to perform tag-only searches with an empty query.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a usage hint for tag-only searches (empty query) but does not explicitly compare with the sibling tool search_by_tags or state when not to use this tool. It lacks clear guidance on alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv1.3.3Jul 13, 2026
- First observedget_answers
- First observedget_question
- First observedget_related
- First observedsearch_by_tags
- First observedsearch_questions

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct aspect of StackOverflow: retrieving a question, retrieving answers, finding related questions, searching by tags, and searching by keywords. There is no ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_question, search_by_tags). No deviations or mixed conventions.

Tool Count5/5

With 5 tools, the set is well-scoped for a StackOverflow Q&A server. It covers core retrieval and discovery operations without being excessive or insufficient.

Completeness4/5

The tool set covers key read operations: question retrieval, answer retrieval, related questions, and two search methods. Missing operations like comment or user retrieval are minor gaps for a read-only informational server, but core workflows are well supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

stackexchange A
io.github.pipeworx-io
StackExchange MCP — wraps the StackExchange API v2.3 (free, no auth required for read)
Search Open Data Research & Data
3621
stackexchange-mcp-server A
io.github.cyanheads
Search Stack Exchange questions, fetch Q&A threads as markdown, look up tag FAQs and user profiles.
Search Research & Data
522
developer-tools-mcp-server A
com.thenextgennexus
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Developer Tools Search
72
OneOAuth
ai.withone
Search, document and execute authenticated API calls across 700+ apps via one MCP server
API Testing App Automation
110

Related MCP Servers

Linear MCP Server
Project Management Version Control
Iwark
A
license
Not graded
quality
D
maintenance
Enables interaction with Linear resources through an MCP interface, offering functionality for issue management and resource retrieval with rate limiting and error handling support.
Updated 2 years ago (2025-02-11 04:05 UTC)
713
1
MIT
stack-overflow-mcp-light
Search Developer Tools
midodimori
A
license
B
quality
C
maintenance
MCP server for searching Stack Overflow questions and retrieving answers with body content, supporting advanced filters and multiple transport types.
Updated a year ago (2025-10-13 13:33 UTC)
3
MIT
Nextcloud Developer
Documentation Access Search RAG Systems
Rello
F
license
Not graded
quality
C
maintenance
Provides MCP tools for searching, retrieving, and answering questions about indexed Nextcloud developer documentation from multiple sources.
Updated 2 months ago (2026-07-07 10:50 UTC)
-
A2ABench
Developer Tools Search RAG Systems
khalidsaidi
A
license
Not graded
quality
B
maintenance
Agent-native developer Q&A service providing MCP tooling and A2A runtime endpoints for deep research and citations.
Updated 10 days ago (2026-08-27 23:27 UTC)
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NoTalkTech/stackoverflow-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server