Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@widgetdash-mcp Put my Stripe MRR on my iPhone widget."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Let your AI agent put any number on your iPhone.
WidgetDash shows numbers from any service on iPhone Home Screen widgets, Lock Screen widgets and Live Activities. This Model Context Protocol server lets Claude Desktop, Claude Code, Cursor and other MCP clients push data to your widgets and read it back. You just ask:
"Put my Stripe MRR on my iPhone widget."
The free WidgetDash iOS app: https://apps.apple.com/us/app/widgetdash/id6761054679, with a WidgetDash widget on your Home Screen or Lock Screen.
Your API keys. Get them at https://widgetdash.app/app.
Write key: lets the agent create and update your widget data.
Read key (optional): read-only access. If you leave it out, the read tools use the write key.
Node.js 18 or newer (npx comes with it).
Related MCP server: iPhone MCP
claude mcp add widgetdash -e WIDGETDASH_WRITE_KEY=your-write-key -- npx -y widgetdash-mcpEdit claude_desktop_config.json (Settings → Developer → Edit Config), then restart Claude Desktop:
{
"mcpServers": {
"widgetdash": {
"command": "npx",
"args": ["-y", "widgetdash-mcp"],
"env": {
"WIDGETDASH_WRITE_KEY": "your-write-key",
"WIDGETDASH_READ_KEY": "your-read-key"
}
}
}
}Add this to ~/.cursor/mcp.json for all projects, or .cursor/mcp.json for one project:
{
"mcpServers": {
"widgetdash": {
"command": "npx",
"args": ["-y", "widgetdash-mcp"],
"env": { "WIDGETDASH_WRITE_KEY": "your-write-key" }
}
}
}Other MCP clients that can launch a stdio server work the same way. The command is npx -y widgetdash-mcp, and the keys go in the environment variables below.
Variable | Required | Description |
| For writes | Write key from https://widgetdash.app/app. |
| No | Read key. |
| No | API base URL. Default: |
"Put my Stripe MRR on my iPhone widget." (The agent reads the number with a Stripe tool, then calls push_number.)
"Show today's GitHub stars, open issues and open PRs for my repo on my Lock Screen widget."
"Make a 'Server' widget with CPU as a progress bar, uptime as a number and a green 'Healthy' status badge."
"Every time you finish a build, set the 'CI' widget status to Passing or Failing."
"What's on my WidgetDash widget right now?"
"Remove the old 'test' source from my widget."
Tool | What it does |
| Sets one value on a source, e.g. |
| Creates or updates a source: title ( |
| Lists your sources (key, title, icon, hidden or shown) and how many your plan allows. The free plan allows 5. |
| Shows what's on the widget now: every enabled source with its metrics and last update time, or a single source. |
| Permanently deletes a source and ends any Live Activity for it. |
Each metric has a label, a value, an optional type and an optional color:
type sets how the widget draws the value:
number: a big bold figure.
text: a plain string.
status: a colored badge.
progress: a bar. The value must be 0 to 100, and a trailing % is removed for you.
percentage: compact percent text.
If you leave type out, values that look like numbers (42, $12,400, 3.5%) become number and everything else becomes text. With push_number, an existing metric keeps its current type and color.
color: green, red, yellow, blue, gray, orange, purple or cyan.
icon: any SF Symbol name, e.g. dollarsign.circle.fill, chart.bar.fill, server.rack or heart.fill.
Fields you leave out (display_name, icon, category, sort_order, raw_data) keep their current values. This means an update from the agent won't undo the order you set in the app.
The write key can only write your own widget data. It can't reach other users' data or your account's billing.
Keys go only in the Authorization header of requests to the WidgetDash API. The server never logs them and removes them from any error text it returns.
Treat the write key like a password. If it leaks, rotate it at https://widgetdash.app/app.
The server only talks to WIDGETDASH_API_URL, which is https://api.widgetdash.app by default.
npm install
npm run build # compiles src/ to dist/
npm test # builds, then runs the end-to-end testsnpm test runs every tool through a real MCP client over stdio, against an in-memory mock of the WidgetDash API (test/mock-api.mjs). It needs no network and no keys, and it never contacts production.
To try it interactively, run npx @modelcontextprotocol/inspector node dist/index.js.
server.json is the entry for the official MCP Registry under the name io.github.purian/widgetdash-mcp, following schema 2025-12-11. The mcpName field in package.json must match that name for npm ownership verification. Status: draft. It hasn't been published yet, and the registry is still in preview, so check server.json against the current schema before running mcp-publisher publish.
MIT © WidgetDash
Permanently delete a data source (and its data) from the user's WidgetDash iPhone widgets. Ends any Live Activity for it. Only do this when the user asks to remove it. Requires WIDGETDASH_WRITE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| source_key | Yes | The source_key to delete (see list_sources). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint and idempotentHint, but the description adds material specifics beyond them: the deletion is permanent and cascades to the source's data, it terminates any associated Live Activity, and it requires WIDGETDASH_WRITE_KEY. These are exactly the irreversible side effects and auth requirements an agent needs before invoking a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: what is deleted, the side effect, the usage constraint, and the auth requirement. The destructive action is stated first and nothing is repeated from the annotations or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with no output schema, the description covers the operation, its cascading consequences, the required credential, and when it should be used. Nothing an agent needs to invoke this safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single required parameter (source_key) already documented with pattern, length, and a pointer to list_sources. The description adds no parameter-level detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with a precise verb+resource+scope: 'Permanently delete a data source (and its data) from the user's WidgetDash iPhone widgets.' It also names the cascading effect ('Ends any Live Activity for it'), so an agent knows exactly what operation it is. Sibling differentiation is only implicit (the schema points to list_sources), but the purpose itself is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Only do this when the user asks to remove it' gives an explicit when-to-use condition and an implied guardrail against proactive deletion. It stops short of naming alternatives (e.g., list_sources for inspection) or noting prerequisites beyond the key, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read what is currently shown on the user's WidgetDash iPhone widgets: every enabled source with its metrics and last update time, or one source if source_key is given. Uses WIDGETDASH_READ_KEY, or the write key if no read key is set.
| Name | Required | Description | Default |
|---|---|---|---|
| source_key | No | Only return this source. Omit to return all sources shown on the widget. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds a genuinely useful operational fact: it authenticates with WIDGETDASH_READ_KEY, falling back to the write key when no read key is set. It also indicates the return payload contains metrics and last update time, though it does not detail error or auth-failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, no filler, with the primary behavior (what is shown on the widget) front-loaded ahead of the mode switch and the auth note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing results and does so at a high level (enabled sources, metrics, last update time) plus the auth mechanism. A slightly fuller sketch of the returned structure would close the remaining gap for an open-world read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter's description already explains that omitting it returns all sources. The description's 'or one source if source_key is given' restates the schema rather than adding format or constraint detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: reading what is currently displayed on the user's WidgetDash iPhone widgets, including metrics and last update time. That framing (current widget state) is distinguishable from generic source management, though the distinction from list_sources is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear selection logic for the two modes: omit source_key for all enabled sources, supply it for a single source. It does not explain when to prefer this over the sibling list_sources, which appears to overlap in returning source information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the data sources on the user's WidgetDash iPhone widgets (source_key, title, icon, enabled/hidden) plus the plan's source usage (the free plan allows 5 sources). Uses WIDGETDASH_READ_KEY, or the write key if no read key is set.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint already declared, the description adds meaningful context: it discloses the required credential (WIDGETDASH_READ_KEY, falling back to the write key) and describes the returned fields and plan quota. It does not cover rate limits or error behavior, but the auth detail is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences that front-load the list operation and then cover return fields, plan quota, and authentication. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only list tool, the description covers what is returned, the auth mechanism, and plan constraints. With no output schema, this is sufficient; nothing critical for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the rubric sets the baseline at 4. The description adds no parameter-level information because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('data sources on the user's WidgetDash iPhone widgets'), and enumerates the returned fields. It clearly separates from push_* and delete_source siblings, but does not explicitly contrast with get_widget_data, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no alternatives named, and no exclusion criteria. The only usage signal is the auth-key note, which explains how to authenticate rather than when this tool is the correct choice over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update a WidgetDash data source shown on the user's iPhone Home Screen / Lock Screen widgets and Live Activities. Sets the source's title, SF Symbol icon, category and its full list of metrics (label + value + type + color). The metrics list REPLACES the source's current metrics; use push_number to change a single value. Omitted display_name/icon/category/sort_order keep their current values. Requires WIDGETDASH_WRITE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| icon | No | SF Symbol name shown next to the title, e.g. 'dollarsign.circle.fill', 'chart.bar.fill', 'server.rack', 'heart.fill', 'cart.fill'. If omitted, keeps the existing icon (default 'circle.fill'). | |
| metrics | Yes | Metrics to show, in display order. Small widgets show the first few, so put the most important first. | |
| category | No | Free-form grouping, e.g. 'finance', 'monitoring', 'fitness'. If omitted, keeps the existing category (default 'general'). | |
| raw_data | No | Optional arbitrary JSON object stored alongside the metrics (not shown on the widget). If omitted, existing raw_data is kept. | |
| sort_order | No | Position among sources on the widget (lower first). If omitted, keeps the existing order (default 0). | |
| source_key | Yes | Stable identifier for this data source, e.g. 'stripe_mrr' or 'server_health'. Lowercase letters, digits, '_' or '-'. Pushing to an existing key updates it; a new key creates a new widget source. | |
| display_name | No | Title shown on the widget, e.g. 'Stripe'. If omitted, keeps the existing name (or derives one from source_key for new sources). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (idempotent, non-destructive, open-world), but the description adds the critical behavioral fact that the metrics list REPLACES existing metrics, that omitted display fields are preserved, and that a write key is required. These are non-obvious traits not derivable from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler: identity and effect first, the replace-vs-merge caveat second, the alternative tool and auth requirement last. Nothing repeats the schema verbatim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-param upsert tool with nested objects and no output schema, the description covers purpose, merge behavior, auth, and sibling routing. It does not say what the call returns or whether a source_key response payload is produced, a minor gap given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description goes slightly beyond by summarizing the field set (title, icon, category, metrics) and emphasizing the destructive replace semantics of the metrics array, which the schema only implies through item descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb pair (create or update) and resource (WidgetDash data source) with the concrete surface it affects (iPhone Home Screen / Lock Screen widgets and Live Activities). It also names the sibling it is not (push_number), so an agent can separate the two without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: use push_number to change a single value, use this tool to set the full metrics list. It also states the merge semantics for omitted fields and the required WIDGETDASH_WRITE_KEY, which is exactly the when/how guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quickest way to put a single number or value on the user's iPhone Home Screen / Lock Screen widget via WidgetDash, e.g. 'Stripe MRR = $12,400' or 'Open tickets = 7'. Sets one metric (matched by label) on a source, keeping the source's other metrics, title and icon; creates the source if it does not exist. Requires WIDGETDASH_WRITE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| icon | No | SF Symbol name shown next to the title, e.g. 'dollarsign.circle.fill', 'chart.bar.fill', 'server.rack', 'heart.fill', 'cart.fill'. If omitted, keeps the existing icon (default 'circle.fill'). | |
| type | No | Optional; defaults to the existing metric's type, else inferred from the value. | |
| color | No | Optional accent color (green/red/yellow/blue/gray/orange/purple/cyan); defaults to the existing metric's color. | |
| label | Yes | Short label shown on the widget, e.g. 'MRR' or 'Users online'. | |
| value | Yes | The value to display, pre-formatted as you want it shown (e.g. '$12,400', '42', 'Healthy'). For 'progress' use 0-100. | |
| category | No | Free-form grouping, e.g. 'finance', 'monitoring', 'fitness'. If omitted, keeps the existing category (default 'general'). | |
| sort_order | No | Position among sources on the widget (lower first). If omitted, keeps the existing order (default 0). | |
| source_key | Yes | Stable identifier for this data source, e.g. 'stripe_mrr' or 'server_health'. Lowercase letters, digits, '_' or '-'. Pushing to an existing key updates it; a new key creates a new widget source. | |
| display_name | No | Title shown on the widget, e.g. 'Stripe'. If omitted, keeps the existing name (or derives one from source_key for new sources). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare write (readOnlyHint=false), non-destructive, and idempotent behavior. The description adds genuine value beyond them: it clarifies that other metrics, title and icon are preserved, that a missing source is created, and that WIDGETDASH_WRITE_KEY is required. It omits return format and any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the primary purpose and an example, followed by upsert behavior and the auth requirement. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter write tool with no output schema and full schema coverage, the description covers upsert semantics, preservation of existing fields, and the write-key requirement, which is largely sufficient. It could say more about what a successful push returns, but the core is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by stating the metric is 'matched by label', clarifying the identity key for the upsert, plus a worked example ('Stripe MRR = $12,400') that illustrates pre-formatted value input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('put a single number or value on the user's iPhone Home Screen / Lock Screen widget') and includes concrete examples. The emphasis on 'a single number' inherently distinguishes it from the sibling push_metrics, which handles batches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when to reach for this tool ('Quickest way to put a single number or value') and explains the upsert outcome when the source exists or not. It does not explicitly name push_metrics as the alternative for multiple values or state exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0delete_sourceget_widget_datalist_sourcespush_metricspush_numberScored across 5 tools
push_metrics and push_number could be confused (both write to a source), but the descriptions explicitly clarify that one replaces the whole metrics list while the other updates a single value. The two read tools (list_sources vs get_widget_data) overlap somewhat but are separated by metadata/plan usage versus live metric values.
Four of five tools follow a clean verb_noun pattern (push_metrics, push_number, list_sources, delete_source). get_widget_data deviates slightly with a three-word noun phrase, but overall the convention is predictable.
Five tools cover the core write/read/delete lifecycle for a widget data-source server, which is well-scoped rather than bloated. It is slightly lean, since there is no dedicated tool for toggling source visibility.
Create/update (push), read (list/get), and delete are all present, giving reasonable lifecycle coverage. However, list_sources exposes enabled/hidden state and sort_order but no tool lets an agent toggle visibility or reorder sources, which is a notable gap.
AI agents and scripts reporting back to your iPhone with Push Notifications and Live Activities.
Publish status cards and Live Activities to iOS widgets, the Lock Screen, and the Dynamic Island.
Push notifications for AI agents - send instant iPhone notifications from any MCP client.
Give your AI agent a memory and body on your iPhone: set alarms, ring your phone, over MCP.
