Connect an agent (MCP)

What MCP is

The Model Context Protocol is a standard way for an AI assistant to call tools in another system. Point a compatible client — Claude Desktop, an IDE assistant, your own agent — at a server, and the assistant can use what that server exposes.

Sloose runs one. An agent can read your CRM’s shape and build importable projects with it.

Connecting

The endpoint is POST /mcp on your API origin, over Streamable HTTP:

https://api.sloose.com/mcp

Point an MCP client at it and it signs you in itself. Sloose is an OAuth 2.1 authorisation server for MCP clients: the first request comes back 401 with a challenge naming /.well-known/oauth-protected-resource/mcp, the client discovers the authorisation and token endpoints from there, and sends you to account.sloose.com to sign in (Zoho or a sign-in link), choose which org it may use, and allow it. The token it gets is for you, in that org, at your role — an agent can do exactly what you could in the widget, and nothing once your access is revoked. Clients register themselves by Client ID Metadata Document (the client id is the HTTPS URL of a document describing the client), which is how Claude and other current clients work; there is no registration form and no dynamic registration. If you are building a client: the document is fetched from the HTTPS URL you send as client_id, must come back as application/json from that URL itself (redirects are not followed), must carry the same URL in its own client_id field, and any client_uri in it must share that URL’s origin.

You can still paste a bearer instead: a session token (the one Login with Zoho hands the widget) or an org API token both work as Authorization: Bearer ….

It is stateless: each request builds a server scoped to your org and tears it down again. There is no session to keep alive.

MCP is a plan feature; a plan without it is refused with FEATURE_MCP. See Plans and limits.

The tools

Tool	Returns
list_modules	The org’s enabled modules and their vocabulary.
get_fields	A module’s importable fields, with the admin annotations.
propose_mapping	A validated mapping proposal for a set of columns.
test_expression	Compiles and runs an expression against sample rows.
validate_project	Checks a project configuration without saving it.
list_projects	Projects visible to the caller.
get_project	One project, migrated to the current schema.
save_project	Creates or updates a project.

Note what is not there: nothing runs an import. An agent can build the recipe; a person runs it.

The rules an agent is held to

Exactly the ones you are, because they are enforced on the server rather than in a client.

• Org scoping. The bearer is issued for one org; the agent cannot see another.
• Roles. Saving a project needs the same role a person would need.
• Sharing. Making a project org-visible is a plan feature, checked here too.
• Validation. A configuration that would not validate in the wizard does not validate here.
• Migration. An old project is migrated forward on read, not refused.

That symmetry is deliberate: a gate the widget honours and the API does not is not a gate. There is no path through MCP that a person could not take through the wizard.

A useful shape of work

The tools compose into an obvious loop, and it is worth doing in this order:

1. list_modules, then get_fields on the one you are importing into — so the agent is working from your real schema and annotations, not a guess.
2. propose_mapping for the columns in hand.
3. test_expression on anything computed, against sample rows, before committing to it.
4. validate_project — which tells you what the wizard would say, without saving.
5. save_project, then open it in the wizard, look at it, and run it.

Step 4 before step 5 is the one people skip and should not. It costs nothing and it is the difference between a project that saves and a project that works.

What to expect from it

Good at: mapping columns from a schema it can read, writing an expression and testing it, building a first draft of a project from a file description.

Not good at: deciding what counts as the same record. That is a judgement about your data and your business, and it is the decision with the worst failure mode — see Match records. Review the match rule yourself, every time.

Cost and data

Tool calls that reach a model are metered like any other AI call; ones that only read your schema are not. See AI credits and Your data and the model — the same sample policy applies here.

For programmatic use without an agent

If you want to script against Sloose rather than converse with it, the REST API and the typed client are the better fit: see the TypeScript client and the API reference.