RocketTurtle

Inspiration

I am a business student, not a traditional software engineer.

For the last two years, I have been following AI and AI agents out of curiosity. As I started building things myself, I kept running into the same thing: almost everything eventually exists in the form of a repository.

AI can write 1,000 lines of code in the next five minutes. But before changing an existing open-source project, a human still needs answers to much simpler questions:

• Where do I begin?
• Which files and folders matter?
• Which files are safe to inspect first?
• Which file is responsible for the exact function that I want to change?
• What can break if I touch it?

That is where RocketTurtle was born.

It started with an MVP and my own brainstorming sessions. I wanted to paste a public GitHub repository into a simple application and get a useful map of what was actually inside it.

I built the first version of RocketTurtle around that idea: help someone understand an unfamiliar repository before they start changing it.

Then I wanted to improve it.

Around that time, I found the Devpost WebMCP Hackathon and started learning what WebMCP actually was.

That immediately made the original RocketTurtle idea more interesting.

RocketTurtle already reduced how much of a repository a human needed to inspect.

With WebMCP, I realized that the same idea can apply to an agent.

Why must a coding agent read an entire repository before it can understand where to work?

That question became the basis of the WebMCP version of RocketTurtle.

---

What It Does

RocketTurtle is a repository understanding layer for humans and AI agents.

For the WebMCP extension, I went back to first principles and asked:

If an agent is about to work inside an unfamiliar repository, what does it need to know before it writes code?

That produced five steps:

Understand → Locate → Inspect → Check → Verify

Those five steps became five WebMCP tools.

1. analyze_repository — Understand

Before anything else, the agent needs a map.

This tool analyzes the repository structure, technologies, complexity, important files, risks, and supporting evidence.

2. map_change_surface — Locate

Understanding the repository is not enough.

If the goal is to change authentication, fix a feature, or update some behavior, the agent needs to know which parts of the repository are likely connected to that goal.

This tool maps the requested change to likely relevant files and risky areas.

3. inspect_file_context — Inspect

After finding a likely file, the agent needs focused information about that file.

This tool inspects one selected text file and returns useful structural context without requiring the agent to explore the complete repository first.

4. validate_change_plan — Check

Before an agent edits code, it can explain what it plans to change.

RocketTurtle checks that plan against the available repository context and identifies risks or missing evidence.

RocketTurtle does not make the code change.

The coding agent remains responsible for the code.

5. get_verification_context — Verify

Finally, the agent needs to know how the repository expects changes to be tested.

This tool finds existing tests, scripts, build commands, lint commands, CI signals, and other useful verification context.

Together, the five tools create one workflow:

Understand → Locate → Inspect → Check → Verify

The user provides the goal.

RocketTurtle provides focused repository context.

The coding agent uses that context before it acts.

---

How I Built It

I extended the existing RocketTurtle MVP instead of creating a separate application for the hackathon.

The WebMCP layer reuses RocketTurtle's existing:

• GitHub access logic
• Repository analyzer
• Types
• API routes
• Vercel deployment

I then added the logic required for the five WebMCP tools.

Each tool has:

• A clear tool name
• A defined input schema
• An execution function
• Structured output
• Error handling
• Input and output boundaries

The browser exposes these tools through document.modelContext, which lets a WebMCP-capable client discover and invoke RocketTurtle's repository tools.

I kept one boundary throughout the project:

RocketTurtle understands and checks. The coding agent writes the code.

RocketTurtle does not:

• Generate code
• Edit repository files
• Create pull requests
• Replace the coding agent

It gives the agent focused repository context before the agent starts changing code.

---

Challenges I Faced

One of the hardest problems was deciding how much repository information each tool must return.

If RocketTurtle returns the entire repository, it defeats the purpose.

If it returns too little information, the agent cannot make a useful decision.

I had to design each tool around one specific question in the agent's workflow.

Another major challenge was safety.

Repository content is untrusted input. The WebMCP layer therefore needed boundaries around:

• Repository access
• File paths
• File types
• File sizes
• Tool inputs
• Tool outputs

Testing also became much more important than I initially expected.

Seeing five registered tools in a browser was not enough.

I tested cases such as:

• Valid inputs
• Invalid inputs
• Missing repositories
• Missing files
• Unsupported files
• Large inputs
• Tool output limits
• Tool cleanup behavior
• The complete five-tool workflow

I also had to make these changes without breaking the existing RocketTurtle application.

That forced me to keep the WebMCP extension focused instead of redesigning the entire product around the hackathon.

---

What I Learned

The biggest thing I learned is that giving an AI agent more context is not always the answer.

A better question is:

What is the minimum useful context that the agent needs for its next decision?

That idea now defines how I think about RocketTurtle.

AI can generate code extremely quickly.

But before generation comes understanding.

An agent still needs to know:

• What already exists?
• Where does the relevant functionality live?
• What files are connected?
• What can break?
• Does the proposed plan make sense?
• How does this repository verify a change?

WebMCP gave me a way to turn those questions into tools that an agent can call directly.

I also learned that building a useful agent tool involves much more than exposing a function.

The input boundaries, output limits, untrusted content, error handling, cleanup behavior, testing, and evidence all matter when another agent depends on that tool.

---

What's Next

The current RocketTurtle WebMCP implementation focuses on public GitHub repositories and one clear five-step workflow:

Understand → Locate → Inspect → Check → Verify

The next goal is not to make RocketTurtle another coding agent.

I want to improve the quality and precision of the repository context that RocketTurtle provides while keeping the same separation of responsibilities.

The original RocketTurtle MVP helped a human understand a repository.

WebMCP gave me a way to extend that same idea to AI agents.

And that is the direction I want RocketTurtle to continue exploring:

Let RocketTurtle understand the repository. Let the coding agent write the code.

---

Accomplishments That I'm Proud Of

The accomplishment I am most proud of is that RocketTurtle started as my own question, not as a hackathon idea.

I am a business student who became curious about AI and agents. I went from trying to understand repositories myself to building a tool that can help both humans and agents understand them.

I am especially proud that:

• I took RocketTurtle from an MVP to a working WebMCP implementation.
• I designed the five WebMCP tools from first principles instead of adding unrelated features.
• I kept one clear workflow: Understand → Locate → Inspect → Check → Verify.
• I made all five tools work together against real public GitHub repositories.
• I tested the tools with a real WebMCP-capable browser instead of relying only on local tests.
• I kept the original RocketTurtle application working while adding the WebMCP layer.
• I learned enough about WebMCP to turn an existing idea into something that an AI agent can directly use.

Most importantly, I built something that I personally wanted when I first started exploring unfamiliar repositories.

That feels like the best accomplishment of the project.

Built With

• git
• github
• nextjs
• react
• typescript