MCP golang is an unofficial implementaion of the Model Context Protocol in Go.
Docs can be found at https://mcpgolang.com
type Content struct {
Title string `json:"title" jsonschema:"required,description=The title to submit"`
Description *string `json:"description" jsonschema:"description=The description to submit"`
}
type MyFunctionsArguments struct {
Submitter string `json:"submitter" jsonschema:"required,description=The name of the thing calling this tool (openai, google, claude, etc)"`
Content Content `json:"content" jsonschema:"required,description=The content of the message"`
}
func main() {
done := make(chan struct{})
server := mcp_golang.NewServer(stdio.NewStdioServerTransport())
err := server.RegisterTool("hello", "Say hello to a person", func(arguments MyFunctionsArguments) (*mcp_golang.ToolResponse, error) {
return mcp_golang.NewToolReponse(mcp_golang.NewTextContent(fmt.Sprintf("Hello, %server!", arguments.Submitter))), nil
})
if err != nil {
panic(err)
}
err = server.RegisterPrompt("promt_test", "This is a test prompt", func(arguments Content) (*mcp_golang.PromptResponse, error) {
return mcp_golang.NewPromptResponse("description", mcp_golang.NewPromptMessage(mcp_golang.NewTextContent(fmt.Sprintf("Hello, %server!", arguments.Title)), mcp_golang.RoleUser)), nil
})
if err != nil {
panic(err)
}
err = server.RegisterResource("test://resource", "resource_test", "This is a test resource", "application/json", func() (*mcp_golang.ResourceResponse, error) {
return mcp_golang.NewResourceResponse(mcp_golang.NewTextEmbeddedResource("test://resource", "This is a test resource", "application/json")), nil
})
err = server.Serve()
if err != nil {
panic(err)
}
<-done
}
This will start a server using the stdio transport (used by claude desktop), host a tool called "hello" that will say hello to the user who submitted it.
You can use raw go structs as the input to your tools, the library handles generating the messages, deserialization, etc.
- The library should bias towards maintaining type safety, even when adding extra complexity (reflection to check types etc)
- The libary api should be simple and easy to use for basic cases of the protocol but we are explicitly aiming to support production use cases firs
- Where complexity arises, the library will have sane defaults and allow the user to override them if needed.
- The library aims to support servers first and foremost, when the server features are stable, we will work on adding client support.
Contributions are more than welcome! Please check out our contribution guidelines.
Got any suggestions, have a question on the api or usage? Ask on the discord server. A maintainer will be happy to help you out.
- Tool Calls
- Programatically generated tool list endpoint
- Prompt Calls
- Programatically generated prompt list endpoint
- Resource Calls
- Programatically generated resource list endpoint
- Stdio
- SSE
- Custom transport support
- HTTPS with custom auth support - in progress. Not currently part of the spec but we'll be adding experimental support for it.
Currently under development