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.
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?
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
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.