What GitHub Developers Can Do Before the MCP Spec Goes Final on July 28

The MCP release candidate shipped May 21 and the spec goes final July 28. The best preparation is not waiting for a launch post. It is making your repo agent-readable now.

The next version of the MCP spec goes final on July 28. The release candidate is not coming; it is already here. The most useful thing you can do in the next two weeks is not wait for a launch post.

It is get your repo ready.

A lot of MCP content starts with the protocol: what it is, how clients and servers talk, and why tool calling matters. Useful context. But if you are building with agents inside GitHub workflows, the practical question is smaller:

What would make this repo easier, safer, and more predictable for an agent to work with?

That is where I would start.

What is actually shipping

The MCP 7-28 release is the largest revision of the protocol since launch, and it has breaking changes.

The initialize handshake is gone. Protocol-level sessions are gone. Any request can land on any server instance behind a plain load balancer. Extensions are now first-class, with the first two official extensions covering MCP Apps for server-rendered UI and Tasks for long-running work. Authorization moves closer to how OAuth and OpenID Connect actually get deployed. Roots, sampling, and logging are deprecated. There is also a formal lifecycle policy, which means future releases should not break your code without at least a twelve-month deprecation window.

If you already ship an MCP server, that paragraph is your to-do list. Read the draft changelog, run your server against the SDK betas, and plan the migration now. If you built on the experimental Tasks API from 2025-11-25, that migration is not optional.

The shift to watch

MCP has become one of the clearest signals that agent development is moving from isolated demos toward repeatable developer infrastructure.

The interesting part is not just that an agent can call a tool. It is that the protocol is formalizing how tools get described, how context gets passed, how permissions work, and how behavior gets verified. A spec proposal cannot reach Final status anymore without a matching scenario in the conformance suite. That is what maturing infrastructure looks like.

This matters for GitHub developers because most agent work eventually hits the same surface area: repositories, issues, pull requests, CI, documentation, auth boundaries, and maintainer expectations.

If July 28 is the moment more developers start taking MCP seriously, the best preparation is making your project more agent-readable now.

What to try before July 28

Start with your repo instructions.

If your project does not have an AGENTS.md yet, write one. It is plain Markdown, more than 60,000 open source projects already use it, and 30+ coding agents read it.

Keep it practical. Tell agents how to build, test, lint, and navigate the repo. Include the conventions a human maintainer would normally explain in a review comment: where source files live, which commands are safe to run, what not to touch, and how changes should be validated. GitHub reviewed thousands of AGENTS.md files and found that the best ones give exact, copy-pasteable commands with flags. Not “run the tests.”

Then pick one workflow where a tool would actually help. Not ten tools. One.

Good first candidates are repeatable and low-risk: searching docs, checking package metadata, validating config, running a known test command, or summarizing an issue against repository guidelines. You are not trying to make the agent autonomous. You are trying to make one interaction explicit enough that another developer could understand and reproduce it.

From there, define the trust boundary.

What can the tool read? What can it write? Does it need credentials? What happens when it fails? If the answer is “the agent will figure it out,” the contract is not clear enough yet. The new spec meets you halfway here. The authorization hardening in MCP 7-28 assumes you know what each tool is allowed to touch. Teams that wrote that down will adopt it faster than teams reverse-engineering their own permissions.

A simple repo-readiness checklist

Before the spec goes final, ask:

Can a new contributor understand how an agent should work in this repo?
Are build, test, and lint commands documented clearly, with exact flags?
Is there one realistic workflow that could become an MCP tool?
Are inputs and outputs explicit?
Are permissions and failure modes documented?
Could this be tested in CI without relying on vibes?

That last one matters. Agent workflows will not become production-ready because they sound impressive. They will become useful when teams can inspect, constrain, and test them.

If you would rather track it than read it, here is the same checklist as an interactive version. It saves your progress in your browser, links each server item to the relevant spec docs, and copies to Markdown so you can open it as an issue in your repo.

Download the printable repo-readiness checklist (PDF)

Do the boring work now

The next phase of agent development is not only about smarter models. It is about better interfaces between models and the systems developers already use.

For GitHub projects, that means the boring work is suddenly important: repo instructions, tool schemas, permission boundaries, examples, and tests.

That is good news. You do not need to wait for July 28 to start. You can make your project easier for agents and humans to work with today.

When the spec goes final, the teams that get the most out of it will be the ones that already know what they want their agents to do, where the boundaries are, and how they will know whether it worked.