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.
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.
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?
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.
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
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.
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.
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. 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.
> 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.
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.*
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?
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.
Thanks, I should have read the tool description more carefully.
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
The same lib is used in this project: https://github.com/TuanKiri/weather-mcp-server/blob/master/g...
oooooh, thanks for sharing.
It's exactly what I was looking for
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...
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.
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.