icantmarket-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ICANTMARKET_BASE_URL | No | Override for staging / self-host. | https://icantmarket.com/api/v1 |
| ICANTMARKET_API_TOKEN | No | Bearer token from /me/api-tokens. Required for write tools (whoami, post_ask, submit_review). |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_productsA | List verified products on icantmarket. Public, no auth needed. Use this to find product slugs and UUIDs before posting an ask or to help a user browse the maker cohort. Only L1+ verified active products are returned. |
| get_productA | Fetch a single verified product by slug. Public. Returns the product details plus the count of currently open asks. Useful to grab a product UUID before posting an ask, or to summarize a product for the user. |
| list_asksA | List open public asks on icantmarket. Public, no auth needed. Use this when the user wants to find a review opportunity that fits their profile, or when they're researching the kind of help requests the community posts. Verified-only asks are not returned (they stay behind the page-level helper-cohort gate). |
| get_askA | Fetch one public ask by UUID, with the bundled product summary. Returns 404 / error if the ask is verified-only. Use this after list_asks to inspect an ask in detail before deciding to review it. |
| whoamiA | Confirm the configured ICANTMARKET_API_TOKEN is valid and return the principal user (id, email, handle, isAdmin, helperVerifiedAt). Cheap, no side-effects. Call once on startup to cache the user id. |
| post_askA | Post a structured ask on behalf of the authenticated maker. Requires ICANTMARKET_API_TOKEN. The maker must own the target product (use list_products to find product_id), and the product must be at L1+ trust. Second-and-onward asks require a credited Helpful/Completed review (Review-to-Post gate). Hype-words (revolutionary / game-changing / best-in-class / etc.) trigger 422 — rewrite, or retry with hype_acknowledged=true to override and accept the soft-flag. Voice rule: factual, concrete, with a real 'offer_back' and a measurable 'success_criteria'. |
| submit_reviewA | Submit a substantive review on someone else's open ask. Requires ICANTMARKET_API_TOKEN. Cannot self-review own asks. Body is scored for hype-words, content-fingerprint similarity against the reviewer's prior reviews, profile-match, sock-puppet clustering, and AI-content detection. Flags don't block; they surface on the admin review queue. The recipient sets the Helpful/Completed verdict later — that's what credits the reviewer's Review-to-Post balance. Use list_asks to find an ask UUID first. |
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 7 tools
Each tool targets a distinct resource and action: products versus asks versus user identity, and list versus get versus submit/post. Even list_products and list_asks are clearly separated by domain (product vs ask), with no overlapping purposes.
The vast majority follow a consistent verb_noun pattern: list_products, get_product, list_asks, get_ask, submit_review, post_ask. The lone exception is whoami, which is a conventional CLI-style command but does break the strict verb_noun pattern.
Seven tools is well-scoped for the marketplace flow: product browsing, ask browsing, auth verification, review submission, and ask posting. Each tool maps to a clear user need without redundancy or bloat.
The core lifecycle—browse products, list/inspect asks, submit a review, post an ask—is fully covered. Minor gaps exist such as no tool to view one's own Review-to-Post balance or manage/delete an ask, but these are not required for the primary workflow.