MCP: your team’s assistant, on your own records.
Connect the assistant your agency approved. It signs in as the consultant, reads the records they can open, and leaves the work waiting for a check.

An illustration of the kind of request. The assistant asks Talisman, and that consultant’s own candidate records come back.
Your team already works this way
Somebody on your desk is using ChatGPT today.
They paste in the CV. They paste in the job spec. The answer lands in a chat window and stops there.
Connect that assistant and every action a consultant takes becomes one it can call. Talisman publishes those actions as MCP tools, the open protocol assistants speak.
So the same CV goes in, and a candidate record comes back with the job linked and the compliance check already running.

Ask in your own words, against your own records
| What somebody asks | What comes back |
|---|---|
| Three drivers free on Thursday, cleared for that site | A shortlist with availability and the checks on each worker, waiting for the consultant’s yes |
| What has happened on this client since March | A summary with the dates, the jobs and the people named in it |
| Draft the message to every worker whose DBS expires next month | A draft per worker, in the wording you approved, each one waiting for a send |
| Which of my perm roles is sitting at offer, and for how long | The candidate, the client and the day it reached offer, in one list |
| Which of my jobs still has a shift open for tomorrow | The open shifts, the client and the hours, in one list |
One question, from the chat window to the record
Your consultant
Their assistant
Talisman
- Your consultantAsks for the shortlistIn the assistant they already use
- Their assistantCalls Talisman as that consultantStraight to the live recordsChatGPT or Claude
- TalismanThe sign-in behind itChecked on every call
- TalismanAnswers with what they may openThat desk’s candidates, jobs and bookings
- TalismanAnything that changes a recordComes back as a draft
- Your consultantSays yes, and it landsOn the record, in their name
One ask, 100 candidates
That diagram is one shortlist. Here is the ceiling.
A consultant asks for an email to all 100 candidates on a job. In their voice. Asking each one whether the role interests them, and asking for an updated CV.
A hundred drafts come back, one per candidate, each written from what Talisman already holds on that person — the last conversation, the ticket that expires in April, the town they live in. The consultant reads them, says yes, and the hundred go out in their name.
Every reply lands on the candidate’s record. Every fresh CV lands with it.

How you connect it
One sign-in, in the assistant your agency already uses.
You add Talisman as a connector and authorise it once, in your browser. From then on it runs as you, with your permissions.
Connecting is one sign-in. Agreeing what it may draft takes longer.
- ChatGPT, Microsoft Copilot and Claude, where your agency has approved them.
- Any client that speaks MCP, including the agent frameworks your team tries.
- The same Talisman records behind whichever assistant you settle on.
What the connection carries
- The person who authorised it, by name
- That person’s permissions, on every call
- The records that person may open
- A run history a manager can read back
MCP access is included in the Talisman Platform, across the modules you have switched on.
MCP FAQ
What can the assistant see?
Exactly what the person who authorised the connection sees. Every call carries that user’s permissions. A consultant’s assistant reaches that consultant’s candidates, jobs, bookings and documents.
Where do the records live?
In Talisman. The assistant works the live candidate, contact, client, job and booking records your team already keeps. So the answer comes back with the job number, the worker and the date on it.
Can we write our own agents against it?
Yes. The tools your team’s assistant calls are open to code you write, in Python, TypeScript or any language with an MCP library. Your agent authorises as a real user and leaves the same run history.
How do we know what it did?
The run history. Every request, the records it read and how far it got are written under the name of the person behind the connection. Anything that would change a record waits there as a draft for them to approve.
Point an assistant at your own records
The session runs on your own desks, with an assistant signed in as a named user.




