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.
After some experience with the flattened version of Content, we see that
it can easily lead to incorrect usage and is a harder API to read.
Therefore, this CL changes back to a design similar to what we had prior
to https://go.dev/cl/672415, though opting to promote content
unmarshalling to the protocol types that use it, which leads to an
overall simpler api.
Update the contribution guide to rename 'steering committee' to 'working
group', as approved by counsel. 'Steering committee' was confusing in
the context of MCP, which has its own steering committee.
* mcp: move to 2025-06-18 schema
Add types and fields for the latest MCP schema.
The main challenge here was dealing with the presence of _meta fields
on many types, like Tool, Prompt and Resource.
- Distinguish between the _meta field of a request's params, which
includes a progress token, from the _meta field on other types,
which is simply a map.
- Redefine GetMeta to return a pointer to the map. We wanted to avoid
that, but I don't see a clean way to do so. An alternative would be
to have GetMeta return a map, and SetMeta to set it.
- Provide GetProgressToken for requests only (not notifications or other
types).
- Still to do: deal with the meta and annotation fields of ContentBlock,
which are currently duplicated for Resource and ResourceContents.
* Meta and progress token redesign
Futher clarify that the 'steering committee' is what we normally would
call a 'working group', in the preamble to the antitrust policy. We'd
like to also update the policy itself, but need approval from counsel.
