Working with MCP tools

Once an assistant is connected, it drives Casewhere through a catalog of MCP tools that mirror the configuration model. You rarely call tools by name — you describe what you want and the assistant selects them — but understanding how the catalog is organized helps you give better instructions and review changes with confidence.

Guide-first workflow

The MCP server ships the Casewhere platform guides and makes them searchable. Well-behaved assistants are instructed (via the workspace AGENTS.md) to read the relevant guide before creating or editing a resource, so generated configuration follows platform conventions.

• SearchGuide — hybrid keyword + semantic search across all guides
• ReadGuide — read a specific guide (start from the guide://index map)

If an assistant produces something that doesn't match your conventions, asking it to "search the guide first" usually corrects the approach.

Tool naming conventions

Tools follow consistent verb prefixes across every domain, so behavior is predictable:

Prefix	Behavior
Search*	Paginated search for resources (usually filtered by product)
Get*	Read the full edit model of one resource — called before any edit
Create*	Create a new resource
Edit*	Full replace of a resource (see below)
Delete*	Delete a resource
Rename*	Rename and update references
Move*ToProduct	Move a resource into another product
Build*	Compile a workflow or rule and report the build status
Run*	Execute a workflow test

Edit semantics: read before you edit

Most Edit* tools are full-replace: they overwrite the entire resource with what is supplied, so any field that is omitted is reset or removed. This is why the assistant calls the matching Get* tool first, modifies the returned model, and sends the whole thing back.

For surgical changes, several domains provide single-slice tools that change one part and preserve the rest — prefer these when you only need a small change:

• Data classes — AddDataClassAttribute / UpdateDataClassAttribute instead of a full EditDataClass
• Form activities — AddFormComponent, UpdateFormComponent, UpdateFormNavigationButtons, and so on, instead of a full EditFormActivityDefinition
• Activities — UpdateActivityInclusionRule, UpdateActivityRequireRule, UpdateActivityTransactionSettings

When you ask for a change to an existing resource, it is good practice to have the assistant summarize what it will replace before it runs an Edit* tool — especially for large resources such as data classes and forms.

Tool catalog

The catalog covers the full configuration model. The table groups the main tool families by area; each family typically includes the search/get/create/edit/delete tools described above.

Area	Tool families
Foundation	Connectivity (PingCasewhere), guides (SearchGuide, ReadGuide), large-response chunking
Solution & content	Product, Process, DevOps package, Text resource, Language, Document
Data	Data class and attributes, Data source, list-component data source
Workflow	Workflow definition, steps, activities (Form, Scripted, Workflow, Loop, Stop), workflow variables, workflow-definition data sources
UI	Page, Widget and actions, Grid / List / Custom / Tab container / Workflow container widgets, Worker site, Theme
Automation & security	Rule and rule assignments, Event trigger, Web trigger, Scheduler, IdP connection (SAML 2.0)
Testing	Workflow tests and test settings

Two conventions worth knowing when you read an assistant's plan:

• Products come first. Every resource lives in a product, so a new solution starts by creating (or selecting) a product, and most searches are scoped by product.
• Build after changing logic. After creating or editing a workflow or rule, the assistant compiles it with a Build* tool and checks the result before moving on.

Large responses are chunked automatically

Some resources (full form designs, long guides) are too large for a single MCP message. The server splits these into chunks and the assistant reassembles them transparently — you don't need to do anything. If a chunked read ever times out, simply ask the assistant to retry the operation.

Safety and good practices

• The token is your identity. Everything an assistant does is authorized and audited as you. Don't share a token, and revoke it if it leaks (see Connect an AI assistant).
• Review before applying to shared environments. Treat AI-generated configuration like any other change — review it, build it, and test it before promoting it. Use DevOps packages and Source Control to capture and review what changed.
• Work within a product. Keep generated resources in a clearly named product so they are easy to find, package, and roll back.
• Confirm destructive actions. Deleting resources, moving them between products, or renaming widely-referenced resources are far-reaching — have the assistant confirm scope first.