[HN Gopher] Show HN: Minimal MCP server in Go showcasing project...
___________________________________________________________________
Show HN: Minimal MCP server in Go showcasing project architecture
I'm relatively new to Go, but recently got interested in how MCP
servers work. I started thinking about what the architecture of
such a project might look like, and decided to build a minimalist
version as an experiment. I based it on my past experience writing
regular REST API servers and figured it might be useful or
interesting to others as well.
Author : TuanKiri
Score : 69 points
Date : 2025-04-07 18:44 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| timewizard wrote:
| Go is one of those languages where "good layout" feels more
| elusive to me than in other languages. I think you accidentally
| highlight one of the reasons why.
| core.WeatherServices
|
| Which makes sense because you're using a lot of things from core
| but since I have to carry the package name around everywhere I
| use it, outside of that module, it becomes a bit of a strain.
| weather.Service
|
| Would clearly be a better name in the "go style," but the single
| level package structure always makes me feel like my types are
| dangling out in space outside of any decent hierarchy.
|
| I love Go as a language but I dislike how often it makes me think
| of exceptionally tiny things like this. Please don't read this as
| a criticism of your project just a general criticism of how thin
| the Go "namespace" ideology actually is.
| 9rx wrote:
| _> Would clearly be a better name _
|
| It appears that it wanted to be services.WeatherService, which
| if reduced to service.Weather isn't looking so bad, but core
| ended up being introduced because the unnecessary interface
| already overloaded the namespace. The code doesn't accidentally
| highlight - it is crying out.
|
| _> always makes me feel like my types are dangling out in
| space_
|
| That's the idea, though, isn't it? Each package is its own
| distinct thing, intended to be useful and usable across many
| projects. There shouldn't be any kind of deep
| interconnectedness in most cases - and where there needs to be,
| you will typically place the related packages in a subfolder to
| communicate that relationship. I can't think offhand of any
| package manager that maintains anything other than a flat list
| of dependencies, and that's essentially what you are building
| here too.
|
| I do think you have a point that many other ecosystems have a
| mindset where you are only building a single application with
| no attempt to find reusability beyond the immediate codebase.
| In large part because those languages/ecosystems require a
| bunch of extra, often complex, steps to make packages
| exportable. It can be a bit of mental shift to consider an
| application as a set of discrete, reusable parts if you come
| from those places.
| angra_mainyu wrote:
| The usual heuristic is if you're repeating a noun in several
| variables, move those to a separate package with that noun.
|
| Example: WeatherConfig, WeatherService, WeatherPollInterval =>
| weather.*
| boyter wrote:
| Perhaps adding some guide on how to hook this up to... well
| anything would be good :)
|
| There is a lack of guidance for https://github.com/mark3labs/mcp-
| go/ which this is using as well so while everything is there, its
| hard to know how to make it do anything.
| RamblingCTO wrote:
| Good one! A lib I've used a few times now to build go mcp servers
| quite quickly would be this one:
| https://github.com/mark3labs/mcp-go I know, different goals, but
| still
| hagbarth wrote:
| The same lib is used in this project:
| https://github.com/TuanKiri/weather-mcp-server/blob/master/g...
| asabla wrote:
| oooooh, thanks for sharing.
|
| It's exactly what I was looking for
| log101 wrote:
| Thanks to tools like aider and claude code, these scaffold
| projects are getting more and more helpful. Just clone it and
| prompt it for your use case.
| ivanvanderbyl wrote:
| You really don't need this much to build an MCP server in Go. I
| built one in a single file: https://github.com/Alcova-
| AI/perplexity-mcp/blob/main/main.g...
| maverwa wrote:
| I may be failing to understand the protocol here, but the thing
| it returns for a weather request is intented to be ingested by an
| LLM, which then uses that information to reply to a user, right?
| Whats the benefit of adding CSS styling, or even HTML formatting
| to the output over just a plaintext response? I'd image that adds
| a lot of unecessary tokens the LM has to grasp?
| ricardobeat wrote:
| The LLM passes the HTML back in their response, translated, so
| it can be rendered to the user as-is. The tool description is
| self-explanatory: https://github.com/TuanKiri/weather-mcp-
| server/blob/master/i...
|
| You could have it respond with JSON, but then the rendering of
| the weather widget would have to be defined by the consumer
| instead of the tool server -- now the 'chat' part of your
| system needs to be aware of all possible content types, how to
| detect and render them; it's also doable but a different set of
| trade-offs.
___________________________________________________________________
(page generated 2025-04-08 23:02 UTC)