API
API vs MCP for Repository-Aware Retrieval
Repokit exposes one retrieval layer through two access paths. The better choice depends on who is integrating it and how much protocol control they need.
Choose the API when you want explicit control
- You are building a backend or internal developer tool.
- You want direct HTTP + JSON requests.
- You care about exact request construction and response handling.
Choose MCP when the client already speaks tools
- You are wiring a tool-capable client or agent environment.
- You want to avoid writing a small wrapper first.
- You still want the same repository-aware retrieval behavior.
What stays the same
The repository-aware retrieval layer is the same. Both paths still depend on a ready repository and a bearer token tied to a real verification flow.
The practical rule
If your integration is application-first, use the API. If your integration is tool-protocol-first, use MCP.
Next up
Start with the MCP setup page before wiring Repokit into a tool-capable client.
Related reading
Building Internal Tools with the Repokit API
A practical guide to using the HTTP API when you want repository-aware retrieval inside your own tooling or workflow automation.
Read articleEmbeddings Search vs Repository-Aware Ranking
A practical comparison between semantic code search and a task-shaped ranking layer anchored to one repository.
Read articleManual Codebase Exploration vs Ranked Entry Points
A practical comparison between browsing a repository manually and starting from a ranked shortlist shaped by the task.
Read articleFeatured paths
If the next useful move is clearer than another article, take it.
Use the main Repokit paths to move from blog reading into docs, submission, API, or MCP without leaving the same funnel.
Debugging path
Start with a regression or failing test.
Use ranked files to narrow the likely implementation surface before you spend time browsing or guessing.
Verification path
Understand ready, tokens, and the real beta flow.
Use the verification and readiness content to judge the product on your own code instead of on generic examples.
API path
Build an internal tool with direct HTTP control.
Go from human-facing API guidance into a real integration once the verification flow and repository boundary are clear.
MCP path
Connect a tool-capable client through MCP.
Keep the scope narrow to one repository and one retrieval task before you try to scale the workflow outward.