# From specification to implementation > How our functional specification moved from a shared Google Document to a Markdown repository served through an MCP server. Published: 2026-11-03 Author: Joep Tags: AI, ENGINEERING, WORKFLOW Canonical URL: https://exodus-protocol.com/journal/from-specification-to-implementation In this journal I want to provide a high level overview of our development workflow. I will outline the journey in which we moved from a simple shared Google Document to a fully featured MCP server with advanced search capabilities. During the development of Exodus Protocol we experimented with different ways to get from an idea to the implementation. One aspect of that is how we document the functional requirements and how we use this form of documentation. We, and by we I mean my co-founder Jeroen, started out by describing what we thought the game should be. This includes how it should behave, how players can interact with it and a lot of formulas to describe the balancing of the internal systems. This was all done in a single Google Document. The benefit of this is that it looks pretty readable for a human and that it's easy to modify and have discussions on specific sections of the document via comment threads. So at the start we would read a chapter of this document and instruct the coding agent to implement a feature based on how we interpreted the documentation. ## Implementation documents At some point in time we tested what the results would be if we fed a whole feature description to the coding agent and let it work with that. This kind of worked, but during coding there was a lot of back and forth going on. After doing some reading about how other AI first developers work with this we started testing with implementation documents. We first feed the feature description to the LLM and let it ask questions about it, after which it will write an implementation md file. This seemed to improve the quality a lot. We let the LLM write the implementation md file in such a way that it splits it up in distinct sessions. Each session can be picked up by a fresh coding session. This is important as it means each session runs with a fresh context window. This has 2 benefits that are closely related. One is that it prevents us from overflowing the context window. The other is that it allows us to work with smaller context windows. This last point is important as it seems that the smaller the context window is, the higher the output quality is. For example Claude Opus can work with a context window up to 1M tokens. In our experience, and in what other developers report, output quality starts to drop well before that limit, though opinions differ on exactly where. It seems that when the context window is becoming too big, the LLM 'forgets' larger parts of the text that is in the middle of the context window. The AI coding community has a name for that part of the context window: the `dumb zone`. By splitting up the work in smaller sessions, we keep working in the smart zone. Another benefit is that these smaller sessions sometimes allow us to work in parallel, but that is a story for another time. Recently we started looking at what can be improved in the first part of this workflow: getting the functional description to the LLM. Up until this point I would copy text snippets out of the Google Document, or download the Google Document as an md file. This is quite cumbersome so it felt like a better solution should be possible. The most obvious route is of course to write the functional specs in Markdown. We saw two possible routes, storing the md file(s) in the repository next to the code, or use a dedicated documentation repository. We landed on the latter as our project consists of multiple repositories. Turning a large Google Document into a Markdown repository was an easy task. Just download as Markdown and let an LLM split it up into md files in a directory structure that follows the chapter names. ## Enhanced access to documentation At the start we had the documentation repository checked out on our local machines. This worked quite well but there were a couple of concerns and things we suspected we could improve: - It requires discipline from us to frequently pull the latest documentation changes - We would need to do a fresh checkout of the documentation repo inside all dev containers - Documentation search relies primarily on keyword-based tools like `grep` or `rg` We found an interesting open source project that seems to solve all of these: [markdown-vault-mcp](https://github.com/pvliesdonk/markdown-vault-mcp). It is a small server that clones the documentation repository and provides access to this data via an MCP server. It can generate a search database which it uses to provide semantic search capabilities. Instead of manually pulling the repository, it can automatically trigger this via WebHooks. For me as a developer this means all I have to do is add the MCP server to my coding agent, and it automatically knows how to access the always up to date documentation. Some examples of how we use this are: `What are the gaps between the documentation and the implementation of the login feature?` or `Make an implementation document for the battle feature`. And as it is an open source project, we like to help out where we can. This week we had our first bugfix PR merged upstream. We don't know yet what the impact is of the semantic search feature. In a first simple test we did not see a difference in the result or in the context window usage when we compared it to having the documentation repository locally available to the LLM. We will investigate this in the coming weeks and in a future journal we will dive into the results.