Skip to main content
Glama
DarkNoah

autoglm-mcp-server

by DarkNoah
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

AutoGLM MCP Server

A Model Context Protocol (MCP) server for the AutoGLM-Phone API, enabling automated GUI interaction on mobile devices.

Overview

This MCP server provides tools for interacting with the AutoGLM-Phone API, which allows AI models to control mobile devices through a series of actions. The server supports Android (ADB).

Related MCP server: Ultimate Android MCP

Quick Start

Using npx (Recommended)

# Run directly without installation
npx -y autoglm-mcp-server

# With options
npx -y autoglm-mcp-server --transport http --port 3000

Global Installation

npm install -g autoglm-mcp-server
autoglm-mcp-server

Local Installation

npm install autoglm-mcp-server

MCP Client Configuration

Claude Desktop / Cursor (stdio mode)

{
  "mcpServers": {
    "autoglm": {
      "command": "npx",
      "args": ["-y", "autoglm-mcp-server"],
      "env": {
        "AUTOGLM_API_KEY": "<YOUR_API_KEY>"
      }
    }
  }
}

StreamableHTTP Mode

First start the server:

npx -y autoglm-mcp-server --transport http --port 3000

Then configure your MCP client:

{
  "mcpServers": {
    "autoglm": {
      "url": "http://127.0.0.1:3000/mcp",
      "headers": {
        "Authorization": "<YOUR_API_KEY>"
      }
    }
  }
}

Configuration

Set the following environment variables:

export AUTOGLM_API_KEY="your-api-key-here"
export AUTOGLM_API_URL="https://open.bigmodel.cn/api/paas/v4"  # optional
export AUTOGLM_MODEL="autoglm-phone"  # optional

Or create a .env file based on .env.example.

Usage

Development

npm run dev

Build

npm run build

Production

# stdio mode (default)
npm start

# HTTP mode
node dist/index.js --transport http --port 3000

# SSE mode
node dist/index.js --transport sse --port 3000

# HTTP mode on all interfaces
node dist/index.js --transport http --host 0.0.0.0 --port 3000

Command Line Options

Option

Alias

Description

Default

--transport

-t

Transport type: stdio, http, or sse

stdio

--port

-p

Port for HTTP/SSE transport

3000

--host

-h

Host for HTTP/SSE transport

127.0.0.1

--help

Show help message

Available Tools

autoglm_list_adb_devices

List all Android devices connected via ADB (Android Debug Bridge).

Parameters:

  • response_format ('markdown' | 'json', optional): Output format

Returns:

  • Device ID, status, connection type, model, Android version, screen dimensions

Example:

{}

autoglm_task

Execute a task on a connected device using AutoGLM online model. The model will iteratively capture screenshots, analyze the screen, and execute actions until the task is complete.

Parameters:

  • prompt (string, required): Natural language task description (1-5000 characters)

  • device_id (string, optional): Target ADB device ID

  • max_steps (number, optional): Maximum steps to execute (default: 100, range: 1-200)

  • lang ('cn' | 'en', optional): Language for responses (default: 'cn')

How it works:

  1. Captures the current screen via ADB

  2. Sends the screen image and task prompt to AutoGLM online model

  3. The model analyzes the screen and decides on the next action

  4. Executes the action via ADB

  5. Repeats until the task is complete or max_steps is reached

Example:

{
  "prompt": "Open WeChat and send a message to Mom saying hello",
  "max_steps": 50,
  "lang": "cn"
}

Supported Actions

The AutoGLM model can execute the following actions:

Action

Description

Parameters

Launch

Launch an application

app_name

Tap

Tap at coordinates

x, y (0-1000 scale)

Type

Type text

text

Type_Name

Type text by name

text

Swipe

Swipe between coordinates

x1, y1, x2, y2, duration

Back

Go back

-

Home

Go to home screen

-

Double Tap

Double tap at coordinates

x, y

Long Press

Long press at coordinates

x, y, duration

Wait

Wait for duration

duration (ms)

Take_over

Request human takeover

reason

Note

Add a note

text

Call_API

Call an API endpoint

endpoint, params

Interact

Interact with UI element

element, action

Coordinate System

All coordinates use a 0-1000 scale relative to screen size:

  • (0, 0) is top-left corner

  • (1000, 1000) is bottom-right corner

Project Structure

autoglm-mcp-server/
├── src/
│   ├── index.ts                    # Main server entry point
│   ├── constants.ts                # Configuration constants
│   ├── types.ts                    # TypeScript type definitions
│   ├── tools/
│   │   └── autoglm-tools.ts        # MCP tool implementations
│   ├── services/
│   │   ├── autoglm-api-client.ts   # AutoGLM API client
│   │   ├── autoglm-client.ts       # AutoGLM client wrapper
│   │   └── adb-service.ts          # ADB device service
│   └── schemas/
│       └── index.ts                # Zod validation schemas
├── dist/                           # Compiled output
├── package.json
├── tsconfig.json
├── .env.example
└── README.md

HTTP/SSE Authentication

When using HTTP or SSE transport, you can pass the API key via the Authorization header:

# Bearer token format
curl -X POST http://localhost:3000/mcp \
  -H "Authorization: Bearer your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"initialize",...}'

References

License

MIT

Available Tools

3 tools
adb_connectADB Connect to DeviceA
Idempotent

Connect to an Android device via ADB over network.

This tool connects to an Android device using its IP address and port number. The device must have ADB over TCP/IP enabled.

Args:

  • address (string): Device address in format IP:PORT (e.g., 192.168.10.20:5555)

Examples:

  • address: "192.168.10.20:5555"

  • address: "10.0.0.100:5555"

Prerequisites:

  • The target device must have ADB debugging enabled

  • The device must have TCP/IP mode enabled (adb tcpip 5555)

  • The device must be reachable on the network

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesDevice address in format IP:PORT (e.g., 192.168.10.20:5555)

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already indicate idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the description's lack of side-effect disclosure is partially mitigated. The description adds useful prerequisites and address-format context beyond annotations, but it does not mention failure modes, whether existing connections are replaced, or what happens on success. This is an adequate but not a rich behavioral profile.

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?

The description is well-structured with clear sections (core statement, args, examples, prerequisites). The core purpose is front-loaded, and the prerequisites are valuable. The examples are partially redundant with the schema's pattern, but this does not significantly bloat the description. It remains concise and scannable.

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

Completeness4/5

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

For a single-parameter tool with no output schema and annotations covering idempotency and safety, the description covers the necessary preconditions and address format. It does not specify the return value or success/failure output, but this is a minor gap given the tool's simplicity and the fact that no output schema exists. An agent has enough information to invoke it correctly.

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?

The input schema already covers the sole parameter 'address' with type, pattern, and description, giving 100% schema description coverage. The description repeats this information and adds examples, but does not introduce new semantic details beyond what the schema provides. Baseline 3 is appropriate.

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

Purpose5/5

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

The description begins with a specific verb and resource: 'Connect to an Android device via ADB over network.' It clearly distinguishes from sibling tools like autoglm_list_adb_devices (listing devices) and autoglm_task (running a task) by focusing on establishing a connection. The address format and examples further reinforce the tool's distinct purpose.

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

Usage Guidelines4/5

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

The description provides clear usage context: this tool is for connecting to a device over the network, and it explicitly lists prerequisites such as ADB debugging enabled, TCP/IP mode enabled, and network reachability. It does not explicitly name alternatives or state 'when not to use,' but the context is unambiguous enough for an agent to decide when this tool is appropriate.

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

autoglm_list_adb_devicesList ADB Connected DevicesA
Read-onlyIdempotent

List all Android devices connected via ADB (Android Debug Bridge).

This tool queries ADB to get a list of all connected Android devices, including their device IDs, status, connection type, model, and screen dimensions.

Device Status:

  • device: Device is connected and ready

  • offline: Device is connected but not responding

  • unauthorized: Device is connected but requires authorization

Connection Types:

  • usb: Connected via USB cable

  • wifi: Connected via WiFi

  • remote: Connected via remote ADB

Examples:

  • Use when: You need to check which Android devices are connected

  • Use when: You need to get device IDs for executing actions on specific devices

  • Use when: You need to verify ADB connection before executing actions

Error Handling:

  • Returns empty devices array if ADB is not installed or not accessible

  • Returns empty devices array if no devices are connected

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

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

With annotations already declaring readOnly, idempotent, and non-destructive behavior, the description adds valuable context by listing the returned fields (device IDs, status, connection type, model, screen dimensions) and defining statuses and connection types. It also documents error handling, stating that an empty array is returned if ADB is not installed/accessible or no devices are connected. This goes beyond annotations without contradicting them.

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?

The description is well-structured with clear section headers for Device Status, Connection Types, Examples, and Error Handling, and the core purpose is front-loaded. It is somewhat repetitive — the opening and second sentence both state the 'list all connected devices' concept — but each bulleted section earns its place by providing useful interpretation and error context.

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

Completeness4/5

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

The tool is simple with zero parameters, and the annotations cover the safety profile, so the description needs to explain output semantics and error behavior. It does this thoroughly, including what fields are returned, what statuses mean, and what happens when ADB is unavailable. A brief pointer to adb_connect for connection scenarios would make it fully complete, but the current description provides enough context for correct invocation.

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

Parameters4/5

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

The input schema is empty with zero parameters, so there are no parameter semantics for the description to explain. The baseline of 4 applies because the description correctly implies that the tool operates without any required inputs and focuses on querying ADB output. No additional parameter documentation is needed.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'List all Android devices connected via ADB (Android Debug Bridge).' It clearly distinguishes this enumeration tool from siblings like adb_connect, which is about establishing a connection. The additional details about statuses and connection types reinforce the tool's specific scope.

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

Usage Guidelines4/5

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

The 'Examples' section provides explicit 'Use when' scenarios, such as checking connected devices, getting device IDs, and verifying ADB connection. However, it does not mention alternatives or explicitly state when not to use this tool, especially given the sibling adb_connect exists. This is clear context but lacks formal exclusions.

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

autoglm_taskExecute AutoGLM TaskA
Destructive

Execute a task on a connected device using AutoGLM online model.

This tool sends a natural language task description to the AutoGLM online model, which analyzes the current screen state and automatically performs the required actions to complete the task. The model will iteratively capture screenshots, analyze the screen, and execute actions until the task is complete or the maximum steps are reached.

Args:

  • device_id (string, optional): Target ADB device ID (if not specified, uses the first connected device)

  • prompt (string): Natural language task description for AutoGLM to execute (1-5000 characters)

  • max_steps (number, optional): Maximum number of steps to execute (default: 100, range: 1-200)

  • lang ('cn' | 'en', optional): Language for system prompt and responses (default: 'cn')

How it works:

  1. Captures the current screen via ADB

  2. Sends the screen image and task prompt to AutoGLM online model

  3. The model analyzes the screen and decides on the next action

  4. Executes the action via ADB

  5. Repeats until the task is complete or max_steps is reached

Examples:

  • Use when: "Open WeChat and send a message to Mom saying hello"

  • Use when: "Order a coffee from Starbucks app"

  • Use when: "Navigate to the settings and enable dark mode"

  • Don't use when: You only need to execute a single known action (use autoglm_execute_action instead)

Error Handling:

  • Returns "Error: No ADB devices connected" if no device is available

  • Returns "Error: API authentication failed" if API key is invalid

  • Returns "Error: Task execution failed" if the task cannot be completed

  • Returns partial results if the task is interrupted

ParametersJSON Schema
NameRequiredDescriptionDefault
langNoLanguage for system prompt and responses (default: cn)cn
promptYesNatural language task description for AutoGLM to execute
device_idNoTarget ADB device ID (if not specified, uses the first connected device)
max_stepsNoMaximum number of steps to execute (default: 100)

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description adds meaningful behavioral context: it iterates through screenshots, executes actions via ADB, stops at max_steps, can return partial results, and lists specific error conditions. It discloses the autonomous multi-step nature that simple annotations cannot convey.

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 well-structured with sections for Args, How it works, Examples, and Error Handling. The opening sentence is front-loaded with the tool's purpose, and every section earns its place by providing operational or routing details.

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

Completeness4/5

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

For a complex autonomous tool with no output schema, the description covers workflow, parameters, examples, error conditions, and partial-result behavior. The only gap is that it does not explicitly describe what a successful return value looks like, though it does mention several failure return strings.

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 already documents all four parameters. The description repeats the parameter meanings and adds a few clarifications (e.g., device_id falls back to first connected device, max_steps controls iteration count), but it does not add substantial semantic value beyond the schema.

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

Purpose5/5

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

The description uses a specific verb-resource pairing: 'Execute a task on a connected device using AutoGLM online model.' It clearly explains that the tool sends a natural-language prompt, iteratively captures screens, and performs actions until completion. This distinguishes it sharply from the sibling device-management tools.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use examples ('Open WeChat and send a message to Mom...', 'Order a coffee...') and an explicit when-not-to-use case, directing the agent to autoglm_execute_action for single known actions. This is strong decision routing guidance.

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. 3 tool updatesv1.0.5
    • First observedadb_connect
    • First observedautoglm_list_adb_devices
    • First observedautoglm_task
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

A3.8/5.0

Scored across 3 tools

Disambiguation4/5

The three listed tools are clearly separated: connecting to a device, listing connected devices, and running an autonomous task. However, autoglm_task references autoglm_execute_action, a tool that is not actually exposed by this server, which could lead an agent to expect or attempt a nonexistent tool.

Naming Consistency2/5

Tool names mix conventions: adb_connect lacks the autoglm_ prefix used by the other two tools, and autoglm_task is a noun rather than a verb-based action name like autoglm_list_adb_devices or adb_connect. The mention of autoglm_execute_action adds another inconsistent naming style not present in the actual tool set.

Tool Count4/5

Three tools is minimal but each covers a necessary stage of the ADB/AutoGLM workflow: connect, list devices, and execute a task. The count feels slightly thin because autoglm_task implies a separate single-action execution tool should exist.

Completeness2/5

The server covers device connection, device listing, and autonomous task execution, but autoglm_task explicitly tells users to use autoglm_execute_action for single known actions, and that tool is missing. This is a significant gap because the intended workflow cannot handle simple direct actions without falling back on the missing tool.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers