How to Build a Terminal AI Coding Agent from Scratch: Installation, Model Integration, MCP, and End-to-End Verification

3 hr ago0 views

This guide explains how to build a terminal-based AI coding agent from zero: install the CLI, connect compatible model providers, configure MCP tools, manage context and permissions, run non-interactive and scheduled tasks, and extend automation to browser and mobile device verification. It also covers team rollout practices, common pitfalls, and safety boundaries.

0. Start With the Real Constraint: Capability Is Defined by Visibility and Reach

Terminal-based AI coding agents can already read code, edit files, execute commands, run tests, and sometimes complete a small requirement from diagnosis to verification. However, before installing and configuring anything, it is worth establishing one principle that runs through the entire workflow:

The degree to which an agent can automate work is not determined only by how intelligent the underlying model is. It is also determined by what information the agent can see and which systems it can touch.

Based on this principle, automation capability can be divided into three layers:

Layer	Core capability	Typical forms	What happens without it
Information layer	Search the web, fetch pages, query documentation and error reports	Built-in web search, search-engine MCP servers, page-fetching MCP servers, documentation-retrieval MCP servers	The agent can only rely on knowledge captured during model training. It cannot answer questions such as “How do I configure the latest version?” or “Has anyone encountered this error recently?”
Interface layer	Open pages, click, enter text, take screenshots, read console logs	Browser automation MCP servers	The agent cannot operate web systems that do not expose public APIs, and it cannot perform end-to-end verification
Device layer	Install applications, launch them, click, read runtime logs	Mobile-device debugging MCP servers	The agent cannot verify real behavior on physical devices, and mobile automation becomes incomplete

When these three layers are combined, they form a complete automation chain:

Search online for the latest documentation and error fixes
   ↓
Read and modify code to locate and implement changes
   ↓
Run tests and local services to verify logical correctness
   ↓
Operate web pages or devices to verify real interfaces and device behavior
   ↓
Summarize results and risks, then hand the report to a human reviewer

Each layer can be built independently or introduced in batches according to priority. The following sections start with the most basic environment setup and then move upward.

1. Start from Zero: Install a Coding Agent in Your Terminal

1.1 Why a terminal agent

The basic form of many coding agents is a command-line tool. There are four main reasons:

Native access to the file system and command execution. The agent can directly read and write project files and run builds or tests without an additional plugin bridge.
Natural integration with version control, build systems, and test frameworks. Generating code, running tests, reviewing diffs, and committing changes can happen in the same command workflow.
Scriptable and pipe-friendly. The agent can be used interactively, or run in non-interactive mode from scripts and scheduled jobs. This is the foundation for the later “scheduled and persistent execution” section.
Decoupled from a specific model. As long as the provider offers a compatible interface, you can switch models by replacing the endpoint and API key, making it easier to include compatible model providers in a unified workflow.

1.2 Environment preparation

Before installation, confirm the local toolchain. Specific version requirements should follow the official installation instructions of the agent:

# Check the JavaScript runtime and package manager versions
# Node.js 18 or later is recommended as an example
node -v
npm -v
# Check the version control tool
git --version
# Confirm that the current directory is the project repository
pwd

If you are working behind a restricted network or corporate proxy, you may need to handle two common issues in advance:

Slow dependency downloads: Configure a package-manager mirror or use an internal private registry.
Access to external services requires a proxy: Set the http_proxy and https_proxy environment variables for the terminal session.

If you only use the agent inside your usual terminal, you usually do not need a separate proxy application. One important point: if you choose a model provider that resides within your own network boundary, the primary model traffic remains within that boundary.

1.3 Installation and launch

# Install the agent CLI globally
# The package name should follow the official documentation
npm install -g <agent-package>
# Confirm that the installation succeeded
<agent-cli> --version

If you only want to try the agent temporarily without installing it globally, you can use the package manager’s one-time execution mode:

# Download and execute once without writing to the global environment
npx -y <agent-package> --version

To start the interactive interface, run the agent from the root directory of the target project:

cd ~/workspace/your-project
<agent-cli>

On first launch, the tool will prompt you to sign in or configure API credentials. You can use a provider subscription, a pay-as-you-go service, or any compatible model provider described in Section 2. The choice does not affect later usage.

1.4 Post-installation self-check

It is recommended to run three self-check tasks, from simple to more complex, to confirm that the agent can correctly read the project, execute commands, and access the network:

Ask it to read the project README and directory structure, then summarize the purpose of the project in one paragraph.
Ask it to run the project’s existing test command and explain why any failing cases fail.
Give it a search task, such as “Check the latest stable version number of the framework used by this project.”

If all three steps pass, the local environment is ready for daily development.

2. Core Step: Connect a Compatible Model Provider to the Agent

2.1 Why connect a model provider to the workflow

For many developers and teams, connecting a compatible model provider directly to the coding agent offers practical benefits:

More predictable network connectivity: Model calls can stay within a preferred network boundary or region, making latency and availability easier to control.
Cost control: Many providers offer competitive pricing and free quotas, which is useful for high-frequency coding scenarios.
Compliance and data safety: Code and enterprise materials can remain within required boundaries, making data classification and industry compliance requirements easier to satisfy.
Better fit for local language and ecosystem: Prompts written in the local language, as well as questions about local frameworks and platforms, may receive better answers.

2.2 Three common integration elements

Regardless of which model provider or cloud platform you choose, integration usually comes down to three elements:

Element	Meaning	Example form
Base URL	The entry point of the model service	`https://<provider-domain>/v1`
API key	Authentication and billing credential	A key generated in the provider console
Model identifier	The specific model to call	The model name listed in the provider documentation

Most coding agents are compatible with common model-provider interfaces, and many model vendors provide compatible endpoints. Therefore, integration usually only requires filling in these three items; the agent itself does not need to be modified.

2.3 Three integration modes: direct, routing, and aggregation

Depending on team size and governance requirements, integration can be divided into three modes.

Mode 1: Direct connection - point the agent’s model endpoint to a single model provider

Fill in the endpoint and API key in the agent configuration file or environment variables. Using environment variables as an example:

# Example using an endpoint compatible with common provider interfaces
# The exact variable names should follow the agent documentation
export MODEL_BASE_URL="https://<provider-domain>/v1"
export MODEL_API_KEY="<your-api-key>"
export MODEL_NAME="<model-identifier>"

You can also write the values into the agent configuration file to avoid relying on environment variables for every command. Field names are illustrative only:

{
  "env": {
    "MODEL_BASE_URL": "https://<provider-domain>/v1",
    "MODEL_API_KEY": "<your-api-key>",
    "MODEL_NAME": "<model-identifier>"
  }
}

The advantage is simplicity. It is suitable for individual developers who want to start quickly. The disadvantage is that model selection and usage management are tied to a single service. If that service is rate-limited or unstable, the entire workflow can be interrupted.

Mode 2: Routing - select models dynamically by task type

Different tasks place different demands on the model:

Understanding a large repository or performing cross-file refactoring places more emphasis on long-context capability.
Debugging complex defects or designing architecture places more emphasis on reasoning capability.
Lightweight tasks such as generating commit messages or formatting code place more emphasis on response speed and cost.

You can switch models inside the agent or point different tasks to different configurations. For example, lightweight batch tasks can use a smaller, cheaper model:

# Lightweight task: use a smaller model to reduce per-call cost
MODEL_NAME="<small-model-identifier>" <agent-cli> -p "Generate a standard commit message for the changes in this directory"
# Complex task: use a model with stronger reasoning capability
MODEL_NAME="<strong-reasoning-model-identifier>" <agent-cli> "Analyze the race-condition risks in this concurrent code"

If the model-switch command requires interactive confirmation, you can wrap it in an alias to reduce repeated input:

# Add to ~/.bashrc or ~/.zshrc, then run source to activate
alias model-fast='<agent-cli> /model <small-model-identifier>'
alias model-pro='<agent-cli> /model <strong-reasoning-model-identifier>'

Mode 3: Aggregation - manage multiple model services through a unified gateway

When a team uses multiple model services and needs failover and usage statistics, you can place a compatible gateway in the middle:

Coding agent --> Unified model gateway --+--> Model provider A
                                         +--> Model provider B
                                         +--> Other model provider (backup)

The gateway typically handles the following responsibilities:

Select upstream services according to policy, such as weighted round-robin or task-type routing.
Automatically fail over when an upstream times out, is rate-limited, or returns a server error.
Record call logs, token usage, and latency.
Centrally manage API keys, so the agent side only needs the gateway address.

A minimal gateway example is shown below. This is illustrative code; a production environment also needs authentication, rate limiting, streaming response forwarding, and sensitive-information redaction:

// gateway.mjs - minimal model gateway with failover and usage logging (example)
import http from 'node:http'
// Upstream service list; order is priority
const upstreams = [
  { name: 'provider-a', base: 'https://<provider-a-domain>/v1', key: process.env.KEY_A },
  { name: 'provider-b', base: 'https://<provider-b-domain>/v1', key: process.env.KEY_B },
]
http.createServer(async (req, res) => {
  const chunks = []
  for await (const chunk of req) chunks.push(chunk)
  const body = Buffer.concat(chunks)
  for (const up of upstreams) {
    const started = Date.now()
    try {
      const resp = await fetch(`${up.base}/chat/completions`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${up.key}` },
        body,
      })
      if (resp.ok) {
        // Log only the routing result and latency; do not log the request body
        // to avoid leaking code content
        console.log(JSON.stringify({ upstream: up.name, status: resp.status, ms: Date.now() - started }))
        res.writeHead(resp.status, { 'Content-Type': 'application/json' })
        res.end(await resp.text())
        return
      }
      // Client errors are returned directly; server errors or rate limits
      // should try the next upstream
      if (resp.status < 500 && resp.status !== 429) {
        res.writeHead(resp.status, { 'Content-Type': 'application/json' })
        res.end(await resp.text())
        return
      }
    } catch (err) {
      console.error(`[${up.name}] request failed: ${err.message}`)
    }
  }
  res.writeHead(502, { 'Content-Type': 'application/json' })
  res.end(JSON.stringify({ error: 'all upstreams unavailable' }))
}).listen(8787, () => console.log('model gateway listening on 8787'))

The three modes can be compared as follows:

Mode	Suitable scenario	Advantages	Costs
Direct	Individual developers, single-project trials	Minimal configuration, shortest path	Hard to manage model selection and usage centrally; higher single-point failure risk
Routing	Multiple models used together, task-tiered usage	Balances cost and effectiveness; can be tuned by scenario	Requires maintaining mappings between models and tasks
Aggregation	Team-level usage, compliance and audit requirements	Centralized key, usage, and failover governance	Requires developing and operating an additional service

The recommended evolution path is: start with direct connection in the individual stage, gradually introduce routing in the team stage, and finally converge to an aggregation gateway.

2.4 API key security: a non-negotiable baseline

Do not hardcode keys: Keep keys only in environment variables, a secret management service, or local agent configuration.
Do not commit keys to version control: Reference environment variables in configuration files, and add ignore rules for all files that may contain credentials.
Apply least privilege: Create a restricted key for coding use in the provider console, and set usage limits and expiration dates.
Rotate regularly: If team membership changes or a leak is suspected, revoke and reissue keys immediately.
Redact logs: Gateway and audit logs should not record request bodies or the keys themselves.

2.5 Verify whether the integration succeeded

Before testing inside the agent, confirm connectivity with a minimal request outside the agent:

curl -s "<provider-domain>/v1/chat/completions" \
  -H "Authorization: Bearer $MODEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"<model-identifier>","messages":[{"role":"user","content":"ping"}]}'

After a normal response is returned, run a simple task inside the agent, such as “Explain the core modules of the current project in one sentence,” to confirm that the model-call path is fully connected. If you use a model service from a platform such as Baidu AI Cloud Qianfan, the troubleshooting approach is the same: confirm that the service is enabled, the key is valid, and the model identifier matches the console.

2.6 Five dimensions for model selection

When selecting a model provider, it is not recommended to rely only on benchmark scores. You should evaluate with real tasks:

Code capability: Select 10 to 20 representative tasks from your own repositories and compare the completion quality of different models.
Context length: Can the model hold the key files of a module, or even a repository?
Tool-calling stability: Can the model reliably output structured tool-call parameters? This is a prerequisite for MCP tools to be called reliably.
Response speed and concurrency limits: These affect interactive experience and batch-task throughput.
Cost and data terms: Pay attention to input and output token pricing, and whether the provider may use your data to train models.

3. MCP, Skills, and Context: Turn the Agent into Your Workbench

When model capabilities are similar, the difference comes from the quality of context and the scope of tools.

3.1 Understand context in layers

The context of a coding agent can be divided into three layers:

Layer	Content	Characteristics
Temporary context	Conversation history in the current session, file snippets, command output	Disappears when the session ends
Project context	Project-level instruction files, code structure, interface conventions	Versioned with the repository and can be retrieved
User context	Personal preferences and general conventions in user-level instruction files	Reusable across projects

In practice, the quality of model output depends heavily on whether the correct layer of context is loaded.

3.2 MCP: connect external tools and data to the agent

The Model Context Protocol, or MCP, is an open protocol for connecting external tools and data sources to large models. Each MCP server can expose three types of capabilities: tools, resources, and prompt templates. The agent acts as the client and is responsible for discovering and calling these capabilities. Common integration methods include:

Launch by local command: Configure a launch command on the agent side, and let the agent start a locally running MCP server.
Remote HTTP access: Connect to an MCP service deployed on a remote server or cloud through an HTTP interface.
Containerized deployment: For MCP services with heavy dependencies, run them in containers to isolate dependencies and simplify distribution.

An example configuration is shown below. Field names should follow the documentation of the agent you use:

{
  "mcpServers": {
    "web-search": {
      "command": "npx",
      "args": ["-y", "<search-mcp-package>"],
      "env": { "SEARCH_API_KEY": "<your-search-service-key>" }
    },
    "remote-tools": {
      "type": "http",
      "url": "https://<mcp-gateway-address>/mcp"
    }
  }
}

Some categories of tools are not recommended:

Tools that duplicate the functionality of other tools.
Tools that directly modify production environments or perform irreversible operations.
Tools from unknown sources whose behavior cannot be audited.

After integration, first confirm that the tools are recognized, then ask the agent to call one tool in a real task to verify that the parameters and returned results match expectations.

3.3 Context instruction files: write project knowledge into the repository

Most coding agents support context instruction files in the repository, commonly including root-level instruction files and user-level instruction files. These files are automatically read during a session, acting like a project manual for the model. A practical template can look like this:

# Project Instructions
## Overview
Describe the project positioning, core modules, and services exposed externally in one sentence.
## Common Commands
- Install dependencies: make install
- Start locally: make dev
- Unit tests: make test
- Lint: make lint
## Directory Conventions
- src/api/: external interface layer; changes require synchronized updates to API documentation
- src/core/: core business logic; unit-test coverage must not be below 80%
- migrations/: database change scripts; additions are allowed, but historical scripts must not be modified
## Collaboration Conventions
- Do not directly modify generated-code directories
- Lint and unit tests must pass before committing
- Do not run git commit or git push by default; human confirmation is required when needed

User-level instruction files are suitable for personal preferences that span projects, such as “answer in the user’s preferred language,” “give the conclusion first and then the details,” or “use four-space indentation by default.”

When maintaining these files, it is recommended to follow three principles:

Write only stable information: Frequently changing content should go into code comments or documentation, not instruction files.
Keep them synchronized with code: Include instruction-file updates in code review checks.
Control length: Instruction files are read into context as a whole, so overly long content wastes the effective context window.

3.4 Reusable skills: turn repeated workflows into standard actions

When a type of task appears repeatedly, such as code review, API documentation generation, or defect reproduction, you can write the standard workflow as a structured skill instruction file and place it in the project’s agreed skill directory. The file usually contains five parts:

Applicable scenarios: When this skill should be triggered.
Input requirements: Which files, parameters, or prerequisites are needed.
Execution steps: The ordered checklist and actions.
Output specification: Output format, fields, and acceptance criteria.
Prohibited actions: Operations that are explicitly not allowed, such as modifying test assertions or skipping lint.

The difference between a skill and a context instruction file is that a skill describes “how to do something,” while a context instruction file describes “what something is.” The value of a skill is that it is reusable, reviewable, and versionable. In essence, it turns team best practices into an operation manual that the model can execute directly.

4. Daily High-Frequency Operations: Use the Agent Efficiently

4.1 Common in-session operations

Operation intent	Typical usage
View help and all commands	Slash-command help, or `--help`
Switch models	Use the model-switch command, or change configuration and restart the session
View tool-call status	Use the status command to confirm which MCP tools are mounted
Clear context	Use the clear command before starting a new task
Manage ignore files	Use project-level and user-level ignore configurations
Non-interactive execution	Use the `-p` flag followed by a prompt

4.2 Plan first, execute later

For changes involving multiple files or architectural adjustments, it is recommended to ask the agent to output a plan first, then execute after confirmation. A common practice is to require it to “only read and analyze first; do not modify any files,” and then allow write access after the plan looks reasonable.

This has two benefits: first, directional mistakes can be caught before implementation, avoiding large-scale rework; second, the plan itself becomes a readable design record that is useful for review and traceability.

4.3 Permission modes: authorize by risk level

Most agents support multiple permission levels. You can choose based on task risk:

Read-only or default mode: Every write or command execution requires human confirmation. Suitable for exploration and unfamiliar codebases.
Allowlist mode: Pre-declare commands or tools that are allowed to run automatically, such as test commands and build commands. Suitable for frequent daily operations.
High-risk mode: Skip confirmation and execute directly. Recommended only in isolated environments, containers, or disposable virtual machines.

At the same time, use project-level ignore configuration to exclude key files, build artifacts, and large data files, so that sensitive information is not read into context or committed to version control.

4.4 Use git as a second brain

The agent can read and write the repository, but it does not “remember” what was done yesterday. Reliable memory comes from version control:

Commit once for every verifiable small change, and write a commit message that explains “what was done and why.”
Review diffs before accepting changes, rather than relying only on the conclusion.
Keep batch renames and large-scale formatting in separate commits so they are easy to roll back.

4.5 Context management for long tasks

The context window is limited, and long-running tasks continuously accumulate conversation history and tool output. Common practices include:

Clear the context before switching tasks.
Split long tasks into independently verifiable stages; after each stage, output a summary and start a new session.
Write intermediate conclusions into project note files rather than leaving everything in the conversation.
Use commands that support resuming or restoring previous sessions, so a new session can continue the previous stage.

4.6 Compare high-frequency prompting patterns

Prompting style	Example	Effect
Vague goal	“Help me optimize this module”	The model cannot determine the optimization direction and may make large-scale changes
Clear goal	“src/core/cache.py has lock contention under high concurrency. First locate the bottleneck, then propose a change plan; do not modify code yet”	Clear direction, narrow scope, reviewable result
Missing constraints	“Fix all the tests”	The agent may “fix” tests by deleting or weakening assertions
Clear constraints	“Fix the failing cases, but do not modify assertion logic; if it is an implementation defect, explain the reason”	Avoids sacrificing correctness just to make tests pass

5. Scheduled and Persistent Execution: Let the Agent Keep Working

Interactive sessions are suitable for exploratory tasks that require judgment and confirmation. For repetitive tasks with clear boundaries, such as daily inspections, periodic report generation, and batch processing, it is better to use loops or scheduled execution.

5.1 Non-interactive batch execution

Most agents provide a non-interactive mode. They accept a prompt, execute the task, and output the result directly, making them suitable for pipelines:

# Ask the agent to analyze current changes and write the result to a file
<agent-cli> -p "Analyze the changes in git diff and list potential issues by risk level" > reports/risk-$(date +%F).md
# Use it as a check step in a continuous integration pipeline
<agent-cli> -p "Check whether new code violates project conventions; if it does, exit with a non-zero status"

5.2 Loops and scheduling with scripts

For example, “Automatically inspect the repository, run tests, and generate a daily report every workday morning” can be wrapped into a script:

#!/usr/bin/env bash
# daily-review.sh - generate a repository review report on each workday (example)
set -euo pipefail
# Use a fixed project path because scheduled tasks do not have a guaranteed working directory
PROJECT_DIR="/srv/repos/your-project"
REPORT_DIR="/srv/reports"
LOCK_FILE="/tmp/daily-review.lock"
# Use a file lock to prevent overlapping runs if the previous run is still active
exec 9>"$LOCK_FILE"
flock -n 9 || { echo "Previous task is still running; skipping this run"; exit 0; }
cd "$PROJECT_DIR"
mkdir -p "$REPORT_DIR"
REPORT="$REPORT_DIR/review-$(date +%F).md"
# Allow only read commands, test commands, and writes to the report directory
# to limit the agent's permission scope
<agent-cli> -p "Please complete today's repository review: 1) Run make test and record the result; 2) Run make lint and record issues; 3) Check change risks in unmerged branches; 4) Output the review conclusion in Markdown, including risk levels and recommended handling order." \
  --allowedTools "Read,Bash(make test),Bash(make lint),Bash(git log),Write($REPORT_DIR/*)" \
  > "$REPORT" 2> "$REPORT.err"
# Release the lock after the task finishes
flock -u 9
# Alert through an available notification channel if the review fails
# Replace the command as needed
if [ -s "$REPORT.err" ]; then
  echo "Review task failed. See $REPORT.err" | mail -s "[Review Alert] $(date +%F)" ops@example.com
fi

Then use the system’s cron or systemd timer to schedule it. Using cron as an example:

# Run the review at 08:30 on weekdays
# Time is based on the server's local time zone
30 8 * * 1-5 /usr/local/bin/daily-review.sh >> /var/log/daily-review.log 2>&1

5.3 Design points for scheduled and persistent tasks

Point	Description
Idempotency	Repeating the same task should not produce duplicate side effects, for example by using the date in the report filename
Concurrency control	Use file locks or distributed locks to avoid overlapping tasks
Least privilege	Use an allowlist to permit only the tools needed by the task, and prohibit writes to production environments
Resource constraints	Set timeouts and maximum token usage to prevent long loops
Observability	Record start time, duration, model usage, exit code, and output location for each run
Failure handling	Distinguish retryable errors from business failures, and configure alerting for critical tasks
Human in the loop	Scheduled tasks should only produce conclusions and recommendations; high-risk actions such as releases or data changes require human confirmation

If you only need to run a few rounds temporarily, you can also agree on a loop rhythm inside an interactive session, such as “after each round, automatically run tests; stop after three consecutive rounds without failures.” However, for production environments, scripts plus scheduled execution are still the most reliable approach.

6. End-to-End Closed Loop: Operate Web Pages and Mobile Devices

Automation becomes a true closed loop only when the agent can not only modify code, but also open pages and operate real devices to verify results.

6.1 Operate web pages: browser automation MCP

Browser automation MCP servers usually provide the following capabilities:

Open a specified URL, navigate forward or backward, and wait for the page to finish loading.
Locate and click, input, select, or upload elements by text or element.
Read page structure and accessibility trees to provide semantic page information to the model.
Take screenshots, export page content, and read browser console logs and network requests.
Simulate different resolutions, browser versions, and network conditions.

Integration is the same as other MCP servers: add an entry to the configuration and, if necessary, provide a headless browser runtime. An example configuration is shown below:

{
  "mcpServers": {
    "browser": {
      "command": "npx",
      "args": ["-y", "<browser-automation-mcp-package>", "--headless"],
      "env": {}
    }
  }
}

After integration, focus on verifying three things: whether the target site can be opened, whether page content can be read correctly, and whether a click or input operation can be completed.

Practical recommendations:

Reuse an existing logged-in session: For systems that require login, let the automation service connect to a browser instance with saved login state, avoiding the login flow every time. Session files are sensitive data and should be stored in a controlled directory and excluded from version control.
Prefer semantic locators: Locate elements by accessible names, labels, roles, and other semantic information rather than volatile style class names, reducing breakage after page redesigns.
Wait for explicit conditions: Wait for a specific element to appear or a specific request to complete, rather than using fixed sleeps. This is faster and more stable.
Collect evidence on failure: When an operation fails, automatically take a screenshot and export console logs to quickly determine whether the issue is frontend rendering or an API problem.
Control scope: Prioritize test environments and avoid write operations against production environments.

6.2 Operate devices: mobile-device debugging MCP

Mobile-device debugging MCP servers usually wrap common device debugging commands, allowing the agent to perform the following tasks through natural-language instructions:

View connected devices and their status, and confirm that device authorization is normal.
Install, uninstall, launch, and stop applications.
Simulate clicks, swipes, text input, back navigation, and screenshots.
Read runtime logs for a specified application or log level.
View the current UI hierarchy and determine element positions and visibility.
Collect basic performance data such as launch time and memory usage.

Configuration is similar to browser MCP:

{
  "mcpServers": {
    "device": {
      "command": "npx",
      "args": ["-y", "<device-debugging-mcp-package>"],
      "env": {}
    }
  }
}

Before integration, confirm the following:

The local machine has the mobile platform’s debugging bridge tool installed and the runtime environment prepared.
Debugging mode is enabled on the device, and authorization is confirmed on the device.
A stable connection exists between the device and the development machine, either via USB or wireless debugging on the same local network.
The application has been installed on the device or emulator.

6.3 End-to-end closed loop: state the intent, let the model plan the path

Point automation is only a tool. The real value is connecting “state the intent” with “complete verification.” Here is a complete example:

Requirement: On the order-list page, the price column is truncated on narrow screens. Please fix it and complete real verification.

The agent’s autonomous planning path is roughly as follows:

1. Retrieve context: Read project instructions and order-list-related components, confirm the styling approach and debugging commands
2. Make local changes: Adjust the narrow-screen layout rules, add or update component tests
3. Verify logic: Run unit tests and lint, confirm there is no regression
4. Web verification (browser MCP)
   - Start the local development server
   - Open the order-list page and switch to a narrow viewport
   - Take a screenshot and confirm the price column is fully visible
   - Read the console and confirm there are no new errors
5. Device verification (device debugging MCP)
   - Install the debug package and launch the app
   - Enter the order-list page, rotate the screen or adjust the system font size
   - Take screenshots and read runtime logs, confirming there is no crash or exception
   - Record basic performance metrics such as launch time
6. Summarize output: Change description, verification evidence (screenshot and log paths), remaining risks, and items requiring human review

Throughout the process, the user only needs to describe the intent. Path planning, tool selection, execution order, and result judgment are completed autonomously by the model. This is the efficiency gain from the closed loop of search, web/device verification, and code changes.

6.4 Security boundaries that must be maintained

The stronger the automation capability, the more important the boundaries become:

Production environments are read-only by default: If operations are truly required, use dedicated accounts and enable approval.
Sensitive operations require human confirmation: Data deletion, configuration changes, version releases, and payment-related operations must not be executed automatically.
Credential isolation: Login states in browsers and devices must not be written into logs or sent with reports.
Operation traceability: Screenshots, logs, and command records should be archived uniformly for later auditing.
Access control: Remotely accessed MCP services must have authentication and access control, and must not be exposed externally without authorization.

7. Rollout Plan: Introduce Capabilities in Stages

It is not recommended to connect all capabilities on the first day. The recommended rhythm is:

Stage	Goal	Key actions
Week 1: Basic workflow	Stable daily use	Install the agent, connect a single compatible model provider, write project context instruction files, and become familiar with common commands
Week 2: Expand tools	Complete the information layer and interface layer	Connect search MCP and browser automation MCP, and complete the first end-to-end verification task
Week 3: Complete the device layer	Enable mobile closed loop	Configure the device debugging environment, connect device debugging MCP, and establish a dual-end verification workflow
Week 4 onward: Engineering	Move from individual productivity to team productivity	Introduce model routing or an aggregation gateway, turn repeated tasks into skill templates, and connect scheduled tasks and continuous integration

7.1 Supporting standards for team rollout

Credential management: Keys should be issued centrally by a secret management service; individual hardcoding is prohibited.
Permission tiers: Default to approval mode, and gradually open permissions according to project risk.
Change traceability: Code changes produced by the agent must pass review and automated checks before being merged.
Usage observation: Track token consumption, task success rate, and average duration to optimize models and prompts.
Knowledge accumulation: Add effective prompts, skill templates, and pitfall records to the team knowledge base.

7.2 Common pitfalls and how to avoid them

Common issue	Cause	Avoidance method
Model call returns an authentication error	Missing, expired, or ineffective key	Verify connectivity with a minimal request first, then start the agent
Tools cannot be invoked	MCP server is not running or there are too many tools	Confirm the tool list after startup, and simplify the tool set as needed
Changes deviate from intent	Insufficient context or vague goal description	Provide project instruction files first, then require “plan first, execute later”
Tests are “turned green”	Missing constraints	Explicitly prohibit modifying assertions, and require explanations when failures are genuine defects
Scheduled task runs repeatedly	Missing concurrency control	Use file locks or distributed locks, and ensure task idempotency
Long task loses context midway	Context limit exceeded	Execute in stages, write intermediate conclusions to files, and resume sessions when necessary

Final Thoughts: Walk Along the Edge of Capability

The setup sequence in this workflow looks like “install, connect a model, configure tools, write instructions, schedule tasks, and automate verification.” In essence, it is about continuously expanding the agent’s perception and execution range. The information layer answers whether the agent knows enough and knows it recently. The interface layer and device layer answer whether verification is real enough.

What truly determines the upper limit of efficiency is not how many tools are configured, but whether you clearly understand where the current capability boundary lies: which tasks can be safely handed to the agent for autonomous completion, and which ones must retain human confirmation. These boundaries are not written in documentation. They are discovered through real tasks.

So start today: connect a compatible model to your terminal, let it read your project, fix a small defect, and run the tests. Then use a browser and a real device to verify the result. When you begin to let the agent complete the full chain of search, modification, and verification, you will find that the way you work changes at the moment you cross that boundary.