The streamable HTTP client is not fully implemented, but did not fail
with meaningful error messages when encountering unsupported content
types from other servers. This may be straightforward to fix, but for
now at least provide a meaningful error message.
For modelcontextprotocol/go-sdk#129.
Add example of implementing mcp on [sequentialthinking
server](https://github.com/modelcontextprotocol/servers/tree/main/src/sequentialthinking),
from [Example Servers](https://modelcontextprotocol.io/examples).
The PR includes dynamic and reflective problem-solving through
structured thinking processes.
The server provides tools for:
- starting thinking sessions
- adding sequential thoughts with step tracking
- revising previous thoughts
- creating alternative reasoning branches
- reviewing complete processes.
Also, features include thread-safe session management, adaptive planning
that adjusts step counts dynamically.
Expose `jsonrpc2.MakeID`, `jsonrpc2.EncodeMessage` and
`jsonrpc2.DecodeMessage` functions to allow implementing custom
`mcp.Transport`.
Add an example that demonstrates a custom transport
implementation.
Fixes#110.
If tools are added to a Server when Run is called, it will send
toolCapabilities to the client. Otherwise it won't. Ditto for prompts
and resources.
For #56.
Negotiate the protocol version properly, and set the header on HTTP
transports.
We follow the logic of the Typescript SDK.
- On initialization, the client sends the latest version it can support,
and accepts the version that the server returns if the client supports
it. If not, the connection fails.
- The server accepts the client's version unless it doesn't support it,
in which case it replies with its latest version.
Fixes#103.
Make `Server.Run` return when the provided context is canceled.
Add tests for when the `Run` context is cancelled and also for when the
server process receives a signal.
Fixes#107.
This PR add cycle detection where it return error instead of waiting for
stack overflow.
This is a fix for https://github.com/modelcontextprotocol/go-sdk/issues/77.
The root cause of the issue was the type being processed is deeply
nested and has cycle. Hence, the heap memory growth is faster than the
stack growth, it went OOM before stack overflow panic can kick in.
When attempting to create an OAuth authentication on top of the SSE
transport I discovered the sseClientConn was using http.DefaultClient
for requests instead of the custom client provided via
SSEClientTransportOptions.
This change stores the HTTP client in the sseClientConn struct and uses
it for all requests. Also adds test to verify the custom client is
properly used.
1. Replaced the `uriTemplateToRegexp` function with the use of
[yosida95/uritemplate](https://github.com/yosida95/uritemplate) to
handle URI template matching as per the request.
2. Updated the relevant test cases to verify the new implementation and
fixed an invalid URI template (`"file:///{}/{a}/{b}"`) that doesn't
conform to RFC 6570 due to an empty `{}` expression.
3. Updated `go.mod` and `go.sum` to reflect the new dependency.
Fixes#11.
BREAKING CHANGE
Change the API for adding tools, prompts, resources and resource
templates to a server.
The ServerXXX types are gone along with the plural Add methods
(AddTools, AddPrompts etc.)
Instead there are single Add methods (AddTool, AddPrompt).
In addition, instead of NewServerTool, there is AddTool[In, Out].
Fixes#73.
The text field is required, but current implementation omits the text
field when it is a blank string.
Some clients fail to parse the response if the text field is omitted. A
blank text result is a valid MCP response.
Claude desktop error message:
```
ClaudeAiToolResultRequest.content.0.text.text: Field required
```
The solution is to return the field even when it is blank by removing
`omitempty`.
This CL implements a completion handler for the server and a complete
method for the client.
Fixes: #12
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
This adds support for completion.
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
Added tests and an example.
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
N/A
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
This PR introduces the ResourceLink type to represent links to
resources. The new type includes the following fields: `uri`, `name`,
`title`, `description`, `mimeType`, `size`, and `_meta`.
This implementation conforms to the `ResourceLink` schema introduced in
the [MCP schema
2025-06-18](1cfdf1e7a8/schema/2025-06-18/schema.json (L1826)).
Note: `ResourceLink` extends from the `Resource` type in the MCP schema.
As such, it inherits support for optional fields like `title`, `_meta`,
etc. Thus, `URI`, `Name`, `Title`, `Description`, and `Size` are added
to the `wireContent`
For reference, the [TypeScript SDK test
suite](fb4d07f0ee/src/types.test.ts (L43))
provides examples demonstrating valid ResourceLink objects with all
optional fields populated.
https://modelcontextprotocol.io/specification/2025-06-18/server/tools#resource-links
- [ResourceLink JSON
Schema](1cfdf1e7a8/schema/2025-06-18/schema.json (L1826))
Signed-off-by: Xin Fu <xfu83@bloomberg.net>
Fixes#14.
Support additional (extra) keywords beyond those specified in the
`Schema` type. The current behavior is additional keywords are dropped.
To follow up:
- There are similar util functions in `mcp/util.go` which don't seem to
be used. Maybe we should move it to `internal/util` instead of
`jsonchema/util.go` package?
- The method `[Un]MarshalJSON` is only on `pointer receiver`, is this
intended? (that means it will only work if we [un]marshal pointer to the
`Schema` instance)
- The fix is using the [un]marshalStructWithMap from `mcp/util.go` and
there are requirements for the function to work properly but these are
not strictly checked e.g. need `json:"-"` tag for the Extra field.
Fixes#69.
I added an example for how rate limiting should be implemented using
middleware.
Fixes#22
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
Rate limiting can be enabled using middleware. This adds an example on
how to do that.
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
N/A
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
No
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
This pull request addresses multiple minor documentation and code
comment fixes to correct typos and improve clarity. These changes do not
introduce functional modifications but enhance readability and
professionalism.
### Documentation Fixes:
* Corrected a typo in the "Security Considerations" section header in
`design/design.md`. ("Securty" → "Security")
* Fixed spelling errors in the "Governance and Community" section of
`design/design.md`. ("accomodating" → "accommodating")
* Updated the "Proposals" section in `design/design.md` to fix a typo.
("accomodate" → "accommodate")
### Code Comment Fixes:
* Corrected a typo in a comment in `mcp/logging.go`. ("LoggingMesssage"
→ "LoggingMessage")
* Fixed a typo in a comment in `mcp/streamable.go`. ("priviledged" →
"privileged")
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
This PR is for fixing some typos in the repo
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
by code diff
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
N/A
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Fix an example using params.Name instead of params.Arguments.Name. All
credit due to @A11Might for noticing this. Sending a separate PR to keep
the internal/readme source consistent.
