How to turn your expertise into an MCP, without writing code

Start with one field where you make repeated decisions: project pricing, product scope, contract terms, or another part of your work you can explain. You need records of what you decided and why, and permission to use them.

This guide follows avva Studio from choosing that material to publishing a Decision Model. Your own AI does the extraction and drafting. You review the decisions before they leave your side, then review the model before publishing. No code is required.

What an MCP is, in one paragraph

MCP (Model Context Protocol) is the standard way an AI assistant reaches tools and data outside its own chat. Claude, ChatGPT, Cursor, and most agent frameworks support it. Once an MCP is connected, the assistant can call it in the middle of a conversation, read what comes back, and use it in its answer. Most MCPs connect assistants to software: a calendar, a database, a code repository. The one you will build connects them to your judgment.

What goes into it

Gather decisions you have already made, with the reasons attached:

• The situation. What was on the table, in general terms.
• The decision. What you decided.
• The reason. Why, in your words. This is the part that transfers to new cases.
• What would have changed it. The condition under which you would have gone the other way.

Keep the field and time period explicit. Include ordinary decisions as well as unusual ones, and cases where you chose differently. A collection containing only exceptions can give a misleading picture of your usual practice.

From those decisions the model records what you weigh first, where you stop, what flips your usual answer, and what you ask before deciding. When an assistant checks it, it gets the published model and its approved cases. The assistant checks which decisions apply to the new question; it should not copy an old answer without checking the circumstances.

Where the decisions come from

You probably have them already, scattered across:

• emails and messages where you explained a decision to a client or a colleague;
• proposals you accepted or turned down, with your notes;
• post-mortems, review comments, or meeting notes;
• the answer you give every time someone asks you the same question.

What to leave out is just as concrete: personal data about other people, material that belongs to a client or employer, anything under NDA, credentials, and figures that identify a specific deal. A threshold you apply (“we do not discount below 20%”) is fine; the name of the client it came from is not.

The steps

1. Connect avva Studio to your own assistant

Studio is itself an MCP. You add it to Claude or ChatGPT the way you would add any other connector. From then on, your assistant does the reading and drafting, on your side.

2. Point your assistant at your material

It goes through what you give it and drafts candidate decisions in the shape above. Your sources stay with your assistant; they are not sent to avva.

3. Read every record and approve what is right

You see each candidate in full before anything leaves your side. Fix the wording, drop what you would not stand behind, and supply missing reasons yourself. A plausible guess is not a record of why you decided. Leave out a decision if you cannot verify it.

4. Let your assistant build the model

From the approved decisions it writes the structure: what you weigh, where you stop, and what changes the answer. You read that back too.

5. Publish

The published model carries the decisions in general terms, and source quotes never publish. A new model starts private. When you open it to everyone, it gets a public page and an address that anyone’s assistant can connect to.

Sign in to claim ownership. Publication currently requires a beta invitation and is free, with no card. Paid access is not available.

What it looks like from the other side

In avva’s composite studio example, a client asks for rights to everything created, including rejected concepts and internal tools. The model’s decision is to transfer delivered, paid work while retaining rejected concepts and reusable tools.

After connecting the model, try two reading checks:

• Ask which rights you should transfer in your contract. Does the assistant distinguish delivered work from internal tools, cite the model, and ask about missing terms?
• Ask a question outside the model’s field. Does it identify the gap rather than invent the author’s position?

Review the answers yourself. These checks are not a measured improvement over an unconnected assistant or legal advice.

Is your expertise a good fit

It works best when:

• your field involves repeated judgment calls, not one-off facts;
• you can explain why you decided, not only what;
• other people regularly ask you, or people like you, the same kinds of questions.

Pricing, hiring, product scope, contract terms, operations, and client management all fit. Pure lookup knowledge, like a tax rate or an API parameter, does not need a model of anyone’s judgment.

Start

If you want to try it, open avva Studio. The first step asks only for a public name and the field the model covers, and no account is needed until you publish.