DEV Community: Pradip Parmar

Writing an MCP Server in Go: Exposing Tools to LLM Agents

Pradip Parmar — Thu, 29 Oct 2026 07:40:45 +0000

The Model Context Protocol (MCP) gives AI clients such as Cursor a standard way to discover and call tools that live in your systems. Instead of writing a custom plugin for every assistant, you write one MCP server, and any MCP-capable client can use it.

I built an MCP server for sprint-management, a Jira-style project management product I built with a Go API, React and PostgreSQL. The server lets Cursor read and update work items directly from the editor. This post covers how to build that kind of server in Go, and the design choices that matter more than the protocol itself. The code is a simplified example, not the product's source.

What an MCP server actually is

At its core, an MCP server is a process that:

Tells the client which tools it offers (name, description, JSON Schema for input and output).
Receives tool calls with JSON arguments.
Returns results the model can read.

It talks JSON-RPC over a transport: usually stdio (the client launches your binary) or streamable HTTP (your server runs as a service). Go is a good fit: a single static binary is easy to point a client at, and struct tags give you schemas almost for free.

Setup

Use the official Go SDK:

go mod init example.com/sprint-mcp
go get github.com/modelcontextprotocol/go-sdk/mcp

A typed read tool

With the official SDK, a tool is a normal Go function with typed input and output. The SDK infers the JSON Schema from your structs, and the jsonschema tag becomes the field description the model sees.

type ListIssuesInput struct {
    ProjectKey string `json:"project_key" jsonschema:"project key, for example CORE"`
    Status     string `json:"status,omitempty" jsonschema:"optional filter: todo, in_progress or done"`
    Limit      int    `json:"limit,omitempty" jsonschema:"max issues to return, 1-50, default 20"`
}

type Issue struct {
    Key      string `json:"key"`
    Title    string `json:"title"`
    Status   string `json:"status"`
    Assignee string `json:"assignee,omitempty"`
}

type ListIssuesOutput struct {
    Issues []Issue `json:"issues"`
}

func (s *Server) listIssues(ctx context.Context, req *mcp.CallToolRequest, in ListIssuesInput) (
    *mcp.CallToolResult, ListIssuesOutput, error,
) {
    if in.Limit <= 0 || in.Limit > 50 {
        in.Limit = 20
    }
    if in.Status != "" && !validStatus[in.Status] {
        return nil, ListIssuesOutput{}, fmt.Errorf("unknown status %q; use todo, in_progress or done", in.Status)
    }
    issues, err := s.store.ListIssues(ctx, s.user, in.ProjectKey, in.Status, in.Limit)
    if err != nil {
        return nil, ListIssuesOutput{}, err
    }
    return nil, ListIssuesOutput{Issues: issues}, nil
}

Notice the error message. It's written for the model, not for a log file. When the model passes a bad status, a clear message telling it the valid values lets it correct itself on the next call. With the official SDK, an error returned from a tool handler is sent back to the client as a tool result with IsError set, so the model sees it and can retry. The SDK also validates arguments against the generated schema before your handler runs, but schema checks can't know your business rules, so validate those yourself.

A write tool, with guardrails

Read tools are low risk. Write tools are where an agent can do real damage, so they get stricter handling:

type MoveIssueInput struct {
    IssueKey string `json:"issue_key" jsonschema:"issue key, for example CORE-123"`
    ToStatus string `json:"to_status" jsonschema:"target status: todo, in_progress or done"`
}

type MoveIssueOutput struct {
    IssueKey   string `json:"issue_key"`
    FromStatus string `json:"from_status"`
    ToStatus   string `json:"to_status"`
}

func (s *Server) moveIssue(ctx context.Context, req *mcp.CallToolRequest, in MoveIssueInput) (
    *mcp.CallToolResult, MoveIssueOutput, error,
) {
    if !issueKeyRE.MatchString(in.IssueKey) {
        return nil, MoveIssueOutput{}, fmt.Errorf("issue_key %q is not in the form ABC-123", in.IssueKey)
    }
    if !validStatus[in.ToStatus] {
        return nil, MoveIssueOutput{}, fmt.Errorf("unknown status %q", in.ToStatus)
    }
    // Same permission check the REST API uses. The MCP server is just another client.
    if !s.authz.Can(s.user, "issue:update", in.IssueKey) {
        return nil, MoveIssueOutput{}, fmt.Errorf("user %s may not update %s", s.user.Email, in.IssueKey)
    }
    from, err := s.store.MoveIssue(ctx, in.IssueKey, in.ToStatus)
    if err != nil {
        return nil, MoveIssueOutput{}, err
    }
    s.audit.Log(ctx, s.user, "mcp.move_issue", in.IssueKey, from, in.ToStatus)
    return nil, MoveIssueOutput{IssueKey: in.IssueKey, FromStatus: from, ToStatus: in.ToStatus}, nil
}

Four rules I apply to every write tool:

Narrow, typed operations. move_issue with an enum, not run_sql or update_issue(fields map[string]any). The smaller the surface, the fewer ways to be wrong.
Reuse your real authorization. The MCP server should call the same domain service and RBAC checks as your REST API. Never give it a privileged database connection that bypasses them.
Return what changed. Including from_status lets the model (and the human) confirm the effect.
Audit everything. Agent-initiated writes should be traceable separately from human ones.

Wiring up the server

func main() {
    logger := slog.New(slog.NewTextHandler(os.Stderr, nil)) // never stdout with stdio transport

    srv, err := NewServer(os.Getenv("SPRINT_API_TOKEN"), logger)
    if err != nil {
        logger.Error("startup", "err", err)
        os.Exit(1)
    }

    server := mcp.NewServer(&mcp.Implementation{Name: "sprint-management", Version: "v0.1.0"}, nil)

    mcp.AddTool(server, &mcp.Tool{
        Name:        "list_issues",
        Description: "List issues in a project, optionally filtered by status. Read-only.",
    }, srv.listIssues)

    mcp.AddTool(server, &mcp.Tool{
        Name:        "move_issue",
        Description: "Move one issue to a new status. Changes data. Use list_issues first to find the key.",
    }, srv.moveIssue)

    if err := server.Run(context.Background(), &mcp.StdioTransport{}); err != nil {
        logger.Error("server stopped", "err", err)
        os.Exit(1)
    }
}

The stdio gotcha: with the stdio transport, stdout is the protocol channel. A stray fmt.Println or a logger writing to stdout corrupts the JSON-RPC stream, and the client fails in confusing ways. Send all logs to stderr.

Descriptions matter more than they look. The model chooses tools from their names and descriptions alone. Say what the tool does, whether it changes data, and which tool to call first.

Connecting it to Cursor

Build the binary and register it in your project's .cursor/mcp.json:

{
  "mcpServers": {
    "sprint-management": {
      "command": "/usr/local/bin/sprint-mcp",
      "env": { "SPRINT_API_TOKEN": "your-token" }
    }
  }
}

Cursor launches the process, lists its tools, and the agent can now call list_issues and move_issue while you work. The token identifies the user, so the agent acts with that user's permissions, nothing more.

When to use HTTP instead of stdio

Stdio is the simplest choice for a developer tool on one machine. If several users or remote agents need the same server, run it as a service with the SDK's streamable HTTP handler:

handler := mcp.NewStreamableHTTPHandler(func(r *http.Request) *mcp.Server {
    return server
}, nil)
http.Handle("/mcp", authMiddleware(handler))
log.Fatal(http.ListenAndServe(":8080", nil))

Over HTTP, authentication is your job. Put it in middleware, derive the user from the request, and apply the same per-user permission checks inside each tool.

Testing

Tool handlers are plain Go functions, so most tests don't need the protocol at all: call srv.moveIssue directly with a fake store and assert on validation, authorization and audit behaviour. For one or two end-to-end tests, the SDK includes a client (mcp.NewClient) and an in-memory transport, so you can connect a real client to your server in-process and call tools by name.

Design checklist

One tool per clear intent; avoid "do anything" tools.
Typed inputs with descriptions and enums; validate anyway.
Error messages that tell the model how to fix the call.
Mark write tools clearly and keep them narrow.
Same auth, RBAC and audit as your REST API.
Logs to stderr on stdio.

MCP itself is a thin layer. The value of a good MCP server comes from the same things that make a good API: small typed operations, strong permissions and honest errors.

Pradip Parmar is a Go backend and AI agent engineer (writing Go since 2018) who builds MCP servers, RAG systems and LLM agents for businesses, including an MCP server that connects a Jira-style product to Cursor. If you're looking for an MCP server developer in Go, contact him on LinkedIn, Upwork or Contra. Code: GitHub.

LLM Tool Calling in Go: A ReAct-Style Agent Loop with Guardrails and Cost Control

Pradip Parmar — Thu, 29 Oct 2026 06:30:09 +0000

Most of my agent projects in Go share one piece of code: the loop. The model looks at the conversation, decides to call a tool or answer, the program runs the tool, feeds the result back, and repeats. That's the ReAct pattern (reason, act, observe) in its practical form.

I've built this loop several times: in agent-helper, a shared Go library that runs the same chat loop on Gemini or local Ollama models with an installable tool registry; in a Gemini tool-calling assistant for a Jira-style product; in a Clean Architecture ReAct agent that drafts social posts; and in a local voice assistant that uses Ollama tool calling. The happy path is about 40 lines. Most of the engineering is in the guardrails. This post builds a simplified version of that loop with the guardrails included.

Step 1: a provider-agnostic interface

Don't let the agent loop import a specific SDK. Define the minimum it needs:

type Role string

const (
    RoleUser      Role = "user"
    RoleAssistant Role = "assistant"
    RoleTool      Role = "tool"
)

type ToolCall struct {
    ID   string
    Name string
    Args json.RawMessage
}

type Message struct {
    Role       Role
    Content    string
    ToolCalls  []ToolCall // set when the model asks for tools
    ToolCallID string     // set on tool results
}

type Usage struct{ InputTokens, OutputTokens int }

type ChatModel interface {
    Chat(ctx context.Context, msgs []Message, tools []ToolSpec) (Message, Usage, error)
}

Each provider (Gemini, OpenAI-compatible APIs, Ollama) gets a small adapter that converts to and from these types. Switching between a hosted model and a local one then becomes a config change, which is exactly how agent-helper moves the same agent between Gemini and Ollama.

Step 2: a typed tool registry

Tools are plug-ins. The loop shouldn't change when you add one.

type ToolSpec struct {
    Name        string
    Description string
    Schema      json.RawMessage // JSON Schema for the arguments
}

type Tool struct {
    Spec    ToolSpec
    Mutates bool          // changes external state?
    Timeout time.Duration // per-call limit
    Run     func(ctx context.Context, args json.RawMessage) (string, error)
}

type Registry struct{ tools map[string]Tool }

func (r *Registry) Register(t Tool) {
    if r.tools == nil {
        r.tools = map[string]Tool{}
    }
    r.tools[t.Spec.Name] = t
}

func (r *Registry) Specs() []ToolSpec {
    specs := make([]ToolSpec, 0, len(r.tools))
    for _, t := range r.tools {
        specs = append(specs, t.Spec)
    }
    sort.Slice(specs, func(i, j int) bool { return specs[i].Name < specs[j].Name })
    return specs
}

Sorting the specs keeps the prompt stable between calls, which helps reproducibility and, with providers that cache prompt prefixes, cost.

Inside Run, decode arguments strictly into a struct and validate them. The model's JSON is untrusted input:

func decodeArgs[T any](raw json.RawMessage) (T, error) {
    var v T
    dec := json.NewDecoder(bytes.NewReader(raw))
    dec.DisallowUnknownFields()
    if err := dec.Decode(&v); err != nil {
        return v, fmt.Errorf("invalid arguments: %w", err)
    }
    return v, nil
}

Step 3: the loop, with budgets

Here's the core. Every guardrail is explicit:

type Limits struct {
    MaxSteps       int           // model round-trips
    MaxTotalTokens int           // input + output across the run
    MaxRepeats     int           // identical tool calls allowed
    RunTimeout     time.Duration // wall clock for the whole run
}

type Approver func(ctx context.Context, call ToolCall) (bool, error)

type Agent struct {
    Model   ChatModel
    Tools   *Registry
    Limits  Limits
    Approve Approver // nil means write tools are refused
}

var ErrBudget = errors.New("agent budget exhausted")

func (a *Agent) Run(ctx context.Context, msgs []Message) (string, error) {
    ctx, cancel := context.WithTimeout(ctx, a.Limits.RunTimeout)
    defer cancel()

    used := 0
    seen := map[string]int{}

    for step := 0; step < a.Limits.MaxSteps; step++ {
        reply, usage, err := a.Model.Chat(ctx, msgs, a.Tools.Specs())
        if err != nil {
            return "", fmt.Errorf("step %d: %w", step, err)
        }
        used += usage.InputTokens + usage.OutputTokens
        msgs = append(msgs, reply)

        if len(reply.ToolCalls) == 0 {
            return reply.Content, nil // final answer
        }
        if used > a.Limits.MaxTotalTokens {
            return "", fmt.Errorf("%w: %d tokens", ErrBudget, used)
        }

        for _, call := range reply.ToolCalls {
            key := call.Name + string(call.Args)
            seen[key]++
            var result string
            if seen[key] > a.Limits.MaxRepeats {
                result = "error: you already made this exact call; use the earlier result or try a different approach"
            } else {
                result = a.execute(ctx, call)
            }
            msgs = append(msgs, Message{Role: RoleTool, ToolCallID: call.ID, Content: result})
        }
    }
    return "", fmt.Errorf("%w: max steps (%d)", ErrBudget, a.Limits.MaxSteps)
}

What each guardrail prevents:

MaxSteps stops a model that never decides it's done.
MaxTotalTokens caps cost per run. Every step resends the whole conversation, so input tokens grow with each round-trip. A ten-step run costs much more than ten times a single call.
MaxRepeats catches the common failure where a model calls the same tool with the same arguments again and again.
RunTimeout bounds wall-clock time, and because it's a context, it cancels in-flight HTTP calls and tools too.

Step 4: executing tools safely

func (a *Agent) execute(ctx context.Context, call ToolCall) string {
    tool, ok := a.Tools.tools[call.Name]
    if !ok {
        return fmt.Sprintf("error: unknown tool %q", call.Name)
    }
    if tool.Mutates {
        if a.Approve == nil {
            return "error: this tool changes data and is not allowed in this session"
        }
        ok, err := a.Approve(ctx, call)
        if err != nil || !ok {
            return "error: the user did not approve this action"
        }
    }

    tctx, cancel := context.WithTimeout(ctx, tool.Timeout)
    defer cancel()

    out, err := tool.Run(tctx, call.Args)
    if err != nil {
        return "error: " + err.Error()
    }
    const maxResult = 8_000
    if len(out) > maxResult {
        out = out[:maxResult] + "\n[truncated]"
    }
    return out
}

Three details matter here:

Errors go back to the model as text, not up the stack. A model that sees "invalid arguments: unknown field prio" usually fixes the call on the next step. Only infrastructure failures (the model API itself failing) should end the run.
Write tools need approval. The Approver can be a CLI prompt, a Telegram button or a web confirmation. Read tools run freely; anything that sends, deletes or updates waits for a human or a policy check.
Truncate tool output. One tool returning a 2 MB web page will blow your token budget and dilute the model's attention. Cap results, or summarise them before they go back.

Cost control beyond the loop

The loop's budgets are the safety net. These keep costs low in normal operation:

Expose fewer tools. Every tool schema is sent on every step. Register only the tools the current task needs.
Keep tool results compact. Return the fields the model needs, not whole database rows.
Use smaller or local models where possible. With a provider-agnostic interface, routine steps can run on a local Ollama model and harder ones on a hosted model.
Log usage per run. Record steps, tokens and tool calls for each run. You can't control a cost you don't measure.

Testing the loop

Because ChatModel is an interface, a scripted fake makes the loop fully testable without network calls:

type scriptedModel struct{ replies []Message; i int }

func (m *scriptedModel) Chat(ctx context.Context, _ []Message, _ []ToolSpec) (Message, Usage, error) {
    r := m.replies[m.i]
    m.i++
    return r, Usage{InputTokens: 100, OutputTokens: 20}, nil
}

Write tests for the boring cases: unknown tool, invalid arguments, repeated call, budget exceeded, write tool without approval. Those are the paths that protect you in production.

Takeaways

The model decides what to try. Your Go code decides what is allowed, how long it may take and how much it may cost. Keep the loop small, keep the tools typed, and make every limit explicit.

Pradip Parmar is a Go backend and AI agent engineer who has worked in Go since 2018. He builds LLM agents with tool calling, MCP servers and RAG systems for businesses, from hosted Gemini and OpenAI-compatible models to fully local Ollama setups. To hire a Go AI agent developer, find him on LinkedIn, Upwork or Contra, and on GitHub.

Building a Production RAG API in Go with pgvector and Gemini

Pradip Parmar — Thu, 29 Oct 2026 05:44:03 +0000

Lessons from building the Restaurant Suggestion System, a Go/Gin backend with a conversational recommendation API.

A RAG demo takes an afternoon: embed some documents, run a similarity search, paste the results into a prompt. A RAG API you can put in front of real users takes longer, because most of the work is not the LLM call. It's everything around it.

I built the Restaurant Suggestion System (RSS) as a Go/Gin backend where users chat to get dish and restaurant suggestions. The answers come from RAG over real menu data in PostgreSQL with pgvector and Gemini embeddings. Because the recommendations have to respect allergies, "the model usually gets it right" was never good enough.

This post walks through the shape of that pipeline and the Go patterns that made it dependable. The snippets are simplified and focused on the ideas, not copied from the private repo.

The pipeline

Every chat request goes through the same steps:

Embed the user's message (plus stored preferences) with Gemini.
Retrieve candidates from Postgres with pgvector, with allergen and health filters applied in SQL.
Score candidates deterministically in Go.
Generate a conversational answer with the LLM, using only the top candidates as context.
Validate the answer against the candidates we sent.
Fall back to a vector-only response if the LLM is slow or unavailable.

The rule behind all of it: the LLM explains and converses. It does not decide what is safe or what exists.

Schema: keep filters as real columns

It's tempting to put everything into the embedded text and let similarity sort it out. Don't do that for anything safety-related. Allergens belong in a column you can filter on exactly.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE menu_items (
    id            BIGSERIAL PRIMARY KEY,
    restaurant_id BIGINT NOT NULL REFERENCES restaurants(id),
    name          TEXT NOT NULL,
    description   TEXT NOT NULL,
    allergens     TEXT[] NOT NULL DEFAULT '{}',
    price_cents   INT NOT NULL,
    is_available  BOOLEAN NOT NULL DEFAULT TRUE,
    embedding     vector(768) NOT NULL
);

CREATE INDEX ON menu_items USING hnsw (embedding vector_cosine_ops);
CREATE INDEX ON menu_items USING gin (allergens);

The dimension (768 here) must match the embedding model's output configuration. Pick one, store it in config, and fail fast at startup if they disagree. A silent dimension mismatch is a miserable bug to find in production.

Embeddings with Gemini

RSS uses Gemini embeddings in two places: when indexing menu items, and during onboarding to capture user preferences as a vector. Wrap the provider behind a small interface so the rest of the code doesn't care which SDK you use:

type Embedder interface {
    Embed(ctx context.Context, text string) ([]float32, error)
}

type GeminiEmbedder struct {
    client *genai.Client
    model  string
    dims   int32
}

func (g *GeminiEmbedder) Embed(ctx context.Context, text string) ([]float32, error) {
    ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
    defer cancel()

    res, err := g.client.Models.EmbedContent(ctx, g.model,
        genai.Text(text),
        &genai.EmbedContentConfig{OutputDimensionality: &g.dims},
    )
    if err != nil {
        return nil, fmt.Errorf("embed: %w", err)
    }
    if len(res.Embeddings) == 0 || len(res.Embeddings[0].Values) != int(g.dims) {
        return nil, errors.New("embed: unexpected embedding shape")
    }
    return res.Embeddings[0].Values, nil
}

Two habits worth copying: a hard timeout on every external call, and a shape check on the response. The interface also makes tests easy, since a fake embedder returns fixed vectors.

Retrieval: filter in SQL, before the LLM

This is the most important design decision in the system. Allergen and health filters run in the retrieval query, so excluded items never reach the model. A prompt like "don't suggest peanuts" is a request. A WHERE clause is a guarantee.

type Candidate struct {
    ID         int64
    Name       string
    Allergens  []string
    PriceCents int
    Distance   float64
}

const retrieveSQL = `
SELECT id, name, allergens, price_cents, embedding <=> $1 AS distance
FROM menu_items
WHERE is_available
  AND NOT (allergens && $2::text[])
ORDER BY embedding <=> $1
LIMIT $3`

func (r *Repo) Retrieve(ctx context.Context, q []float32, exclude []string, k int) ([]Candidate, error) {
    rows, err := r.db.Query(ctx, retrieveSQL, pgvector.NewVector(q), exclude, k)
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var out []Candidate
    for rows.Next() {
        var c Candidate
        if err := rows.Scan(&c.ID, &c.Name, &c.Allergens, &c.PriceCents, &c.Distance); err != nil {
            return nil, err
        }
        out = append(out, c)
    }
    return out, rows.Err()
}

One pgvector gotcha: with an approximate index such as HNSW, filtering happens after the index returns its nearest neighbours. With a strict filter you can get fewer than k rows back. pgvector 0.8+ supports iterative index scans (SET hnsw.iterative_scan = relaxed_order;), which keep scanning until enough rows pass the filter. On older versions, raise hnsw.ef_search or over-fetch and trim. Either way, write a test where most rows are filtered out and check you still get results.

Deterministic scoring

Vector distance is one signal, not the ranking. RSS ranks filtered candidates with a deterministic scoring engine, so the same input gives the same order and every recommendation can be explained.

type Weights struct {
    Similarity, Preference, Budget float64
}

func Score(c Candidate, prefSim float64, budgetCents int, w Weights) float64 {
    s := w.Similarity*(1-c.Distance) + w.Preference*prefSim
    if budgetCents > 0 && c.PriceCents <= budgetCents {
        s += w.Budget
    }
    return s
}

func Rank(cands []Candidate, scores map[int64]float64) {
    sort.SliceStable(cands, func(i, j int) bool {
        si, sj := scores[cands[i].ID], scores[cands[j].ID]
        if si != sj {
            return si > sj
        }
        return cands[i].ID < cands[j].ID // stable tie-break
    })
}

Note the tie-break on ID. Without it, equal scores can shuffle between runs, and your tests become flaky. The signals here are illustrative; the point is that ranking lives in plain Go you can unit-test, not in a prompt.

Generation: ground it, then check it

Only the top candidates go into the prompt, each with its ID. A pattern I recommend on top of that: ask the model for structured output that references those IDs, and validate the response before returning it:

type LLMAnswer struct {
    Message string  `json:"message"`
    ItemIDs []int64 `json:"item_ids"`
}

func validateAnswer(a LLMAnswer, sent []Candidate) error {
    allowed := make(map[int64]bool, len(sent))
    for _, c := range sent {
        allowed[c.ID] = true
    }
    for _, id := range a.ItemIDs {
        if !allowed[id] {
            return fmt.Errorf("model referenced unknown item %d", id)
        }
    }
    return nil
}

If the model mentions something you didn't give it, that's a hallucination by definition, and you can detect it in a few lines.

The fallback: vector-only results

LLM APIs time out, hit rate limits and have outages. RSS handles that by degrading gracefully: if the LLM call fails, the API still returns the filtered, scored candidates from vector search. In the sketch below, an answer that fails validation takes the same path:

func (s *Service) Recommend(ctx context.Context, req ChatRequest) (ChatResponse, error) {
    cands, err := s.retrieveAndRank(ctx, req)
    if err != nil {
        return ChatResponse{}, err // no data, no answer
    }

    genCtx, cancel := context.WithTimeout(ctx, 8*time.Second)
    defer cancel()

    ans, err := s.llm.Answer(genCtx, req.Message, cands)
    if err == nil {
        err = validateAnswer(ans, cands)
    }
    if err != nil {
        s.log.Warn("llm unavailable, using vector-only fallback", "err", err)
        return fallbackResponse(cands), nil
    }
    return ChatResponse{Message: ans.Message, ItemIDs: ans.ItemIDs, Source: "llm"}, nil
}

Because the safety filters ran before the LLM, the fallback is just as safe as the full path. It's less chatty, not less correct. Returning a Source field also helps the frontend and your dashboards see how often you're degrading.

The rest of the production checklist

The RAG pipeline is maybe a third of the system. The rest is ordinary backend work that still matters:

Auth: passwordless email OTP, JWT, and role-based access control so admin endpoints stay admin-only.
Data ingest: CRUD plus CSV/JSON bulk upload and AWS file upload. Whatever your ingest path, make sure every write also refreshes the item's embedding, or search goes stale.
Privacy: admin analytics built without exposing PII.
Ops: Postgres with pgvector in Docker, so local, CI and production run the same database.
Tests: a Newman (Postman) end-to-end suite that hits the real API. Make sure the fallback path has its own tests too.

Takeaways

Put safety rules in SQL and Go, never only in the prompt.
Rank deterministically, with stable tie-breaks.
Validate model output against the context you sent.
Design the fallback first. If the LLM disappears, users should still get a correct answer.

Go suits this well: strict types for model output, context deadlines on every call, and a single binary that's easy to run next to Postgres.

Pradip Parmar is a Go backend and AI agent engineer who has been writing Go since 2018. He builds RAG systems, MCP servers and LLM agents for businesses, and previously led the Python-to-Go migration of the Flights backend at MakeMyTrip. If you need a Go AI agent developer for a RAG or agent project, you can reach him on LinkedIn, Upwork or Contra, or see his code on GitHub.