Skip to main content
Glama
stvlynn

mindreset-mcp

by stvlynn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

MindReset MCP Server

A Model Context Protocol (MCP) server that provides tools for interacting with MindReset devices. This server implements the official MindReset API endpoints for displaying text and images on MindReset device screens.

Features

  • Simple Text API: Display basic text content on MindReset devices

  • Complex Text API: Display text with signatures and formatting

  • Text with Icons: Display text content with custom icons and tap-to-jump links

  • Image API: Display PNG images with customizable borders

Related MCP server: Discord MCP Server

Prerequisites

  • Node.js >= 18

  • A MindReset device with API access

  • Device ID and Secret from MindReset App

Installation

  1. Clone or download this repository

  2. Install dependencies:

    npm install

  3. Build the project:

    npm run build

Configuration

Set the required environment variables:

export MINDRESET_DEVICE_ID="your_device_serial_number"
export MINDRESET_DEVICE_SECRET="your_device_secret"

You can obtain these credentials from the MindReset App by following the official MindReset API documentation.

Usage

Development Mode

npm run dev

Production Mode

npm start

Available Tools

mindreset_simple_text

Send simple text content to a MindReset device screen.

Parameters:

  • deviceId (required): Device serial number

  • title (optional): Text title

  • message (required): Text content to display

Example:

{
  "deviceId": "ABCD1234ABCD",
  "title": "Hello World",
  "message": "I can swallow glass without harming myself"
}

mindreset_complex_text

Send complex text content with signature to a MindReset device screen.

Parameters:

  • deviceId (required): Device serial number

  • title (optional): Text title

  • message (required): Text content to display

  • signature (optional): Text signature/footer

Example:

{
  "deviceId": "ABCD1234ABCD",
  "title": "Verification Code Helper",
  "message": "A verification code from 'Shao Pai'\n205112",
  "signature": "August 4, 2025 19:58"
}

mindreset_text_with_icon

Send text content with icon and optional link to a MindReset device screen.

Parameters:

  • deviceId (required): Device serial number

  • title (optional): Text title

  • message (required): Text content to display

  • signature (optional): Text signature/footer

  • icon (optional): Base64 encoded PNG icon data (40px*40px)

  • link (optional): HTTP/HTTPS link or Scheme URL for tap-to-jump

Example:

{
  "deviceId": "ABCD1234ABCD",
  "title": "Daily Health",
  "message": "Calories burned: 702 kcal\nSteps today: 4183\nStanding time: 62 minutes",
  "signature": "August 4, 2025 20:16",
  "icon": "iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAABGdBTUEAALGPC/xhBQAAACBjSFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAA...",
  "link": "x-apple-health://"
}

mindreset_image

Display PNG image on a MindReset device screen.

Parameters:

  • deviceId (required): Device serial number

  • image (required): Base64 encoded PNG image data (296px*152px)

  • border (optional): "0" for white border, "1" for black border

  • link (optional): HTTP/HTTPS link or Scheme URL for tap-to-jump

Example:

{
  "deviceId": "ABCD1234ABCD",
  "image": "iVBORw0KGgoAAAANSUhEUgAAASgAAACYCAYAAABXunTYAAAABGdBTUEAALGPC/xhBQAAACBjSFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAA...",
  "border": "0",
  "link": "https://dot.mindreset.tech"
}

Integration with Claude Desktop

To use this MCP server with Claude Desktop, add the following configuration to your Claude Desktop settings:

{
  "mcpServers": {
    "mindreset": {
      "command": "node",
      "args": ["/path/to/your/project/dist/index.js"],
      "env": {
        "MINDRESET_DEVICE_ID": "your_device_id",
        "MINDRESET_DEVICE_SECRET": "your_device_secret"
      }
    }
  }
}

Error Handling

The server provides comprehensive error handling for:

  • Missing or invalid authentication credentials

  • Network connectivity issues

  • API response errors

  • Input validation errors

API Documentation

For detailed information about the MindReset API, refer to the official documentation:

License

ISC

Available Tools

4 tools
mindreset_complex_textB

Send complex text content with signature to MindReset device screen

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoText title
messageYesText content
deviceIdYesDevice serial number
signatureNoText signature

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It never says whether this replaces the current screen content, requires the device to be online, needs auth, or what side effects occur — significant gaps for a device-write tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler. It is appropriately sized, though its brevity is partly what leaves the behavioral gaps unaddressed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, and a mutation against a physical device, the definition should explain at least the effect on existing screen content and any device-state prerequisites. Neither is present, so an agent cannot confidently predict the outcome.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so title, message, deviceId, and signature are already documented. The description adds only a restatement of 'text content with signature' and no format, length, or encoding details beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Send'), a resource ('complex text content with signature'), and a target ('MindReset device screen'). The word 'complex' implicitly separates it from the sibling mindreset_simple_text, but the differentiation is not stated outright.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: 'complex text' suggests this is for richer content than mindreset_simple_text, and 'with signature' hints at the signature parameter. No sibling is named, no when-not-to-use condition or prerequisite is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mindreset_imageC

Display PNG image on a MindReset device screen

ParametersJSON Schema
NameRequiredDescriptionDefault
linkNoHTTP/HTTPS link or Scheme URL for tap-to-jump
imageYesBase64 encoded PNG image data (296px*152px)
borderNo0 for white border, 1 for black border
deviceIdYesDevice serial number

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It states that an image is displayed, but does not explain device-side effects, whether the image replaces current content, error behavior, or any other operational trait beyond what the schema already documents.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description should provide more context for a device-mutating tool. It omits when to use this versus sibling text tools and gives no behavioral details about the display action beyond the basic purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents deviceId, image, link, and border. The description adds no parameter meaning beyond the schema, making the baseline score of 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a clear verb and resource: display a PNG image on a MindReset device screen. The resource type distinguishes it from the sibling text tools, but it does not explicitly name or contrast those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus the sibling text-display tools or any other alternative. Usage is only implied by the purpose statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mindreset_simple_textC

Send simple text content to MindReset device screen

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoText title
messageYesText content
deviceIdYesDevice serial number

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It doesn't say whether the device must be online, whether this replaces or queues on screen content, whether display is transient or persistent, or what happens on failure. Only the mutation intent ('Send') is conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with the action and target front-loaded and no wasted words. It is appropriately sized, though not unusually informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a device-mutating tool with no annotations and no output schema, the description leaves key agent questions unanswered: delivery requirements, content replacement behavior, and failure modes. The 100% schema coverage covers parameters but not behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (title, message, deviceId) are already documented in the schema. The description adds no format, length, or device-resolution detail beyond what the schema states, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Send') and resource ('simple text content') with the target ('MindReset device screen'). The word 'simple' implicitly distinguishes it from mindreset_complex_text and mindreset_text_with_icon, though it never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to choose this over mindreset_text_with_icon, mindreset_complex_text, or mindreset_image. The word 'simple' implies a lightweight case but no conditions, prerequisites, or alternatives are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mindreset_text_with_iconC

Send text content with icon and optional link to MindReset device screen

ParametersJSON Schema
NameRequiredDescriptionDefault
iconNoBase64 encoded PNG icon data (40px*40px)
linkNoHTTP/HTTPS link or Scheme URL for tap-to-jump
titleNoText title
messageYesText content
deviceIdYesDevice serial number
signatureNoText signature

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It says 'Send' and targets a device screen, but omits whether it replaces existing content, what permissions are required, rate limits, or whether the device must be online.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no wasted words. It is efficient and earns its place, though it is terse for a six-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a send tool with six parameters, no annotations, and no output schema. The description omits return behavior, prerequisites, and side effects, leaving the agent without enough context to invoke it correctly in all cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema documents all six parameters including icon, link, title, message, deviceId, and signature. The description mentions icon, optional link, and text content but adds no format or constraint details beyond what the schema already provides, making 3 the correct baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States the verb 'Send' and the resource 'text content with icon and optional link' to 'MindReset device screen.' It distinguishes itself from mindreset_image and simple_text by including icon/link, but does not explicitly name or compare against siblings, so a 4 is appropriate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides no when-to-use guidance or alternative selection criteria. The implied context is sending rich text with an icon, but nothing tells the agent when to choose this over mindreset_simple_text or mindreset_complex_text.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.0.0
    • First observedmindreset_complex_text
    • First observedmindreset_image
    • First observedmindreset_simple_text
    • First observedmindreset_text_with_icon
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored across 4 tools

Disambiguation3/5

Three of the four tools send text to the device screen, with overlapping purposes (simple text, complex text with signature, text with icon/link). The descriptions hint at differences, but an agent could easily struggle to choose the right one without more explicit guidance.

Naming Consistency4/5

All names use the mindreset_ prefix and snake_case, which is consistent. However, the suffix patterns vary (simple_text, complex_text, text_with_icon, image) rather than following a strict verb_noun convention.

Tool Count5/5

Four tools is a well-scoped set for a device display integration, covering both text and image output. Each tool appears to serve a distinct display variant, so none feels redundant at the count level.

Completeness4/5

The surface covers the core operations of sending text and images to the device, which is likely the main use case. Minor gaps exist, such as clearing the screen or querying device status, but these are workaroundable by sending new content.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers