Raj Nagulapalle

Really like the line “your codebase is your context.” One place I’d extend this: AI-readable code helps the agent understand the repo, but agents also need readable execution environments. That’s where MCP gets interesting. A clean codebase tells the agent what the app is trying to do. An MCP server can tell it what the outside system actually does: available tools, expected inputs, state transitions, webhook outcomes, logs, and failed runs. For API integrations, this is a big shift. Instead of an agent only reading code + docs and guessing, it can use MCP to run the workflow before editing the code. So the stack becomes: code clarity → repo contextMCP → execution contextagent → better changes We’re exploring this with FetchSandbox MCP for API workflows: giving agents a stateful sandbox they can execute against before touching app code. https://fetchsandbox.com/mcp

Really like this framing: MCP does not replace infrastructure. MCP replaces the interface to infrastructure. We are seeing the same pattern with API integration testing. Once agents start wiring real systems, endpoint docs are not enough. They need a runnable execution layer: discover the workflow, run the calls, inspect state transitions, observe webhooks, and then decide what code to change. That is the direction we are taking with FetchSandbox MCP: give coding agents a stateful API sandbox they can execute against before they edit app code. The interesting shift is that the API stops being just documentation + endpoints. It becomes something the agent can reason through. Related: https://fetchsandbox.com/mcp