Use these prompts to guide your initial exploration of working with the Fullcast Model Context Protocol (MCP) server.
Before you begin
The Fullcast MCP server must be turned on in your tenant. If this toggle is off, the MCP cannot connect with Fullcast.
Your artificial intelligence (AI) client is connected to the Fullcast MCP URL and you have authenticated by logging in to Fullcast. Your admin may need to give you the URL, and some organizations require a security review before the MCP can be enabled in an AI client.
You know what your role-based access control (RBAC) permissions cover. The MCP acts as you. If you cannot do something in the Fullcast user interface (UI), you cannot do it through the MCP.
How to use this library
Every prompt carries a label. Read-only prompts return information and change nothing. Write prompts create, change, or end records in Fullcast.
Write actions stay inside Fullcast. Your normal import and export jobs still move data to and from Salesforce — the MCP does not write to Salesforce.
Start with the read-only prompts in Get oriented and Reporting and analysis. Move to write prompts once you have seen the shape of the answers you get back.
While you are building confidence, run a write prompt and then confirm the result in the Fullcast UI. Proposed changes show up attributed to you, because the MCP is signed in as you.
These are starting points, not scripts. Short, open prompts surface gaps in your data and in your own thinking faster than long, precise ones. Get specific after you know what you want.
Get oriented
See what the MCP can do
Read-only. You have just connected and you want to know the surface area before you start asking for work. Replace [territory management] in the starter prompt with any capability.
List every tool you have available for [territory management] in the Fullcast MCP, along with example use cases. Give me this in bullet points.Teach the AI and MCP your business terminology
Read-only. Your team uses its own words for go-to-market, which have organizational nuance beyond “standard” go-to-market terms; you want the model to appropriately interpret your asks and leverage the best Fullcast functionality for the task.
Interview me about my internal processes and business terms so we can create a memory doc, so that when I ask you to do things you understand what I am asking for based on my terms.Tip: The MCP includes a set of topics tools that already teach the model Fullcast terms, definitions, and the relationships between them.
Print your go-to-market strategy
Read-only. A stakeholder outside revenue operations asks what the go-to-market plan actually is, and the answer currently lives across a dozen screens.
Produce a document that describes our go-to-market strategy as currently deployed in Fullcast: the territory hierarchy, the coverage model, and the targets attached to each node. Write it for business stakeholders who do not use Fullcast. Deliver it as an HTML file.Tip: This is the safest place to start. It is entirely read-only and it produces something you can circulate the same day.
Reporting and analysis
Analyze unassigned accounts and prioritize data enrichment
Read-only. Accounts are sitting in Unassigned. Some are there because of missing data and some because you have no territory that covers them, and you cannot tell which is which.
Do a full analysis of all accounts in the Unassigned node. I want to figure out where to prioritize data enrichment and whether any key go-to-market territories are missing. Deliver the analysis as an HTML file that is easy to read and act on.Tip: Three sentences produced a full report in the demo: total accounts unassigned, aggregate bookings potential at risk, the single dominant root cause (96 percent were missing billing country), and a recommended enrichment sequence. Ask for HTML — long text blocks are hard to act on.
Report on territory balance and composition
Read-only. Before a planning cycle you want to know whether territories in one region are actually balanced, without exporting and pivoting.
Give me a report on the balance of the territories in [REGION]. Show account count, bookings potential, and composition by segment for each territory, and flag any territory that is a clear outlier.Measure the disruption from a rule change
Read-only. You changed segmentation rules and need to know how much movement you just created before you commit it.
What is the impact of the changes I made to the rules in [REGION]? Measure proposed versus current account counts in each territory and display it as a chart.Report on who covers which territories
Read-only. A manager asks for the current coverage picture for a specific month, including partial-month changes.
Give me a list of all account executives (AEs) covering which territories in [MONTH YEAR]. Include the full territory breadcrumb and flag anyone who does not cover the whole month.Tip: Ask for the breadcrumb and the partial-month flag explicitly. Without them you get a list that looks complete and hides the mid-month changes, which are the ones that cause disputes.
Territories
Recommend rules for a new territory
Read-only. You know you want a new segment or vertical territory but you do not yet know what the rule should be, because you have not looked at the underlying data distribution.
Under the [PARENT TERRITORY] territory we want to add a [SEGMENT] territory and a [INDUSTRY] vertical. Inspect the data first and recommend what the rule should be for each.Sweep for stale proposed changes
Read-only. Proposed changes that never get committed do not export, and they do not go away either. They sit indefinitely and quietly distort what the plan looks like.
Find every proposed but uncommitted change in this plan. Group them by who proposed them and how old they are, and tell me which ones look abandoned.Tip: Worth running before every scheduled export. Reviews of live tenants have turned up account moves still sitting in a proposed state more than a year after they were created.
Audit named accounts before a rules rerun
Read-only. Named accounts and named exceptions are pinned and will not move, even when a rule says they should. An unnoticed pin makes a rebalance look broken when it is working as designed.
List every named account and named exception in [PLAN OR TERRITORY] before I rerun the segmentation rules, and tell me which pins look stale.Look up geographic coverage for a new location
Read-only. You are hiring into a new metro and need to know whether an existing geographic territory already covers it before you carve a new one.
Which territory currently covers [ZIP CODE, CITY, OR COUNTY]? If more than one geographic level applies, show me each one.Model a rebalance before you commit it
Write. Leadership wants to see a rebalanced plan with new headcount before anything touches the live CRM.
Rebalance the smart territories under [PARENT TERRITORY] for [N] reps. Leave the changes proposed, then show me a before-and-after comparison of account count and bookings potential per territory. Do not commit anything until I say so.Tip: Rebalancing writes proposed state. Nothing exports until you commit, and you can undo before you commit.
Design a plan from scratch
Read-only. You are starting a new plan with no territories and want a first draft to react to rather than a blank canvas.
I have a new plan with no territories. Look at the account data available and tell me what go-to-market structure you would build, and why. Do not create anything yet.Account placement
Move one account
Write. A single account is in the wrong territory and needs to move.
Move [ACCOUNT NAME] to [TERRITORY]. Tell me what happens to its child accounts and whether there are already uncommitted changes on it, then wait for me to confirm before you commit.Tip: In the demo the MCP surfaced an uncommitted move already sitting on the account from an earlier action, checked for subsidiaries, proposed the change, and asked before committing.
Move a list of accounts from a spreadsheet
Write. You have a hundred accounts to place and no interest in doing them one at a time.
Here is a spreadsheet of account moves. The columns are account identifier and target territory. Check my plan rules for how child accounts should be handled in each destination, then propose all of the moves and give me a summary table to review before anything commits.Tip: Label your columns clearly. The comma-separated values (CSV) upload in the Fullcast UI does the same job — which path you use is a workflow preference, not a capability difference.
Consolidate an account family
Write. After an acquisition or a hierarchy update, one corporate family is split across territories and reps, and you want it unified before the next renewal cycle.
Analyze the [PARENT COMPANY] corporate family and its coverage. Show me every territory the family touches and who covers each part, then propose a consolidation under a single owner. Do not commit until I confirm.Tip: Add "and coverage" to any family analysis. It changes the answer from where accounts sit to who is actually working them — and in the demo it surfaced entities that did not roll up to the parent correctly, unprompted.
Explain why an account is where it is
Read-only. A rep disputes an account placement and you would rather not trace the rule chain by hand.
Why did [ACCOUNT NAME] land in the territory it is in? Walk me through the specific rule or exception that placed it.Tip: Placement explanation works best on accounts placed by an active rule. For an account that was placed directly with no rule chain, use the account history prompt below instead.
Trace the full history of an account
Read-only. An account has been moved manually, had rules rerun over it, and been committed by more than one person. Reconstructing that by hand is close to impossible.
Tell me what has happened with [ACCOUNT NAME]. How did it get into the territory it is in today? Include each manual action, who took it, when, and whether any rule rerun overrode a manual placement. Flag any entry you could not fully explain.The same prompt works across a set of accounts:
Here is a spreadsheet of accounts. For each one, tell me how it got into its current territory and flag any where a rule rerun overrode a manual placement.Tip: Audit logs hold 90 days of history. If you use routing logic in the managed package, you can send policy status to the audit log through Metadata Settings — CX can turn this on for you, and it makes placement history considerably richer.
Coverage and assignments
Find coverage gaps
Read-only. You need to know which territories have no one on them before a commission cycle or a quarter start.
Which territories do not have account executive (AE) coverage right now? Include the territory breadcrumb and any target attached to each uncovered node.Create a coverage assignment
Write. A rep is picking up a territory next week.
Assign [PERSON] to [TERRITORY] as an [ROLE], starting [DATE].Tip: Name the role. Without it you will be asked which role you mean every time. If your team almost always means the same role, put that default in your project instructions or a skill instead of repeating it.
End coverage for a transfer
Write. A rep is moving to a new territory and you do not want a gap in the old one — or a silent gap in the new one.
End coverage for [PERSON] in [TERRITORY]. Keep coverage continuous with their new assignment, tell me what happens to any target attached to the node, and tell me if the territory will be left uncovered.Tip: In the demo this recommended an end date the day before the new assignment began, then flagged that the vacated territory would be left with no AE and asked how to handle it.
Make bulk coverage changes from a spreadsheet
Write. A reorganization produced dozens of assignment changes at once.
Here is a spreadsheet of coverage changes. The columns are person, territory, role, start date, and end date. Walk me through what you are about to do, then execute them and give me a confirmation table.Tip: This is the single highest-value first write prompt for most teams. Individual coverage tools are one person, one seat per call — the model handles the repetition for you. If the reorganization also moves people between teams, handle targets separately: a bulk team move leaves every target untouched by default.
Inventory a departure before you decide anything
Read-only. Someone is leaving and their book has to be handed off across a manager and several teammates. There is no default split rule, and you do not want one invented for you.
List every active assignment held by [PERSON], and for each node and role, every target attached to it. Include the territory breadcrumb and the target value. Present it as a table with an empty column for who takes over. Do not propose a split — I will decide seat by seat.Tip: This is the pattern worth encoding as a skill. The model inventories and structures the decision, a human makes it, and the model then executes exactly that decision. Ask for targets by node and role rather than by person — targets are role-mediated, so a query framed around a person can come back empty even where a quota exists.
Cover a leave of absence
Write. A rep is going on leave of absence (LOA) and their coverage needs to revert to them when they come back.
Set up temporary coverage across every assignment held by [PERSON], from [START DATE] to [RETURN DATE], with [COVERING PERSON] on each seat. Confirm each one back to me with the return date.Tip: Nothing reverts automatically on the return date. Put a reminder on your own calendar, or schedule a prompt that checks for expiring temporary coverage each week.
Confirm a new hire into an open seat
Write. A to-be-hired (TBH) placeholder has become a real person.
End the [TBH PLACEHOLDER] assignment on [TERRITORY] the day before [NEW HIRE] starts, then create the assignment for [NEW HIRE] starting [START DATE] and resolve the matching ramp profile. Show me both steps before you run them.Tip: There is no single confirm-new-hire tool in the MCP. It is an end-then-create pair, which is exactly why it is a good candidate for a skill.
Targets
Note: Target reading and relief work through the MCP. Creating targets, distributing top-down, rolling up bottom-up, applying schedules and ramps, and setting minimums are UI-only today. Analysis, auditing, and relief are where the MCP earns its keep on targets.
Check quarterly pacing
Read-only. Before a quarterly business review (QBR) or forecast call you want to know who is behind pace without pulling a manual report.
Which targets are behind pace for the current fiscal quarter? Rank them by how far off track they are and show attainment to date against expected pacing.Check average attainment against a target
Read-only. A leader asks how the team is tracking against one specific quota.
What is the average attainment of reps against the [TARGET NAME] target? Show the distribution, not just the average.Sanity-check quotas before a comp run
Read-only. You are about to run a compensation period and you do not want to pay against a broken quota.
Before I run [COMP PLAN] for [PERIOD], check that every target feeding it has a current owner and a non-zero value. Give me a punch list of what to fix.Build a cross-year quota trend
Read-only. A leader wants to see how a rep’s quota and attainment moved across the last two or three fiscal years. Fullcast does not do this natively, because target identifiers do not persist across years by design.
Show me how quota and attainment for [PERSON OR ROLE] moved across fiscal years [YEAR] through [YEAR]. Match the series across years and tell me what you matched on.Tip: Ask what it matched on. Stitching years together requires matching on the actuals metric plus role or person, and you want to see that reasoning rather than trust it.
Commissions
Explain what a rep was paid on one deal
Read-only. A rep asks why they got paid what they did on a specific deal. You need the full deal-level story — every component, the rate, the tier, any true-up — not just a number.
Walk me through everything [PERSON] was paid on the [ACCOUNT] deal — every component, the rate and tier, and call out anything still pending versus committed.Tip: The answer comes back in the language defined in your own comp plan, including the quota trajectory and which attainment tier the deal landed in.
Rank the top-earning deals for one rep
Read-only. A comp review or QBR where you want to see which deals actually drove earnings this period.
Show me the top 10 deals that contributed to commissions for [PERSON], ranked by amount, with the account name for each. Tell me explicitly which rows are committed and which are still pending, and flag any deal missing an account identifier.Tip: Ask for the commit status. Earned, committed, and paid are three different things, and a table headed "amount paid" can be wrong in a way that is easy to miss. Flagging missing account identifiers here catches data problems before payroll rather than after.
Explain a single ledger entry
Read-only. A line on the ledger looks wrong, or someone asks you to justify it. You need the math behind one entry.
In the [COMP PLAN] plan, explain how the [ROLE] override for [PERSON] on the [ACCOUNT] deal was calculated — the rate, the commissionable amount, and which attainment tier it landed in.Tip: Ask for attainment before and after the deal — the progression is what answers the real question behind most of these requests, which is where the next deal puts someone against an accelerator. Also ask whether the explanation is derived or calculated. A derived explanation reconstructs the math from stored values and ties out, but it is not an engine trace, so do not present it as a full audit trail.
Measure draw liability across the team
Read-only. Finance needs to know the outstanding draw exposure — who is carrying an unrecovered advance and how much.
What is our total outstanding draw liability on [COMP PLAN], broken down by person and split between recoverable advances and non-recoverable guarantees?Tip: Ask how many periods have actually been processed. A recovery projection built on three processed periods out of 12 is a shape, not a number.
Review credit on large deals
Read-only. Finance wants to stay ahead of credit inflation — people adding colleagues to deals so they pick up commission.
Find all deals with an opportunity amount over [AMOUNT] and tell me everyone being credited on each one. Pull in the relevant deal, crediting, and commission data. My goal is to make sure we are not over-crediting.Tip: Before you accept an answer that says a role receives no credit anywhere, ask which plan the crediting rules were read from. Ledgers span plans, and crediting objects do not always live where you expect.
Data quality, audit, and troubleshooting
Check whether your jobs are running
Read-only. Something downstream looks stale and you want to know whether an integration has been quietly failing.
Are my import and export jobs working? Show me the most recent failures and what they point to.Tip: In the demo this returned a set of failures nobody had gone looking for, with timestamps and error detail.
Get a daily job report
Read-only. You want integration failures to find you rather than the other way around.
Every morning, tell me what happened to my import and export jobs in the last 24 hours. Flag any failure and what it points to. Keep it short.Tip: Set this up as a scheduled run in your AI client rather than typing it each day.
Review proposed changes each morning
Read-only. You are the person who has to approve changes, and you would rather start the day with a list than go looking for one.
Every morning, tell me what has been proposed in the last 24 hours: how many accounts are in a proposed state, which territories they are proposed into, who proposed them, and what I need to review today.Trace what one person did
Read-only. You need an activity trail for a specific user, for an access review or because something changed and nobody knows who changed it.
Tell me everything [PERSON] did in this tenant over the last [N] days. Report timestamps in [TIME ZONE].Tip: Timestamps come back in coordinated universal time (UTC) by default. Ask for your own time zone, or put it in your project instructions once. If a timestamp does not line up with what the Fullcast UI shows, raise it with support rather than assuming the MCP value is wrong.
Scan the audit log for anything unusual
Read-only. A periodic security or governance review.
Review the audit log for the last [N] days and tell me anything that looks unusual — bulk changes, actions outside normal hours, or activity by a user who does not normally make changes here. Tell me if any entries came back without a full explanation.Tip: Not every event type returns a detailed explanation yet — some come back as a generic entry. Ask which ones did, so you know what the scan could not read.
Follow-up turns that improve almost any answer
The second prompt is usually where the value is. These are worth keeping close:
Put this in an HTML file that is easy to read. Summarize it for me and show me charts.
Which plan did each of these results actually come from?
What will happen if I commit this?
Show me the list first, then wait for me to confirm.
Create a summary table with [columns] and an empty column for notes.
How can you confirm that this is the amount actually paid?
Only commit the [subset] — leave the rest proposed.
Tell me what I need to do to make that change.
Be more concise. Cut the preamble.
What the MCP does not do today
Knowing the edges saves you from writing prompts against capabilities that are not there:
No Salesforce writes. Changes land in Fullcast. Your normal import and export jobs move data downstream, unchanged.
No source data cleanup. If a field is wrong because it is wrong in the source system, that is where it gets fixed. The MCP tells you where to go look.
Comp plan configuration is not writable. You can run and commit comp engines through the MCP, but editing plan configuration happens in the UI.
Most target operations are UI-only. Reading targets and applying relief work. Creating, distributing, rolling up, scheduling, and setting minimums do not.
Coverage changes commit immediately. Assignment creation, ending coverage, end-date changes, and role changes all take effect the moment they are called — there is no proposed state to review first. Team membership moves are the exception and default to proposed.
Audit history covers 90 days. For placement questions further back than that, ask for account, people, or product history instead — those cover a longer window and answer where a record sat on a given date.
Commits are irreversible. There is no uncommit. Undo works only before a commit.
Plan state is not a guardrail. The MCP knows which plans are in draft, but it will act in any plan you point it at. If you want that restricted, put it in your project instructions.