Blake as a tool, not a tab

The CRM was always meant to hold the truth. It only did when someone typed it in.

Most of the work around a deal happens somewhere other than the CRM. The follow-up gets drafted in an assistant. The signed PDF lands in an inbox. The call notes sit in a notes app. Somebody at some point is supposed to carry each of those into Blake, and that somebody is a person with a full calendar. So the pipeline shows what was remembered, not what happened.

Blake is a tool now. Anything that already knows something about a deal can put it in the pipeline itself, and anything that needs to know can ask. Two doors, one set of keys: a REST API and an MCP server.

One key, sixteen scopes

Keys are created in Settings under API keys. Each key gets a label and a set of scopes from a list of sixteen: read, write and delete on notes, tasks and documents; read and write on opportunities, contacts and companies; write on leads. A scheduling bot gets tasks:write and nothing else. A website form gets leads:write. Revoke a key and it stops in the same second, everywhere.

The label is not decoration. Every note added, stage moved or task completed through a key shows that label in the activity feed. "Sales bot moved Northwind Freight to Proposal sent" reads as what it is, next to the things people did, and nobody has to wonder who touched the deal.

The MCP server: nineteen tools

If you run an agent, Claude Code or anything else that speaks MCP over HTTP, point it at app.blakecloses.com/api/mcp with the key as a bearer token:

The agent then has nineteen tools: search, list_opportunities, get_opportunity, move_stage, upsert_contact, upsert_company, create_lead, add_note, list_notes, delete_note, create_task, list_tasks, get_task, update_task, complete_task, delete_task, upload_document, list_documents and delete_document. Each is gated by the key's scopes, so an agent with a read-only key can look at the pipeline all day and change nothing.

The server is stateless: one request, one response, no session to keep alive, and plain HTTP clients work without an event-stream parser. That is a deliberately boring design, because the interesting part is what the agent does with the tools, not how it connects.

The REST half

The same capabilities as plain endpoints, documented at app.blakecloses.com/api/v1/docs with the OpenAPI file behind it: companies, contacts, leads, opportunities with their stage, notes and documents, tasks, notes, search, and me to check what a key can do.

Writes honour an Idempotency-Key header, so a retried request creates one task, not two. Sixty requests a minute per key, and every response says where you stand in x-ratelimit-remaining.

The rules do not change for a machine

The API cannot send email. That was the rule for people and it is the rule for keys: Blake records the conversation, it does not become a sending channel that a leaked key could abuse. A key cannot see another workspace, cannot widen its own scopes, and cannot delete what it was not given delete on.

Three things to build this week

An agent that reads today's tasks each morning and drafts the follow-ups, attaching each draft as a note on the opportunity. A form on your site that posts straight to /leads, so a request lands in the pipeline before anyone reads the email. A nightly job that finds the signed PDF in the shared drive and files it on the deal with upload_document.

None of those need a person to remember anything. That was the point.