Open the client registration table on an authorization server that has been fronting MCP servers for a year and you get row after row of client_id values that mean nothing, because Dynamic Client Registration asked every authorization server to run an unauthenticated write endpoint on the public internet. The 2026-07-28 MCP spec deprecated it in favor of Client ID Metadata Documents, where the client publishes its identity at a stable HTTPS URL and that URL is the client_id. CIMD removes the write endpoint and makes client identity portable, but it buys attribution rather than trust and hands your authorization server an SSRF surface you have to secure yourself. Earliest removal is the first spec revision on or after 2027-07-28, so keep the DCR fallback.
Architecture5 articles
I had a remote MCP server that worked with every client I pointed at it, until Grok's OAuth flow asked a discovery question no other client had asked and the integration stopped before a single tool call. The July 2026 MCP specification goes straight at that class of failure. The protocol is stateless over Streamable HTTP, discovery is explicit, OAuth discovery is hardened around RFC 9728, and MCP Apps let a tool return a sandboxed interface. MCP is turning into ordinary Internet infrastructure, and the interesting engineering starts after the JSON-RPC leaves your process.
A five-line change should not take five days to ship, but chase a small fix across four repositories and that is what happens: the code is the fast part, and the coordination burns the week. Arguments about monorepos usually start with tooling when the question underneath is coordination, because a repository structure is a delivery model that encodes ownership, release flow, and how much coordination people need before they can safely ship. Size repositories around deployables and publishables so the repo boundary tells the truth about how the software ships.
We only pay when it runs, says one team; this instance is cheaper at volume, says the other. Both can be true, and both can lead to bad decisions. Underneath is a tradeoff between utilization efficiency and economies of scale: serverless makes waste visible as usage, and hosting hides it as idle capacity. The cheapest system is the one whose cost model matches the shape of the workload and the maturity of the team operating it.
I started writing software before source control was a given, back when you found out who changed a file by asking around. Git made creating branches cheap, but it never made integrating them cheap. Long-running branches feel productive to the developer who opens them, while the cost lands on everyone else as delayed integration and uncertainty that surfaces right before a release. Trunk-based development is where you end up once you take CI/CD seriously.