AutoTool
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_toolA | Create a new tool when none of your current tools can do what the task needs (a web API, live data, a computation). Write a complete Python MCP tool server script (MCPServer); AutoTool verifies it in a guarded subprocess, injects only the credentials it declares, and mounts it: its tools appear in your tool list (or call them through run_tool). If verification fails you get the error; fix the code and call create_tool again with the same name. The script MUST follow this contract:
No credentials are available: only use public, keyless APIs and do not declare REQUIRED_ENV. Structural reference: |
| run_toolA | Call a tool created with create_tool by its full name (e.g. 'weather_tool__current'). Use this if a newly created tool does not show up in your tool list. |
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
create_tool and run_tool have clearly distinct purposes: one writes and mounts a new Python MCP server, the other invokes an already-created tool by name. There is no overlap in intent or expected arguments.
Both names follow a clean snake_case verb_noun pattern (create_tool, run_tool), sharing the same noun and differing only in the action verb. Fully predictable.
Two tools is minimal, but for a self-extending meta-server this is the core lifecycle: author a tool, then call it. The actual capability surface is unbounded via generated tools, so the small count is justified rather than thin.
The create/execute loop is fully covered and re-calling create_tool with the same name handles regeneration. Minor gaps remain: no explicit list of generated tools, no removal or inspection of mounted tool metadata, though the host tool list largely compensates.