A typed Go client for agent servers, generated from our OpenAPI spec

Go tends to run the quiet, load-bearing parts of a stack: the control plane, the scheduler, the service that manages a fleet of something. If that something is a fleet of agent servers, you want a client that is typed, boring, and always in sync with the API it targets. That is exactly what the official Go SDK is.

Unlike the Python and TypeScript clients, which are hand-written, the Go client is generated from our OpenAPI specification. That difference is the point of this post: it shapes how you authenticate, how the types are named, and why the client never drifts from the API.

Quick answer

Add the client with go get github.com/Server4Agent/server4agent-go. It is a typed Go client generated from the Server4Agent OpenAPI spec and covers the full REST API. You authenticate by passing your sk_live_ key as a bearer token through a context.Context value, then call typed service methods like client.ServersAPI.CreateServer(ctx). Because it is generated, every endpoint, model, and enum in the spec has a matching Go type.

Key takeaways

• The Go client is generated from the OpenAPI spec, so it always matches the live API surface.
• Authentication flows through a context value, which fits Go's idiom of passing ctx as the first argument.
• Every operation returns a typed model, a raw *http.Response, and an error, the standard generated-client shape.
• It is the right tool for Go backends and control planes that manage agent servers, not for the agent's own tool-calling.
• The module path points at the public mirror, so go get just works.

Install

Import the package and let Go resolve it:

import server4agent "github.com/Server4Agent/server4agent-go"

Then run go mod tidy, or add it directly:

go get github.com/Server4Agent/server4agent-go

There is nothing else to configure at install time. Authentication is handled per request, which we get to next.

Authenticate through context

The generated client reads your bearer token from a context value rather than a constructor argument. This is deliberate: it matches how Go code already threads ctx through call stacks, and it keeps the token scoped to the calls that need it.

package main

import (
	"context"
	"fmt"
	"os"

	server4agent "github.com/Server4Agent/server4agent-go"
)

func main() {
	client := server4agent.NewAPIClient(server4agent.NewConfiguration())

	// Your sk_live_ key as a bearer token.
	ctx := context.WithValue(context.Background(),
		server4agent.ContextAccessToken, os.Getenv("SERVER4AGENT_API_KEY"))

	tier := server4agent.SERVERTIER_SMALL
	server, _, err := client.ServersAPI.CreateServer(ctx).
		ServerCreate(server4agent.ServerCreate{Tier: &tier}).
		Execute()
	if err != nil {
		panic(err)
	}

	fmt.Println("server", server.GetId(), server.GetStatus())
}

A few things that are characteristic of a generated client: the token lives on ContextAccessToken, tiers are typed enum constants like SERVERTIER_SMALL rather than bare strings, and request bodies are typed structs (ServerCreate) built up with a fluent .Execute() at the end. Keys are server-side secrets, so read them from the environment and never ship them in anything a browser can see.

The generated-client shape

Every operation follows the same three-value return pattern, which is worth getting comfortable with because it repeats across the whole surface:

server, httpRes, err := client.ServersAPI.CreateServer(ctx).
	ServerCreate(server4agent.ServerCreate{Tier: &tier}).
	Execute()

• server is the typed model for the response body.
• httpRes is the raw *http.Response, so you can inspect status codes and headers when you need to.
• err is non-nil on transport failures and non-2xx responses.

Accessor methods like server.GetId() and server.GetStatus() guard against nil pointers on optional fields, which is the generator's way of keeping optional-versus-required honest at the type level. The full method list, grouped by service (ServersAPI, ProjectsAPI, FilesAPI, BuildsAPI, WebhooksAPI, and more), is in the API reference.

Why generated, not hand-written

The Python and TypeScript SDKs are hand-written because their audiences value ergonomics: rich handles, an async variant, promise-based calls. The Go SDK optimizes for a different thing: fidelity. Because it is generated straight from the OpenAPI document that also defines the REST API, there is no hand-maintained layer that can quietly fall behind. When the spec gains an endpoint, the Go types gain it too, in the same release.

This is the OpenAPI-first approach applied end to end. One specification is the single source of truth: it renders the API reference, and it generates this client. For a Go service whose whole job is to manage infrastructure reliably, that guarantee of "the client matches the API" is worth more than a few extra ergonomic conveniences.

Where a Go client fits

Reach for the Go SDK when Go is already the language of the system that needs to talk to Server4Agent:

• A control plane that provisions a server per tenant and tracks their lifecycle.
• A scheduler that starts builds on a cron and records the resulting URLs.
• A background worker that reacts to webhook events and updates internal state.
• An internal CLI your platform team runs to inspect and clean up servers.

What it is *not* for is the agent's own decision-making. If your agent chooses when to provision a server or run a command, connect it to the MCP server instead; it speaks tool-calling natively and needs no SDK. The Go client, like the Python and TypeScript clients, is for the code around the agent. That split is the same reason MCP tools should ship software, not just fetch data: the agent operates over MCP, and your services operate over a typed client.

FAQ

How do I install the Server4Agent Go SDK?

Run go get github.com/Server4Agent/server4agent-go, or import github.com/Server4Agent/server4agent-go and run go mod tidy. The module path points at the public mirror, so no extra configuration is needed.

How does authentication work in the Go client?

You pass your sk_live_ API key as a bearer token through a context value on server4agent.ContextAccessToken, then pass that ctx to each operation. This matches Go's idiom of threading context through call stacks.

Is the Go client hand-written or generated?

Generated from the Server4Agent OpenAPI specification. That is why it always matches the live API surface: one spec renders the API reference and generates the client, so the two never drift apart.

What does each operation return?

The typed response model, the raw *http.Response, and an error. This is the standard generated-client pattern, and it lets you inspect status codes and headers whenever you need to.

Should my agent use the Go SDK or MCP?

If the agent does its own tool-calling, use MCP. Use the Go SDK for the surrounding Go services: control planes, schedulers, workers, and internal tools that manage agent servers.

Related reading

• The Server4Agent Python SDK: provision and orchestrate agent servers
• The Server4Agent TypeScript SDK: a preview URL for every pull request
• Give your AI agent its own server with one MCP call
• MCP tools should ship software, not just fetch data
• SDK documentation

External references

• OpenAPI Initiative specification
• Go modules reference