webdev-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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| listScreensA | List available screens/displays that can be captured |
| takeScreenshotA | Take a screenshot of a specific screen and return it as a base64 encoded string. |
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
The two tools have clearly distinct purposes: listScreens identifies available screens for capture, while takeScreenshot performs the actual screenshot operation on a specified screen. There is no overlap or ambiguity between these functions, making it easy for an agent to select the correct tool based on the task.
The naming is inconsistent: listScreens uses camelCase, while takeScreenshot uses camelCase but with a different verb style (list vs. take). Although both are camelCase, the lack of a uniform verb_noun pattern (e.g., list_screens, take_screenshot) and mixed verb conventions reduce predictability and readability.
With only 2 tools, the server feels too thin for the web development domain implied by the name 'webdev-mcp'. This limited set lacks essential operations such as screen recording, window management, or other common web development tasks, making it insufficient for comprehensive coverage.
The tool surface is significantly incomplete for a web development server. While listScreens and takeScreenshot cover basic screenshot functionality, there are obvious gaps like capturing specific windows, recording screen activity, or integrating with web development workflows (e.g., browser automation, code editing). This will likely cause agent failures in broader tasks.