Skip to main content
MCP servers extend Cline beyond what text prompts can achieve alone. By building your own server, you can give Cline direct access to internal APIs, proprietary data sources, local tools, and any system that has a programmable interface. This guide walks through the full development lifecycle using the @modelcontextprotocol/sdk for TypeScript, Cline’s structured development protocol, and a real worked example.
Once you’ve built a great MCP server, you can share it with the community by submitting it to the Cline MCP Marketplace.

The development protocol

Cline has a built-in protocol for MCP server development enforced through a .clinerules file. Place this file at the root of your MCP working directory (~/Documents/Cline/MCP/) and Cline will automatically enter a structured development mode when you work in that folder. The protocol has four phases:
1

Plan (PLAN MODE)

Define the problem, choose the API or service, map out authentication requirements, and design the tool interfaces before writing any code.
2

Implement (ACT MODE)

Bootstrap the project, write the server code using the MCP SDK, add logging, handle errors, and configure the server in your MCP settings.
3

Test (required before completion)

Test every tool with valid inputs and confirm correct output. The protocol blocks completion until all tools pass.
4

Complete

Once all tools are verified, mark the server as complete and optionally submit it to the Marketplace.

.clinerules file

Copy the following into ~/Documents/Cline/MCP/.clinerules:

Getting started

1. Bootstrap a TypeScript server

The create-server scaffolding tool sets up a complete project with the SDK, TypeScript config, and a working index.ts:
Project structure after scaffolding:

2. Write the server

The core pattern for every MCP server:
Always log to console.error, not console.log. The MCP protocol uses stdout for structured messages; anything written to stdout that isn’t valid JSON-RPC will break the connection.

3. Build the server

This compiles TypeScript to build/index.js.

4. Register with Cline

Add the server to cline_mcp_settings.json:
Cline picks up the change automatically. You should see the server appear in the MCP Servers panel with a green dot.

Case study: AlphaAdvantage stock analysis server

To illustrate a complete build, here is a walkthrough of an MCP server that wraps the AlphaAdvantage financial API and exposes tools for stock overviews, technical analysis, fundamental analysis, earnings reports, and news.

Planning phase

Before writing code, the planning phase established:
  • Problem: Analysts want stock data, price charts, and earnings history available directly in their AI assistant without switching tools.
  • API: AlphaAdvantage — standard API key authentication, 5 requests per minute on the free tier.
  • Tools needed: get_stock_overview, get_technical_analysis, get_fundamental_analysis, get_earnings_report, get_news_sentiment.
  • Output format: Clean markdown with tables, trend arrows (↑/↓), and properly formatted financial figures.

Project structure

Rate limiting

The free tier allows only 5 API calls per minute. Rate limiting was built into the client:

Caching

Cache TTLs matched the staleness tolerance for each data type:

Tool definitions

Configuration

Test results

Each tool was tested individually before marking the server complete:

Best practices

Logging

Consistent log prefixes make debugging fast:
Always include enough context in error logs to diagnose failures without needing to reproduce them.

Input validation

Validate inputs before making any API calls:

Error handling

Return errors as structured responses rather than throwing, so Cline can relay the message to the user:

Exposing resources

Resources let your server share read-only data (files, database records, config) that Cline can reference as context:

Common challenges

  • For API keys: pass them as environment variables in your MCP config (env field) and read them with process.env.YOUR_KEY. Exit with a clear error message if the variable is missing.
  • For OAuth: write a separate script to perform the OAuth flow and store the refresh token, then load it from disk in your server.
Design rate limiting into the client from the start. Use a counter + timestamp approach (as shown above) or a token bucket. Add caching to reduce the number of upstream calls. Return a helpful error message when the limit is hit rather than silently failing.
If a tool makes multiple sequential API calls, it may exceed the default 60-second timeout. Solutions:
  • Increase the timeout value in cline_mcp_settings.json for that server.
  • Split complex tools into smaller, single-purpose tools.
  • Cache aggressively to avoid repeated calls.
APIs don’t always expose exactly what you need. Options:
  • Combine multiple endpoints to synthesize the data.
  • Transform and reshape the response to match your tool’s output schema.
  • Document limitations clearly in the tool’s description field so Cline sets accurate user expectations.

Additional resources