How do I use hotcopper-mcp?

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., "@hotcopper-mcp search for ASX: BHP threads" 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.

hotcopper-mcp

by mKlus

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

HotCopper MCP

Unofficial Model Context Protocol server for HotCopper — Australia’s largest ASX share-trading forum.

HotCopper has no public API. This server reverse-engineers the site’s session cookies and HTML pages so agents can search, read threads, and (optionally) reply as a logged-in user.

Not affiliated with HotCopper / Gumtree Australia Markets. Personal use only. Respect HotCopper’s terms of service and rate limits. Never commit session cookies.

Features

Tool	Description
`auth_status`	Whether a session is loaded (`xf_user` / `xf_session`)
`latest_posts`	Live feed (`/postview/`)
`stock_threads`	Discussion threads for an ASX ticker
`get_thread`	Read posts in a thread
`search`	Site search
`get_news`	Homepage news / opinion
`watchlist_summary`	Account page + auth summary
`reply_to_thread`	Post a reply (`confirm=true` required; supports `dry_run`)

Related MCP server: mcp-financex

Requirements

Node.js 20+
A HotCopper account
Playwright Chromium (for the one-time login capture)

Install

git clone https://github.com/mKlus/hotcopper-mcp.git
cd hotcopper-mcp
npm install
npx playwright install chromium

Authenticate (once)

npm run capture
# or use your installed Google Chrome:
npm run capture:chrome

A browser window opens on HotCopper.
Log in.
Optionally browse search / a stock / a thread so capture notes the flows.
Press Enter in the terminal (or touch auth/DONE).

This writes (gitignored):

auth/storage-state.json — Playwright storage state (cookies)
auth/cookies.json — cookie jar dump
captures/* — optional network HAR / endpoint summary

Re-run capture when the session expires.

Run the MCP server

npm start

Grok

[mcp_servers.hotcopper]
command = "node"
args = ["/absolute/path/to/hotcopper-mcp/src/server.js"]
enabled = true
startup_timeout_sec = 30
tool_timeout_sec = 120

grok mcp add hotcopper -- node /absolute/path/to/hotcopper-mcp/src/server.js

Claude Desktop / Cursor

Add a stdio MCP server pointing at node + src/server.js (same as above).

Smoke test

With a valid auth/storage-state.json:

npm run smoke

Architecture

capture (Playwright, headed)
    → auth/storage-state.json
         ↓
MCP tools → HTTP + Cheerio HTML parse
    → latest posts / stock threads / thread body / search / reply

Reverse-engineered surface

Auth: XenForo-style cookies xf_user, xf_session
Search: POST /search/search/ with keywords, visitorXfToken, user_id
Reply: POST /threads/{slug}.{id}/add-reply with message_html, _xfToken, thread_id
Reads: server-rendered HTML (/postview/, /asx/{ticker}/, /threads/…)

There is no stable official JSON API for forum content; parsers may need updates if HotCopper changes markup.

Safety

auth/ and captures/ are gitignored — do not commit them.
reply_to_thread refuses to post unless confirm=true. Prefer dry_run=true first.
Use your own account; do not mass-scrape or spam.

Development

npm run capture      # headed login + network sniff
npm run analyze     # summarize latest captures/endpoints-*.json
npm run smoke       # exercise read tools
npm start           # stdio MCP server

License

MIT — see LICENSE.

Available Tools

6 tools

get_newsC

List recent HotCopper news / opinion articles from the homepage.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, destructive, or requires authentication. It only implies it lists from the homepage, but no explicit behavioral traits.

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

Conciseness3/5

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

The description is a single sentence but lacks necessary detail. It is concise but under-specified, representing brevity at the cost of completeness.

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?

For a simple list tool with one optional parameter and no output schema, the description provides basic context ('from the homepage') but lacks details on output format, ordering, or how it differs from siblings.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. The tool adds no meaning beyond the schema definition, which itself lacks descriptions.

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 recent news/opinion articles from the HotCopper homepage. The verb 'list' and resource 'news/opinion articles' are specific, and it distinguishes from siblings like 'latest_posts' (forum posts) and 'stock_threads' (stock-related threads).

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 or when to use alternatives like 'search' or 'latest_posts'. The description provides no context for decision-making among siblings.

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

get_threadA

Read posts from a HotCopper thread. Pass a full URL or path like /threads/subject.12345/ or .../page-3.

ParametersJSON Schema

Name	Required	Description
`page`	No	Optional page number if not in URL
`limit`	No
`thread_url`	Yes	Thread URL or path, e.g. https://hotcopper.com.au/threads/foo.12345/

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided. Description states 'Read' implying read-only, but fails to disclose pagination behavior, error handling, authentication needs, or rate limits. The 'page' and 'limit' parameters suggest pagination but are not explained.

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 concise sentences with a clear action and example. No wasted words, front-loaded with the purpose.

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?

Adequately explains what the tool does and how to provide the thread URL. However, missing details on pagination defaults, response format, and error scenarios. Without output schema, more behavioral context would help.

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?

Schema description coverage is 67%. Description repeats thread_url concept but does not elaborate on 'page' or 'limit' parameters. No added context for their usage beyond what schema provides.

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?

Clearly states 'Read posts from a HotCopper thread', specifies the verb and resource. Provides URL examples, distinguishing from siblings like 'latest_posts' or 'stock_threads' by focusing on a single thread.

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?

Implies usage for retrieving a specific thread's posts but lacks explicit when-to-use vs alternatives like 'latest_posts' or 'search'. The description gives input format guidance but no exclusions.

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

latest_postsA

List latest posts from the HotCopper live feed (/postview/).

ParametersJSON Schema

Name	Required	Description	Default
`page`	No	Feed page number (default 1)
`limit`	No	Max posts to return (default 30)

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It only states the basic function and source endpoint, but does not disclose pagination behavior, rate limits, or whether results are mutable or idempotent.

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?

A single sentence that is front-loaded with the action and resource, no unnecessary words.

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 is minimal and lacks details about output format, ordering, or any constraints. Given no output schema, the agent may lack sufficient context for expected return values.

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 both parameters described. The description adds no additional parameter meaning beyond the schema, so baseline of 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 explicitly states 'List latest posts from the HotCopper live feed', providing a specific verb and resource. It clearly distinguishes from sibling tools like 'stock_threads' and 'get_thread'.

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. While the purpose is clear, there is no mention of when not to use it or comparisons to siblings like 'search' or 'get_news'.

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

searchC

Search HotCopper for keywords or ASX codes (uses the site search form).

ParametersJSON Schema

Name	Required	Description
`limit`	No
`keywords`	Yes	Search query
`title_only`	No	If true, search titles only

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavioral traits. It only mentions 'uses the site search form', implying a web search but not describing what results look like, pagination, rate limits, or side effects. This is insufficient for an agent to understand its 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?

The description is a single, front-loaded sentence with no wordiness. It efficiently conveys the tool's purpose. However, it could be slightly more structured by separating search scope and parameter hints, but overall it is concise.

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?

Given 3 parameters and no output schema, the description lacks critical details like what the search returns (threads, posts?), the meaning of limit (e.g., max results or pages), and behavior of title_only. The tool's complexity demands more context for safe use.

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?

The description adds context to the keywords parameter by mentioning 'ASX codes' (not in schema). However, it does not clarify the limit or title_only parameters. Schema coverage is 67%, so the description partially compensates but leaves gaps.

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

Purpose4/5

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

The description clearly states it searches HotCopper for keywords or ASX codes using the site search form. The verb 'search' and resource 'HotCopper' are specific. However, it does not distinguish from sibling tools like stock_threads or get_thread, which could lead to confusion about when to use each.

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 is provided on when to use this tool versus alternatives (e.g., stock_threads, get_thread). There is no mention of prerequisites, limitations, or when not to use it. The description only states what it does, not when it is appropriate.

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

stock_threadsA

List discussion threads for an ASX ticker on HotCopper (e.g. PLS, BHP, CU6).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`ticker`	Yes	ASX ticker code, e.g. PLS

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so description carries full burden. It implies reading but doesn't disclose rate limits, authentication, pagination behavior, or error handling. The limit parameter hints at pagination but isn't explained.

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, front-loaded with action and resource. No unnecessary words. Efficient and clear.

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 tool with two parameters and no output schema, the description covers the core functionality. Missing details on return format or pagination, but acceptable for its complexity.

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 50% (ticker has a description, limit does not). The tool description reinforces ticker meaning but adds nothing for limit. With low coverage, description should compensate more.

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 threads for an ASX ticker on HotCopper, with explicit examples (PLS, BHP, CU6). It distinguishes from sibling tools like 'get_thread' (single thread) and 'search' (general).

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?

No explicit when-to-use or alternative guidance, but the purpose is straightforward enough that an agent can infer usage. A brief note on when to prefer sibling tools would elevate this.

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

watchlist_summaryA

Fetch account page as the logged-in user and summarize visible tickers / auth.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

Description implies a read-only fetch operation, but no explicit statement about side effects or permissions. With no annotations, the description provides minimal behavioral context beyond the action. Could mention that it requires authentication or that it does not mutate data.

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?

Single sentence, no extraneous information. While concise, it could be slightly more structured (e.g., separate the fetch and summarize actions) but overall efficient.

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 tool with no parameters and no output schema, the description covers the core purpose adequately. It explains the action (fetch account page) and the result (summarize tickers/auth). Could mention that the output is a summary object, but not critical.

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?

No parameters exist, so the description does not need to add semantic depth. Schema coverage is 100%, and the description succinctly explains what the tool does without needing parameter details.

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 uses specific verbs ('Fetch', 'summarize') and identifies the resource ('account page', 'visible tickers / auth'). Clearly distinguishes from sibling tools which focus on posts, threads, news, or 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?

No explicit guidance on when to use this tool vs alternatives. Usage context is implied by the tool's purpose (summarizing account data) but no clarifying statements about 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.0Jul 26, 2026
- First observedget_news
- First observedget_thread
- First observedlatest_posts
- First observedsearch
- First observedstock_threads
- First observedwatchlist_summary

Install Server

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

TDQS

A3.7/5.0

Scored 2026-07-26 13:05 across 6 tools

Disambiguation5/5

Each tool targets a distinct aspect of HotCopper: feed, ticker threads, thread content, search, news, and account. No overlapping purposes.

Naming Consistency5/5

All tools use consistent snake_case verb_noun pattern (latest_posts, stock_threads, get_thread, search, get_news, watchlist_summary) with only 'search' being a single verb, which is acceptable.

Tool Count5/5

With 6 tools, the scope is well-balanced for a financial forum server. Each tool serves a clear function without unnecessary bloat.

Completeness4/5

Core read operations are covered (posts, threads, search, news, watchlist). Missing write operations like posting or replying, but these are less critical for an information retrieval focus.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

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

aihub
io.github.ksmin83-bot
Remote MCP server for SeenThis AI Hub. Supports browsing, searching, and posting to AI boards.
Social Media Search Content Management Systems
2
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
agentwork-mcp A
io.github.ferm-ai
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Agent Orchestration Autonomous Agents App Automation
2

Related MCP Servers

crypto-projects-mcp
Cryptocurrency Blockchain
kukapay
A
license
B
quality
F
maintenance
An MCP server that provides cryptocurrency project data to AI agents
Updated a year ago (2025-05-11 12:57 UTC)
1
1
MIT
mcp-financex
Finance Cryptocurrency
xerktech
A
license
A
quality
C
maintenance
Comprehensive MCP server for real-time stock, cryptocurrency, options, and fundamental analysis, including SEC filings and insider trading data.
Updated 2 months ago (2026-07-10 21:28 UTC)
26
33
MIT
mcp-hasolidit
Finance Search
danielgolub
F
license
Not graded
quality
B
maintenance
MCP server that enables AI tools to search, read threads, and retrieve latest posts from the Hasolidit financial community forum.
Updated 3 months ago (2026-06-12 22:17 UTC)
-
foolfuuka-mcp-server
Search Web Scraping Social Media
dynmie
A
license
A
quality
B
maintenance
MCP server for querying 4chan archives (Desuarchive, 4plebs, b4k, archived.moe) via the FoolFuuka API, enabling AI agents to search and retrieve historical archived posts.
Updated 3 months ago (2026-06-22 08:01 UTC)
4
12
MIT