wcc
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WCC_DATA_DIR | No | Where templates and history are stored. Absolute paths only; defaults to the OS per-user data directory. | |
| WCC_ALLOW_PRIVATE_NETWORK | No | Set to 1 to allow loopback and private addresses. Development only — it switches off the SSRF boundary of specification 10.2. |
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 |
|---|---|
| open_sessionA | Open a browser session on a URL and report what page it landed on. The URL policy is enforced before the session is returned, so a refused address never becomes a session. |
| inspect_pageA | Read the current page and return the capabilities it supports, the entities it is about, and anything the compiler refused. Reuses a stored template for the page class when one binds, and compiles a new one only when none does. |
| list_capabilitiesA | List the capabilities already bound in this session, optionally filtered by category and by a maximum risk level. Inspect the page first; this reports what that inspection found. |
| execute_capabilityA | Run one bound capability and return the complete result: the steps that ran, what changed on the page, whether the intended effect was verified, and the entities the resulting page is about. Only low-risk capabilities execute; anything else is refused with a reason. |
| get_execution_resultA | Retrieve a stored execution result. Only the session that produced the execution can read it. |
| close_sessionA | Close a session and retire its capabilities. Closing an already closed session is not an error. |
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 6 tools
Each tool has a distinct role in the session lifecycle: opening, inspecting, listing, executing, retrieving results, and closing. There is no overlap in purpose; even get_execution_result and execute_capability differ in that one runs a capability and the other fetches a stored result.
All tool names follow the same verb_noun snake_case pattern (open_session, inspect_page, list_capabilities, etc.). The verbs are clear and the nouns correspond to the domain entities, making the set highly predictable.
With 6 tools, the server is well-scoped for its purpose of session-based browser automation. Each tool is necessary and covers a distinct step in the workflow, neither too few nor too many.
The lifecycle from opening a session through inspection, capability execution, result retrieval, and closing is fully covered. The only notable gap is the lack of an explicit navigation tool to change the URL within an open session, though capabilities may inherently handle page changes.