Search Stack Exchange questions, fetch Q&A threads as markdown, look up tag FAQs and user profiles.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 5 of 5 tools scored.
Each tool has a distinct purpose: tag-based FAQ, full thread retrieval, user profile, site enumeration, and free-text search. No functional overlap.
All tools follow a consistent 'stackexchange_verb_noun' pattern using snake_case, e.g., get_tag_faq, list_sites, search_questions.
Five tools cover the core read workflows for Stack Exchange (search, tag browsing, thread detail, user info, site discovery) without bloat.
Covers essential read operations, but lacks a tool to list a user's questions or answers, which could be useful for credibility checks.
stackexchange_get_tag_faqGet Stack Exchange Tag FAQAFetch the highest-voted answered questions for a tag on a Stack Exchange site — the canonical "best answers in X" list. Returns a question list without bodies; use stackexchange_get_thread to read the full body and answers for any result. Use this tool to find the authoritative community resources on a topic (e.g. tag "javascript" on stackoverflow). Use stackexchange_search_questions for free-text search rather than tag-based browsing.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag to look up (e.g. "python", "javascript", "docker"). Must match exactly. | |
| site | No | Stack Exchange site — use the api_site_parameter value (e.g. "stackoverflow", "superuser"). Defaults to "stackoverflow". Call stackexchange_list_sites to discover valid values. | stackoverflow |
| pageSize | No | Number of results to return (1–30, default 10). |
| Name | Required | Description |
|---|---|---|
| cap | No | The pageSize cap applied to this request. |
| tag | Yes | Tag name used for this FAQ lookup. |
| site | Yes | Stack Exchange site api_site_parameter used for this lookup. |
| shown | No | Number of results returned. |
| notice | No | Actionable guidance when results are empty or filtered. |
| quotaMax | Yes | Maximum API quota calls per day (300 keyless, ~10,000 with API key). |
| questions | Yes | Highest-voted answered questions for the specified tag, ordered by votes. |
| truncated | No | True when results were capped at pageSize. |
| attribution | Yes | Content license notice. Stack Exchange content is licensed under CC BY-SA 4.0 and requires attribution. |
| quotaRemaining | Yes | Remaining API quota calls for the current day. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the useful behavioral note that the returned list lacks question bodies, which is not covered by annotations. No contradiction present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The purpose is stated upfront, followed by concise usage instructions and a link to a sibling. Efficient and well-structured.
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 presence of output schema (mentioned) and thorough annotations, the description is sufficient. It specifies the return content (list without bodies) and points to stackexchange_get_thread for deeper access, ensuring completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the baseline is 3. The description does not significantly add meaning beyond the schema, aside from re-emphasizing the site parameter's value format. No additional semantics provided.
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 fetches the highest-voted answered questions for a tag, serving as the canonical 'best answers in X' list. It distinguishes itself from sibling tools by mentioning stackexchange_search_questions for free-text search and stackexchange_get_thread for reading full bodies.
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?
Explicit guidance on when to use this tool (finding authoritative community resources) and when to use alternatives (stackexchange_search_questions for free-text, stackexchange_get_thread for full details). This leaves no ambiguity for the AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stackexchange_get_threadGet Stack Exchange Q&A ThreadAFetch a complete Q&A thread — question body and all answers, accepted answer first then sorted by score, rendered as clean markdown with fenced code blocks. Accepts an integer question ID or a full Stack Exchange question URL (e.g. "https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster" or "11227809"). HTML is normalized to markdown automatically; attribution (author + link) included per CC BY-SA 4.0. Get question IDs from stackexchange_search_questions or stackexchange_get_tag_faq.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Stack Exchange site — use the api_site_parameter value (e.g. "stackoverflow", "superuser"). Defaults to "stackoverflow". Must match the site where the question lives. Call stackexchange_list_sites to discover valid values. | stackoverflow |
| maxAnswers | No | Maximum number of answers to include (1–100, default 10). Answers are sorted: accepted first, then by score. | |
| questionIdOrUrl | Yes | Numeric question ID (e.g. "11227809") or a full Stack Exchange question URL (e.g. "https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster"). The integer immediately following /questions/ is extracted from URLs. |
| Name | Required | Description |
|---|---|---|
| cap | No | The maxAnswers cap applied to this request. |
| link | Yes | Direct URL to the question. |
| tags | Yes | Tags applied to this question. |
| score | Yes | Question score (upvotes minus downvotes). |
| shown | No | Number of answers returned. |
| title | Yes | Question title. |
| answers | Yes | Answers sorted: accepted answer first, then by score descending. |
| quotaMax | Yes | Maximum API quota calls per day (300 keyless, ~10,000 with API key). |
| truncated | No | True when answers were capped at maxAnswers. |
| authorLink | No | Question author profile URL when available. |
| authorName | No | Question author display name when available. |
| questionId | Yes | Numeric question ID — identifies this thread on the site. |
| answerCount | No | Total answers the question has upstream. When greater than the returned answers[] length, more answers exist — raise maxAnswers to fetch them. |
| authorUserId | No | Question author numeric user ID when available — pass to stackexchange_get_user to fetch the full profile. |
| bodyMarkdown | Yes | Question body normalized from HTML to markdown. |
| quotaRemaining | Yes | Remaining API quota calls for the current day. |
| acceptedAnswerId | No | ID of the accepted answer when one exists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description adds valuable behavioral details: automatic HTML-to-markdown normalization, CC BY-SA 4.0 attribution inclusion, and answer sorting (accepted first, then by score). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words. It front-loads the core purpose and output format in the first sentence, then efficiently adds input details and attribution notes.
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 presence of an output schema (not shown but indicated), the description covers all necessary input aspects, behavior, and provenance of IDs. It is complete for an agent to select and invoke correctly.
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 100% coverage, but the description adds meaningful context: for questionIdOrUrl, explains both integer and URL formats; for site, clarifies usage of api_site_parameter and list_sites; for maxAnswers, specifies range and sorting behavior.
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 'Fetch a complete Q&A thread' with specifics on output format (markdown with code blocks) and sorting order. It distinguishes itself from sibling tools by directing to 'stackexchange_search_questions' or 'stackexchange_get_tag_faq' for obtaining IDs.
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 gives explicit instructions on input formats (integer ID or URL) and how to find IDs via sibling tools. It also mentions the site parameter and how to discover valid sites via 'stackexchange_list_sites'. No explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stackexchange_get_userGet Stack Exchange User ProfileAFetch a Stack Exchange user profile by numeric user ID: reputation, badge counts, top tags by answer score, and account metadata. Useful for credibility context on an answer author — pass the authorUserId from any question or answer in stackexchange_get_thread output. Returns profile fields plus up to 10 top tags by answer score.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Stack Exchange site — use the api_site_parameter value (e.g. "stackoverflow", "superuser"). Defaults to "stackoverflow". Call stackexchange_list_sites to discover valid values. | stackoverflow |
| userId | Yes | Numeric user ID — use the authorUserId field from a question or answer in stackexchange_get_thread output. |
| Name | Required | Description |
|---|---|---|
| link | Yes | Direct URL to the user profile. |
| userId | Yes | Numeric user ID on this Stack Exchange site. |
| topTags | Yes | Top tags by answer score (up to 10). Empty array for new users with no answers. |
| location | No | User-provided location string when available. |
| quotaMax | Yes | Maximum API quota calls per day (300 keyless, ~10,000 with API key). |
| reputation | Yes | User reputation score. |
| websiteUrl | No | User-provided website URL when available. |
| answerCount | No | Total number of answers posted when provided by the API. |
| badgeCounts | No | Badge counts when provided by the API. |
| displayName | Yes | Display name shown on the site. |
| questionCount | No | Total number of questions posted when provided by the API. |
| quotaRemaining | Yes | Remaining API quota calls for the current day. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying the returned fields (reputation, badge counts, top tags) and a limit of 10 top tags, providing behavioral context beyond annotations. No contradiction.
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 short, information-dense sentences. The first sentence states the core action and return data, the second sentence provides usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description adequately covers the purpose, input, and usage. The tool is simple (read-only fetch), so the description is sufficient. It mentions return fields and a limit, but lacks details on error handling or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (site and userId) well-documented. The description reinforces the source of the userId (from stackexchange_get_thread) but adds minimal new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a Stack Exchange user profile by numeric user ID, listing specific fields. It distinguishes itself from sibling tools like stackexchange_get_thread (threads) and stackexchange_search_questions (searching). The verb 'fetch' and resource 'user profile' are explicit.
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 it is useful for credibility context on an answer author and instructs to pass the authorUserId from stackexchange_get_thread output. This provides a clear when-to-use scenario, but it does not mention when not to use or specify alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stackexchange_list_sitesList Stack Exchange SitesAEnumerate all sites in the Stack Exchange network — name, api_site_parameter, audience, and URL. The api_site_parameter value is what other tools accept as the site input (e.g. "stackoverflow", "superuser", "serverfault"). Results are fetched live and optionally filtered by name. Use this tool to discover valid site parameters before calling other stackexchange_* tools.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional case-insensitive name filter — returns only sites whose name contains all provided tokens. Omit to return all sites. |
| Name | Required | Description |
|---|---|---|
| sites | Yes | Stack Exchange network sites matching the optional name filter. |
| notice | No | Actionable guidance when results are empty or filtered. |
| quotaMax | Yes | Maximum API quota calls per day (300 keyless, ~10,000 with API key). |
| totalCount | Yes | Total number of sites returned after filtering. |
| quotaRemaining | Yes | Remaining API quota calls for the current day. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds that results are fetched live and filtered optionally, providing extra behavioral context without redundancy.
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?
Three sentences, front-loaded with purpose, no wasted words. Clearly structured with purpose, output fields, usage advice, and parameter behavior.
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 presence of an output schema, the description need not detail return values. It covers all necessary context: purpose, key output fields, filtering, and usage in the tool ecosystem.
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 100% coverage and description explains the filter parameter's case-insensitive substring matching. It also elaborates on the significance of api_site_parameter in output, adding value beyond 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?
Clearly states it enumerates all Stack Exchange sites with specific fields (name, api_site_parameter, audience, URL) and distinguishes from sibling tools that focus on specific sites or operations.
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 advises to use this tool to discover valid site parameters before calling other stackexchange_* tools, providing clear when-to-use and how to use the results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stackexchange_search_questionsSearch Stack Exchange QuestionsASearch questions across a Stack Exchange site. Returns ranked questions with title, score, answer count, accepted status, tags, and excerpt — no bodies at this stage. Results supply question_id values for stackexchange_get_thread, which fetches the full question body and all answers. Use the site parameter to target a specific community (e.g. "stackoverflow", "superuser", "unix"); call stackexchange_list_sites to discover valid site values.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Stack Exchange site to search — use the api_site_parameter value (e.g. "stackoverflow", "superuser", "serverfault"). Defaults to "stackoverflow". Call stackexchange_list_sites to discover valid values. | stackoverflow |
| sort | No | Result ordering: "relevance" (default, best match), "votes" (highest score first), "activity" (most recently active), "newest" (most recently created). | relevance |
| tags | No | Filter results to questions with all specified tags. | |
| query | Yes | Full-text search query (e.g. "python async generator send value"). | |
| minScore | No | Minimum question score — excludes questions with lower scores. Setting minScore orders results by score (votes), which may differ from the requested sort. | |
| pageSize | No | Number of results to return (1–30, default 10). | |
| acceptedOnly | No | When true, return only questions that have an accepted answer. |
| Name | Required | Description |
|---|---|---|
| cap | No | The pageSize cap applied to this request. |
| shown | No | Number of results returned. |
| notice | No | Actionable guidance when results are empty or filtered. |
| quotaMax | Yes | Maximum API quota calls per day (300 keyless, ~10,000 with API key). |
| questions | Yes | Questions matching the search query, ordered by the specified sort. |
| truncated | No | True when results were capped at pageSize. |
| attribution | Yes | Content license notice. Stack Exchange content is licensed under CC BY-SA 4.0 and requires attribution. |
| quotaRemaining | Yes | Remaining API quota calls for the current day. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and the description adds valuable behavioral context: it returns only titles, scores, etc., not bodies, and that results supply question_id for use with another 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?
The description is four concise sentences, each providing essential information: purpose and output, relationship to sibling, parameter usage, and discovery of valid values. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 1 required) and presence of an output schema, the description fully covers the tool's behavior, return data limitations, inter-tool dependencies, and parameter validation (via list_sites).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds meaning by explaining how to use the site parameter (with examples) and the relationship between parameters and the overall workflow (e.g., using results for get_thread).
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 searches questions across a Stack Exchange site and distinguishes itself from siblings by mentioning that results provide question_id for stackexchange_get_thread and that stackexchange_list_sites discovers valid sites.
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 provides explicit guidance on when to use this tool (searching questions) and references sibling tools for related tasks (stackexchange_get_thread for full thread, stackexchange_list_sites for site discovery), offering clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.