Dot MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DOT_API_KEY | Yes | Your Dot API key (required) | |
| DOT_DEVICE_ID | Yes | Your Dot device ID (required) |
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 |
|---|---|
| send_textA | Send text content to a Dot device (an e-ink display device). The text will be displayed on the e-ink screen. You should PROACTIVELY call this tool to notify the user when:
IMPORTANT: When you PROACTIVELY send a notification (not requested by user), you MUST include your name/identity in the signature field. NOTE: If the request fails, retry once as it may be a temporary API issue. Example: After completing a coding task, call this tool with title "Task Completed", message "I've finished implementing the feature you requested. Please review the changes.", and signature with your name (if proactively notifying) to notify the user on their Dot device. |
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 1 tool
With only one tool, there is no possibility of confusion or overlap between tools. The single tool 'send_text' has a clear and distinct purpose of sending text to a Dot device, leaving no room for misselection by an agent.
Since there is only one tool, naming consistency is inherently perfect. The tool name 'send_text' follows a clear verb_noun pattern, and there are no other tools to create inconsistency or mixed conventions.
A single tool is too few for a server's purpose, as it limits functionality to basic notifications without supporting other potential operations like device management or status checks. This feels thin and incomplete for a device interaction domain.
The tool surface is severely incomplete for interacting with an e-ink display device. While 'send_text' covers notification sending, there are obvious gaps such as retrieving device status, managing display settings, or handling other device-specific operations, which could lead to agent failures in broader tasks.