Skip to main content
Glama
Sedation6612

glp1forum-mcp

by Sedation6612
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

glp1forum-mcp

An MCP stdio server that searches and reads https://glp1forum.com (a XenForo forum) with no API keys. It shells out to system curl because Cloudflare there blocks Node's own TLS fingerprint but passes a real curl with a browser User-Agent.

⚠️ The one gotcha

Verified only with Windows curl 8.18 (Schannel). Linux/macOS curl presents a different TLS fingerprint and may get a 403 from Cloudflare. If every request 403s, this is almost certainly why.

Related MCP server: evo-scry

Requirements

  • Node 18+

  • System curl on your PATH (curl --version should work)

Tools

  • search_forum — full-text search with XenForo filters (keywords, nodes, author, date range, min replies, order, page, maxPages up to 3). Keywords are AND-matched; category nodes need includeChildNodes: true.

  • get_thread — read a thread's posts (author, datetime, body, permalink), paginated.

  • get_thread_images — opt-in: download a thread's image attachments at full size as image blocks so vision can read image-only pricing tables / stock boards / COA figures. max caps the count (default 4, max 5 — full-size images are token-expensive).

  • list_threads — browse a forum section's thread list by nodeId, paginated.

  • list_forums — list forum sections with their numeric node IDs (feed these to search_forum.nodes and list_threads.nodeId).

Rate limiting

All requests share a global throttle: ≥2.5s between hits. On HTTP 403/429/503 the server backs off 8s plus up to 10s of jitter and retries once; if still blocked it throws glp1forum rate-limited or unavailable (HTTP 503) — wait ~60s before retrying.

The backoff is deliberately much shorter than the ~60s a Cloudflare 503 actually takes to clear: a handler that slept that long would trip the MCP client's own 60s timeout (-32001), and the sleep holds the search mutex. So it fails fast with a retryable error and asks the caller to wait instead — hence "wait ~60s" in the message.

Two env vars tune this:

  • GLP1_BACKOFF_MS (default 8000) — the retry backoff. Raise it if one retry isn't enough.

  • GLP1_INTERVAL_MS (default 2500) — the global gap between requests. Raise it for heavy concurrent use; each search costs 2 requests, and 8-way concurrency trips Cloudflare at 2.5s.

Install

Option A — Claude Code plugin marketplace (recommended)

/plugin marketplace add Sedation6612/glp1forum-mcp

Then install the glp1forum-mcp plugin. This auto-wires the MCP server; the plugin's config uses ${CLAUDE_PLUGIN_ROOT} so there are no paths to edit.

Option B — Desktop Extension (.mcpb, one-click Claude Desktop)

Download glp1forum-mcp.mcpb from the repo's Releases and double-click it — Claude Desktop installs it with no paths to edit and no npm install (the server is bundled into a single dependency-free dist/index.mjs). You still need system curl on your PATH.

Option C — manual (Claude Desktop)

Run npm install && npm run build first, then add to claude_desktop_config.json:

"glp1forum": { "command": "node", "args": ["C:\\path\\to\\glp1forum-mcp\\dist\\index.mjs"] }

MSIX Claude Desktop installs put this config under %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\, not plain %APPDATA%.

Build (contributors)

The distributed artifact is a single bundled dist/index.mjs (esbuild). After editing anything in src/, rebuild and commit dist/:

npm install
npm run build       # -> dist/index.mjs (what the plugin & .mcpb run)
npm run pack        # build + produce glp1forum-mcp.mcpb for Claude Desktop

Self-test

npm run selftest      # or: node src/selftest.js

Makes a few dozen seconds of live requests under the throttle. Failure means curl is being blocked or the site's HTML drifted.

License

All rights reserved (see LICENSE). The source is public for viewing and for contributions back to this repository via pull request. It is not open source — you may not redistribute it or publish your own version. See the LICENSE file for details.

Available Tools

5 tools
get_threadA
Read-only

Read a thread's posts (paginated) for full context.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoPrefer this: pass the url from a search_forum result row.
pageNoClamped to lastPage. For current status read page 1 then re-fetch page: lastPage — the opening post may be months stale.
threadIdNoAlternative to url.

TDQS

A4/5.0
Behavior4/5

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

The description adds pagination behavior beyond the readOnlyHint annotation. It is consistent with the annotation and provides useful context without contradicting it.

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?

Single sentence, 8 words, efficiently communicates purpose and key feature (paginated). No wasted content.

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 the rich schema annotations and readOnlyHint, the description provides sufficient high-level context (purpose, pagination). It does not repeat schema details and is adequate for a tool with no output schema.

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

Parameters3/5

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

Schema coverage is 100% with detailed parameter descriptions. The description adds no additional parameter information, so baseline 3 is appropriate.

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 reads a thread's posts, indicates pagination, and implies obtaining full context. It is distinct from sibling tools like get_thread_images or search_forum.

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 or avoid this tool versus alternatives. The context is implied by the description and sibling names, but no direct comparison or conditions are provided.

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

get_thread_imagesA
Read-only

Opt-in: download a thread's image attachments at full size so their text (pricing tables, per-warehouse stock boards, COA purity figures, payment pages) is readable by vision. Much of the vendor pricing on glp1forum is image-only and invisible to get_thread's text. Returns a summary plus the images as blocks; use max to cap how many download (default 4, max 5). Costs one throttled request per image.

ParametersJSON Schema
NameRequiredDescriptionDefault
maxNoHow many images to download (default 4, capped at 5). Each costs one throttled request and ~4.6k tokens — lower it when you only need the first table.
urlNoPrefer this: pass the url from a search_forum result row.
pageNoClamped to lastPage.
threadIdNoAlternative to url.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true, and description adds behavioral details: costs one throttled request per image, token cost (~4.6k per image), default/max for max parameter, and returns summary plus images as blocks. 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.

Conciseness5/5

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

Two well-structured sentences with every sentence adding value: front-loaded purpose, specific examples, cost info, and parameter guidance. No wasted words.

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

Completeness5/5

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

Given no output schema, description adequately covers return type (summary plus images as blocks), usage context, cost, defaults, and distinguishes from sibling tool get_thread. Complete for a tool with 4 parameters.

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 100%, baseline 3, but description adds significant context: max parameter has default 4, max 5, and cost details; url parameter suggests origin from search_forum result; page is clamped to lastPage; threadId is an alternative to url.

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?

Description explicitly states the tool downloads image attachments at full size for readability via vision, specifies the context (pricing tables, stock boards, etc.), and distinguishes itself from get_thread which only returns text.

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

Usage Guidelines4/5

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

Provides clear guidance on when to use ('much of the vendor pricing is image-only and invisible to get_thread's text') and how to cap downloads with max, but does not explicitly state when not to use or list alternatives besides get_thread.

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

list_forumsA
Read-only

List forum sections with numeric node IDs (feed these to search_forum.nodes).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description doesn't need to restate. It adds that the tool returns numeric node IDs, which is useful behavioral context. No other traits like pagination or ordering are mentioned, but the tool is simple with no parameters.

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 a single sentence, front-loaded with the core purpose, and every word adds value. No wasted text.

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?

For a simple list tool with no parameters, the description is complete enough. It states what it does and what it returns. With no output schema, the description provides the output structure implicitly. It could mention if there are any limitations or ordering, but it's adequate.

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?

There are no parameters, and schema coverage is 100% (vacuously). The description adds no param info, but none is needed. Baseline for 0 parameters is 4.

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 lists forum sections and provides numeric node IDs, which is a specific verb+resource. It distinguishes from siblings like list_threads and search_forum by mentioning the output is used for search_forum.nodes.

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

Usage Guidelines4/5

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

The description explicitly says to feed the node IDs to search_forum.nodes, giving a clear use case. However, it doesn't exclude other uses or contrast with siblings, but the context is clear enough for selection.

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

list_threadsA
Read-only

Browse a forum section's threads (use list_forums for nodeIds).

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNo
nodeIdYesSection ID from list_forums. Never guess one.

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description's 'browse' aligns with that. The description adds no additional behavioral details beyond the annotation, such as pagination, result limits, or ordering. It is adequate but does not enrich the safety profile.

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 extremely concise: one sentence plus a parenthetical note. Every word adds value, and the key verb 'browse' is front-loaded. There is no redundancy or wasted text.

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 tells the agent how to obtain the nodeId and what the tool does, but it does not describe the output format, pagination, or what fields each thread will contain. With no output schema, this lack of information reduces completeness. It is adequate for a simple list operation but leaves gaps.

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

Parameters2/5

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

The input schema has 50% description coverage (nodeId has a description, page does not). The tool description does not mention parameters at all, so it fails to compensate for the missing page parameter description. The nodeId description in the schema is good, but the overall parameter context is lacking.

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 browses threads in a forum section using the verb 'browse' and resource 'threads'. It distinguishes itself from sibling tool list_forums by noting that list_forums should be used to obtain nodeIds. This is specific and unambiguous.

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

Usage Guidelines4/5

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

The description explicitly instructs the agent to use list_forums to get valid nodeIds, providing a clear prerequisite. It implies the tool is for browsing all threads in a section, contrasting with search_forum and get_thread siblings. However, it does not explicitly state when not to use it.

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

search_forumA
Read-only

Full-text search glp1forum.com with granular XenForo filters. Multi-word keywords are AND-matched (all terms must appear). Category/parent nodes (e.g. 45 Vendor Connection) return nothing unless includeChildNodes: true. A rate-limit error means wait ~60s before retrying. Result has truncated: true when more result pages exist than were fetched — re-search with a higher maxPages (max 3) to get the rest.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNo
nodesNoSection IDs from list_forums. Never guess one — a wrong ID silently returns 0 rows instead of erroring.
orderNoOmit for relevance. "date" (newest first) for any current / latest / in-stock question. "replies" (most-discussed) for reputation, consensus, or what-are-people-saying questions.
authorNoRarely worth setting.
keywordsYesAND-matched: every word must appear. Start with one or two broad terms; if you get 0 hits, drop a term, never add one.
maxPagesNoClamped 1-3. A result with truncated:true has more pages — re-search with a higher maxPages.
newerThanNoYYYY-MM-DD. Only to hard-exclude stale rows — order:"date" alone usually suffices, so don't agonize over a cutoff.
olderThanNoYYYY-MM-DD. Only to hard-exclude rows newer than a cutoff.
minRepliesNoRarely worth setting.
searchTypeNoOmit (= "post") so a keyword buried in a reply still matches. "thread" matches only titles/opening posts.
titlesOnlyNoRarely worth setting.
groupByThreadNotrue collapses results to one row per thread. Omitting searchType plus groupByThread:true is the discovery default.
includeChildNodesNoSet true when nodes names a parent/category section: those hold no posts of their own and return 0 rows if searched alone.

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses behaviors beyond annotations: rate-limiting with a recommended wait, silent failure when using a wrong node ID (returns 0 rows), and the truncated flag indicating incomplete results. These details are critical for an agent to invoke the tool correctly. Annotations only provide readOnlyHint=true, which is consistent with the read-only search operation.

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 well-structured but somewhat verbose, containing multiple sentences that each provide distinct value. It could be slightly more concise by grouping related guidelines, but it remains clear and front-loaded with essential information. No wasted sentences.

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

Completeness5/5

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

Given the tool's complexity (13 parameters, no output schema), the description is remarkably complete. It covers rate-limit handling, the truncated field in results, and common pitfalls like wrong node IDs. It also provides best practices for keyword usage and ordering. No output schema exists, so the description's coverage of result behavior compensates well.

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?

Despite high schema coverage (92%), the description adds substantial meaning beyond the schema. For example, it explains the AND-matching logic for keywords, the behavior of nodes with includeChildNodes, and the semantics of order values ('date' for latest, 'replies' for most-discussed). It also clarifies when to omit parameters (e.g., order for relevance). This adds value for agent comprehension.

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 'Full-text search glp1forum.com with granular XenForo filters', specifying the domain and type of search. This verb+resource combination is distinct from sibling tools like get_thread or list_forums, which are for retrieval or listing, not full-text search.

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?

The description provides explicit when-to-use guidance: it explains AND-matching for keywords, the need for includeChildNodes when searching category nodes, rate-limit retry behavior, and handling truncated results. It also advises on using the order parameter for different query types, such as 'date' for current topics and 'replies' for consensus. While it doesn't explicitly exclude sibling tools, the context is sufficient given their distinct purposes.

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.

  1. 4 tool updatesv0.5.0
    • Changedget_thread3 fields changed
      • addedInput schema / properties / page / description
        Added value: +"Clamped to lastPage. For current status read page 1 then re-fetch page: lastPage — the opening post may be months stale."
      • addedInput schema / properties / threadId / description
        Added value: +"Alternative to url."
      • addedInput schema / properties / url / description
        Added value: +"Prefer this: pass the url from a search_forum result row."
    • Changedget_thread_images4 fields changed
      • addedInput schema / properties / max / description
        Added value: +"How many images to download (default 4, capped at 5). Each costs one throttled request and ~4.6k tokens — lower it when you only need the first table."
      • addedInput schema / properties / page / description
        Added value: +"Clamped to lastPage."
      • addedInput schema / properties / threadId / description
        Added value: +"Alternative to url."
      • addedInput schema / properties / url / description
        Added value: +"Prefer this: pass the url from a search_forum result row."
    • Changedlist_threads1 field changed
      • addedInput schema / properties / nodeId / description
        Added value: +"Section ID from list_forums. Never guess one."
    • Changedsearch_forum13 fields changed
      • addedInput schema / properties / author / description
        Added value: +"Rarely worth setting."
      • addedInput schema / properties / groupByThread / description
        Added value: +"true collapses results to one row per thread. Omitting searchType plus groupByThread:true is the discovery default."
      • addedInput schema / properties / includeChildNodes / description
        Added value: +"Set true when nodes names a parent/category section: those hold no posts of their own and return 0 rows if searched alone."
      • addedInput schema / properties / keywords / description
        Added value: +"AND-matched: every word must appear. Start with one or two broad terms; if you get 0 hits, drop a term, never add one."
      • addedInput schema / properties / maxPages / description
        Added value: +"Clamped 1-3. A result with truncated:true has more pages — re-search with a higher maxPages."
      • addedInput schema / properties / minReplies / description
        Added value: +"Rarely worth setting."
      • addedInput schema / properties / newerThan / description
        Added value: +"YYYY-MM-DD. Only to hard-exclude stale rows — order:\"date\" alone usually suffices, so don't agonize over a cutoff."
      • addedInput schema / properties / nodes / description
        Added value: +"Section IDs from list_forums. Never guess one — a wrong ID silently returns 0 rows instead of erroring."
      • addedInput schema / properties / olderThan / description
        Added value: +"YYYY-MM-DD. Only to hard-exclude rows newer than a cutoff."
      • addedInput schema / properties / order / description
        Added value: +"Omit for relevance. \"date\" (newest first) for any current / latest / in-stock question. \"replies\" (most-discussed) for reputation, consensus, or what-are-people-saying questions."
      • removedInput schema / properties / prefixes
        Removed value: -{
-  "items": {
-    "type": "number"
-  },
-  "type": "array"
-}
      • addedInput schema / properties / searchType / description
        Added value: +"Omit (= \"post\") so a keyword buried in a reply still matches. \"thread\" matches only titles/opening posts."
      • addedInput schema / properties / titlesOnly / description
        Added value: +"Rarely worth setting."
  2. 5 tool updatesv0.3.0
    • First observedget_thread
    • First observedget_thread_images
    • First observedlist_forums
    • First observedlist_threads
    • First observedsearch_forum
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clear and distinct purpose: listing forums, listing threads, reading a thread's posts, downloading images, and searching. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (list_forums, list_threads, get_thread, get_thread_images, search_forum), making the set predictable.

Tool Count5/5

With 5 tools, the server covers browsing, reading, and searching a forum without being excessive or insufficient. The count feels well-scoped for the domain.

Completeness5/5

The tool set provides a complete read-oriented interface for the forum: navigating sections, listing threads, reading posts with pagination, accessing images, and full-text search. No obvious gaps for a read-only use case.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • metasearch-mcp

    YeonwooSung
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for using various search tools like Tavily API. Planning to support various search tools (i.e. wiki search, searxng, etc)
    3
    MIT

  • evo-scry

    krich11
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for internet search via direct Google and DuckDuckGo HTML scraping with AI-powered result normalization and optional summarization, requiring no API keys for search.
    MIT