Audit all cases where params must not be null, and enforce this using
methodInfo via a new methodFlags bitfield that parameterizes method
requirements. Write extensive conformance tests catching all the
(server-side) crashes that were possible.
We should go further and validate schema against the spec, but that is
more indirect, more complicated, and potentially slower. For now we
adopt this more explicit approach.
Still TODO in a subsequent CL: verify the client side of this with
client conformance tests.
Additionally, improve some error messages that were redundant or leaked
internal implementation details.
Fixes#195
When calling `ServerSession.CreateMessage`, will get an json unmarshal
error because `CreateMessageResult.Content` is an interface, and it
doesn't implement `json.Unmarshaller`.
Implement the `json.Unmarshaller` to `CreateMessageResult`, let it able
to unmarshal the client response without error
Add an isRequest field to methodInfo, used it to reject non-notification
requests that lack a valid ID. Furthermore, lift this validation to the
transport layer for HTTP server transports, so that we can preemptively
reject bad HTTP requests.
Fixes#194Fixes#197
This CL adds an option for servers to advertise support for features
that have not been added yet. This includes Prompts, Tools, and
Resources as these could be dynamically added after initialization.
Fixes: #135.
- move done field outside of mutex hat
- refactor handler into a function that returns `error` to avoid repeated `http.Error` calls
- use an atomic for the signal channel to simplify locking
Introduce an EventStore interface to store events for resumable streams.
Provide an in-memory implementation.
Still to do: connect to streaming transports.
For #10
Export the Event type in preparation for providing user-definable
storage for resumable streams.
Also, move event code to a separate file.
This PR is just renaming and code motion.
Update `ImageContent` and `AudioContent` to use an inline wire format
to ensure that required fields are not omitted during JSON marshaling,
matching TypeScript schema requirements. This follows the TextContent
approach.
- `ImageContent` requires `data` and `mimeType` fields.
- `AudioContent` requires `data` and `mimeType` fields.
I needed to implement some logging for our experimental server that we
are building out using the SDK, and figured I could propose an example
that might make it easier for folks in the future.
For #33.
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.
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.
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.
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
-->
