A portfolio API is a programmatic interface that lets you read and write your portfolio and career data (projects, resume, posts, profile) from code instead of a dashboard. An MCP server exposes that same data to AI assistants through the Model Context Protocol, a standard way to let an assistant read from and act on external tools. Together they mean you can script updates, sync from your own systems, back up your data, and ask an assistant to change your portfolio for you, all behind scoped API keys you control. Folio ships both: a v1 REST API that reads and writes, and an MCP server.
The protocol
What the Model Context Protocol actually is
The Model Context Protocol, or MCP, is a standard for connecting AI assistants to external tools and data. Before it existed, every assistant had its own bespoke way of calling out to your systems, so each integration was a one-off. MCP fixes that the way any good protocol does: it defines a common shape for a server to describe what it can do (the tools it exposes and the data it can read) and for a client to call those tools. Write one MCP server and any MCP-aware assistant can use it.
The mental model is simple. An MCP server is a small program that advertises a set of capabilities, for example "read my projects" or "create a post". The AI assistant is the MCP client. When you ask the assistant to do something, it discovers the available tools, decides which ones to call, and calls them through the protocol. The server does the real work and returns a result the assistant can reason about. You stay in the loop: the server only exposes what you let it, and calls run against credentials you granted.
This matters for a portfolio because a portfolio is not a static document, it is structured data that changes as your career does. A new project ships. A role ends. A talk gets accepted. If that data sits behind an MCP server, the assistant you already use can keep it current for you, in plain language, instead of you opening a dashboard and filling in fields by hand.
The API
What a read and write portfolio API unlocks
An MCP server is the assistant-facing door. A REST API is the everything-else door, and it is the one engineers reach for first. When your portfolio and career data are readable and writable over HTTP, they stop being trapped in one product and become a resource you can wire into your own systems. The three jobs it does best are sync, scripting, and backup.
Sync is the big one. Most developers already have a source of truth for their work: a repo of side projects, a database, a spreadsheet, a JSON file in a dotfiles folder. With a write API, that source of truth drives your public portfolio. A script reads your systems, pushes the current state, and your site reflects reality without you ever retyping it. The read side closes the loop, so your automation can check what is already published before it decides what to change.
Scripting covers the one-off jobs that a dashboard makes tedious: rename a batch of projects, retag everything from a certain year, flip drafts to published on a schedule, or import a year of posts in one run. Backup is the quiet insurance. A read API means you can pull a full copy of your portfolio, resume, and posts on a cron and keep it in your own storage, so your career data is never something you can only access through someone else's UI. This guide keeps the specifics conceptual on purpose; the exact resources, request shapes, and limits live in the docs at /developers.
The security model
API keys, scopes, and authentication
Programmatic access is only safe if access is bounded. Three ideas do almost all the work: keys, scopes, and how you send them.
Keys
An API key is an identity
A key stands in for you when a script or an assistant calls the API. You create it, you can revoke it, and you can hold more than one so a broken automation never means rotating your whole life. Treat a key like a password: put it in an environment variable or a secret manager, never in a commit.
Scopes
Scopes bound what a key can do
A scope is a permission attached to a key, such as read-only versus read and write. A backup job gets a read scope and physically cannot change anything. An import script gets write. The rule is least privilege: give each key the smallest set of scopes that lets it do its one job.
Auth
Authentication is how you present the key
Every request carries the key so the server knows who is calling and what they are allowed to do. You send it over HTTPS in the header the docs specify, the server validates it against its scopes, and the call succeeds or is refused. No key, or the wrong scope, means no access.
MCP
The MCP server rides the same rules
The MCP server is not a separate security world. It authenticates with a scoped key just like the REST API, so an AI assistant acting on your behalf can only touch what that key permits. Grant read to let it summarize your work; grant write to let it update it.
Rotation
Rotate and revoke without fear
Because keys are cheap to create and independent, rotation is routine, not an incident. Issue a new key, update the one automation that uses it, revoke the old one. A leaked key is contained to its scopes and gone the moment you revoke it.
Audit
One key per job pays off later
When each automation has its own scoped key, you can reason about who did what. If something writes a bad update, you know which key and which job to look at, and you can pull that one key without disturbing anything else.
The workflow
A clean automation, start to finish
This is the pattern that holds up. It works the same whether a nightly script or an AI assistant is the thing making the changes.
Decide your source of truth.
Pick the one place your project data actually lives: a repo, a database, a JSON file. The portfolio is a projection of that source, never a second copy you edit separately. Everything downstream depends on there being exactly one authority.
Create a scoped key for the job.
Make a dedicated API key with only the scopes this automation needs. A read job gets read. A sync job gets write. Store it as a secret, not in the code, so the script is safe to commit and share.
Read before you write.
Have the automation pull the current published state first, then compute the difference against your source of truth. Writing blind creates duplicates and drift; reconciling against what is already there keeps the operation predictable.
Make the write idempotent.
Design it so running it twice produces the same result as running it once. Match on a stable identifier, update in place, and only create what is genuinely new. Idempotency is what lets you run the job on a schedule and forget about it.
Hand the boring parts to the assistant.
For the updates that are easier described than scripted, let the MCP server do it. "Add the project I just shipped and draft a short post about it" is a sentence to an AI assistant, and the same scoped key keeps it inside its lane.
Schedule it and keep a backup.
Run the sync on a cron so your portfolio never lags your work, and run a read-only pull that saves a full copy to your own storage. Now your career data is both always current and always recoverable.
The payoff
Manual upkeep versus API and MCP
The value of a programmatic portfolio is not novelty, it is that the maintenance stops being your problem. Here is the difference in practice.
| Capability | Folio | Dashboard by hand |
|---|---|---|
| Adding a new project | A script or assistant writes it from your source of truth | Open the dashboard and retype every field |
| Keeping data in sync | A scheduled job reconciles the portfolio to your systems | Remember to update two places and hope they match |
| Bulk changes | One run retags or republishes everything at once | Click through each item one at a time |
| Backups | A read-only pull saves a full copy to your storage | Whatever the UI lets you export, if anything |
| AI updates | Describe the change to an assistant over MCP | No path; the UI is the only way in |
| Access control | Scoped keys grant exactly the access each job needs | One login with full access to everything |
The point is not to stop using the dashboard. It is that the repetitive, error-prone parts move to code that runs itself.
The takeaway
Treat your portfolio like the API-backed product it is
For most people a portfolio is a chore they update twice a year. For a developer it can be a system: one source of truth, a scoped key, a small script, and an assistant that handles the rest in plain language. The data was always structured. Giving it an API and an MCP server just lets you work with it the way you already work with everything else you build.
Start narrow. Wire up one read-only backup so you never lose your data, then one write job that syncs your projects from wherever they already live. Once those two run themselves, add the assistant for the updates that are easier to describe than to script. Each piece is small, and each one removes a recurring task from your plate for good.
Folio ships this today: a v1 REST API that reads and writes your portfolio and career data behind scoped keys, and an MCP server so an AI assistant can do the same on your behalf. The endpoints, the resource shapes, and the key management all live in the docs. When you are ready to turn your portfolio into something you manage as code, that is where you start.
Frequently asked questions
What is an MCP server for a portfolio?
It is a small program that exposes your portfolio and career data to AI assistants through the Model Context Protocol, a standard for letting an assistant read from and act on external tools. With it, an assistant you already use can read and update your projects, resume, and posts on your behalf, bounded by a scoped API key you control.
What can a portfolio API do?
A read and write portfolio API lets you manage your data from code instead of a dashboard. You can sync projects from your own systems, script bulk updates, publish on a schedule, and pull a full backup of your portfolio, resume, and posts to your own storage. Folio ships a v1 REST API that does all of this; the specifics live at /developers.
How do API keys and scopes keep access safe?
An API key is an identity a script or assistant uses to call the API, and a scope is a permission attached to that key, such as read-only versus read and write. You give each key the least access its job needs, so a backup key can never write and a leaked key is contained to its scopes and revocable instantly.
Does Folio have a developer API and MCP server?
Yes. Folio ships a v1 REST API that reads and writes your portfolio and career data using scoped API keys, plus an MCP server so AI assistants and automations can read and write that data for you. Documentation, key management, and setup are on the Folio developer platform at /developers.
What is a good automation pattern for a portfolio?
Keep one source of truth for your data, create a scoped key for each job, read the current state before you write, and make writes idempotent so running twice is safe. Then schedule a sync so your portfolio never lags your work and a read-only pull for backups. Hand the updates that are easier described than scripted to an assistant over MCP.