Skip to content

Commit cf2eac3

Browse files
cryo-zdcryo-zd
committed
merge main and update test
2 parents c71f318 + a26e1dc commit cf2eac3

File tree

10 files changed

+1438
-11
lines changed

10 files changed

+1438
-11
lines changed

‎README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -43,7 +43,7 @@ The SDK consists of three importable packages:
4343
package provides an implementation of [JSON
4444
Schema](https://json-schema.org/), used for MCP tool input and output schema.
4545
- The
46-
[`github.com/modelcontextprotocol/jsonrpc`](https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/jsonschema) package is for users implementing
46+
[`github.com/modelcontextprotocol/go-sdk/jsonrpc`](https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/jsonrpc) package is for users implementing
4747
their own transports.
4848

4949

‎examples/custom-transport/main.go

Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
// Copyright 2025 The Go MCP SDK Authors. All rights reserved.
2+
// Use of this source code is governed by an MIT-style
3+
// license that can be found in the LICENSE file.
4+
5+
package main
6+
7+
import (
8+
"bufio"
9+
"context"
10+
"errors"
11+
"io"
12+
"log"
13+
"os"
14+
15+
"github.com/modelcontextprotocol/go-sdk/jsonrpc"
16+
"github.com/modelcontextprotocol/go-sdk/mcp"
17+
)
18+
19+
// IOTransport is a simplified implementation of a transport that communicates using
20+
// newline-delimited JSON over an io.Reader and io.Writer. It is similar to ioTransport
21+
// in transport.go and serves as a demonstration of how to implement a custom transport.
22+
type IOTransport struct {
23+
r *bufio.Reader
24+
w io.Writer
25+
}
26+
27+
// NewIOTransport creates a new IOTransport with the given io.Reader and io.Writer.
28+
func NewIOTransport(r io.Reader, w io.Writer) *IOTransport {
29+
return &IOTransport{
30+
r: bufio.NewReader(r),
31+
w: w,
32+
}
33+
}
34+
35+
// ioConn is a connection that uses newlines to delimit messages. It implements [mcp.Connection].
36+
type ioConn struct {
37+
r *bufio.Reader
38+
w io.Writer
39+
}
40+
41+
// Connect implements [mcp.Transport.Connect] by creating a new ioConn.
42+
func (t *IOTransport) Connect(ctx context.Context) (mcp.Connection, error) {
43+
return &ioConn{
44+
r: t.r,
45+
w: t.w,
46+
}, nil
47+
}
48+
49+
// Read implements [mcp.Connection.Read], assuming messages are newline-delimited JSON.
50+
func (t *ioConn) Read(context.Context) (jsonrpc.Message, error) {
51+
data, err := t.r.ReadBytes('\n')
52+
if err != nil {
53+
return nil, err
54+
}
55+
56+
return jsonrpc.DecodeMessage(data[:len(data)-1])
57+
}
58+
59+
// Write implements [mcp.Connection.Write], appending a newline delimiter after the message.
60+
func (t *ioConn) Write(_ context.Context, msg jsonrpc.Message) error {
61+
data, err := jsonrpc.EncodeMessage(msg)
62+
if err != nil {
63+
return err
64+
}
65+
66+
_, err1 := t.w.Write(data)
67+
_, err2 := t.w.Write([]byte{'\n'})
68+
return errors.Join(err1, err2)
69+
}
70+
71+
// Close implements [mcp.Connection.Close]. Since this is a simplified example, it is a no-op.
72+
func (t *ioConn) Close() error {
73+
return nil
74+
}
75+
76+
// SessionID implements [mcp.Connection.SessionID]. Since this is a simplified example,
77+
// it returns an empty session ID.
78+
func (t *ioConn) SessionID() string {
79+
return ""
80+
}
81+
82+
// HiArgs is the argument type for the SayHi tool.
83+
type HiArgs struct {
84+
Name string `json:"name" mcp:"the name to say hi to"`
85+
}
86+
87+
// SayHi is a tool handler that responds with a greeting.
88+
func SayHi(ctx context.Context, ss *mcp.ServerSession, params *mcp.CallToolParamsFor[HiArgs]) (*mcp.CallToolResultFor[struct{}], error) {
89+
return &mcp.CallToolResultFor[struct{}]{
90+
Content: []mcp.Content{
91+
&mcp.TextContent{Text: "Hi " + params.Arguments.Name},
92+
},
93+
}, nil
94+
}
95+
96+
func main() {
97+
server := mcp.NewServer(&mcp.Implementation{Name: "greeter"}, nil)
98+
mcp.AddTool(server, &mcp.Tool{Name: "greet", Description: "say hi"}, SayHi)
99+
100+
// Run the server with a custom IOTransport using stdio as the io.Reader and io.Writer.
101+
transport := &IOTransport{
102+
r: bufio.NewReader(os.Stdin),
103+
w: os.Stdout,
104+
}
105+
err := server.Run(context.Background(), transport)
106+
if err != nil {
107+
log.Println("[ERROR]: Failed to run server:", err)
108+
}
109+
}

‎examples/sequentialthinking/README.md

Lines changed: 203 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,203 @@
1+
# Sequential Thinking MCP Server
2+
3+
This example shows a Model Context Protocol (MCP) server that enables dynamic and reflective problem-solving through structured thinking processes. It helps break down complex problems into manageable, sequential thought steps with support for revision and branching.
4+
5+
## Features
6+
7+
The server provides three main tools for managing thinking sessions:
8+
9+
### 1. Start Thinking (`start_thinking`)
10+
11+
Begins a new sequential thinking session for a complex problem.
12+
13+
**Parameters:**
14+
15+
- `problem` (string): The problem or question to think about
16+
- `sessionId` (string, optional): Custom session identifier
17+
- `estimatedSteps` (int, optional): Initial estimate of thinking steps needed
18+
19+
### 2. Continue Thinking (`continue_thinking`)
20+
21+
Adds the next thought step, revises previous steps, or creates alternative branches.
22+
23+
**Parameters:**
24+
25+
- `sessionId` (string): The thinking session to continue
26+
- `thought` (string): The current thought or analysis
27+
- `nextNeeded` (bool, optional): Whether another thinking step is needed
28+
- `reviseStep` (int, optional): Step number to revise (1-based)
29+
- `createBranch` (bool, optional): Create an alternative reasoning path
30+
- `estimatedTotal` (int, optional): Update total estimated steps
31+
32+
### 3. Review Thinking (`review_thinking`)
33+
34+
Provides a complete review of the thinking process for a session.
35+
36+
**Parameters:**
37+
38+
- `sessionId` (string): The session to review
39+
40+
## Resources
41+
42+
### Thinking History (`thinking://sessions` or `thinking://{sessionId}`)
43+
44+
Access thinking session data and history in JSON format.
45+
46+
- `thinking://sessions` - List all thinking sessions
47+
- `thinking://{sessionId}` - Get specific session details
48+
49+
## Core Concepts
50+
51+
### Sequential Processing
52+
53+
Problems are broken down into numbered thought steps that build upon each other, maintaining context and allowing for systematic analysis.
54+
55+
### Dynamic Revision
56+
57+
Any previous thought step can be revised and updated, with the system tracking which thoughts have been modified.
58+
59+
### Alternative Branching
60+
61+
Create alternative reasoning paths to explore different approaches to the same problem, allowing for comparative analysis.
62+
63+
### Adaptive Planning
64+
65+
The estimated number of thinking steps can be adjusted dynamically as understanding of the problem evolves.
66+
67+
## Running the Server
68+
69+
### Standard I/O Mode
70+
71+
```bash
72+
go run .
73+
```
74+
75+
### HTTP Mode
76+
77+
```bash
78+
go run . -http :8080
79+
```
80+
81+
## Example Usage
82+
83+
### Starting a Thinking Session
84+
85+
```json
86+
{
87+
"method": "tools/call",
88+
"params": {
89+
"name": "start_thinking",
90+
"arguments": {
91+
"problem": "How should I design a scalable microservices architecture?",
92+
"sessionId": "architecture_design",
93+
"estimatedSteps": 8
94+
}
95+
}
96+
}
97+
```
98+
99+
### Adding Sequential Thoughts
100+
101+
```json
102+
{
103+
"method": "tools/call",
104+
"params": {
105+
"name": "continue_thinking",
106+
"arguments": {
107+
"sessionId": "architecture_design",
108+
"thought": "First, I need to identify the core business domains and their boundaries to determine service decomposition."
109+
}
110+
}
111+
}
112+
```
113+
114+
### Revising a Previous Step
115+
116+
```json
117+
{
118+
"method": "tools/call",
119+
"params": {
120+
"name": "continue_thinking",
121+
"arguments": {
122+
"sessionId": "architecture_design",
123+
"thought": "Actually, before identifying domains, I should analyze the current system's pain points and requirements.",
124+
"reviseStep": 1
125+
}
126+
}
127+
}
128+
```
129+
130+
### Creating an Alternative Branch
131+
132+
```json
133+
{
134+
"method": "tools/call",
135+
"params": {
136+
"name": "continue_thinking",
137+
"arguments": {
138+
"sessionId": "architecture_design",
139+
"thought": "Alternative approach: Start with a monolith-first strategy and extract services gradually.",
140+
"createBranch": true
141+
}
142+
}
143+
}
144+
```
145+
146+
### Completing the Thinking Process
147+
148+
```json
149+
{
150+
"method": "tools/call",
151+
"params": {
152+
"name": "continue_thinking",
153+
"arguments": {
154+
"sessionId": "architecture_design",
155+
"thought": "Based on this analysis, I recommend starting with 3 core services: User Management, Order Processing, and Inventory Management.",
156+
"nextNeeded": false
157+
}
158+
}
159+
}
160+
```
161+
162+
### Reviewing the Complete Process
163+
164+
```json
165+
{
166+
"method": "tools/call",
167+
"params": {
168+
"name": "review_thinking",
169+
"arguments": {
170+
"sessionId": "architecture_design"
171+
}
172+
}
173+
}
174+
```
175+
176+
## Session State Management
177+
178+
Each thinking session maintains:
179+
180+
- **Session metadata**: ID, problem statement, creation time, current status
181+
- **Thought sequence**: Ordered list of thoughts with timestamps and revision history
182+
- **Progress tracking**: Current step and estimated total steps
183+
- **Branch relationships**: Links to alternative reasoning paths
184+
- **Status management**: Active, completed, or paused sessions
185+
186+
## Use Cases
187+
188+
**Ideal for:**
189+
190+
- Complex problem analysis requiring step-by-step breakdown
191+
- Design decisions needing systematic evaluation
192+
- Scenarios where initial scope is unclear and may evolve
193+
- Problems requiring alternative approach exploration
194+
- Situations needing detailed reasoning documentation
195+
196+
**Examples:**
197+
198+
- Software architecture design
199+
- Research methodology planning
200+
- Strategic business decisions
201+
- Technical troubleshooting
202+
- Creative problem solving
203+
- Academic research planning

0 commit comments

Comments
 (0)