Retrieval, RAG and MCP: stop being the API between Claude and the rest of the SDLC

One question, several mechanisms

This article is not about memorizing the difference between five buzzwords.

It is about one question:

How should Claude get the information needed to perform the task?

The answer depends on the kind of information.

1. Built-in tools: first use what you already have

If the information is in the repository, Claude can often find it by itself:

grep
glob
read
git
shell

Example:

Why did change X break test Y?

Claude can:

• run the test,
• see the failure,
• search the repository,
• check git diff,
• find the relevant code.

You do not need MCP or RAG.

First rule:

Do not add new infrastructure where a normal tool is enough.

2. CLI: often the best interface for a developer and an agent

If your environment has:

gh pr view
gh run view
kubectl logs
terraform plan

Claude can use the same interfaces that a developer uses.

That has a huge advantage: you do not create a separate integration path only for AI.

Example:

Check why CI for this branch is failing.

Claude can:

gh
|
v
finds the run
|
v
reads the failure
|
v
repository
|
v
reproduces the problem
|
v
fix
|
v
test

The developer stops copying logs manually.

3. Retrieval: find the right knowledge

Some information should not live permanently in Claude's context window.

You have:

• ADRs,
• runbooks,
• documentation,
• project decisions,
• incident history.

Retrieval simply means:

I need information about X
|
v
search the source
|
v
select relevant fragments
|
v
add them to context

This can be plain full-text search.

It can also be a more complex system.

4. RAG: retrieval becomes part of the answer

RAG, Retrieval-Augmented Generation, is a pattern where relevant knowledge is fetched from an external source before generating an answer.

Classic diagram:

query
|
v
retrieval
|
v
relevant documents
|
v
Claude
|
v
answer / decision

A popular implementation can use embeddings and a vector DB, but that is not the definition of RAG.

In a practical system you can have:

full-text
+
vector search
+
metadata filters
+
reranking

For a developer, recognizing the use case matters more.

RAG makes sense when:

• there is a lot of knowledge,
• it is distributed,
• it should not be loaded permanently,
• the agent has to find it by meaning.

It makes no sense to build a vector DB only so Claude can find the definition of a class located in the current repository.

5. External retrieval: the internet is also a source of context

Knowledge needed to perform a task does not always live in the repository or internal company documentation.

Often the problem depends on current external information:

• framework documentation,
• release notes,
• changelog,
• GitHub issues,
• vendor docs,
• RFCs/specifications,
• security advisory,
• cloud provider documentation,
• changes in an external service API.

Then Claude can use web search or another retrieval tool for the internet.

Example:

CI started failing after a library upgrade.

Claude can:

repository
|
v
checks the current dependency version
|
v
web search
|
v
release notes / migration guide / issue tracker
|
v
connects that with the local failure
|
v
proposes a fix

Or:

Is this method deprecated in the current SDK version?

Instead of relying only on model memory:

Claude
|
v
searches current documentation
|
v
returns with the current API state

This distinction matters:

repo search
= knowledge from current code

internal retrieval / RAG
= company knowledge

web search
= current external knowledge

MCP / tools
= access to specific systems and actions

The most important conclusion:

Context does not end at the repository and company documentation.

A good agent should also be able to choose current external sources by itself when the problem requires it.

6. MCP: access to systems and tools

Retrieval mostly answers:

What should Claude know?

MCP lets you expose external data and actions to the agent as tools.

Mental model:

Claude
  |
  +-- repo tools
  |
  +-- GitHub
  |
  +-- issue tracker
  |
  +-- observability
  |
  +-- internal APIs

MCP is a standard interface between the agent and these tools.

That does not mean every integration should be rewritten as MCP.

If gh solves your problem well, use gh.

If you have an internal platform with operations like:

get_recent_deployments(service)
get_service_health(service)
find_incidents(service)

MCP starts to look very natural.

RAG and MCP do not compete

This is a common misunderstanding.

You can have an MCP tool:

search_engineering_docs(query)

that uses RAG underneath.

Then:

MCP
= interface to the tool

RAG
= way of finding knowledge

Similarly, an MCP tool can return the current CI state, where RAG is not involved at all.

One task that shows the whole level

Command:

Check why this PR does not pass CI. Find the cause, reproduce the problem locally and prepare a fix.

Old workflow:

developer
|
v
GitHub
|
v
copies log
|
v
Claude
|
v
developer finds files
|
v
Claude

New:

Claude
+-- GitHub / CLI / MCP -> finds failing run
+-- repo tools -> locates code
+-- docs retrieval -> checks relevant rules
+-- web search -> checks current vendor docs / changelog
+-- shell -> reproduces failure
+-- edit + test -> prepares fix

This is the practical meaning of:

The agent gets the needed context itself.

What does this change in SDLC?

Planning

Claude can fetch:

• issue,
• acceptance criteria,
• relevant ADR,
• current external documentation.

Implementation

Claude has:

• repository,
• documentation,
• git history,
• vendor docs.

CI/debugging

Claude fetches:

• failing job,
• log,
• artifacts available through tools,
• dependency changelog if needed.

Review

Claude can read:

• PR,
• diff,
• linked issue,
• build status,
• current documentation for the API used in the change.

Incident response

Claude can fetch:

• logs,
• metrics,
• deployment history,
• runbook,
• current vendor statuses or documentation.

Permissions and reasonable boundaries still apply. Access to information does not automatically mean permission to modify production.

Implement this today

1. List three things you regularly copy to Claude

For example:

• CI failure,
• issue description,
• internal documentation fragment,
• vendor docs link,
• dependency release notes.

2. Choose one

Do not integrate everything at once.

3. Find the simplest interface

In order:

built-in tool?
|
v
CLI?
|
v
web search?
|
v
MCP?
|
v
custom tool?

4. If the problem is knowledge, add retrieval

Start with the simplest search.

Vector RAG only when it actually solves the problem.

5. Let Claude use the internet where freshness matters

For:

• new library versions,
• API changes,
• vendor docs,
• security advisory,
• cloud services,

do not rely only on model memory.

6. Repeat a real task

Condition: you are not allowed to manually paste information that the agent should now fetch itself.

Level complete

The level is complete if at least one type of information from daily SDLC that you previously copied manually can now be retrieved by Claude itself.

It can come from:

• repository,
• CLI,
• internal documentation,
• internet,
• MCP,
• another external system.

At the next level we will handle another kind of repetition: not data, but instructions such as "how we do review / incident / migration".

Materials

• Model Context Protocol in Anthropic documentation
• Claude Code CLI reference: claude mcp
• Contextual Retrieval in Anthropic Engineering
• Enhancing RAG with contextual retrieval