Add article.json

Author: calvinmclean

articles/gopls-mcp-demo/article.json

@@ -0,0 +1,6 @@
+{
+  "title": "Experiment with gopls MCP: Improving Agent Context for Go Development",
+  "description": "Join me while I learn about the gopls MCP and see how (or if) it can improve your agentic development and reduce context usage.",
+  "tags": ["go", "tutorial", "ai"],
+  "gopher": "https://storage.googleapis.com/gopherizeme.appspot.com/gophers/6bea50eb4b234e091ccac017cd9587bb5a68a717.png"
+}

articles/gopls-mcp-demo/article.md

@@ -1,8 +1,8 @@
-When working with LLMs, managing the context size is really important. [In previous research](https://dev.to/calvinmclean/how-to-implement-llm-tool-calling-with-go-and-ollama-237g), I learned that a chat session with an LLM or agent is stored as a continuous array of messages and is re-processed by the model for each prompt. As the conversation or coding sessions goes on, the amount of data the model has to process grows. This eventually erodes the responses since they are processing too much information. It is best to keep sessions short, concise, and on-topic.
+When working with LLMs, managing the context size is really important. [I previously learned](https://dev.to/calvinmclean/how-to-implement-llm-tool-calling-with-go-and-ollama-237g) that a chat session with an LLM or agent is stored as a continuous array of messages and is re-processed by the model for each prompt. As the conversation or coding sessions goes on, the amount of data the model has to process grows. This eventually erodes the responses since they are processing too much information. It is best to keep sessions short, concise, and on-topic.
 
 When you are using an agent to write code, it constantly has to search directories and read files. A lot of this information is not relevant to the goal and contributes to the context rot. This is something that the experimental Model Context Protocol (MCP) server in `gopls` aims to fix. This tool provides direct access to some parts of the language server protocol (LSP) for Go. Some of these tools, like `go_package_api`, which fetches the exported functions, types, and comments for a Go package, can be really useful to learn how to use a package. Additionally, `go_search` provides a way to search a codebase and its dependencies without reading all of the implementation code. `go_symbol_references` allows the agent to search where a function is used so it can understand the impact of a change without searching a large number of files.
 
-I want to take a deeper dive into `gopls` MCP and how it can improve coding agents. Specifically, I want to see how it can improve an agent's ability to use external packages where the source code is not readily available. One way to get around this is to use `go mod vendor` to get a local copy of dependencies. However, this is not efficient because the agent really only cares about how to use a package. Reading in all of the implementation source code is a waste of the precious context. An abundance of source code in the context can also cause an agent to start copying pieces of code and style choices from dependencies which is not ideal. If you are using a popular package with tons of open source examples in the LLMs training set, you might not notice this issue. However, it is a huge drawback when trying to use new versions of packages, private internal libraries, or more obscure packages.
+I want to take a deeper dive into `gopls` MCP and how (or if) it can improve coding agents. Specifically, I want to see how it can improve an agent's ability to use external packages where the source code is not readily available. One way to get around this is to use `go mod vendor` to get a local copy of dependencies. However, this is not efficient because the agent really only cares about how to use a package. Reading in all of the implementation source code is a waste of the precious context. An abundance of source code in the context can also cause an agent to start copying pieces of code and style choices from dependencies which is not ideal. If you are using a popular package with tons of open source examples in the LLMs training set, you might not notice this issue. However, it is a huge drawback when trying to use new versions of packages, private internal libraries, or more obscure packages.
 
 
 ## The Experiment
@@ -107,12 +107,17 @@ While the gopls MCP sounds really promising for improving an agent's ability to
 
 In regards to the `gopls` MCP, my example usecase is probably not the most useful one. As demonstrated, simply reading the documentation is sufficient for smaller, well-documented libraries. LLMs are trained on existing code and like to copy, so reading examples is more effective than analyzing function signatures.
 
-I expect that the `gopls` MCP will work better to augment development in large codebases where the agent can benefit from the `go_search` and `go_symbol_references` tools. Also, in a more extended and iterative development example, loading up the whole documentation might pollute the context too much, especially when using multiple packages.
+I expect that the `gopls` MCP will work better to augment development in large codebases where the agent can benefit from the `go_search` and `go_symbol_references` tools. Also, in a more extended and iterative development example, loading up the whole documentation might pollute the context too much, especially when using multiple packages. I plan to continue using it in my real development flow to observe how it works in a larger real-world usecase. While it didn't crush this example, it is still promising.
 
 Another interesting strategy for working with external libraries is to use a multi-agent workflow. A second agent can be used to browse a variety of relevant documentation. Then, it will extract or summarize the most important pieces and provide that smaller set of data to the main agent.
 
+Ultimately, I learned that good prompting is still the best way to get good results from an agent. The `gopls` MCP is another tool that, when used properly, can improve the workflow, but is not a perfect solution. It can be used along with good prompts to guide an agent to the best solution.
+
+
 ## Next Steps
 
-Before I heard about the `gopls` MCP, I started theorizing about and working on an idea to improve an agent's ability to get relevant context about a library. This idea is to use retrieval augmented generation (RAG) by vectorizing and semantic-searching documentation. This will provide documentation that is directly relevant to what the agent is looking for. My initial idea was to use information from `pkg.go.dev`, but I ended up parsing Go files directly to read documentation comments. This was easier to parse and link directly to the code. After hearing about the gopls MCP, I felt discouraged about this idea and thought that it might no longer be relevant. This experiment proved otherwise. The agent that read documentation was really effective. While reading the whole documentation worked well, using the vectorized data could reduce overall context since the agent won't need to load the whole documentation into each session. Additionally, it should pair really well with the `gopls` MCP. The semantic search will find relevant symbol and file names, and `gopls` can be used to look them up and get more details if needed. I will continue working on this and rerun the experiments to see if there are any benefits. I learned here that I should also parse a library's README since it can be more useful than the code comments. Keep an eye out for my next post where I will share these results!
+Before I heard about the `gopls` MCP, I started theorizing about and working on an idea to improve an agent's ability to get relevant context about a library. This idea is to use retrieval augmented generation (RAG) by vectorizing and semantic-searching documentation. This will provide documentation that is directly relevant to what the agent is looking for. My initial idea was to use information from `pkg.go.dev`, but I ended up parsing Go files directly to read documentation comments. This was easier to parse and link directly to the code.
+
+After hearing about the gopls MCP, I felt discouraged about this idea and thought that it might no longer be relevant. This experiment proved otherwise. The agent that read documentation was really effective. While reading the whole documentation worked well, using the vectorized data could reduce overall context since the agent won't need to load the whole documentation into each session. Additionally, it should pair really well with the `gopls` MCP. The semantic search will find relevant symbol and file names, and `gopls` can be used to look them up and get more details if needed. I will continue working on this and rerun the experiments to see if there are any benefits. I learned here that I should also parse a library's README since it can be more useful than the code comments. Keep an eye out for my next post where I will share these results!
 
 Thank you for reading! If you learned anything new or have any advice, please let me know in the comments.