DEV Community: Josh

How to List the CCAR-F (CCA-F) on a Resume and LinkedIn

Josh — Mon, 21 Sep 2026 11:56:05 +0000

You passed. Here is the short version of how to show it:

Claude Certified Architect – Foundations (CCAR-F), Anthropic. Earned September 2026, expires September 2027.

That line goes in a Certifications section on your resume and in Licenses & certifications on LinkedIn, with your own month in place of September. The rest of this article explains each part of it, how to make the credential do real work on your profile, and how to handle the expiry date the credential carries.

The exact wording

The exam guide names the credential "Claude Certified Architect – Foundations" and gives its exam code as CCAR-F (Section 3). You will also see it written CCA-F, and there is more on why the exam has two codes if a recruiter asks.

Anthropic itself writes the name two ways: the exam guide uses a dash, and Anthropic's announcement of its role-based certifications uses a colon, "Claude Certified Architect: Foundations". Either is recognizable. The rule that settles it is simple: match your badge. Anthropic's announcement says that people who pass receive a digital badge through Credly by Pearson, and its Academy FAQ says the credential is issued through Credly. Whatever your badge shows is the version to copy, character for character, everywhere you list it.

On a resume

A Certifications section is the standard home. Put the full name first, then the issuer, then the dates:

Claude Certified Architect – Foundations (CCAR-F) | Anthropic | Sep 2026 to Sep 2027

Whether it also belongs in your summary line at the top is a judgment call, and here is the test we would use. Section 2 of the guide describes the candidate the exam is built for: "a solution architect who designs and implements production applications with Claude". If that sentence describes work you actually do, the credential earns a place in your summary, because it confirms the claim your summary is already making. If you are earlier in your career, keep it in Certifications and let your experience section carry the story. That is our advice, not the guide's, and it rests on one idea: a credential is strongest when it confirms something the rest of the page already shows.

It also helps to know who the certification is built for, since the same description tells you which of your experiences to put next to it.

On LinkedIn

Add it under Licenses & certifications. The form asks for a name, an issuing organization, dates, and optionally a credential ID and URL.

Name: exactly as your Credly badge shows it.
Issuing organization: Anthropic.
Issue date: the month you were awarded the credential.
Expiration date: twelve months later (see the next section).
Credential ID and URL: fill these in only from your Credly badge. Neither Anthropic's announcement nor its Academy FAQ describes a separate ID or verification link for the exam credential, so copy whatever the badge provides and nothing else.

Your headline and About section follow the same test as a resume summary. If you design and build production systems with Claude, "Claude Certified Architect – Foundations" in the headline tells a reader what kind of work you do before they open your profile. If you are moving into that work, put the credential in your About section next to what you are building.

The expiry date

Section 15 is clear that this credential does not last forever: it "is valid for 12 months from the date it is awarded." The guide gives the reason directly: "Because the underlying technology evolves rapidly, the credential is time-limited so that holders maintain current knowledge."

List the expiry date. It is accurate, and it tells a reader the credential is current, which is the point of holding one. (There is more on how long the credential lasts in our FAQ.)

Renewal is straightforward. The guide says: "To renew on time, you review what has changed since you certified and complete a free, non-proctored assessment on the Anthropic Partner Academy. There is no fee for on-time renewal." When you renew, update the expiry date on your resume and on LinkedIn. It is also worth knowing how renewal compares with the Associate certification if you plan to hold more than one.

If a credential lapses, the guide says "you must retake the full exam at the full fee to regain certified status." On your profile, a lapsed credential keeps its real dates, with the end date in the past. Never leave it open-ended. An honest date range still shows the work you did to earn it.

Turning the domains into resume lines

The credential tells a reader you were examined on something. Your experience section tells them what you did with it. The guide's own structure is a good map for connecting the two: Section 4 lists five domains, and Section 2 lists the hands-on experience the exam assumes. You can see the five domains and their weights laid out on our exam guide page.

The patterns below are for describing your own work. Fill the brackets with what you actually built and what actually happened. Do not copy them as claims.

Agentic Architecture & Orchestration (27%): "Designed [a multi-agent or agentic workflow] using the Claude Agent SDK to [what it did], [a result you can point to]."
Claude Code Configuration & Workflows (20%): "Configured Claude Code for [team or project] with [CLAUDE.md files, Agent Skills, MCP integrations], [what changed for the team]."
Prompt Engineering & Structured Output (20%): "Built [an extraction or generation pipeline] producing structured output against [a JSON schema or format], [a reliability result you measured]."
Tool Design & MCP Integration (18%): "Designed MCP tools and resources connecting Claude to [backend system], [what it enabled]."
Context Management & Reliability (15%): "Handled [long documents, long conversations or agent handoffs] with [the approach you used], [what it fixed or prevented]."

One line per domain you have genuinely worked in is plenty. Two strong lines are worth more than five vague ones.

If you are still preparing

You can mention an exam you have not passed yet, as long as the wording is exact. If your exam is booked, "Claude Certified Architect – Foundations (CCAR-F): exam scheduled, [month]" is accurate. If it is not booked yet, leave it off and let your project work speak for itself. Never write "certified" before you are, and never use the badge name for a credential you do not hold.

If you are working toward the exam now, a good place to start is a free ten-question diagnostic that scores you by domain. When you are ready to book, the registration steps through the Partner Academy and Pearson VUE are laid out step by step.

In interviews

A credential on a resume invites the question "what was on it?" Here is how to answer well.

Talk about how the exam is designed, because that says something about what you can do. Section 1 says candidates must demonstrate "practical judgment about architecture, configuration, and tradeoffs in production deployments." Section 5 explains that the exam presents four scenarios, picked at random from six, each one "a realistic production context that frames a set of questions." So you can say, truthfully, that you were tested on making design decisions in production scenarios, then move straight to a decision you made in your own work.

Do not describe specific questions. Section 14 is the confidentiality agreement every candidate accepts, and Section 13 lists "revocation of your credential" among the consequences for disclosing exam content. The design of the exam is public; its content is not. The best interview answer uses the first and moves on to your own work.

What this article does not claim

The CCAR-F exam guide says nothing about salaries, hiring rates, or whether employers require or prefer the credential, and neither does this article. What the credential gives you is a precise statement that you were examined on production Claude architecture, with a Credly badge to show it and a date to show it is current. Listed exactly and paired with real work, that statement does its job.

FAQ

What is the exact name to put on a resume?

The exam guide calls it "Claude Certified Architect – Foundations", exam code CCAR-F. Anthropic also writes it with a colon. Copy the name exactly as it appears on your Credly badge.

Who is the issuing organization on LinkedIn?

Anthropic. Anthropic says people who pass receive a digital badge through Credly by Pearson, and that the credential is issued through Credly, so take any credential ID or URL from your Credly badge.

Should I list an expiration date?

Yes. Section 15 of the guide says the credential is valid for 12 months from the date it is awarded. Update the date when you renew.

Can I list the exam before I pass?

Only as what it is. "Exam scheduled" with a month is accurate if the exam is booked. Never write "certified" before you are.

Originally published at claudecertifiedarchitects.com. Section numbers refer to the CCAR-F exam guide, version 1.0 (July 2026).

CCAR-F (CCA-F) exam dumps: do they exist, and would they help?

Josh — Thu, 17 Sep 2026 05:41:52 +0000

If you searched for CCAR-F dumps, here is the short answer. Everyone who has taken the Claude Certified Architect Foundations exam (CCAR-F, also written CCA-F) had to accept a confidentiality agreement before the first question appeared, promising not to disclose, reproduce or distribute any part of it. On our reading, that means a genuine dump could only exist because somebody broke that agreement. This article does not guess whether any real one exists, and it does not point to anywhere that claims to sell one.

The more useful answer is that even a genuine dump is a poor bet for this particular exam, for reasons that follow directly from how the published exam guide describes it. The rest of this article walks through those reasons, then covers what prepares you instead, most of it free. (If you are unsure which code is the official one, the guide's details table lists the exam code as CCAR-F.)

What a dump would have to contain

Section 3 of the CCAR-F guide sets out the shape of the exam: 60 items, a 120-minute time limit, and an exam structure described as "4 scenarios drawn from a bank of 6".

Section 5 explains what a scenario is: "Each scenario presents a realistic production context that frames a set of questions. During the exam, 4 scenarios are presented and picked at random from the full set of the 6 scenarios below."

Two things follow from that. First, you cannot know in advance which four scenarios you will get. A set of questions remembered from someone else's exam reflects the four they drew, not the four you will draw. Second, the questions are not free-standing facts. Each one sits inside a production context, and the context is part of the question.

Section 10 adds one more detail: "Scaled scoring models help equate scores across multiple exam forms that might have slightly different difficulty levels." So the guide says more than one form exists. It does not say how many, how they differ, or what changes between them, and this article will not fill that gap with a guess.

None of this makes the scenarios secret. You can read the six scenarios the guide publishes, and knowing them well is legitimate preparation. What nobody can tell you is which four you will face.

What the questions actually test

Section 1 of the guide is direct about the level: "Candidates must demonstrate not only conceptual knowledge but practical judgment about architecture, configuration, and tradeoffs in production deployments."

The format supports that. Section 3 lists the item format as "Multiple-choice and multiple-response items; each item states how many responses to select". In a multiple-response item, you pick that stated number of correct options from several plausible ones, which is where a remembered letter is least help. There is more on how each item states how many responses to select and what that means for how you read a question.

This is why the exam is hard in the way engineering judgment is hard. The right option depends on the constraints the scenario sets: what the system must guarantee, what it can afford, what has already failed. Change those constraints and a different option becomes correct. An answer key with no reasoning teaches you a letter for one set of constraints. It does not teach you to notice when the constraints have moved, and memorizing a rule can produce the wrong answer when they have.

The guide also shows you what real items look like. Section 9 says its sample questions "illustrate the format and difficulty level of the exam" and that they "are drawn from the practice test". So the guide's own samples come from a practice test, and the guide publishes them with explanations. Read those in the guide itself.

The agreement, and what the rules attach consequences to

Section 14 is short enough to quote in full:

Before the exam begins you must accept a confidentiality and non-disclosure agreement. By accepting, you agree that all exam content, including questions, answer options, and scenarios, is the confidential and proprietary property of Anthropic, and that you will not disclose, reproduce, or distribute any portion of it. If you do not accept the agreement, the exam session ends and no refund is issued.

Section 13 sets the rules for the session itself. Among them, candidates must "Not capture, copy, photograph, or reproduce any exam content in any form". Its consequences clause reads:

Cheating, attempting to access prohibited resources, or disclosing exam content may result in invalidation of your result, revocation of your credential, and a ban from future exams.

Section 15 adds that the obligation does not end at the exam room door: "Holders remain subject to the rules of conduct described in Section 13."

It is worth being precise about what these sections say. They attach consequences to cheating, to attempting to access prohibited resources, and to disclosing exam content. They say nothing about studying from leaked material, and this article does not claim they do. What they do make clear is that anyone who shares exam content is putting their own result and credential at risk to do it.

Twelve months, then a renewal

Section 15 opens: "The Claude Certified Architect – Foundations credential is valid for 12 months from the date it is awarded. Because the underlying technology evolves rapidly, the credential is time-limited so that holders maintain current knowledge."

Renewal is not a formality either. The guide says: "To renew on time, you review what has changed since you certified and complete a free, non-proctored assessment on the Anthropic Partner Academy." And: "If exam content changes significantly, Anthropic may require holders to retake the full exam to recertify rather than complete the renewal assessment."

The conclusion here is ours, not the guide's. The credential is built around keeping up with a technology that changes, and renewal means reviewing what has changed. Understanding can be updated. A list of remembered answers cannot: there is nothing in it to review, only something to replace.

What a failed attempt costs

If you were looking for a shortcut because time or money is tight, this is the part worth weighing.

Section 3 lists the exam fee as $125 USD, and Section 11 notes that the fee shown at checkout reflects any discount for your partner tier. Section 12 sets the retake policy: after a failed attempt you wait 14 days, then 30 days after a second, then 90 days after a third, and you may take the exam up to four times in a rolling twelve-month period. The same section is explicit that the fee applies to each attempt.

Two more rules can cost the fee without a result. Section 11 says changes made within 24 hours of your appointment forfeit it, and Section 12 says a no-show or late arrival forfeits it too.

The pass mark is 720 on a scale of 100 to 1,000, and it is a scaled score: Section 10 says the per-domain percentages on your score report are not used to decide a pass or fail. Walking in with answers that belong to a different draw of scenarios is a costly way to find out where you stand.

What works instead, free first

The guide itself is the best free starting point.

Section 7, "How to Prepare", lists concrete things to build: a complete agentic loop with the Claude Agent SDK, a real project configured in Claude Code, MCP tools with clearly differentiated descriptions and structured errors, a structured data extraction pipeline, and practice with prompt engineering, context management and escalation patterns. Section 8 turns several of these into step-by-step hands-on exercises. Section 9 gives you the sample questions with explanations. All three are in the guide, free, and written by the people who wrote the exam.

After that, test yourself against questions in the same format:

Start with a free ten-question diagnostic that needs no account. It scores you by domain, so you know where to spend your time.
Work through ten free questions with detailed explanations, and read the explanations for the options you got right as well as the ones you missed.

The point of any practice question is the reasoning behind it, not its letter. That is what carries over to the four scenarios you actually draw.

The short version

A genuine CCAR-F dump could only come from someone breaking the agreement every candidate accepts. Even then, it would reflect someone else's four scenarios out of six, it would teach answers rather than the judgment the exam is built to test, and it would age as the credential is designed to. The guide's own preparation list, exercises and sample questions are free, and practice that explains its reasoning is the preparation that transfers.

FAQ

Are there real CCAR-F exam dumps?

The CCAR-F exam guide requires every candidate to accept a confidentiality and non-disclosure agreement before the exam begins, covering all questions, answer options and scenarios. Any genuine dump would therefore come from a breach of that agreement. This article does not assess or point to any source that claims to offer one.

Can using an exam dump get me banned?

Section 13 of the CCAR-F guide says cheating, attempting to access prohibited resources, or disclosing exam content may result in invalidation of your result, revocation of your credential and a ban from future exams. It does not mention studying from leaked material. Anyone who shares exam content does put their own result and credential at risk.

Would a dump help me pass CCAR-F?

The guide describes 60 items built around 4 scenarios picked at random from a bank of 6, testing practical judgment about architecture, configuration and tradeoffs. A remembered answer set reflects someone else's draw and teaches answers rather than reasoning. Practice questions that explain why each option is right or wrong are a better use of limited time.

What is the best free preparation for CCAR-F?

Start with the official exam guide: Section 7 lists what to build, Section 8 gives hands-on exercises, and Section 9 has sample questions with explanations. Then a free ten-question diagnostic shows which domains need the most work.

Originally published at claudecertifiedarchitects.com. Section numbers refer to the CCAR-F exam guide, version 1.0 (July 2026).

Guarantee or accuracy: a CCAR-F question type

Josh — Thu, 10 Sep 2026 10:04:07 +0000

There is a family of questions in this exam's published objectives that splits candidates two ways, and the advice most preparation material gives you, including ours, only covers one of them.

The scenario gives you a system that must never do something. A classifier that can only return categories from a fixed list. An agent that must not run destructive SQL. A step that must not start before an earlier one has completed. Then it asks which option satisfies the requirement.

One option adds a clear, well written instruction. Another adds a hook, a gate, a scope restriction or a validation step.

The standard advice is that infrastructure enforces and prompts only guide, so pick the infrastructure. Our own anti-patterns post says exactly that, and it is right about half the time.

Where these questions actually sit

Most people file this under Prompt Engineering and Structured Output. That is where the schema discussion belongs, and it is where the vocabulary of validation gets taught.

In our own bank, the questions where a code-level answer is keyed over a prompt-level distractor cluster in Agentic Architecture and Orchestration: twelve items there against five in Prompt Engineering. Hooks, prerequisite gates, subagent isolation, tool scoping.

But the reverse runs the other way. Of the items where the prompt-level answer is correct and the code-level option is marked wrong, two thirds are in Prompt Engineering.

So if you revise this topic by reading about structured output, you will meet the cases where wording is right and miss most of the cases where it is not. And if you revise it by memorising "always enforce in code", you will do the opposite.

The guide's own phrasing is conditional

This is the part worth taking from the published guide directly.

Each time the guide sets a deterministic mechanism against a prompt instruction, the condition sits beside it. Hooks and gates appear "when deterministic compliance is required" and "when business rules require guaranteed compliance". Even the strongest statement about structured output, that it is the most reliable approach for guaranteed schema-compliant output, carries "guaranteed" inside it.

The guide never says enforcement is generally better. It says it is what you reach for when a guarantee is what the requirement demands.

Beside those, the same guide names prompt-level answers elsewhere. Normalisation rules belong in the prompt alongside a schema. Few-shot examples are named as the most effective technique for format consistency. Tool descriptions are named as the primary mechanism for tool selection, not a routing layer.

The test that works

Does the requirement need a guarantee, or does it need accuracy?

If something must never happen or must always hold, and a violation is a business or safety failure rather than a quality one, the requirement needs enforcement outside the model.

If something needs to be done well, consistently, or in a particular format, that is a prompting problem, and adding infrastructure is the wrong answer.

The reliable way to tell them apart is not the wording of the requirement. It is asking whether the consequence lands outside the conversation. Downstream code branches on the category. A deletion touches production. A step commits something irreversible. When the failure escapes the conversation and lands somewhere else, you need a guarantee.

When it does not, when the cost of a bad output is that the output is bad, you need accuracy.

Why the obvious shortcut fails

The tempting version of this test is to scan the stem for "never", "always" or "must".

That does not work, and it is worth knowing why before you rely on it. In our bank, guarantee words appear in at most half the items where a code-level answer is correct. The rest state the requirement without them. Meanwhile at least one item where the prompt-level answer is correct contains "always" inside a quoted system prompt line, which is precisely the trap: the word is in the scenario because someone wrote it into an instruction, and the instruction is the thing being examined.

Read the consequence, not the adjectives.

Three shapes worth recognising in the wrong options

From hand-classifying the distractors in our own items in this family:

Prompt wording offered as the guarantee. The most common by some distance. An instruction that names the constraint clearly and emphatically, sitting where a mechanism should be.

A real mechanism at the wrong scope. The option names something that genuinely enforces things, applied where it does not cover the failure. A hook on an event that fires after the damage. A tool withdrawn from the subagent that actually needs it. A forced tool choice that cannot sequence a second call.

A false claim about how a real mechanism behaves. Harder to spot, because the mechanism is right and the described behaviour is not. Hooks that retry. Hooks configured somewhere they do not live. A strict schema that fills missing fields from the source document.

There is also a smaller group worth naming separately, because it catches experienced people: temperature zero, or a change of model, offered as a substitute for a guarantee. Neither converts a probability into a certainty. Temperature zero is genuinely the right answer to some consistency questions, which is what makes it effective as a distractor everywhere else.

How to use this while revising

Take questions you have already answered in this family and, before looking at the options, write down where the consequence of a failure lands. Inside the conversation, or outside it.

If you can classify that correctly, the right option usually becomes obvious. If you cannot, the wrong answer will keep looking reasonable no matter how many times you review it.

Then check which direction your errors run. Reaching for infrastructure on an accuracy question and reaching for wording on a guarantee question are different mistakes with different fixes. The first means you have over-corrected, probably from advice like ours. The second means you have not yet internalised that an instruction is a request.

A worked example of this family, with the full explanation, is in our free questions post.

The one sentence version

An instruction changes what the model is likely to do. A hook, a gate or a validation step changes what the system is able to do. Read where the failure lands, decide which one the requirement needs, and the option that mixes them up will stand out.

For the structured output side of this, including where a schema stops helping, see the prompt engineering and structured output guide. For the orchestration patterns these questions sit inside, the agentic architecture guide covers the wider domain.

Zero Is the Worst Return Value

Josh — Mon, 07 Sep 2026 08:00:18 +0000

I once wrote a working capability out of a system's study material because a search returned nothing.

The question was whether a particular hook could rewrite a tool's output before the model saw it. I searched the codebase and the vendor documentation for the field name I remembered, updatedOutput. Zero hits, both places. I concluded the capability didn't exist, appended that conclusion as a "correction" in four places, and moved on.

The field is called updatedToolOutput. The capability exists, is documented, and does exactly what I'd wanted. My search was correct, my regex was correct, and the answer I took away was the opposite of the truth.

That's the shape this article is about. A search that finds nothing and a search that ran wrong return the same thing. Zero is a legitimate answer to a well-formed question, which means there is no signal in it — a true negative and a broken query are byte-identical at the call site.

I started keeping a list the first week this cost me something. It had six entries then and has fifteen now. What follows is the part of it I could reproduce on the machine I'm writing this on, each command quoted as it behaved here, the mechanism behind each, and the discipline I now use instead of trusting a zero. It ends with the one that happened while this piece was being fact-checked.

The shell cases

**
These cost the most, because the shell tells you nothing went wrong. Everything below is Git Bash on Windows: bash 5.2.37 (MSYS), git 2.53.0.windows.2, GNU grep 3.0, findutils 4.10.0, curl 8.18.0, Node 24.14.1. Your versions will differ, and the whole point of the piece is that you should check rather than trust mine.

Two I've written up before, so one sentence each. Under MSYS, any argument token that starts with / is rewritten to a Windows path before a native executable sees it, so git grep 'href="/blog/' actually searches for href="C:/Program Files/Git/blog/, prints nothing and exits 1 — exactly what a real no-match does, so a converted pattern and a true negative are indistinguishable by exit code as well as by output, and MSYS_NO_PATHCONV=1 is the fix (hold that thought). And xargs -0 LC_ALL=C grep tries to execute a program called LC_ALL=C: on findutils 4.10.0 that is loud — stderr says xargs: LC_ALL=C: No such file or directory and the exit code is 127 — and it becomes a clean zero only when the pipeline continues past xargs or stderr is dropped, which is how it once reported zero across a repo holding 218 matches. Both are in the earlier piece.

git log -G with a Perl-style pattern. -G takes a POSIX extended regular expression. \d, \w and \s are not part of it, and neither is the basic-regex habit of escaping | and {}. Six patterns against one file in a repository where the right pattern lists 76 commits, each run as git log --oneline -G '' -- sitemap.xml | wc -l:

2026-\d\d 0 # \d is not ERE
2026-[0-9]{2} 0 # BRE interval, wrong flavour
ogImage|lastmod 0 # BRE alternation, wrong flavour (run over sitemap.xml and posts/)
2026-[0-9]{2} 76
2026-[[:digit:]]{2} 76
ogImage|lastmod 77 # ERE alternation (same two paths)
The fix I first reached for, --perl-regexp, does nothing: the manual says it governs the "limiting patterns" — --grep, --author — not -G, and git log --perl-regexp -G '2026-\d\d' still returns 0 here. --pickaxe-regex is for -S and refuses to combine with -G at all. Write the extended regex:

0 — \s and \d are not ERE

git log --oneline -G '"date":\s*"\d+' -- posts | wc -l

39

git log --oneline -G '"date":[[:space:]]*"[0-9]+' -- posts | wc -l

This one is nastier than it looks because the same \d works in grep -P two lines earlier in the same script, so you carry a mental model that has already been validated.

node --check as a verification step. It parses. It does not evaluate. A file with a temporal-dead-zone violation — a const referenced before its declaration is reached — parses cleanly and exits 0, then throws the moment it actually runs.

// tdz.js
const items = ["a", "b"];
items.forEach(x => LABELS.push(x));
const LABELS = [];
node --check tdz.js # exit 0
node -e "require('./tdz.js')" # ReferenceError: Cannot access 'LABELS' before initialization, exit 1
I used node --check as a gate on generated code for weeks. It catches a missing operand (const x = ; fails it, I checked). It catches nothing about whether the file works.

Line-ending counts. grep -c $'\r$' is the folk way to count CRLF lines. On GNU grep 3.0 under MSYS it returns 0 for a file a byte scan shows to have 1,585 CRLF endings and no bare LF — this grep strips the CR from each line before matching, so the pattern can never fire. It also returns 0 on a pure-LF file. Same output, opposite files. -U keeps the bytes:

grep -c $'\r$' index.html # 0 (file has 1,585 CRLF lines)
grep -U -c $'\r$' index.html # 1585 (-U: binary mode, CR preserved)
grep -U -c $'\r$' blog/index.html # 0 (pure LF — the negative control)
sed strips the CR too: sed -n 1p index.html | od -c ends in a bare \n on that same CRLF file, so a sed | od pipeline reports LF for everything.

Read the bytes directly, or use -U.

grep -P on this locale. With LANG unset, grep -P refuses every pattern, not just exotic ones:

grep -c -P 'html' index.html

grep: -P supports only unibyte and UTF-8 locales (stderr, exit 2, nothing on stdout)

LC_ALL=C.UTF-8 grep -c -P 'html' index.html # 8
Redirect stderr, or pipe the result into wc -l, and it is a clean zero.

od | grep -o '0d 0a'. A tempting byte-level check for CRLF: dump hex, count the pairs. od emits sixteen bytes per output line, so any 0d 0a pair that straddles a line boundary never matches. On the same 1,585-line file:

od -An -tx1 index.html | grep -o '0d 0a' | wc -l # 1487
od -An -tx1 -w1 index.html | tr -d ' ' | tr '\n' ' ' | grep -o '0d 0a' | wc -l # 1585

Not a zero this time — an undercount of 98, which is worse in one way: it looks like a measurement.

grep -c '\r'. In a basic regular expression \r is the letter r. On a pure-LF, 401-line file it returned 317: every line containing an r. This is the saturated failure — the detector that fires on everything — and it is why the discipline below has a negative control as well as a positive one.

git show HEAD:file as a baseline. Under core.autocrlf=true the blob is stored LF and the working tree is CRLF. git show HEAD:index.html | wc -c gives 135376; wc -c < index.html gives 136961. The delta is 1,585 — exactly the line count. A byte comparison against the blob therefore reports every CRLF file as changed, and a "14-byte difference" on a block with fourteen newlines is not a difference at all. Compare LF-normalised content.

The fix that caused the next one

**
This is the best case on the list, and my first draft had it wrong.

The git grep fix above is MSYS_NO_PATHCONV=1: stop the shell translating Unix-looking arguments before they reach a native executable. I exported it for every session that grepped HTML or JSON. Some weeks later a search-engine submission silently never ran, and it took a while to connect the two.

Path conversion is also what turns /dev/null into nul for native programs. With the variable set, curl.exe receives the literal string /dev/null, cannot open it as a Windows path, and exits 23 — write error — after a complete, successful fetch. -s hides the message. -w prints the 200. And && short-circuits.

MSYS_NO_PATHCONV=1 curl -s -o /dev/null -w 'HTTP %{http_code}\n' https://www.claudecertifiedarchitects.com/sitemap.xml && echo "NEXT COMMAND RAN"

HTTP 200

(nothing else — $? is 23)

MSYS_NO_PATHCONV=1 curl -sS -o /dev/null https://www.claudecertifiedarchitects.com/sitemap.xml

curl: (23) client returned ERROR on write of 8268 bytes

curl -s -o /dev/null -w 'HTTP %{http_code}\n' https://www.claudecertifiedarchitects.com/sitemap.xml && echo "NEXT COMMAND RAN"

HTTP 200

NEXT COMMAND RAN

Writing to NUL or to a real file works with the variable set; I ran both. So the fix for one false zero manufactured another, in a different tool, weeks later, with the visible output — an HTTP 200 — actively reassuring. A list of tools that lie is not a list of independent facts. The entries interact, and the fix column is where they do it.

The same shape in code

**
The shell cases are easier to spot once you know them. The ones that live in application code have cost me far more.

A lookup with a fallback. This one ran for eleven weeks in an email template.

const tip = own(STUDY_TIPS, domain) || STUDY_TIPS['Agentic Architecture'];
STUDY_TIPS was keyed on 'Claude Code Configuration'. The value stored against every affected record was 'Claude Code Configuration & Workflows' — the display label, not the key. The lookup missed, the || supplied a default, and every consumer downstream received a valid, well-formed, entirely wrong tip.

167 emails went out that way: 85 carrying a study tip from the wrong domain, 82 carrying a sample question from the wrong domain, each under a heading naming the domain the reader had actually asked about. Nobody complained. The content was correct advice about something, and no recipient had any way to know what they were supposed to have received.

|| on a lookup converts a miss into a value. If the key is expected to exist, the miss is a bug and needs to be loud:

const tip = own(STUDY_TIPS, domain);
if (!tip) throw new Error(no tip for domain: ${domain});

A wrapper that catches and returns []. The agentic version of the same thing — a subagent fails, the wrapper logs it and returns an empty array, and the orchestrator receives [] and treats it as a fact about the world — which I wrote up last week and won't repeat, beyond noting that it survives code review because the code looks defensive.

**A script that fabricates a readout. **The worst one I've written. An audit script was supposed to report stored state. It didn't merely always answer yes — it compared its input to itself and printed a plausible, well-formatted readout of state it had never read. Everything downstream consumed the readout as the check.

If you want to see how this reads as an exam problem rather than an essay, we write scenario questions on exactly this in the practice bank. It's independent preparation material. We're not affiliated with Anthropic, and we neither sell nor administer the exam.

The discipline

**
One rule, and it is not "be careful."

Never accept a zero you have not proved with a known-positive control.

Before you believe a search returned nothing, run the same detector against something you know it should find. If the control doesn't fire, the zero is meaningless and you have learned that instead — which is a result, and a cheap one.

the question: does git grep find the link?

git grep -c 'href="/blog/' -- blog/index.html # (nothing), exit 1

the control: the MSYS grep binary, same file, same pattern

grep -c 'href="/blog/' blog/index.html # 47

the question again, with the fix

MSYS_NO_PATHCONV=1 git grep -c 'href="/blog/' -- blog/index.html # blog/index.html:47

Two controls are better than one: a positive that must fire and a negative that must miss. The second catches detectors that match everything — grep -c '\r' above — which is the failure mode the first one can't see.

The second half of the rule matters just as much, and it's the one I'm still bad at.

State the property your detector tests, then check that the detector tests that property — not the instance that made you look. When I found the updatedOutput error, I fixed the four places that carried it. I did not ask what else I'd written from the same guessed name on the same day. Closing an instance feels like closing a class, and the difference surfaces weeks later, by accident, usually in production.

For the email lookup, the detector that would have caught it in June is, in outline, three lines: call the real render function once for each distinct value actually present in the datastore, and read the output.

for (const domain of await distinctStoredDomains()) {
console.log(domain, '→', buildEmail1({ weakestDomain: domain }).subject);
}
That check now exists.

Where this costs more than it's worth

**
Controls are not free, and I don't run them on everything.

If a zero is cheap to be wrong about — you're looking for a string you half-remember in a file you're about to read anyway — the control is ceremony. If a zero is loud when wrong — the build fails, the tests go red, a human sees the empty page — the environment is already your control.

The cases worth the discipline are the ones where a wrong zero is quiet and durable: an audit result written into documentation, a class-closure claim, an enum lookup with a fallback, anything an autonomous process consumes without a human between the query and the conclusion.

There's an inverse failure worth mentioning too, since it cost me an hour last week. I compared two spreadsheet files cell by cell using a library's style objects, and every cell came back as different — including the empty ones — because those objects don't compare equal across two workbook instances. A detector that fires on everything is as useless as one that fires on nothing, and the negative control is what catches it.

Why this got worse, and what happened while this was being checked

**
All of the above predates LLM agents. What changed is who reads the zero.

A human who gets an empty result brings context: they know roughly how many results to expect, they remember that this search worked yesterday, and they have the option of asking someone. A model has your string and nothing else. Hand it [] and it will report, fluently and confidently, that nothing matched — and then act on that.

It happened during the fact-check for this article. To confirm the opening example, the hooks documentation was fetched through a tool that hands the page to a small model and asks it a question. Asked how many times updatedToolOutput appears, it answered: zero. It added, helpfully, that the page does not describe the hook modifying output. A curl of the same URL and a grep of the bytes: seven occurrences, including the table row that defines the field, with the control string PostToolUse at 58. The summariser had read part of the page and reported its absence as the page's. The false zero at the top of this piece was reproduced, by an agent, inside the session checking whether the piece was true, on the exact field name the piece is about.

So in an agentic system, "nothing found" and "the search did not run" have to be told apart in the value that comes back — not in a log, not in an exit code the model never sees, and not by a reader who was not there.

{ "results": [], "status": "ok" }
{ "results": [], "status": "error", "error": "upstream_timeout", "retryable": true }

Two different facts about the world. If your tool returns the first for both, every consumer downstream will eventually treat the second as the first, and the one reading it hardest is the one least equipped to notice.

Your MCP Tool Errors Are Written for the Wrong Reader

Josh — Fri, 04 Sep 2026 08:05:22 +0000

An agent called our calendar tool eleven times in ninety seconds. Same arguments, same failure, same response. It only stopped because the token budget ran out.

The tool was working exactly as designed. It returned a 409 with {"error": "Conflict"}, which is a perfectly reasonable thing for an HTTP API to say to a human holding a browser's dev tools open. The human reads "Conflict," checks the calendar, sees the event already started, and does something else.

Claude read "Conflict" and inferred that something transient had gone wrong. Transient things are worth retrying. So it retried.

That's the whole bug. The error message was addressed to a reader who wasn't there.

Errors are prompts

**
The thing that took me embarrassingly long to internalise: in an agentic system, every string your tool returns is model input. Your error messages are prompts. You wrote them for a developer reading a log, and then you handed them to a language model as instructions about what to do next.

A human reading {"error": "Conflict"} brings a mental model of your system, memory of the last time this happened, and the option of asking a colleague. The model brings none of that. It has your string and the tool schema. If the string doesn't say what went wrong or what to do instead, the model will guess — and the most available guess, given how much of the internet is retry logic, is "try again."

Rewriting the response fixed it in one line:

{
"error": "event_already_started",
"message": "This event has already started and cannot be modified. Use update_event to change its end time, or create_event to schedule a new one.",
"retryable": false
}

Three things changed. The error has a stable machine-readable code. The message names the constraint in plain language. And it points at the tool that would work.

The agent stopped retrying immediately. Not because we added retry logic — because we removed the ambiguity that made retrying look sensible. Writing error messages for the model rather than the operator is the single highest-leverage change I've made to a tool surface, and it sits squarely inside what the CCAR-F exam (also written CCA-F) calls its tool design and MCP domain, if you want the structured version of the same ground.

The three questions a tool error should answer

**
After rewriting about forty of these, the useful ones all answer the same three questions.

What class of failure is this? Not the HTTP status — a stable string the model can pattern-match on. event_already_started is a different beast from rate_limited, and both are 409-adjacent in a way that a status code flattens.

Is retrying meaningful? Say it explicitly. A retryable boolean does more work than any amount of message wording, because it removes the inference step entirely. Transient network failure: true. Business-rule violation: false. Rate limit: true, and include the wait.

What should happen instead? This is the one people skip, and it's the one that changes behaviour. An error that names the alternative tool converts a dead end into a next step. An error that doesn't leaves the model to invent one.

None of this is novel API design. What's different is the cost of getting it wrong. A human hitting an unhelpful error loses thirty seconds. An agent hitting one can burn a context window, or — worse — take a plausible wrong action that no one notices until later.

Retries make this worse before they make it better

**
Once you've told the model which failures are retryable, you have to be sure a retry is actually safe. Ours wasn't.

The same calendar tool had a create_event that was not idempotent. A retried call after a timeout produced two identical events. The failure mode was invisible in testing because our tests never timed out, and it was invisible in production because two identical calendar entries look like user error.

The fix is the boring one: accept a client-supplied idempotency key, store it against the created resource, and return the original result on a repeat. But the general principle is worth stating, because it applies to every tool an agent can call more than once: designing tools so a retried call doesn't produce duplicate side effects is a prerequisite for telling a model that retrying is safe, not an optimisation to add later.

If you mark something retryable and it isn't idempotent, you have built a duplication machine and given the model the keys.

The failure that returns nothing at all

**
There's a nastier cousin of the unhelpful error, and it's the one I'd look for first in any tool surface I hadn't written.

A subagent fails. The wrapper catches the exception, logs it, and returns an empty array. Upstream, the orchestrator receives [] and treats it as a fact about the world: there are no results. It reports confidently that nothing matched.

Nothing about that response says a failure occurred. It's the kind of thing I'd put on an anti-patterns list and expect to keep finding anyway, because the code looks defensive — it catches the error, after all — and the caller has no way to distinguish "searched and found nothing" from "search never ran."

I hit the same shape in a completely different context recently, where a search tool returned a clean zero. The lesson generalises: an empty result and a failed result must be distinguishable in the response, or every consumer downstream will treat the second as the first.

The contract between an orchestrator and its subagents needs an explicit error signal, not just an implicit success channel. That's a design decision, and it belongs to agentic architecture and orchestration rather than to whoever writes the subagent — it's easier to get right at the start than to retrofit once four call sites are treating [] as authoritative.

Schemas don't save you
A reasonable objection at this point: define a strict error schema, validate everything, done.

A schema constrains the shape of what you return. It says nothing about whether the values inside it are useful. You can be perfectly compliant with an error contract and still return {"code": "ERROR", "message": "Something went wrong", "retryable": true} on a permanent business-rule failure — and you'll have built the retry loop I started this post with, but now with validation.

This is the same trap structured output sets: a schema enforces shape, not correctness. The validation passing tells you the envelope is right. It tells you nothing about the letter.

Where this lands in practice

**
The changes that actually moved behaviour, in the order I'd do them again:

Give every failure a stable code that isn't an HTTP status. Add an explicit retryable flag rather than making the model infer one. Name the alternative action in the message. Make anything marked retryable genuinely idempotent. And make failure distinguishable from emptiness in every response shape you return.

That's five changes, none of them clever. The reason they matter more in agentic systems than in ordinary APIs is that your error strings have been promoted from diagnostics to instructions, and nobody sends a memo when that happens.

Worth reviewing your tool surface with that framing, if you haven't. The common design mistakes in MCP servers are mostly this class — decisions that were correct for a human consumer and became wrong the moment a model started reading them. And if you're working through tool granularity at the same time, it interacts with all of this: fewer, broader tools mean more failure modes crowded into a single error surface.

CCDV-F vs CCAR-F: 53 items, 8 domains, same $125 fee

Josh — Sun, 30 Aug 2026 20:01:17 +0000

Anthropic's certification programme publishes more than one Foundations exam, and two of them are aimed at people who build things. CCDV-F is the Claude Certified Developer – Foundations exam. CCAR-F is the Claude Certified Architect – Foundations exam, the one you will also see written informally as CCA-F — we covered why that exam answers to two different codes separately. The third, CCAO-F, is the Associate exam, written for people who use Claude rather than build with it; we set the Associate exam against the Architect one in its own article.

Both cost $125. Both run 120 minutes. Both are pitched at technical practitioners rather than at general users. So the fee will not tell you which one you are preparing for, and neither will the clock. What separates them is the shape of the exam and the syllabus behind it — and here the two published guides diverge sharply. This article sets them side by side using only what those documents state.

The short answer

**
The Developer exam is weighted toward getting Claude into an application: the API, the SDKs, the surrounding software engineering, and the design of the app itself. The Architect exam is weighted toward agentic systems and the tooling around them: orchestration, subagents, MCP interfaces, and Claude Code configuration. Both guides describe candidates who write code. They disagree about what that code is mostly doing.

Where the two exams are identical

**
Set the two at-a-glance tables next to each other (Section 5 of the Developer guide, Section 3 of the Architect guide) and almost every row matches, several of them word for word.

CCDV-F vs CCAR-F

Items: 53 vs 60
Domains: 8 vs 5
Fee: $125 both
Pass: 720 of 100–1,000 both
Time: 120 minutes both
Structure: CCAR-F specifies 4 scenarios from a bank of 6; the CCDV-F guide has no such row

The item-format row is identical in both guides, down to the punctuation: “Multiple-choice and multiple-response items; each item states how many responses to select”. Neither guide says what proportion of items takes each form, for either exam. That is worth holding onto, because it is an easy thing to assume; we wrote about what multiple-response actually means for how you answer when the Architect guide's wording raised the same question.

The scaled score of 720 on a 100–1,000 range is common to both, and both describe a criterion-referenced assessment measured against a fixed standard rather than against other candidates, with the per-domain percentages on your score report explicitly not used to decide pass or fail. The $125 fee is the same figure in both, which is why it cannot be the deciding factor here.

The policies are not merely similar — the retake sections are word-for-word identical. Both set the same waiting periods after a failed attempt: fourteen days after the first, thirty after the second, ninety after the third, four attempts maximum in a rolling twelve-month period, and the fee payable on each one. Both note the limits apply per exam, so failing one does not stop you registering for the other. Registration for both runs through the Anthropic Partner Academy and Pearson VUE, and both credentials last twelve months and renew through a free, non-proctored assessment.

Where they genuinely differ

**
The blueprint, and how it is published
This is the substantive difference, and it starts before you read a single domain name.** The two guides do not publish their blueprints at the same resolution.**

The Architect guide (Section 4) gives five domains in whole percentage points. Its Section 6 lists thirty task statements underneath them, each with “Knowledge of” and “Skills in” bullets, but no weight of its own. You know a domain is worth 20%; you do not know how that 20% is split.

The Developer guide (Section 6) gives eight domains to one decimal place and weights every skill inside them as well — twenty-five skills, each with its own percentage, summing exactly to their domain weights. A candidate can budget study time against it directly.

The eight Developer domains, and roughly how many of the 53 items each is worth:

Applications and Integration — 33.1% · ~17.5 items
Model Selection and Optimization — 16.8% · ~8.9
Agents and Workflows — 14.7% · ~7.8
Prompt and Context Engineering — 11.0% · ~5.8
Tools and MCPs — 10.6% · ~5.6
Security and Safety — 8.1% · ~4.3
Claude Code — 3.1% · ~1.6
Eval, Testing, and Debugging — 2.6% · ~1.4

And the five Architect domains, for comparison:

Agentic Architecture & Orchestration — 27%
Claude Code Configuration & Workflows — 20%
Prompt Engineering & Structured Output — 20%
Tool Design & MCP Integration — 18%
Context Management & Reliability — 15%

We break down the five Architect domains and what each one weighs in a separate post.

One domain is a third of the Developer exam

**
Applications and Integration is 33.1% on its own: roughly 17.5 of the 53 items. Nothing on the Architect blueprint is that concentrated; its heaviest domain, Agentic Architecture & Orchestration, is 27%, or about 16 of its 60 questions.

The Developer guide breaks that domain into six weighted skills: Claude Application Design (8.6%), Software Engineering Foundations (7.4%), Claude API Mechanics (6.8%), Configuration Management (4.1%), Understanding Requirements (3.4%) and Systems Life Cycle (2.8%). Note what is in there: Software Engineering Foundations covers REST APIs, JSON, asynchronous programming, version control and refactoring. That is general engineering practice, not Claude-specific knowledge, and on this exam it alone outweighs two entire content domains.

Two domains round to almost nothing

**
Claude Code is 3.1% of the Developer exam and Eval, Testing, and Debugging is 2.6%: about 1.6 and 1.4 items. Each is a single undivided skill, and together they come to 5.7%, or roughly three questions. Four individual skills each outweigh the pair: Claude Application Design at 8.6%, Software Engineering Foundations at 7.4%, Claude API Mechanics at 6.8% and Technical Fundamentals at 6.1%.

The contrast with the Architect exam is sharpest on Claude Code: 3.1% of the Developer blueprint against 20% of the Architect one, where it is a domain in its own right covering CLAUDE.md hierarchy, custom slash commands, settings and plan mode. If Claude Code is the reason you are looking at certification at all, that number is the one to read carefully.

The exam's structure, and what the Developer guide does not say
The Architect guide specifies its structure twice: in the Section 3 table as four scenarios drawn from a bank of six, and again in Section 5, which gives all six scenarios a section of their own and names the primary domains each one draws on.

**The Developer guide describes no scenario structure at all. **Its at-a-glance table has no exam-structure row, and it has no section corresponding to the Architect guide's Section 5. That is a statement about the two documents: one specifies a structure and the other does not. It does not follow that the Developer exam is, or is not, organised into scenarios — the guide simply does not say, and guessing from a silence is how people end up preparing for an exam that does not exist.

The same asymmetry shows up elsewhere. The Architect guide runs to eighteen sections and carries two things the Developer guide has no equivalent of: preparation exercises (Section 8) and an appendix listing technologies and concepts that might appear (Section 17). It publishes twelve sample questions in Section 9. The Developer guide runs to sixteen sections and publishes three samples in Section 8, noting that they illustrate item style rather than coming from the operational pool.

If you cross-reference the two documents, be careful with section numbers: they do not line up, and the offset is not constant. Exam details are Section 5 in the Developer guide against Section 3 in the Architect one, and the blueprint Section 6 against Section 4, but registration is Section 10 against Section 11, and the confidentiality agreement Section 13 against Section 14.

Who each exam is written for

**
The Developer guide's Section 3 is specific. It names AI and machine learning engineers, technical leads and senior software engineers, and expects one to five years of software engineering experience, at least six months hands-on with Claude, proficiency in Python and/or TypeScript, and fluency with REST APIs and command-line tools. It then says plainly who the exam is not for: non-technical or casual users, anyone without hands-on software development experience, and roles limited to prompt writing or other isolated tasks.

The Architect guide's Section 2 describes a solution architect who designs and implements production applications with Claude, with hands-on experience across the Agent SDK, Claude Code, MCP interfaces and context management, and typically six or more months of practical work against those technologies. Both profiles assume a working engineer; the Developer one is framed around shipping an application, the Architect one around designing the system's agentic structure. Our longer piece on which roles the Architect certification actually fits works through that side in more detail.

Neither guide requires anything. The Developer guide's Section 4 states there are no mandatory prerequisites or courses, and that the credential is awarded on exam performance alone.

How to choose

**
**What are you mostly building? **If it is an application that calls Claude — API integration, streaming, error handling, model and cost decisions — the Developer blueprint puts half its weight there. If it is an agentic system with subagents, orchestration and MCP tooling, the Architect blueprint is built around that.

How much does Claude Code matter to you? 20% of one exam, 3.1% of the other. This is the single largest divergence between the two blueprints.

**Do you want the syllabus at skill resolution? **The Developer guide gives you twenty-five weighted skills; the Architect guide gives thirty task statements with no weights attached. If you plan study time against percentages, that is practical rather than cosmetic.

Are you comparing on price? You cannot. Both are $125, with the same retake costs and waiting periods. The decision has to be made on content.
Nothing in either guide ranks one credential above the other, and neither is described as a prerequisite for the other. They are different scopes of work with different blueprints, and nothing stops you holding both.

Common MCP Server Design Mistakes and How to Avoid Them

Josh — Thu, 27 Aug 2026 08:35:01 +0000

Why MCP Server Design Matters for CCA Certification

**
The Model Context Protocol (MCP) represents a fundamental shift in how AI systems interact with external tools and data sources. For Claude Certified Architect candidates, understanding MCP server design isn't just about passing an exam—it's about building production-grade integrations that actually work. Yet even experienced developers consistently make the same design mistakes when implementing MCP servers, leading to brittle integrations, security vulnerabilities, and failed deployments.

After reviewing hundreds of MCP implementations and working with CCA exam candidates, we've identified seven critical design mistakes that appear repeatedly. These errors cause the majority of real-world integration failures. More importantly, they're entirely preventable once you understand the underlying patterns.

This guide examines each mistake in detail, explains why it matters for both certification and production use, and provides concrete patterns you can implement immediately. Whether you're preparing for the CCA Foundations exam or building actual MCP servers, these insights will save you significant debugging time and help you design more robust integrations.

Mistake 1: Treating MCP Like a Traditional REST API

**
The most pervasive mistake developers make is approaching MCP server design with a REST API mindset. This fundamental misunderstanding leads to poorly structured servers that fight against the protocol's design rather than leveraging it.

MCP operates on a client-server architecture where the client (typically Claude Desktop or another AI application) initiates all connections. Unlike REST APIs that respond to individual HTTP requests, MCP servers maintain stateful connections using JSON-RPC 2.0 over stdio transport. This connection model fundamentally changes how you should design your server.

What goes wrong: Developers create MCP servers with dozens of fine-grained tools that mirror REST endpoint patterns. For example, they'll implement separate tools for "getUserById", "getUserByEmail", "getUserByUsername", "listUsers", and "searchUsers". This approach creates cognitive overload for the AI model, increases token usage unnecessarily, and makes tool selection less reliable.

The correct approach: Design tools around user intent and capabilities rather than database operations. Instead of five separate user lookup tools, create a single "manage_users" tool with parameters that handle different query patterns. The tool description should clearly articulate what the tool accomplishes, not how it works internally. Your implementation can route to different backend services based on provided parameters, but the AI should see a coherent capability.

For the CCA exam, expect questions that test your understanding of appropriate tool granularity. The exam often presents scenarios where you must choose between multiple tool designs, and the correct answer consistently favours capability-oriented design over operation-oriented design. Remember that each tool you expose carries a token cost in the system prompt—good design minimises this overhead whilst maximising capability.

Mistake 2: Neglecting Resource Discovery Patterns

**
MCP's resource system provides a powerful mechanism for exposing readable content to AI applications, yet many implementations completely ignore this capability or use it incorrectly. Resources represent documents, data, or content that an AI might need to reference, distinct from tools which represent actions.

What goes wrong: Developers either skip implementing resources entirely, relying solely on tools to fetch data, or they implement resources without proper URI schemes and metadata. A common anti-pattern is creating a tool called "readDocument" instead of properly exposing documents as resources. This forces the AI to explicitly call a tool every time it needs content, increasing latency and complicating the interaction model.

Another frequent mistake is implementing static resource lists without supporting resource templates or subscriptions. When you have potentially thousands of accessible documents, files, or data objects, hardcoding them all in the resource list becomes unmanageable and defeats the purpose.

The correct approach: Implement resources for any content that the AI might need to read or reference. Use clear, hierarchical URI schemes that make sense to both humans and AI models. For example, "file:///project/docs/api-reference.md" is far superior to "resource://doc123". Support resource templates when dealing with large or dynamic content sets—this allows the AI to construct resource URIs based on patterns you define.

Include comprehensive metadata with your resources. The MIME type helps the AI understand how to interpret the content. The description should explain what the resource contains and when it might be relevant. If your resource content changes, implement the resources/updated notification so clients can refresh their understanding.

CCA exam questions frequently test whether candidates understand the resource versus tool distinction. You'll encounter scenarios asking you to design an MCP server for specific use cases—choosing between implementing something as a resource or a tool is a critical decision point that appears repeatedly.

Mistake 3: Poor Error Handling and Message Validation

**
MCP servers operate in an environment where failures are inevitable—network issues, rate limits, invalid parameters, missing permissions, and downstream service failures all occur regularly. Yet many implementations handle errors poorly or inconsistently, leading to confusing failures that are difficult to debug.

What goes wrong: Developers return generic error messages, fail to validate input parameters properly, or worse, let exceptions bubble up uncaught. Common patterns include returning "Error: something went wrong" without context, not validating required parameters before attempting operations, and mixing error reporting mechanisms (sometimes throwing exceptions, sometimes returning error objects).

Another critical mistake is not implementing proper timeout handling. When your MCP tool calls an external API that hangs, your entire server can become unresponsive, breaking the client connection and requiring a restart.

The correct approach: Implement comprehensive input validation for every tool and resource request. Check that required parameters are present, that types are correct, and that values fall within acceptable ranges before attempting any operations. Return JSON-RPC error objects with meaningful error codes and descriptive messages that help both developers and AI models understand what went wrong.

Structure your error messages to be actionable. Instead of "Invalid parameter", return "The 'start_date' parameter must be in ISO 8601 format (YYYY-MM-DD), but received '2024-13-45'". The AI model can use these detailed errors to correct its approach and retry successfully.

Implement timeouts for all external operations. If you're calling a database, API, or file system, wrap these operations in timeout logic. When timeouts occur, return clear errors indicating that the operation exceeded its time limit. Set reasonable timeout values based on your service's performance characteristics—typically 30-60 seconds for tool operations.

For CCA certification, you need to understand the JSON-RPC 2.0 error object structure and the standard error codes (-32700 to -32603). Exam questions often present error scenarios and ask you to identify the appropriate error response structure or troubleshoot why an error handling implementation is failing.

Mistake 4: Inadequate Security and Permission Models

**
Security considerations in MCP servers extend beyond basic authentication. Because MCP servers often act as bridges between AI systems and sensitive data or powerful capabilities, the security model must be thoughtfully designed from the ground up.

What goes wrong: The most dangerous mistake is implementing MCP tools that perform privileged operations without proper authorisation checks. Developers sometimes assume that because the MCP server is running locally or on a trusted network, security controls aren't necessary. This assumption creates severe vulnerabilities, especially when the AI model might be influenced by untrusted input.

Another common error is hardcoding credentials or API keys directly in the server code, exposing them in version control or making them difficult to rotate. Some implementations also fail to implement rate limiting or resource quotas, allowing a misbehaving or compromised client to exhaust system resources.

The correct approach: Implement proper authentication and authorisation for your MCP server. Even if your server runs locally, it should validate that requests come from authorised clients. Use environment variables or secure configuration management for credentials and secrets—never hardcode them.

Design your tools with the principle of least privilege. Each tool should only have access to the minimum resources and permissions necessary to accomplish its purpose. If a tool only needs read access to a database, don't grant it write permissions "just in case". Implement role-based access controls when different clients might have different permission levels.

Add rate limiting to prevent abuse. Even well-intentioned AI interactions can generate rapid sequences of tool calls. Implement per-client rate limits that prevent resource exhaustion whilst allowing normal operations. Return clear error messages when rate limits are exceeded, including information about when the client can retry.

Validate and sanitise all input parameters, especially those that will be used in database queries, file system operations, or command executions. Implement allowlists for file paths, database tables, or other resources that tools can access. Never construct SQL queries through string concatenation with user-provided values—use parameterised queries exclusively.

The CCA exam includes scenarios testing your understanding of security boundaries in MCP implementations. You'll need to identify security vulnerabilities in provided code samples and recommend appropriate mitigations. Understanding prompt injection risks—where malicious content in retrieved documents might influence the AI's behaviour—is particularly important.

Mistake 5: Ignoring Prompts and Sampling Capabilities

**
MCP servers can expose prompts—pre-configured message templates that clients can use—and implement sampling support, allowing the server to request AI completions. Many developers completely overlook these capabilities, missing opportunities to create more sophisticated integrations.

What goes wrong: Most MCP server implementations focus exclusively on tools and resources, treating prompts and sampling as advanced features they'll "add later". This approach misses the power of prompts for standardising common interaction patterns and sampling for implementing agentic behaviours within the server itself.

When developers do implement prompts, they often create overly specific ones that don't accept dynamic arguments, making them less reusable. Or they create prompts that are too vague, failing to provide the structure and context that makes them useful.

The correct approach: Identify common interaction patterns in your domain and create prompts that encapsulate them. For example, if your MCP server provides access to a project management system, you might create prompts like "analyse_project_status" or "generate_sprint_report" that structure how the AI should approach these tasks using your tools and resources.

Design prompts to accept arguments that parameterise the interaction. A prompt for analysing project status should accept the project identifier as an argument, making it reusable across different projects. Include clear descriptions of what each prompt does and what arguments it expects.

Consider implementing sampling support if your server needs to make autonomous decisions or generate content. Sampling allows your MCP server to request AI completions, enabling sophisticated behaviours like automated content generation, intelligent routing, or adaptive responses. This is particularly powerful for servers that act as agents rather than simple tool providers.

CCA exam content increasingly covers the full MCP specification, including prompts and sampling. While these features receive less emphasis than tools and resources, expect at least one question testing your understanding of when and how to use them appropriately.

Mistake 6: Insufficient Logging and Observability

**
When MCP integrations fail in production, troubleshooting becomes nearly impossible without proper logging and observability. Yet many implementations treat logging as an afterthought, making debugging a frustrating experience of guesswork and trial-and-error.

What goes wrong: Developers implement minimal logging, often just printing errors to stderr. They don't log tool invocations, parameter values, response times, or resource access patterns. When issues occur, they lack the visibility needed to understand what the AI requested, how the server processed it, and where failures occurred.

Another mistake is logging too verbosely in production, creating noise that obscures important events. Or worse, logging sensitive data like user credentials, API keys, or personally identifiable information, creating security and compliance issues.

The correct approach: Implement structured logging from the start. Log every tool invocation with the tool name, parameters (sanitised to remove sensitive data), execution time, and result status. Log resource access patterns, showing which resources were requested and whether they were found. Include request identifiers that allow you to trace a complete interaction flow across multiple operations.

Use appropriate log levels. Debug logs should include detailed information useful for troubleshooting but disabled in production. Info logs should record normal operations like tool invocations and resource access. Warning logs should highlight unusual but handled conditions. Error logs should capture failures with sufficient context to diagnose and fix issues.

Implement metrics collection for operational visibility. Track tool invocation rates, average execution times, error rates, and resource usage. These metrics help you understand usage patterns, identify performance bottlenecks, and detect anomalies that might indicate problems.

Consider implementing request tracing for complex operations that involve multiple tool calls or external service dependencies. Distributed tracing helps you understand the complete flow of a request and identify where time is being spent or where failures occur.

Sanitise logs to prevent leaking sensitive information. Implement allowlists of parameters that can be logged safely, and redact or hash sensitive values. Never log full API keys, passwords, or tokens—log only non-sensitive identifiers.

For the CCA exam, understanding observability best practices is essential. Questions often present troubleshooting scenarios where you must identify what information would be needed to diagnose an issue, and the correct answer invariably involves having implemented appropriate logging and metrics.

Mistake 7: Inadequate Testing and Validation Strategies

**
Testing MCP servers presents unique challenges because the client is an AI model whose behaviour isn't deterministic. Many developers struggle to implement effective testing strategies, leading to fragile implementations that break in production.

What goes wrong: Developers test their MCP servers manually by running them with Claude Desktop and trying a few interactions. They don't implement automated tests, don't validate the JSON-RPC protocol compliance, and don't test error conditions systematically. When they do write tests, they often test internal implementation details rather than the MCP protocol surface.

Another common mistake is not testing with realistic AI interaction patterns. The AI might invoke tools in unexpected orders, provide parameters in different combinations than you anticipated, or interpret your tool descriptions in creative ways. Without testing these scenarios, you won't discover issues until production use.

The correct approach: Implement multiple layers of testing. Start with unit tests for your internal business logic, validating that your core functionality works correctly independent of the MCP protocol. Then implement integration tests that validate your MCP protocol implementation—that tools are exposed correctly, resources are accessible, and the JSON-RPC messages are properly formatted.

Use MCP protocol testing tools to validate compliance. The MCP specification defines exact message formats and behaviours—your server should conform to these precisely. Test that your server correctly handles the initialisation handshake, properly formats tool and resource lists, and returns correctly structured responses and errors.

Create test scenarios that simulate realistic AI interactions. Build test cases that call tools in various orders, provide different parameter combinations, and test edge cases like very long strings, special characters, or boundary values. Test what happens when external dependencies are unavailable, slow, or returning errors.

Implement property-based testing for complex tool parameters. Rather than manually writing test cases for every possible input combination, use property-based testing frameworks to generate diverse inputs and validate that your parameter validation and error handling work correctly.

Test your server's performance characteristics under load. AI applications can generate bursts of rapid tool calls. Validate that your server handles concurrent requests properly, that it doesn't leak resources, and that performance remains acceptable under realistic load patterns.

Document test cases that validate your tool descriptions match their behaviour. The AI relies on your descriptions to understand when and how to use tools. If your description says a tool requires a parameter that's actually optional, or claims it returns data in a format different from reality, the AI will use it incorrectly. Your tests should validate this alignment.

CCA exam questions often present MCP server implementations and ask you to identify issues or suggest improvements. A solid understanding of testing strategies helps you recognise implementations that lack adequate validation and recommend appropriate testing approaches.

Building Production-Ready MCP Servers: A Checklist

**
As you prepare for the CCA Foundations exam or build real MCP implementations, use this checklist to ensure you're avoiding the common mistakes covered in this guide:

Tool Design: Tools represent capabilities, not database operations. Each tool has a clear purpose and comprehensive description. Parameter schemas are well-defined with appropriate types and descriptions.

Resource Implementation: Resources use clear URI schemes. Metadata includes MIME types and descriptions. Resource templates handle dynamic content. Updates are properly signalled when content changes.

Error Handling: All inputs are validated before processing. Errors return proper JSON-RPC error objects with meaningful codes and messages. Timeouts are implemented for all external operations. Error messages are actionable and specific.

Security: Authentication and authorisation are properly implemented. Credentials are stored securely, never hardcoded. Input is validated and sanitised. Rate limiting prevents abuse. Principle of least privilege is applied to all operations.

Prompts and Sampling: Common interaction patterns are encapsulated as prompts. Prompts accept appropriate arguments for reusability. Sampling is implemented where autonomous behaviour is needed.

Observability: Structured logging captures all important events. Sensitive data is sanitised from logs. Metrics track usage patterns and performance. Request tracing enables debugging of complex flows.

Testing: Protocol compliance is validated automatically. Unit tests cover business logic. Integration tests validate MCP behaviour. Edge cases and error conditions are tested systematically. Performance under load is validated.

Preparing for Success on the CCA Foundations Exam

**
Understanding these common MCP server design mistakes and their solutions provides essential knowledge for the Claude Certified Architect Foundations exam. The exam tests not just theoretical understanding but practical application of MCP concepts in realistic scenarios.

Expect questions that present MCP server implementations with subtle issues and ask you to identify problems or recommend improvements. You'll encounter scenarios requiring you to choose between different design approaches, and the correct answers consistently align with the patterns described in this guide. Questions often test your understanding of the trade-offs between different implementation strategies and your ability to recognise when an approach violates MCP best practices.

The exam also includes questions about troubleshooting failed MCP integrations. Your ability to identify missing logging, inadequate error handling, or security vulnerabilities in provided code samples directly impacts your score. Understanding the complete MCP lifecycle—from initialisation through tool invocation to error handling and connection termination—is essential.

Beyond the exam, these patterns represent proven approaches for building MCP servers that work reliably in production. The mistakes covered here account for the majority of real-world MCP integration failures. By understanding them deeply, you're not just preparing for certification—you're developing skills that will serve you throughout your career working with AI systems.

How to Write an Effective CLAUDE.md File: A Practical Guide for AI Architects

Josh — Wed, 26 Aug 2026 09:44:44 +0000

Understanding the CLAUDE.md File and Its Purpose

**
A CLAUDE.md file serves as a critical communication bridge between human developers and AI agents like Claude. Think of it as an instruction manual that sits at the root of your project directory, telling Claude exactly what your project does, how it's structured, and what coding standards to follow. For those preparing for the Claude Certified Architect (CCA) Foundations exam, mastering the art of writing effective CLAUDE.md files is essential—it demonstrates your ability to design systems that leverage AI assistance whilst maintaining code quality and project coherence.

The fundamental purpose of a CLAUDE.md file is to provide persistent context that Claude can reference throughout your development session. Without this file, you'd need to repeatedly explain your project's architecture, conventions, and requirements every time you start a new conversation. This becomes particularly problematic when working on larger codebases where context matters significantly. A well-crafted CLAUDE.md file reduces friction, minimises errors, and ensures Claude's suggestions align with your project's specific needs and constraints.

For CCA candidates, understanding CLAUDE.md files isn't merely about passing an exam—it's about demonstrating competency in one of the most practical aspects of working with AI agents. The exam tests your ability to structure information effectively, communicate technical requirements clearly, and anticipate the needs of both human collaborators and AI assistants. These skills translate directly into real-world scenarios where Claude becomes an integral part of your development workflow.

Essential Components of a CLAUDE.md File

**
Every effective CLAUDE.md file should contain several core sections that work together to provide comprehensive project context. Let's examine each component in detail and understand why it matters.

Project Overview and Purpose
Begin your CLAUDE.md file with a clear, concise description of what your project does. This section should answer fundamental questions: What problem does this project solve? Who are the intended users? What are the key features? Avoid marketing language or vague descriptions. Instead, focus on technical accuracy and specificity.

For example, rather than writing "A revolutionary data processing system," write: "A Python-based ETL pipeline that extracts customer data from PostgreSQL, transforms it according to GDPR requirements, and loads it into BigQuery for analytics. Processes approximately 500,000 records daily with a target latency under 2 hours."

This level of detail helps Claude understand not just what your system does, but also its scale, technology stack, and performance requirements. These contextual clues inform every suggestion Claude makes, from optimisation recommendations to error handling strategies.

Architecture and Structure
Describe your project's architecture in a way that helps Claude navigate your codebase mentally. Include information about the directory structure, key modules or packages, and how different components interact. You don't need to list every file, but highlight the important patterns and organisational principles.

Consider including a simple directory tree for clarity:

src/ - Main application code organised by feature
src/api/ - RESTful API endpoints using Flask
src/services/ - Business logic layer
src/models/ - SQLAlchemy ORM models
tests/ - Pytest unit and integration tests
config/ - Environment-specific configuration files
scripts/ - Utility scripts for deployment and maintenance

When Claude understands your project structure, it can suggest where new code should live, identify potential architectural issues, and maintain consistency across your codebase. This becomes particularly valuable when refactoring or adding new features.

Coding Standards and Conventions
This section is where you establish the rules Claude should follow when generating code. Be explicit about style guides, naming conventions, error handling patterns, and any project-specific standards. The more specific you are, the more consistent Claude's output will be.

Specify your preferred style guide (PEP 8 for Python, Airbnb for JavaScript, etc.) and any deviations from it. For instance: "Follow PEP 8 with the following exceptions: maximum line length is 100 characters (not 79), and we use double quotes for strings unless avoiding escape characters."

Include naming conventions: "Use snake_case for functions and variables, PascalCase for classes, SCREAMING_SNAKE_CASE for constants. Prefix private methods with underscore. Boolean variables should start with 'is_', 'has_', or 'should_'."

Document error handling expectations: "Use specific exception types rather than bare 'except' clauses. Always log exceptions with full stack traces. For API endpoints, return JSON error responses with appropriate HTTP status codes (400 for validation errors, 500 for server errors)."

Technology Stack and Dependencies
List the key technologies, frameworks, libraries, and tools your project uses. Include version numbers when specific versions matter. This prevents Claude from suggesting incompatible libraries or deprecated APIs.

Be comprehensive: "Python 3.11, Flask 2.3.x, SQLAlchemy 2.0, PostgreSQL 14, Redis 7.0 for caching, Celery for background tasks, Docker for containerisation, pytest for testing, black for code formatting, mypy for type checking."

If certain libraries should be avoided, state this explicitly: "Do not use pandas for data processing—we use Polars instead for better performance. Avoid the requests library; we standardise on httpx for both synchronous and asynchronous HTTP calls."

Development Workflow and Commands
Include the essential commands developers (and Claude) need to work with your project. This helps Claude provide accurate instructions when discussing setup, testing, or deployment procedures.

Document setup commands: "Run 'poetry install' to install dependencies. Copy .env.example to .env and configure database credentials. Run 'docker-compose up -d' to start local PostgreSQL and Redis containers."

List testing commands: "Run 'pytest' for all tests. Use 'pytest -m integration' for integration tests only. Run 'pytest --cov' for coverage reports. Target is 80% coverage minimum."

Include quality checks: "Run 'black .' to format code. Use 'mypy src/' for type checking. Run 'flake8 src/' for linting. All checks must pass before committing."

Writing Practices That Improve AI Performance

**
Be Explicit Rather Than Implicit
Claude cannot read your mind or infer unwritten conventions. If your team has specific preferences or requirements, state them clearly. Don't assume Claude will "figure it out" from examining existing code. Whilst Claude is capable of learning from context, explicit instructions in CLAUDE.md take precedence and ensure consistency.

For example, instead of hoping Claude will notice your preference for async/await patterns, write: "Prefer async/await for all I/O operations. Use asyncio for concurrent tasks. Avoid threading except when interfacing with synchronous third-party libraries."

Provide Examples for Complex Patterns
When describing coding patterns that might be unfamiliar or project-specific, include brief examples. This is particularly valuable for architectural patterns, testing strategies, or domain-specific code structures.

For instance, if your project uses a specific service layer pattern, show it: "All database operations must go through service classes. Example: 'UserService.create_user(email, password)' rather than directly instantiating User models. Services handle validation, business logic, and database transactions."

Update Your CLAUDE.md File Regularly
A CLAUDE.md file is a living document. As your project evolves, your CLAUDE.md file should evolve with it. When you make architectural changes, adopt new libraries, or establish new conventions, update the file immediately. An outdated CLAUDE.md file is worse than none at all—it actively misleads Claude and can result in suggestions that conflict with your current setup.

Consider adding a "Last Updated" date at the top of your CLAUDE.md file and treating updates as part of your standard development workflow. When you review pull requests, check whether the CLAUDE.md file needs updating based on the changes introduced.

Use Clear Headings and Organisation
Structure your CLAUDE.md file with clear markdown headings. This helps both humans and Claude quickly locate relevant information. A well-organised file might follow this structure: Project Overview, Architecture, Technology Stack, Coding Standards, Testing Strategy, Development Workflow, Deployment Process, Common Pitfalls, and Additional Resources.

Within each section, use subsections, bullet points, and numbered lists to break information into digestible chunks. Avoid long paragraphs of dense text—they're harder for Claude to parse efficiently and for humans to scan quickly.

Common Mistakes and How to Avoid Them

**
Being Too Generic
The most common mistake is writing a CLAUDE.md file that could apply to any project. Generic instructions like "Write clean code" or "Follow best practices" provide no actionable value. Claude already knows general best practices—what it needs from you is specific guidance about your project's unique requirements and constraints.

Transform generic statements into specific instructions. Instead of "Use appropriate error handling," write: "Wrap all external API calls in try-except blocks. Retry failed requests up to 3 times with exponential backoff. Log all retry attempts at INFO level. After 3 failures, log at ERROR level and raise a custom 'ServiceUnavailableError' exception."

Including Too Much Detail
Whilst specificity is valuable, there's a point of diminishing returns. Don't document every function or describe every edge case. Focus on information that Claude can't easily infer from reading your code. Document the why and the what, not the how of every implementation detail.

For instance, don't list every API endpoint in your CLAUDE.md file—Claude can discover those by examining your route definitions. Instead, document your API design principles: "API endpoints follow RESTful conventions. Use plural nouns for resources (/users, not /user). Nested resources should be limited to one level deep. Prefer query parameters for filtering and pagination."

Forgetting About Human Readers
Remember that whilst the primary audience is Claude, humans will read this file too—particularly new team members or collaborators. Strike a balance between providing machine-parseable information and maintaining human readability. Use natural language, include context where helpful, and consider adding links to relevant documentation or resources.

Neglecting Security and Sensitive Information
Never include credentials, API keys, or other sensitive information in your CLAUDE.md file. Instead, reference where this information should be stored (environment variables, secrets management systems) and provide guidance on how to configure them.

Write: "Database credentials are stored in environment variables: DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD. For local development, copy .env.example to .env. For production, credentials are managed through AWS Secrets Manager." This tells Claude how to reference credentials without exposing them.

Advanced Techniques for CCA Candidates

**
Context Hierarchies
For larger projects, consider creating a hierarchy of context files. Your main CLAUDE.md file provides project-wide context, whilst subdirectories might contain their own CLAUDE.md files with module-specific information. For example, your API directory might have its own CLAUDE.md describing endpoint patterns, authentication requirements, and response formats.

This approach prevents your main CLAUDE.md file from becoming unwieldy whilst ensuring Claude has access to detailed context when working in specific areas of your codebase.

Conditional Instructions
Some instructions might only apply in certain contexts. Make this clear: "When modifying API endpoints: always update the OpenAPI specification, add integration tests, and update the API documentation. When adding database models: create Alembic migrations, add model tests, and update the ER diagram."

This conditional guidance helps Claude understand when specific rules apply, reducing unnecessary work and maintaining appropriate context sensitivity.

Known Issues and Workarounds
If your project has known limitations, technical debt, or requires specific workarounds, document them. This prevents Claude from suggesting "ideal" solutions that don't work within your constraints: "Our PostgreSQL version doesn't support certain JSON operations—use JSONB casting instead. The legacy authentication system requires specific header formats—see auth_utils.py for the wrapper function."

Integration Patterns
Describe how your system integrates with external services or APIs. Include information about rate limits, authentication methods, and data formats: "GitHub API integration uses OAuth2. Rate limit is 5000 requests/hour. Always check 'X-RateLimit-Remaining' header. Cache repository metadata in Redis with 1-hour TTL."

Testing and Validating Your CLAUDE.md File

**
After writing your CLAUDE.md file, test it practically. Start a new conversation with Claude, ask it to perform a typical development task, and observe whether it follows your guidelines. Does it use the correct naming conventions? Does it import the right libraries? Does it structure code according to your patterns?

If Claude deviates from your expectations, review your CLAUDE.md file. The issue is usually ambiguity, contradiction, or missing information. Refine your instructions and test again. This iterative process helps you develop increasingly effective CLAUDE.md files.

Ask Claude to summarise its understanding of your project based on the CLAUDE.md file. This reveals whether key information is being understood correctly. If Claude's summary misses important points or misinterprets your instructions, revise those sections for clarity.

Sample CLAUDE.md Template
Here's a practical template you can adapt for your projects:

Project Name and Overview: Brief description of what the project does, its purpose, and key functionality.

Architecture: High-level architecture description, key components, and how they interact. Include directory structure for important folders.

Technology Stack: Programming languages, frameworks, libraries, databases, and tools used. Include versions where relevant.

Coding Standards: Style guide, naming conventions, code organisation patterns, comment requirements, and any project-specific conventions.

Testing Requirements: Testing framework, coverage expectations, test organisation, and quality gates.

Development Setup: Commands to install dependencies, configure environment, start development servers, and run tests.

Common Patterns: Frequently used patterns with brief examples—service layer structure, error handling, logging, API response formats.

Things to Avoid: Deprecated patterns, discouraged libraries, or anti-patterns specific to your project.

Additional Resources: Links to relevant documentation, architecture diagrams, or decision records.

CLAUDE.md Files in the CCA Foundations Exam Context

**
The CCA Foundations exam evaluates your understanding of how to effectively communicate with Claude in real-world scenarios. CLAUDE.md files represent a practical application of these principles. Exam questions might ask you to identify issues in a poorly written CLAUDE.md file, suggest improvements, or write sections for specific scenarios.

Key concepts the exam tests include: understanding context windows and token usage (concise but complete documentation), structuring information for machine parsing (clear hierarchies and formatting), anticipating Claude's needs (explicit rather than implicit instructions), and balancing specificity with maintainability.

When preparing for the exam, practise writing CLAUDE.md files for different types of projects: web applications, data pipelines, CLI tools, microservices. Each has unique documentation needs. Understanding these variations demonstrates broader competency.

Remember that effective CLAUDE.md files reflect deeper understanding of both software engineering principles and AI collaboration patterns. They're not mere documentation—they're interfaces that shape how humans and AI work together. This perspective is central to the CCA certification philosophy.

Taking Your Skills to the Next Level

**
Mastering CLAUDE.md files is just one aspect of becoming proficient with Claude. As you prepare for the CCA Foundations exam, focus on understanding the underlying principles: clear communication, appropriate context provision, and effective human-AI collaboration patterns. These skills extend far beyond a single file format.

Experiment with your CLAUDE.md files. Try different organisational approaches, varying levels of detail, and observe how these changes affect Claude's performance on real tasks. Build a personal library of patterns and templates based on what works well. Share your CLAUDE.md files with colleagues and gather feedback on clarity and completeness.

Consider documenting your learnings: which instructions worked particularly well, which created confusion, and how you resolved ambiguities. This reflective practice accelerates your development as a Claude architect and provides valuable study material for certification.

Six searches returned zero. Every one was broken.

Josh — Sun, 23 Aug 2026 08:11:23 +0000

I lost about forty minutes on Friday to a search that returned nothing.

The command was a repo-wide sweep for a string, the kind you run twenty times a day without thinking about it. It printed no matches. I read that as no matches. It exited 0, which is what a successful search with no results also does, so there was nothing to notice.

There were 218 matches.

The command was git ls-files -z | xargs -0 LC_ALL=C grep -n 'PATTERN'. If you have written that line before, look at it again. xargs takes the first token after it as the program to run. That token is LC_ALL=C. It is not a program. xargs tried to execute it, got nothing, produced no output, and returned success. The grep never ran. The locale variable ate the command.

The fix is xargs -0 env LC_ALL=C grep. One word. But the reason it cost forty minutes is not that the bug is subtle — it is that the failure is shaped exactly like a correct answer. Empty stdout, empty stderr, exit 0. Every signal I would have used to check it agreed that the search had worked and found nothing.

It was the fifth one that week
I had already been caught four times, which is the only reason I caught this one at all.

git grep returns silent false zeros for any pattern containing ="/. On Git Bash under Windows, MSYS path conversion rewrites an argument that looks like a Unix path into a Windows path before git.exe ever sees it. So git grep 'href="/blog/' searches for something else entirely and reports nothing. Plain grep is an MSYS binary and is unaffected — which is why the two disagree, and why the git grep zero looks like the authoritative one. MSYS_NO_PATHCONV=1 fixes it. Every link, nav, and internal-href search I had run on that repo was suspect.

grep -P with a non-ASCII character class dies on this locale. It prints "-P supports only unibyte and UTF-8 locales" to stderr and nothing to stdout. If you are reading stdout — and you are, because that is where matches appear — you see a clean zero.

grep -c $'\r$' miscounts line endings. cat -A strips CR and shows a CRLF file as LF. Both were being used to decide whether a file's line endings were about to be mangled, and both were answering a different question than the one asked.

Six tools, one week, all reporting nothing while the thing sat in front of them.

The same bug, one level up

**
What made me start checking is that I had already been burned by the abstract version of this.

A defect class in that project had been recorded as closed. The note said, in effect, no item in the bank now has this problem. It was written after a sweep, the sweep was real, and the sweep had found and fixed everything it looked at.

The sweep had been aimed at one particular string. The claim was about a whole class. Those are different statements, and the gap between them had been sitting there for four days with a live instance in it — an instance the same document mentioned in a different section, which nobody had read against the first one.

That is the same failure as the xargs line. A detector was pointed at one thing, returned zero for that thing, and the zero got promoted into a claim about something larger. The tool was working correctly. The inference was not.

And this is where it interacts badly with agents. I do a lot of this work with a coding agent, and an agent that runs a search and gets no output will tell you, accurately and confidently, that it found no occurrences. It is not wrong about what it observed. It is reporting a zero it has no way to distinguish from a broken detector — and it will report it in a clear declarative sentence that reads exactly like a finding.

This is not a quirk of one tool. Designing systems that can distinguish a real result from a failed instrument is a named competency — the CCAR-F exam's Context Management & Reliability domain covers it directly, down to building a taxonomy that separates transient failures worth retrying from permanent ones that need different handling.

I have written about this before, in a different form: your coding agent's summary of its own work is not evidence. This is the narrower case. A zero that an agent reports is not evidence of absence. It is evidence that a command produced no output, and those are only the same thing when the command ran.

The rule, which is one extra line

**
Before you trust a zero, prove the detector fires.

Run the same command against something you know is there. If you are sweeping for a flag that should have been removed, first search for a flag you know is still present and confirm you get hits. If that control comes back empty too, your detector is broken and the real search was never a search.

It costs one command. It would have caught all six.

In practice it looks like this. Say you are confirming a deprecated flag is gone:

grep -rn -- '--old-flag' . # the real search: expect 0
grep -rn -- '--flag-that-remains' . # the control: expect hits
If the second one is also empty, stop. You have not learned that the flag is gone; you have learned that your search does not work in this directory, with this shell, against these files. The control costs two seconds and it is the only thing standing between a zero and a belief.

The control has to be a string you have independently confirmed is present — ideally by opening the file and looking at it. A control you assume is there is just a second unproved search, and two unproved searches agreeing tells you nothing at all.

There is a second half, for when the zero is real but the claim is bigger than the search: **state the property you are claiming, then name the detector that tests that property. **If your detector only tests the specific instance that made you look, you have closed an instance. Say so. Do not write down that the class is closed, because in three weeks somebody — possibly you — will read that sentence and stop looking.

The same distinction matters one level up, in orchestrator and subagent designs: a subagent returning "no results" and a subagent that failed to run are different states, and every extra handoff is one more place that difference can be lost.

And a third, which caught me on a different question the same week: before attributing a change to a commit, check that the code actually differed. I had a metric that dropped in a particular week and a new event that appeared in the same week, and the fit was so tight that I built a whole explanation on it. The event was new. The behaviour was not — the file was byte-identical across both periods, and the event had simply started measuring something that had been there for a month. Two blob hashes would have killed it in five minutes. A new event is not a new behaviour.

What I actually changed

**
Not much, and that is the point. I keep a short list of tools that have lied to me on this setup, with the failure mode and the fix, and I read it before I trust a zero on anything that matters. There are six entries. I expect there to be more.

The list is worth more than any individual fix on it, because the entries are not really about xargs or git grep. They are about a category of result that looks identical whether it is true or whether the machinery failed — and that category is much larger than six commands. It includes every empty search, every clean test run that did not actually execute, every green check on a job that skipped, and every confident report from an agent that a thing does not exist.

A zero is a measurement. Measurements have instruments. Check the instrument.

CCAR-F vs CCA-F: which is the real Claude Certified Architect – Foundations exam code?

Josh — Thu, 20 Aug 2026 16:16:07 +0000

Anyone researching the Claude Certified Architect – Foundations certification runs into the same small confusion early: the exam appears under two different codes. Community study repos, forum threads and prep sites — including parts of this one until recently — call it CCA-F. The official Exam Guide calls it CCAR-F.

CCAR-F is the code in the published guide. Version 1.0, effective July 2026, lists it in the exam details table alongside the credential name. It is the string that appears on the official listing and on the booking.

CCA-F is informal shorthand for the same exam. It reads as a natural abbreviation of "Claude Certified Architect – Foundations", it circulated widely in community material, and a great deal of study content still uses it. It is not a different certification, an earlier version, or a lower tier. It is the same sixty-item exam under a name that was never on the paperwork.

There is also a Professional-level Architect exam, CCAR-P, with its own published guide and a separate blueprint. Foundations is the entry point of the two, and the shared "CCAR" stem is the clearest signal that the Architect codes were designed as a family.

Which code to use, and when
The distinction matters in three practical places.

Registering. Use CCAR-F. It is what appears when registering through the Anthropic Partner Academy, with scheduling handled by Pearson VUE. Searching a booking system for CCA-F may return nothing at all.

Searching for study material. Use both, separately. The two codes surface substantially different results, because most existing content was written under one or the other rather than both. A search under a single code returns perhaps half of what exists. Anyone who has downloaded the guide and read the code off it will naturally search CCAR-F — and will miss the large body of community material filed under CCA-F.

**Writing or citing. **Lead with CCAR-F and mention CCA-F alongside it. Both are true, one is official, and readers arrive with either.

A useful heuristic falls out of this: the code a resource uses is a rough proxy for whether it was written from the guide or from other people’s summaries of it. That is not a reliable rule — plenty of good material predates the v1.0 guide — but it is worth noticing when weighing an unfamiliar source.

What the published guide specifies
Everything below is from Exam Guide v1.0. The guide is the authoritative reference and this is a summary of it, not a substitute — it is worth reading in full before scheduling.

Credential Claude Certified Architect – Foundations
Exam code CCAR-F
Number of items 60
Item format Multiple-choice and multiple-response; each item states how many responses to select
Exam structure 4 scenarios drawn from a bank of 6
Time limit 120 minutes
Passing score Scaled score of 720 on a range of 100–1,000
Exam fee $125 USD
Validity 12 months from the date the credential is awarded
Delivery Proctored — online or at a Pearson VUE test centre

Three of those lines are worth expanding, because each one changes how a candidate should prepare.

Four scenarios appear out of six. All six are published in the guide: a customer support resolution agent, code generation with Claude Code, a multi-agent research system, developer productivity tooling, Claude Code in CI/CD, and structured data extraction. Because only four appear on any given form, core mechanisms recur across them — a candidate meets the same ideas from several angles rather than answering sixty scenario-based items on sixty separate topics. That has a direct consequence for study material: encountering a mechanism more than once is how the exam itself works, not a defect in the practice bank.

**Both item formats are used. **The guide specifies multiple-choice and multiple-response items, and states that each item tells the candidate how many responses to select. It does not say what share of the exam is multiple-response, so any source quoting a percentage has taken that number from somewhere other than the guide.

The pass mark is not a percentage. It is a scaled score of 720 on a range of 100 to 1,000, which is not the same as answering 72% of items correctly — scaled scoring exists to equate results across exam forms of slightly different difficulty. The $125 registration fee is charged per attempt, which matters more than it first appears.

The five domains and their weights
Domain Weight
Agentic Architecture & Orchestration 27%
Claude Code Configuration & Workflows 20%
Prompt Engineering & Structured Output 20%
Tool Design & MCP Integration 18%
Context Management & Reliability 15%

Because the weights differ by nearly two to one between the largest and smallest, it is worth deciding deliberately how to allocate study time by domain weight rather than working through the blueprint evenly.

Agentic Architecture & Orchestration is the largest single block at more than a quarter of the exam, and it carries the most task statements — seven, covering agentic loops, coordinator and subagent patterns, context passing, enforcement and handoff, hooks, task decomposition, and session management.

The most commonly underestimated is Claude Code Configuration & Workflows. On paper it looks like the domain a working developer absorbs by using the tool. In practice it turns on distinctions nobody stumbles into — when a path-scoped rule beats a directory-level CLAUDE.md, what context: fork actually protects, why plan mode earns its cost on a migration and wastes it on a one-line fix. A fifth of the exam sits there.

The score report gives a pass or fail with a scaled score, plus percent-correct by domain. The domain percentages are informational only; the pass decision rests on the total scaled score alone.

The section most candidates never read
The guide names topics that will not appear on the exam, and several are exactly what an experienced engineer assumes an AI certification must test:

Fine-tuning or training custom models
Claude’s internal architecture, training process, or model weights
Constitutional AI, RLHF, and safety training methodology
Embedding models and vector database implementation
Computer use, browser automation, vision and image analysis
Streaming API implementation and server-sent events
Rate limiting, quotas, and API pricing calculations
OAuth, API key rotation, and authentication protocols
Deploying or hosting MCP servers — infrastructure, networking, containers
Specific cloud provider configuration
Token counting and tokenization specifics
Prompt caching implementation details, beyond knowing it exists
Time spent revising vector stores or working through fine-tuning tutorials buys nothing here. The blueprint tests architectural judgement in production — which mechanism to reach for, and what trade-off comes with it. Not whether a candidate can recall that PostToolUse exists, but whether they know when a hook is the right answer and when a prompt instruction is.

Scheduling, retakes and renewal
Candidates can cancel or reschedule up to twenty-four hours before the appointment; changes inside that window forfeit the fee.

The waiting periods after a failed attempt lengthen each time — fourteen days after the first, thirty after the second, ninety after the third — with a maximum of four attempts per rolling twelve months. The fee applies to each attempt, so a retake costs another $125. That arithmetic is worth doing before booking the first sitting.

The credential lasts twelve months. Renewing on time means reviewing what has changed and completing a free, non-proctored assessment on the Partner Academy, at no fee. A lapsed credential means retaking the full exam at full price. The guide also notes that if exam content changes significantly, holders may be required to retake rather than renew.

Preparing
The guide’s own preparation section is specific and hands-on rather than theoretical: build an agent with the Agent SDK and implement a complete loop with tool calling and session management; configure Claude Code for a real project with a CLAUDE.md hierarchy, path-specific rules and at least one MCP server; design MCP tools with structured error responses; build an extraction pipeline using tool use with JSON schemas; and practise escalation and human-in-the-loop patterns. Section 8 sets out four full exercises with steps.

Practice questions earn their place by surfacing the trade-off reasoning the exam actually tests, which is difficult to rehearse against documentation alone. A free diagnostic gives a rough read on where a candidate stands against the 720 mark, and the practice question bank covers all five domains at their published weights.

Claude Certified Architect Jobs: Who's Hiring and How to Land One

Josh — Tue, 18 Aug 2026 13:17:12 +0000

If you're chasing the roles built around Claude and agentic AI — not just curious about the certification, but actually job-hunting — the useful question isn't "how do I become a Claude Certified Architect." It's where the openings actually are, what those postings ask for, and how to put the CCA-F in front of the right hiring manager. This page is about the demand side: the job titles worth searching for, the kinds of employers building on Claude right now, and a realistic path from credential to interview.

A quick note on scope, since the CCA-F is a new credential: this is an independent, third-party exam-prep resource — not an official Anthropic hiring program — and the CCA Foundations exam only launched in March 2026. That means there isn't hard data yet on exactly how many postings name it as a requirement. What follows is grounded guidance on where the underlying skills are in demand and how to position yourself, not invented statistics.

Looking for the career path itself, rather than the job search? See how to become a Claude Certified Architect for the roles and route in. For what the work actually involves day to day, see what a Claude Certified Architect actually does. For pay expectations, see Claude Certified Architect salary and career outlook. This page picks up where those leave off — landing the role.

Job Titles Worth Searching For
Very few postings say "Claude Certified Architect" verbatim yet — the title is new, and most hiring managers are still using the job titles that predate the credential. Search and set alerts for these instead, ideally paired with "Claude" or "Anthropic" in the description:

AI/ML Engineer — where the description specifies Claude, Anthropic, or LLM-based systems specifically

Agentic Systems Engineer / Agent Engineer

AI Solutions Architect / AI Solutions Engineer

AI Platform Engineer

Applied AI Engineer

LLM Integration Engineer / Conversational AI Engineer

AI Product Engineer — at product companies embedding Claude into an existing product

Technical AI Product Manager — less common, but draws on the same architectural fluency

The common thread across all of these is agent design, tool use, and production LLM deployment — not the literal job title. Filter and search on the skills above rather than searching "Claude Certified Architect" as a title, and you'll surface far more of the roles actually built for this skill set.

Where the Demand Is Coming From
Naming specific employers here would go stale fast and wouldn't be a reliable guide — but the types of organisations doing this hiring right now are fairly consistent:

AI-native startups and scale-ups building their core product on Claude
Established software companies adding Claude-powered features to an existing product

Enterprise consulting and professional-services firms doing client-facing AI implementation work

Internal platform teams at larger companies standing up shared Claude or Claude Code infrastructure for other engineers

Independent agencies and boutique studios specialising in AI transformation projects

Each of these hires differently. Startups move fast and weight shipped work heavily. Consulting firms care about client-facing communication as much as technical depth. Internal platform teams look for DevOps or infrastructure background alongside the Claude-specific skills. Match your search — and how you frame your resume — to the employer type, not just the skill set.

What These Postings Actually Ask For
Even where "Claude Certified Architect" doesn't appear as a title, the postings in this space tend to converge on a consistent set of asks:

Production experience with an LLM API — Claude or otherwise — not tutorials or personal projects alone

Experience designing tool use, function calling, or multi-step agent workflows

Prompt engineering treated as a discipline, not just "writes good prompts"
Some exposure to context management at scale — token budgets, prompt caching, long-running conversations

For platform-leaning roles: developer tooling, CI/CD, or internal infrastructure experience

This is exactly the ground the CCA Foundations exam covers, which is the point of holding it: the credential is a compressed way of demonstrating you've studied this territory. It doesn't replace showing real work — but it gives whoever's screening resumes a faster reason to take yours seriously.

How to Put the CCA-F on Your Resume and LinkedIn

LinkedIn
Add it properly under "Licenses & Certifications," with Anthropic listed as the issuing organisation and the credential name exactly as issued.
Add "Claude," "Anthropic API," "Agentic AI," "Model Context Protocol (MCP)," and "Prompt Engineering" as skills — these are the terms recruiters filter search results on.

If you've shipped a Claude-powered project, feature it and tie the certification to it directly in the description, rather than letting the credential stand alone.

Only lead your headline with the credential if you also have production experience to back it. A headline claim without substance behind it invites exactly the scrutiny you don't want in a first screen.

Resume
Place it in a dedicated "Certifications" section near the top when applying to AI or Claude-specific roles — buried under a generic "Other" heading, it won't do its job.

Pair it with one bullet describing something concrete you built or shipped with Claude. The certification plus evidence is a materially stronger signal than either on its own.

If you're switching careers and don't have production Claude experience yet, say so honestly and lead with transferable architecture or engineering experience instead — see the career-switch prep guide for how to frame that gap.

A Realistic Hiring Pipeline for CCA-F Holders
The certification changes what happens at the top of the funnel — it doesn't change what happens after it. A realistic pipeline looks like this:

Resume or application screen: the CCA-F earns you a second look, especially where an AI-literate recruiter or keyword filter is doing first-pass screening. It improves your odds of getting past this stage — it doesn't guarantee it.
Recruiter or hiring-manager call: you'll be asked what you've actually built, not to describe the exam. Have a specific project ready to walk through.

Technical screen: expect scenario-based questions similar in spirit to the exam itself — architectural trade-offs, not trivia. This is where studying the material, not just passing the exam, pays off.

System design or take-home: the stage where the judgment the CCA-F verifies actually gets tested directly, usually through an exercise involving agent orchestration, tool design, or context management.

Final or culture round: standard for the role level, largely unrelated to the credential itself.

Because the CCA-F only launched in March 2026, most hiring pipelines haven't formalised around it yet the way they have for older, established certifications. Treat that as an opportunity, not a gap: holding it now positions you ahead of the market catching up to it, not behind a requirement everyone else already has.

CCA-F (CCAR-F) Certification vs an AI Bootcamp: Which Is Worth Your Time and Money?

Josh — Fri, 14 Aug 2026 15:50:22 +0000

If you're trying to break into AI/Claude architecture work, you've probably looked at two very different price tags: a bootcamp running into the thousands of dollars over several months, or a $125 exam plus a self-paced practice bank. That's not a question of which one is objectively "better" — it's a question of which container actually fits where you're starting from, how you learn, and what's missing between now and a job. This page is a head-to-head on that specific fork, not a broader argument for either path.

For the ROI case on the certification itself, see is the Claude Certified Architect certification worth it. If you've already decided the certification path is right for you and want a study plan built around switching careers, see how to prepare for the CCA-F when you're switching careers. This post picks up before either of those — deciding whether a bootcamp or the certification path is the right starting point at all.

What an AI Bootcamp Actually Gives You
Be honest about this: a good bootcamp offers real things a certification exam and a question bank cannot.

A structured curriculum sequenced by someone who has already figured out the right order to learn things in, instead of you assembling that order yourself from scattered resources.

Live mentorship — instructors and TAs who can catch a conceptual gap in real time, something a static resource can't do.
A cohort — peers moving through the same material on the same timeline, which normalizes the struggle and creates accountability that's hard to manufacture alone.
Career services — resume workshops, interview prep, and sometimes direct employer relationships or placement partnerships.
Forced momentum — a fixed schedule and sunk cost that keeps people moving who would otherwise stall out studying alone.

If you're coming from a genuinely non-technical background with no engineering foundation to build on, or you've tried to self-teach before and stalled without external structure, that container is a legitimate reason to pay for a bootcamp. No certification replaces it.

What a Bootcamp Typically Costs — Time and Money
Pricing and length vary widely by provider, format, and whether the program is full-time or part-time, so treat any number here as a general pattern, not a quote — confirm current pricing directly with whichever program you're considering. That said, full-time, instructor-led AI or software bootcamps typically run into the thousands of dollars and often into the five-figure range, with part-time or self-paced tracks usually priced lower. Program length commonly spans several weeks of full-time study up to a few months. Financing plans, income-share agreements, and employer sponsorship are common ways people offset the cost, but the upfront commitment — in both money and time away from other things — is real.

The Case for the Certification + Self-Study Path
The CCA-F path looks completely different if you already have a functioning technical foundation — existing software engineering experience, a cloud or solutions architecture background, ML/data engineering work, or a technical product management role. In that case, you're not trying to learn to build software from zero. You're formalizing architectural judgment on top of skills you already have, and a bootcamp's core value — teaching you to code, or teaching the fundamentals of software engineering — is largely redundant for you.

The certification itself is a fixed, known cost: a $125 exam fee, 60 scenario-based questions across five weighted domains, 120 minutes, scored on a 100–1000 scale with a pass mark of 720, delivered through Pearson VUE, valid for 12 months. Items are multiple-choice and multiple-response — each item states how many responses to select. If you want structured practice beforehand, our own $49 question bank is modeled on the exam's format and difficulty (not the actual exam questions), and the free diagnostic gives you a quick read on where you stand before you spend anything.

Set against even the cheaper end of a bootcamp, that's a small fraction of the cost, and the time commitment is measured in weeks of self-paced study around a job rather than months away from one. What it doesn't give you: no mentorship, no cohort, no career-services team. You supply the accountability, and you need to already have (or separately build) the underlying technical skill — the exam certifies judgment, it doesn't teach the fundamentals.

Who Should Actually Choose a Bootcamp
You're starting from little or no technical background and need the fundamentals taught, not just certified. You learn best with external structure, deadlines, and accountability rather than self-directed study. You want built-in mentorship or a peer cohort going through the same material at the same time. You want a career-services pipeline — resume help, interview prep, employer connections — bundled into the program rather than assembled yourself. You can afford the time and money commitment a structured program requires.

Who the Certification Path Fits Better
You already have relevant technical experience — software engineering, cloud/solutions architecture, ML/data engineering, or a technical product role — and need to formalize or prove it, not acquire it from scratch.
You're a self-directed learner who doesn't need external structure to stay on track. You're constrained on time or money and can't take months off or pay bootcamp tuition. You want a fast, low-cost way to signal architectural competence to employers while you keep working.

Can You Do Both?
They're not mutually exclusive, and for some people the right sequence is both, not either/or. If you're starting from genuinely no technical background, a bootcamp can build the foundation, and the CCA-F afterward becomes the credentialing step that proves what the bootcamp taught. Treat them as sequential rather than competing in that case — neither one substitutes for the other's role in your specific situation.

Not sure which situation actually describes you? Take the free 10-question readiness diagnostic. If you clear it comfortably, you likely already have the technical foundation the certification path assumes. If it's a real struggle, that's a signal you may need more structured groundwork first — whether that's a bootcamp or another foundational path — before the certification makes sense. If you decide the certification path is right for you, build exam-ready judgment with the 400-question practice bank, modeled on the exam's format and difficulty.