This server lets you send real-time content updates to PushToDisplay boards and manage those boards from AI agents or automated pipelines.
Send display updates (pushtodisplay_send_update): Publish text content to a board with rich styling options — text size, font weight, hex colors, background colors, panel targeting (1–4), full-panel mode, content density, and horizontal/vertical alignment.
List boards (pushtodisplay_list_boards): Retrieve all boards owned by the authenticated user.
Get board details (pushtodisplay_get_board): Fetch details of a specific board by its ID.
Create a board (pushtodisplay_create_board): Create a new display board with a name, optional description, and optional layout ID.
Update a board (pushtodisplay_update_board): Modify an existing board's name, description, or layout.
Set default board (pushtodisplay_set_default_board): Designate a board as the user's default, so updates can be sent without specifying a board ID each time.
Delete a board (pushtodisplay_delete_board): Permanently remove a board and all its data (irreversible).
List active devices (pushtodisplay_list_devices): View all active device-board stream connections currently linked to your boards.
Allows GitHub Copilot (VS Code Copilot) to send updates to display boards and manage boards (create, list, delete, set default) via the MCP protocol.
Command-line interface and MCP server for Push To Display — send real-time updates to display boards from your terminal or AI agents.
Run directly with npx (no install needed):
npx pushtodisplay --helpOr install globally:
npm install -g pushtodisplayRequires Node.js 18+. See the PushToDisplay documentation for guides, use cases, and API details.
Related MCP server: @zeph-to/mcp-server
# Log in (opens browser)
pushtodisplay auth login
# Send an update (uses your default board)
pushtodisplay send "Hello, Display!"
# Send to a specific board
pushtodisplay send -b <board-id> "Deploy completed"
# List your boards
pushtodisplay boards listLog in with your Push To Display account — the same account you use in the mobile app.
pushtodisplay auth loginOpens your browser. Sign in and the CLI receives your credentials automatically.
For machines without a browser — SSH sessions, containers, or remote servers:
pushtodisplay auth login --device-codeThe CLI prints a URL and a one-time code. Open the URL on any device, enter the code, and approve the login.
Credentials are stored in your OS keychain (macOS Keychain, Linux libsecret, Windows Credential Manager). Falls back to ~/.config/pushtodisplay/ if the keychain is unavailable.
# Check auth status
pushtodisplay auth status
# Machine-readable status for scripts/agents (exit 0 = authenticated)
pushtodisplay auth status --json
# Log out (clear stored credentials)
pushtodisplay auth logoutauth status reports effective auth: an expired access token is still
reported as authenticated when a valid refresh token can renew it transparently
(a will refresh automatically note is shown instead of the raw token expiry).
It exits 0 when authenticated and 1 when not, so it is safe to gate
scripts on it.
{
"authenticated": true,
"method": "oauth",
"accessTokenExpired": true,
"canRefresh": true,
"sessionExpiresAt": "2026-06-01T00:00:00.000Z"
}sendSend a display update to a board.
# Simple text
pushtodisplay send -b my-board-id "Deploy succeeded"
# Styled text
pushtodisplay send -b my-board-id "Status" --size large --weight bold --color "#00FF00"
# Multiple blocks
pushtodisplay send -b my-board-id "Build:" "passing" --color "#22C55E"
# Panel targeting with layout options
pushtodisplay send -b my-board-id --panel 2 "Right panel content"
pushtodisplay send -b my-board-id --panel 1 --full-panel --density compact --align-x center "Alert"
# Per-block styling with JSON (repeatable)
pushtodisplay send -b my-board-id \
--block '{"text": "API Health", "size": "large", "weight": "bold"}' \
--block '{"text": "Uptime: 99.97%", "color": "#22C55E"}'
# Pipe a full JSON payload from stdin
echo '{"boardId":"my-board-id","blocks":[{"text":"From pipe"}]}' | pushtodisplay send --stdinIf no -b flag is provided, the server uses your default board.
Flag | Values | Description |
|
| Text size |
|
| Font weight |
| Hex color ( | Text color |
| Hex color ( | Background color |
Flag | Values | Description |
|
| Target panel number |
| — | Fill the entire panel area |
|
| Content spacing |
|
| Horizontal alignment |
|
| Vertical alignment |
Flag | Description |
| Board ID |
| Styled block as JSON (repeatable) |
| Read full JSON request from stdin |
boardspushtodisplay boards list # List all boards
pushtodisplay boards get <id> # Get board details
pushtodisplay boards create -n "Name" # Create a board
pushtodisplay boards create -n "Dash" -l 4 # Create with a layout
pushtodisplay boards delete <id> # Delete a boardCreate options:
Flag | Description |
| Board name (required) |
| Board description |
| Layout ID |
devicespushtodisplay devices list # List active device-board streamsconfigpushtodisplay config # Show current configuration
pushtodisplay config show # Same as aboveAdd --json to any command for machine-readable output:
pushtodisplay boards list --json
pushtodisplay send -b my-board "test" --jsonConfiguration is resolved in order: environment variables → config file → defaults.
Env var | Description | Default |
| API endpoint |
|
| Service endpoint |
|
| Identity provider |
|
| Config directory |
|
The CLI includes a built-in Model Context Protocol server, giving AI agents (Claude, Cursor, VS Code Copilot, and others) direct access to your display boards.
The MCP server inherits your CLI session — if you've run pushtodisplay auth login, it authenticates automatically.
claude mcp add pushtodisplay -- npx pushtodisplay mcpAdd to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"pushtodisplay": {
"command": "npx",
"args": ["pushtodisplay", "mcp"]
}
}
}Open Settings → MCP Servers → Add Server, or edit .cursor/mcp.json:
{
"mcpServers": {
"pushtodisplay": {
"command": "npx",
"args": ["pushtodisplay", "mcp"]
}
}
}Add to .vscode/mcp.json:
{
"servers": {
"pushtodisplay": {
"command": "npx",
"args": ["pushtodisplay", "mcp"]
}
}
}Any MCP client that supports stdio transport can use Push To Display. The server command is:
npx pushtodisplay mcpTool | Description |
| Send content to a board |
| List all boards |
| Get details of a board |
| Create a new board |
| Update a board's name, description, or layout |
| Set a board as your default |
| Delete a board permanently |
| List active device connections |
Command | Description |
| Log in (browser or device code) |
| Remove stored credentials |
| Show current auth status |
| Send a display update |
| List your boards |
| Get board details |
| Create a new board |
| Delete a board |
| List active device connections |
| Show current configuration |
| Start the MCP server |
For CI/CD pipelines and scripts where interactive login isn't available, you can authenticate with an API key. Create one from the mobile app or the web portal. API keys start with pt_.
# Via environment variable
export PTD_API_KEY=pt_your_key_here
pushtodisplay send "From CI"
# Or store in keychain
pushtodisplay auth login --api-key pt_your_key_hereNote: API key auth only supports the
sendcommand. Useauth loginfor full access to boards, devices, and config management.
4-panel layout — regional status at a glance
Multi-panel with CI/CD pipeline and infrastructure logs
Incident timeline with color-coded severity
Create a new board.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Board name | |
| description | No | Board description | |
| layoutId | No | Layout ID for the board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a mutation (create), but provides no details beyond that. With no annotations, the agent is left unaware of potential side effects, permissions, or constraints.
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?
The description is a single sentence, which is concise, but it omits useful context. It is not overly verbose, but could be slightly more informative without being wasteful.
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?
Given that there are 3 parameters and no output schema, the description should explain the purpose of layoutId or what a board represents. Without this, the agent may struggle to use the tool correctly.
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% with clear parameter descriptions. The description adds no extra meaning beyond the schema, so baseline of 3 is appropriate.
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?
The description states 'Create a new board,' which clearly indicates the action and resource. However, it does not differentiate from the sibling tool for updating boards, but the verb 'create' 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?
No guidance on when to use this tool versus alternatives like 'pushtodisplay_update_board' or 'pushtodisplay_list_boards'. The description lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a board and all its data. This action cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | The board ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond the destructiveHint=true annotation by specifying that the deletion is permanent and affects all data. This fully discloses the irreversible nature of the action.
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?
The description is extremely concise, using two short sentences to convey the core action and the irreversible consequence. Every word is necessary and earned.
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?
Given the tool's simplicity (one required parameter, no output schema, no nested objects), the description fully covers what the tool does, the parameter, and the behavioral impact. No additional context is needed.
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?
The single parameter boardId is fully described in the schema with 100% coverage. The description adds value by noting that the deletion cascades to 'all its data', which goes beyond the schema's parameter description.
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?
The description clearly states it deletes a board and all its data permanently, using the specific verb 'delete' and resource 'board'. The sibling tools (create, get, list, update, set_default) are distinct operations, so no confusion.
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?
The description does not explicitly state when to use this tool or when to avoid it, nor does it compare to alternatives like update_board. The usage is implied by the name and description, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific board by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | The board ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get details', implying a read-only operation, but does not disclose any behavioral traits such as required authentication, rate limits, or what happens if the board ID does not exist (e.g., error response).
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?
A single, front-loaded sentence that perfectly captures the tool's purpose with no unnecessary words.
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?
Given the simplicity of the tool (one required parameter, no output schema, no nested objects), the description is largely complete. It clearly specifies what the tool does and what is needed. Minor improvement could mention that the ID must be valid, but not critical for a straightforward get operation.
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%, with the parameter description 'The board ID to retrieve' adequately defined. The tool description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
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?
The description 'Get details of a specific board by ID' clearly states the action (get) and resource (details of a board by ID). It distinguishes from sibling tools like list_boards (which retrieves multiple boards) and create/delete/update (which modify data).
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 guidance on when to use this tool versus alternatives. The description does not mention when to use get_board instead of list_boards or other tools, nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all boards owned by the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description explicitly states it lists boards owned by the authenticated user, implying a read-only operation. No mention of side effects, but for a list operation, this is sufficient.
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?
Single concise sentence, no superfluous words. Immediately conveys the tool's purpose.
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?
Complete for a simple list tool with no parameters and no output schema. No missing critical information.
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?
No parameters, schema coverage 100%. Description adds no parameter info, but none needed. Baseline score appropriate.
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?
Clearly states the action (list) and resource (boards owned by authenticated user). Distinguishes from sibling tools like create, delete, get, etc.
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?
Implies usage for listing all boards, but no explicit when-to-use or when-not-to-use compared to siblings. Adequate for a simple list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active device-board stream connections.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must disclose behavior. States 'active' implying read-only fetch, but no details on pagination, output format, or what constitutes 'active' (e.g., recently seen connections).
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?
Single sentence front-loads the action. Concise but could be slightly improved by specifying output scope.
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?
Given no output schema and no annotations, description is minimal. Does not explain return structure, whether filtering is possible, or what 'stream connections' means concretely.
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?
With zero parameters and full schema coverage (100%), baseline is 4. Description does not add extra meaning, but schema already covers all parameters.
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?
The description clearly states it lists active device-board stream connections, using specific verb 'list' and resource 'devices'. It distinguishes from sibling tools focused on board management and updates.
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 guidance on when to use this tool versus alternatives like list_boards or get_board. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a display update to a PushToDisplay board. Publishes text content to all devices connected to the specified board.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | No | The board ID to send the update to. If omitted, the user's default board is used. | |
| blocks | Yes | Text blocks to display | |
| panelId | No | Panel ID (1-4) | |
| fullPanel | No | Use full panel mode | |
| density | No | Line density | |
| alignX | No | Horizontal alignment | |
| alignY | No | Vertical alignment | |
| background | No | Overall background color as hex |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that content is published to all devices on the board, but lacks details on authentication, rate limits, or error behavior (e.g., if the board does not exist). Minimal but not misleading.
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 concise sentences with no redundant information. Effective and to the point.
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?
Despite 8 parameters (1 required), the description offers no explanation of their effect or default behavior. The schema covers details, but for completeness, a brief overview of optional parameters would help. No output schema exists, so the description could have mentioned the return type.
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 does not add any extra meaning beyond what is in the schema; it only mentions sending text content without elaborating on parameters like panelId or density.
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?
The description clearly states the action ('send a display update') and the resource ('PushToDisplay board') and specifies that it publishes text to all connected devices. It is distinct from sibling tools which focus on CRUD operations for boards and devices.
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?
The description implies when to use the tool (to send updates to a board) but does not explicitly mention when not to use it or provide alternative tools for other operations. Given the sibling tools are clearly different, it is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a board as the user's default board. The default board is used when no board ID is specified in send_update.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | The board ID to set as default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions setting the default board but omits details like whether it overwrites existing defaults, if it requires special permissions, or what the response indicates. This is insufficient for understanding full behavioral impact.
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?
The description is a single, clear sentence with no filler, efficiently conveying the core functionality.
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?
Given the tool's simplicity (1 param, no output), the description is adequate but could be more explicit about the overwrite behavior of previous defaults. It is missing context about persistence or confirmation.
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 description does not add any extra meaning beyond parameter name and type. It does not explain how to obtain boardId or its expected format.
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?
The description clearly states the tool's action ('Set a board as the user's default board') and explains the purpose ('used when no board ID is specified in send_update'), effectively differentiating it from sibling tools like create, delete, or update board.
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?
The description provides context by linking to send_update, indicating when the default board is used. However, it does not explicitly state when to use this tool over alternatives or when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing board's name, description, or layout.
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes | The board ID to update | |
| name | No | New board name | |
| description | No | New board description | |
| layoutId | No | New layout ID for the board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only lists updatable fields but does not disclose whether updates are partial or full, authorization requirements, or error handling.
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?
Single sentence, 9 words, front-loaded with purpose. 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?
No output schema or annotations. The description is minimal but covers the core operation. Lacks details on return value and update semantics.
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 parameters are already documented. The description adds no extra meaning beyond listing fields, yielding a baseline score.
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?
The description clearly states the tool updates an existing board, listing the specific updatable fields (name, description, layout). It distinguishes from siblings like create_board, delete_board, etc.
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 guidance on when to use this tool versus alternatives. Does not mention prerequisites (e.g., board must exist) or exclusions.
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. Dates show when Glama detected each change.
v1.0.0pushtodisplay_create_boardpushtodisplay_delete_boardpushtodisplay_get_boardpushtodisplay_list_boardspushtodisplay_list_devicespushtodisplay_send_updatepushtodisplay_set_default_boardpushtodisplay_update_boardEach tool targets a distinct action/resource: board CRUD, device listing, sending updates, and setting defaults. No overlapping functionality.
All tools follow a consistent pattern: `pushtodisplay_verb_noun` in snake_case, making them predictable and easy to differentiate.
8 tools provide a balanced scope for board management and display updates, neither too few nor too many.
Covers full CRUD for boards plus device listing, sending updates, and default board setting. Minor gap: no device management beyond listing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Display delivery platform for AI agents. Push HTML, dashboards and live data to screens.
Publish, search, and promote time-sensitive news and messages through a public remote MCP server.
Send notifications, updates and daily digests to a person's phone — typed cards in a private feed.
Push notifications with personalized sounds - manage and trigger your vybits via MCP
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pushtodisplay/cli'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
