botcan-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| play_recipeB | Execute a YAML recipe file: open pages, run browser steps, return extracted data. |
| play_stepsC | Execute an inline YAML recipe string (agent-generated). Args mirror recipe file format. |
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 2 tools
Both tools execute YAML recipes; the only difference is file vs inline string input. Descriptions clarify the distinction, but the core action overlaps, and the names play_recipe vs play_steps could confuse an agent about which to use.
Both tools follow a clear verb_noun pattern with the same verb 'play_', making the naming predictable and consistent throughout.
Only two tools are provided, which feels thin for a recipe execution server. While both earn their place, the set is borderline minimal for the apparent scope.
The surface covers file-based and inline execution, but notable operations like recipe validation, listing available recipes, or error handling without execution are missing. Agents can work around these gaps, but they are significant.