About askboard
askboard is a local bridge to FeatQ's hosted feature-request board for software teams. It relays board tools, including request ranking and statistics, status updates, and implementation-spec drafts, without storing board data locally.
Key features
- 01List and filter feature requests
- 02Retrieve request details and comments
- 03View board statistics and ranked requests
- 04Draft implementation specs
- 05Update request status
- 06Read competitor claims
Use cases
- 01Review the most requested product features
- 02Inspect a request and its discussion
- 03Draft an implementation spec from a request
- 04Move a request through board statuses
MCP support
askboard exposes the captured FeatQ tool list through a local MCP server and forwards calls to the hosted MCP server. Upstream results are passed through.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
Tools
7Saved tool list · updated 1w ago
| Parameter | Type | Required | Description |
|---|---|---|---|
| sort | enum | No | Ordering of results: votes (most voted first) or newest.votes | newest |
| limit | integer | No | Maximum number of requests to return. |
| status | enum | No | Filter by request status: new, considering, planned, in_progress or done.new | considering | planned | in_progress | done |
Details
From the project READMEaskboard
askboard is a small local bridge to FeatQ's hosted MCP server, which runs a feature-request board for a software product: customers and teammates file requests, vote and comment on them, and the board keeps track of what is new, planned, in progress or done.
The bridge keeps no board data of its own. It serves the
upstream server's tool list locally, exactly as captured
from the live endpoint, and forwards each tool call
upstream, returning the result untouched. One tool in
the captured surface writes — update_request_status
changes a request's status on the hosted board — and
one generates a document: generate_spec drafts an
implementation spec for a single request. Everything
else reads.
Tools
list_requests— list the board's feature requests. Optional filters:status(new,considering,planned,in_progressordone),sort(votesornewest, defaultvotes) andlimit(1-50, default 20).get_request— one feature request in full, with its comments. Required:id.get_board_stats— the board at a glance: request counts, vote totals and the top requests. No arguments.get_ranked_requests— the top requests by demand score, excluding ones already marked done. A vote counts as one point and a comment as half a point, scores decay as a request ages on a 90-day scale, and ties go to the newer request. Optional:limit(1-20, default 5).generate_spec— an agent-ready markdown implementation spec for one feature request. Required:id.update_request_status— move a request to a new status (new,considering,planned,in_progressordone). Required:id,status. Marking a request done makes it appear in the public changelog.list_competitor_claims— what watched competitor comparison pages say about this product. Read only; claims are signals, not votes. Optional:state(new,addedordismissed, defaultnew) andlimit(1-100, default 25).
Configuration
FEATQ_MCP_URL(optional) — override the upstream endpoint. Defaults tohttps://featq.com/api/mcp. (The override hook is this rebuild's own labelled reconstruction.)FEATQ_API_KEY(optional) — when set, every upstream request carries anAuthorization: Bearer <key>header. When it is not set, no auth header is sent. (This forwarding is also a labelled reconstruction; the original surface was captured keyless.)
Forwarding mechanics
On the first tool call the client opens a streamable
HTTP session with the upstream: a JSON-RPC initialize
request (protocolVersion 2025-03-26, clientInfo name
askboard), then a notifications/initialized
notification, then the tools/call request carrying
the caller's arguments unchanged. When the upstream
answers initialize with an Mcp-Session-Id header,
that value rides on every later request of the session,
which is reused for the life of the process. Replies
may arrive as plain JSON or as server-sent events;
both are read.
Successful upstream results pass through verbatim,
including any isError flag the upstream sets.
Failures — a JSON-RPC error, a non-2xx status, an
unreadable response, or a request that cannot be
completed — come back as an isError result whose
text starts with askboard error: (this rendering
is this rebuild's own labelled reconstruction).
CLI
Each tool is also a subcommand taking one JSON argument string (omit it for tools that take none):
npx @reneturcios/askboard list_requests '{"status":"planned","sort":"votes"}'
npx @reneturcios/askboard get_request '{"id":"req-42"}'
npx @reneturcios/askboard get_board_stats
npx @reneturcios/askboard update_request_status '{"id":"req-42","status":"done"}'
npx @reneturcios/askboard --version
Exit codes: 0 on success, 1 on an isError
result, 2 on a usage error.
MCP server
npx -y @reneturcios/askboard mcp
MCP client config:
{
"mcpServers": {
"askboard": {
"command": "npx",
"args": ["-y", "@reneturcios/askboard", "mcp"]
}
}
}
Docker
docker run -i ghcr.io/cloudcorprecords/askboard
docker run --rm ghcr.io/cloudcorprecords/askboard --version
The container's default command is mcp, so the first
form is a stdio MCP server; any other arguments reach
the CLI normally.
Development
npm install
npm run build
npm test
npm run dev
The test suite runs entirely against a stubbed JSON-RPC upstream — no live network calls.
License
MIT — see LICENSE.
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.