wca-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WCA_PROJECT_ROOT | No | Overrides the path to this checkout. The optional clients (Codex plugin and Claude Code skill) find the checkout relative to their own folder; WCA_PROJECT_ROOT overrides it. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ask_chatgptA | Send one question and optional PDF through signed-in Chrome and return ChatGPT's answer. |
| read_chatgpt_conversationA | Read the latest assistant response from an existing ChatGPT conversation. |
| discover_siteA | Inspect one public page and list likely content links. This never downloads a collection. Use it first for an unfamiliar site, then ask the user which collection they want. |
| create_collectionB | Create a safe WebContent collection and source.yaml without starting a job. |
| start_collectionB | Start the existing worker as an independent background process. |
| get_run_statusA | Get concise progress for a run without returning full logs. Use this when the user asks how a download is going. Never call it repeatedly in one response. |
| resume_runB | Resume a failed or interrupted run without repeating completed work. |
| validate_runB | Validate final outputs, hashes, and local image paths. Use after status reports success. |
| list_collectionsB | List collections with source URL, latest status, and content counts. Use for questions about existing collections or the latest run. |
| get_failureA | Return a redacted failure summary and bundle path for a failed run. Never returns cookies, authorization headers, credentials, or full logs. |
| create_context_handoffA | Compress durable run state into a small snapshot for continuing in a new Chat. Use once when a Chat becomes long or before a long background wait. It intentionally omits page bodies, logs, screenshots, repeated tool results, and hidden reasoning. |
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 11 tools
The collection lifecycle tools (create/start/get_run_status/resume/validate/list/get_failure) each target a distinct stage, and the ChatGPT pair (ask vs read) is clearly separated. Minor adjacency exists between get_run_status and get_failure, and between start_collection and resume_run, but descriptions disambiguate them adequately.
Every tool follows a consistent snake_case verb_noun (or verb_resource) pattern: create_collection, start_collection, get_run_status, list_collections, resume_run, validate_run, discover_site, ask_chatgpt. No mixed conventions or vague bare verbs.
11 tools is well within the healthy range and each tool maps to a real step in the web-collection workflow or the ChatGPT bridge. No tool appears redundant or padded.
The surface covers discovery, creation, execution, monitoring, resumption, validation, and failure inspection, which is strong lifecycle coverage. Gaps remain: no cancel/stop for a running collection and no delete/update for collections, though agents can work around these.