wais-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PLATFORM_URL | No | WAIS Provider URL | https://pod.deeger.io |
| WAIS_API_KEY | Yes | API key from provider dashboard |
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 |
|---|---|
| wais_discoverA | Discover what a WAIS-compatible site offers. Call this first for any site. Fetches /.well-known/agents.json and returns a summary showing:
The agents.json is the source of truth. Use the action IDs and parameter schemas it defines when calling wais_execute. Args: site_url: The site's URL (e.g. "https://serphub.deeger.io"). |
| wais_registerA | Register the user at a WAIS-compatible site using their WAIS identity. Uses SD-JWT selective disclosure — only shares the claims listed in agents.json data_requirements.registration.required_claims. Call wais_discover first to see what claims the site needs. Args: site_url: The site.url from agents.json. claims: Claims to disclose (e.g. ["email"]). If not provided, uses required_claims from agents.json automatically. |
| wais_executeA | Execute an action at a WAIS-compatible site. Uses the agents.json from wais_discover to resolve the action's endpoint, HTTP method, and required scopes. If the site has an api_base_url, requests are routed there automatically. Tokens and DPoP proofs are handled internally. Pass site.url (from agents.json) as site_url, the action id, and params matching the action's input_schema. Examples: wais_execute("https://serphub.deeger.io", "search", {"query": "python"}) wais_execute("https://serphub.deeger.io", "get_usage") wais_execute("https://serphub.deeger.io", "list_jobs", {"limit": 5}) Args: site_url: The site.url from agents.json (shown in discover output). action_id: The action id from agents.json (e.g. "search", "get_usage"). params: Parameters matching the action's input_schema. |
| wais_confirmA | Confirm a high-risk action or complete a payment challenge. Call after wais_execute returned a 402 confirmation challenge and the user has approved. If there was a payment link, the user must complete payment first. Polls for completion automatically if the challenge included a resolution object. Args: site_url: The site.url from agents.json. challenge_id: The challenge_id from the 402 response. |
| wais_statusA | Check the user's account status at a WAIS-compatible site. Returns plan, credits, usage stats. The user must be registered first. Looks for a 'get_usage' or 'status' action in agents.json. Args: site_url: The site.url from agents.json. |
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 5 tools
Each tool has a unique, clearly defined purpose: discovery, execution, confirmation, registration, and status checking. No overlap or ambiguity between them.
All tools follow the consistent pattern 'wais_<verb>' with snake_case, such as wais_discover, wais_execute, wais_confirm, wais_register, and wais_status.
With 5 tools, the server is well-scoped for the WAIS protocol domain. It covers all essential operations without unnecessary extras or gaps.
The tool surface provides a complete workflow: discover site capabilities, register, execute actions, handle payment confirmations, and check status. No obvious missing functionality for the intended use case.