Capstone part 3: secure, test and ship crescent-crm

0:00 Capstone part 3

Crescent CRM works on your machine. Now let's make it something an agency can trust with real clients. In this final lesson you'll add authentication and scopes, deploy it remotely, automate tests and evals, run a security review, and roll it out to hosts.

0:19 Why shipping matters

Why does shipping need its own lesson? Because this is where good intentions become evidence. Anyone can say, it's secure and it works. A platform team shows the tests that prove it, the checklist with links, the eval results in real hosts, and the plan for when something goes wrong. Think of a building inspection. The builder's confidence doesn't matter; the inspector's signed checklist does. In this lesson, you're both the builder and the person preparing for inspection.

0:53 Step 1: auth and scopes

Step one is authentication. Reuse the JWT verifier from the authorization lesson and require the read scope on every request. Then enforce the write scope inside the write tools with a small helper that checks the verified token and returns the caller's identity. That identity replaces the placeholder in the created by field, so every logged activity records who really did it. In production, prefer a four oh three with a scope challenge so clients can step up, and keep the per tool check as defense in depth.

1:31 Step 2: deploy

Step two is deployment. Containerize the server, run it over Streamable HTTP behind TLS, and put it behind the company gateway. Load secrets like the database connection and OAuth settings from a secret manager. At the gateway, rate limit per user on the tool name header, log method, tool, user and duration, and cap request sizes. And run two replicas from day one, which proves the server really is stateless before anyone depends on it.

2:04 Step 3: tests

Step three is automated tests. The lesson's tests check that the company brief never exposes contact emails or phone numbers, that a five month performance range is rejected with a helpful message, and that logging the same activity twice doesn't create a duplicate. Security tests run against staging: no token and wrong audience both get four oh one, a read token can't log activities, marketing drafts to non consented contacts fail, and SQL characters in search queries are treated as plain text.

2:40 Simple example: three layers

A simple example of defense in depth. An analyst's token has only the read scope. Their AI app, influenced by an injected note in an activity record, tries to call log activity. First line of defense: the transport's required scopes. Second line: the require scope helper inside the tool rejects it with a clear message. Third line: even if both were misconfigured, the activity would be recorded with the analyst's real identity, so the audit log shows exactly who did what. Three independent layers, each simple.

3:17 Step 4: evals in two hosts

Step four is model evaluation in two hosts. Run your twenty five eval requests through the client bridge with two models, and manually in Claude and VS Code for a subset. Score tool selection, argument validity, calls per task and correctness against your fictional data, with thresholds agreed with the account team. When selection goes wrong, fix the tool descriptions, not host prompts, because descriptions travel with the server to every host.

3:48 Step 5: security review

Step five is the security review. Confirm the server publishes protected resource metadata and validates audience. No token passthrough, and the server uses its own least privilege database user. Scopes enforced per tool. No generic SQL, export, send or delete tools. Parameterized queries, caps and range limits. Minimal personal data in outputs and none in logs. Tool definitions hashed in the catalog. Dependency and image scanning. And a red team check that injected text inside activity notes never triggers writes in your agent eval.

4:25 Step 6: rollout

Step six is rollout. Add a catalog entry with owner, scopes, data classification and approved hosts. Pilot with five account managers and two analysts for two weeks, and feed every failure into the eval set. Then add it as an organization connector in Claude, share a VS Code snippet with developers, and give the reporting agent a read only machine token. Publish a changelog and book a review in six months.

4:56 Example: pilot findings

Here's how a pilot might go. Account managers love the company brief but ask for last contacted dates. Analysts hit the ninety two day limit for quarter over quarter comparisons. The team adds last contacted to the contact summary, with no new personal data, and adds guidance to the performance tool's description about using two calls for quarters. Eval accuracy stays stable, and the changelog records both changes. That's the loop: pilot, learn, adjust, re evaluate, document.

5:29 After launch

What happens after launch? Plan a short operating rhythm. Weekly for the first month: review errors, slow tools, denied scope attempts and a sample of real questions that went badly, and add them to the eval set. Monthly after that: review the catalog entry, dependency updates and costs. And every time a new host version or protocol version arrives, rerun the host tests. A server that's cared for stays trustworthy; one that's forgotten slowly drifts.

6:02 Deeper: the two-week pilot (illustrative)

Let's deepen the pilot for Crescent Growth with illustrative numbers. Five account managers and two analysts, two weeks. Account managers used the company brief most, often daily. Analysts hit the ninety two day limit a few times and adapted. Security monitoring showed a handful of denied write attempts from analysts, all accidental, all correctly refused. Two eval failures came from real questions phrased in Roman Urdu, which the model sometimes misread; the team added those phrasings to the eval set and clarified two tool descriptions. At the end of the pilot, the head of accounts approved rollout to all staff, with a six month review booked in the catalog.

6:49 Watch me do it: auth + tests

Watch me do it. Let's walk through the scope helper and the tests. Require scope calls get access token, which returns the verified token for the current HTTP request. If there's no token, it allows a local development user only when the unauthenticated flag is explicitly set, otherwise raises authentication required. If the scope is missing, it raises a clear tool error. Otherwise it returns the token's subject, or the client id. In log activity, created by now comes from require scope with crm write. Now the tests, run with the local flag and a test database. The first asserts that every contact in a brief has exactly three fields: id, name and role. The second asks for a five month range and checks the ninety two day message. The third logs the same activity twice and checks for, already logged. I run pytest, three passes. Then, against staging over HTTP, the negative auth tests: no token, wrong audience and read only token all fail as expected.

8:02 Try this now

Try this now. Deploy crescent CRM to staging with OAuth and two replicas. Run the protocol tests, the security tests and your twenty five request eval in two hosts. Fill in the security checklist with evidence links, write the catalog entry, and plan a two week pilot. Put all of it in one folder: that's your launch pack. When a friend who hasn't seen the project can read it and explain how to switch the server off, it's done.

8:36 Deliverable and course recap

Your final deliverable is a launch pack: the design doc, the repository with tests, the security checklist with evidence, eval results in two hosts, the catalog entry, the rollout plan and the changelog. It's exactly what real platform teams produce. Across this course you've learned why MCP exists, its architecture and primitives, transports, building servers in Python and TypeScript, connecting hosts and clients, OAuth and security, testing, deployment, registries and enterprise rollout. Assemble the pack, then take the final exam.