Tool Packs and Safe Exposure
Four curated tool packs ship — casework, CRM, documents and ERP — alongside the generic datastore tools.
Where to find it
Which packs a credential may use is set on the credential itself, in the MCP datastore opened from All Datastores.
What the packs contain
- Casework — finding cases, reading their state, and the operations a case handler would recognise.
- CRM — contacts, organisations and pipeline enquiries.
- Documents — locating and reading documents, including extracted text.
- ERP — ledger, stock and document enquiries expressed in ERP terms.
Each pack is a handful of well-named tools rather than dozens, which is deliberate.
Expose the smallest useful surface
Every tool you expose is something a model may attempt to use. A narrow, clearly named set produces markedly better results than everything at once, because the model is choosing from a shorter list of less ambiguous options.
This is a quality argument as much as a security one. Models pick badly from long menus, and a wrong tool choice produces a confident wrong answer.
Prefer curated packs to generic access
A pack expresses operations at the level the module works at, which is safer as well as more effective. An operation meaning "post a journal" carries the ledger's own rules with it — balancing, period checks, immutability. Raw write access to the journal table carries none of them.
Think about the blast radius before granting write
Ask what the worst plausible outcome is if a model misinterprets an instruction.
- Creating a duplicate contact is recoverable in a minute.
- Posting to the ledger is a reversing entry and an awkward conversation.
- Sending messages to service users cannot be recalled.
- Disposing of records cannot be undone at all.
The last two deserve either read-only exposure or a human approval step in between — and the approvals mechanism already exists for exactly this.
Watch what is actually called
Review the call log after enabling a client, particularly in the first fortnight. It tells you which tools are being used and how — the fastest way to spot both a tool being misused and a tool you exposed that nothing ever touches. Remove the latter.
Personal data leaves the building
Data reaching a model reaches whoever operates that model. Check where the provider processes it, what they retain, and whether that is compatible with what you told people in your privacy notice.
This is a data protection decision as much as a technical one, and it belongs with whoever owns that in your organisation — not with whoever is configuring the credential. For casework data in particular, get it in writing before you enable anything.
Worked example
A housing team exposes the casework pack read-only to an assistant used by the duty desk. Documents are deliberately not exposed, because tenancy files contain third-party information the team does not want summarised by an external model. When the team later wants case notes drafted, they add write access to a single notes datastore rather than the whole pack.
Recommendations
- Start with one pack. Add a second only when something concrete needs it.
- Never expose a pack "to see what it does" on production.
- Put approvals in front of anything irreversible.
- Re-read the call log monthly once it is live.