Public Feature Board and Roadmap Monitor
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify API token from console.apify.com/account/integrations. The server lists its tool without a token; a call needs one. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_feature_board_requestsA | Find a company's public feature board from its domain (for example clickup.com) and return its top requests. The homepage is read for a link to a feedback board or public roadmap, including one on the company's own subdomain; when none is linked, the common Canny, Featurebase, Frill, and UserVoice addresses are checked and a board is used only when it links back to the company domain. You get one company_board row (platform, board URL, total posts, top request, status counts, and the integrations customers ask for) and one request row per feature request, most votes first, with votes, status, comments, board, and an integration flag naming the product asked for. With only_new and a state_key, only new requests, status changes, and vote jumps since the last run. A Productboard portal comes back as a link. No board, a blocked board, and a board with no readable request are free. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges once per company whose board was found and read. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
With only one tool there are no tool boundaries to confuse, so misselection is impossible. The caveat is that this clarity comes from consolidating every behavior (discovery, fetching, delta tracking) into one tool rather than from well-separated tools.
The single name, get_feature_board_requests, is a clear snake_case verb_noun phrase consistent with common MCP conventions. There is only one name, so no inconsistency is possible, though the plural object and long compound are slightly awkward.
A one-tool server is borderline thin: the tool bundles board discovery, request retrieval, and run-over-run delta tracking into a single call with only only_new/state_key as control parameters. It works for the narrow purpose but offers no granularity for agents that want just discovery or just a refresh.
The core read-only workflow (find board, list top requests with votes/status/integrations, detect changes since last run) is covered. Notable gaps exist: no way to fetch a specific request or its comment thread, no multi-company or multi-board comparison, and no routine that continues past the top requests or previous-run delta.