In our last article, we walked through how to set up the Marketo MCP server connection. Getting that connection live is a real milestone. Once it’s working, your AI can reach into Marketo and start doing actual work like reading folders, cloning programs, pulling lead records, and updating tokens.

But there’s a catch that trips up a lot of teams.

Being able to reach your instance is not the same as understanding it.

An MCP connection hands your AI the keys to the Marketo API. It gains access. But what it doesn’t gain is any sense of how your instance is built, or why it’s built that way. And as every Marketo admin knows, no two instances are alike.

Think about everything that makes yours different from the next:

Folder structure 

Some teams organize Marketing Activities by year, others by region, others by workspace. You’ve got templates folders, archive folders, and that one folder structure only the person who built it fully understands. An AI has no way of knowing where things are supposed to live.

Naming conventions 

Program names, asset names, smart campaign names. These patterns are usually carried around in people’s heads, rarely written down, and often inconsistent even within the same team.

Channels and statuses 

Channels are custom to each instance. One company’s “Webinar” channel runs Invited > Registered > Attended > Attended On-demand. The next company defines completely different statuses and a different bar for what counts as success.

Templates 

Which programs are the official ones to clone from? And which are abandoned drafts that just look like templates? The API can’t tell the difference.

Lead fields

Instances pile up hundreds of fields over the years. Only a fraction are actually in use. Some are deprecated, some sit empty, and a handful of custom fields are the ones that really matter.

Integrations 

Salesforce, your webinar platform, enrichment tools. Each connection comes with its own rules about what should and shouldn’t be touched.

Tokens

Which my.tokens are standard on your programs, what they map to, and what their default values are.

None of that is visible from the API alone. The instance context is what bridges the gap between a generic AI and an AI that operates like a member of your team.

How Instance Context Makes a Difference

The fastest way to see why this matters is to watch what happens when the context isn’t there. Below, we’ll look at two simple request examples and what will happen if the AI has instance context vs. no instance context.

Example A: “Create a webinar program.”

Without instance context, the AI might:

• Clone from the wrong program, grabbing some random old webinar instead of your official template
• Build a program from scratch using the wrong channel, like a generic “Email Send” channel for what should be a webinar
• Drop it in the wrong folder, or worse, the root of Marketing Activities
• Ignore your naming convention completely
• Leave every template token sitting at its placeholder default

With instance context, the same prompt produces something usable:

The AI clones the correct template, places it in the right year and type folder, follows your naming pattern, sets the proper channel, and fills in the tokens you expect.

Same request, completely different result.

Example B: “Pull information about this lead.”

Without context, the AI might:

• Read from the wrong fields, like a deprecated scoring field instead of the live one
• Return empty or stale values and present them as the answer
• Skip the fields that actually matter for the question, like lifecycle stage or ICP fit

With context, it knows which fields are the source of truth, which ones are dead weight, and which ones to report on for the question you actually asked.

These failures happen when the AI is uninformed. Any new hire would make these exact mistakes on day one without someone to show them the ropes. Think of “instance context” as that onboarding doc. You wouldn’t drop a new teammate into your instance with zero guidance and expect clean work, and the same logic applies here.

What a Good Instance Context Looks Like

A solid instance context is a single, structured reference document that your AI reads before it does any work. Think of it as the employee handbook for your instance. Let’s walk through what belongs in it and why each piece earns its place.

1) Instance details

The instance URL, workspaces, lead partitions, and primary timezone all anchor everything else. The timezone alone saves you from a pile of scheduling mistakes.

2) Folder structure

A tree of the relevant folders with their IDs, plus two maps: which template programs exist (name, type, ID, channel) and which destination folder each program type belongs in. The IDs are what make the AI’s work deterministic instead of guesswork.

3) Naming conventions

The naming pattern for each program type, pulled from real programs in your instance. This keeps AI-created assets indistinguishable from the ones your team builds by hand, which protects your reporting and keeps everything searchable.

4) Channels and program statuses

Each channel, which program types use it, the full status progression, and which statuses count as success. If you get the channel wrong, you’ll break reporting and lifecycle tracking for that program from then on.

5) Token standards

The tokens on each template, their types, and their default values. The AI needs to know which tokens have to be filled and what a “still set to default” placeholder looks like so it doesn’t ship one.

6) Email program configuration

The clone-and-configure workflow spelled out step by step, plus default sender info like from name, from email, and reply-to. This captures how your team actually works, not just what your assets contain.

7) Lead and list configuration

These are the custom fields that matter, grouped by purpose (lifecycle and scoring, stage dates, firmographic and segmentation), along with your suppression and compliance lists. This is the direct fix for the “wrong-fields” problem from Example B above, and the suppression lists act as a compliance safety net that the AI should never skip.

8) CRM integration

Your sync rules, and a clear statement of what the AI should and shouldn’t touch. Changes in Marketo ripple straight into Salesforce, so the AI needs to understand this domino effect before it does anything.

9) Scheduling and operations rules

Send windows, blackout dates, and frequency caps. These are basically “human judgment” things written down as rules, so your AI never tries to schedule a 3am send on a Saturday.

10) Audit and QA standards

Define what your severity levels mean and what gets flagged. This sets the quality bar in writing instead of leaving it to chance.

11) Tags and reporting

Your tag types, which ones are required, and which program types they apply to. A missing required tag won’t throw an error, it’ll just quietly break your reporting downstream.

12) Integration notes

Webinar platforms, enrichment tools, and anything else connected to the instance. Programs often lean on external systems that the API simply can’t reveal on its own.

13) QA instructions

This one might be the most valuable section of all. It splits every check into two lists.

The first covers what the API can verify automatically. Such as:

• The program exists
• It’s in the right folder
• It uses the right channel
• The name matches your convention
• The tokens are filled
• The email is approved
• The smart list has rules

The second covers what still needs a human:

• Rendering across email clients
• Personalization fallbacks
• Whether the smart list logic targets the right audience,
• Send volume
• Timezone fit
• Legal compliance
• A/B setup

Laying it out this way makes the division of labor explicit. The AI can self-check everything on the automated list, and your team knows exactly which checks are still theirs to own.

Practical Considerations

Now, let’s touch on a few practical things worth knowing about this “instance context” document.

It’s meant to be constantly evolving, not static. You can generate and refresh it by pulling live data straight from the Marketo API. We’ve actually built a skill that does exactly this: it reads your folders, channels, programs, tokens, fields, and tags through the MCP and merges them into the document for you.

Smart merging is what makes that work. The API-sourced sections get refreshed automatically because they’re the parts that go stale. The human-written sections, like your scheduling rules, compliance notes, and integration decisions, stay put because they capture decisions rather than data (you don’t want an automated refresh wiping out the judgment calls your team made).

And don’t be put off by placeholders like [NOT CONFIGURED] or NEEDS TEAM INPUT. Those are features, not flaws. They make the gaps visible and prompt the right conversation, instead of letting a blind spot sit quietly until it causes a problem.

It’s Not a Document, It’s a Practice

Building the instance context is the first step, but the real payoff comes from how your team uses and maintains it. A great context that lives in one person’s chat history isn’t doing much for the rest of your organization.

Here’s how to get value out of it over time.

Share it with the whole team. It should live in a central repository everyone can reach, not buried in a local folder or one teammate’s previous AI conversations. Everyone working against the instance should be using the same context; in their chats, in their projects, etc.

Keep it current. Always stamp it with a “last updated” date, and ideally a “last refreshed from API” date too. Set a routine: refresh on a schedule and again after any meaningful change to the instance, such as a new channel, a new template, a field change, or a new integration.

Enforce consistent usage. The context only helps if it’s actually attached to the work. Make “AI work uses the instance context” a team norm, the same way “programs follow the naming convention” is already a norm for you.

Audit against it. Every so often, check the Marketo audit trail for activity happening outside the rules the context defines: programs created in the wrong folders, off-convention names, channels showing up where they shouldn’t. This catches drift from both your AI and your humans, and it tells you whether the context needs an update or the behavior does.

So there you have it!

Instance context is what turns AI from a clever tool into a governed teammate.

The teams that get the most from the Marketo MCP server connection will be the ones with the best instance context implementation.

As mentioned before, the “Instance Context” Claude skill we designed will be a huge help. It reads your folders, channels, programs, tokens, fields, and tags through the MCP server and merges them into the instance context document for you.

You can download that for free here: