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
-->
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.
* 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
Address comments on CL 682555 about using sscanf for parseEventID,
adding a test for parseEventID and formatEventID.
Change-Id: Ie31c5431c33829eaf244a5927da9e07bf5c300b5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/683336
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Findley <rfindley@google.com>
