Your team works in Lumo. Your agents run it headless.

MCP is the open standard AI agents use to call tools in other systems. Lumo runs an MCP server at /mcp. Your agent sends a request with its API key and gets back the list of tools it may use. If the key can only read contacts, the agent only sees the tools to search and fetch a person.

There are 593 tools, grouped in 24 domains. A regular key sees 506 of them. The other 87 are for owner and admin work and only appear for a key with workspace:admin, which only an owner can create. Add ?toolsets= to the address to narrow an agent further, for example to deals and activities.

So an agent can do far more than keep contacts up to date. It searches with search, pulls deals with list_deals and logs a call with log_activity. It records hours with log_time or starts a timer with start_timer, see time tracking. It puts people in a call campaign with create_call_campaign and logs the result with record_call_outcome, see telephony. It adds people to a Cadence with add_people_to_cadence and picks up LinkedIn actions with claim_linkedin_actions. It reads a score with get_lead_score from lead scoring, fills in a person with enrich_person, and finds a free slot with get_planner_availability before it books with create_planner_booking in the planner. For marketing there are tools such as create_marketing_campaign and record_campaign_spend.

Tools that contact a customer, send email or delete something for good ask for an explicit confirm: true. And every tool is also a REST endpoint under /api/v1/tools, so a script without an MCP client can do exactly the same. The fixed routes are documented on REST API.

• 593 tools in 24 domains, 506 visible to a regular key
• The tool list follows the rights of the key and ?toolsets=
• Sending email, contacting customers and deleting ask for confirm: true
• Up to 20 requests in one batch, counted against the limit
• Every result says record text is data, not instructions

The difference with an agent next to your CRM is where the work ends up. Lumo has no agent inbox and no separate tab of suggestions. A call your agent logs is simply an activity. It sits on the timeline of the person and the deal, in the activity list, and on Today for whoever has to make the call, on the day it is due.

That works because the API and the MCP server use the same write path as the screens. The same required fields, the same links, the same warnings when something is off. If the agent breaks a rule, it gets an error with an explanation per rule, and nothing is half saved. A lead that comes in over MCP gets the source mcp if your agent does not set one, so you can later filter on exactly what your agents created. An activity logged over MCP is owned by whoever created the key. To give it to another colleague, your agent sets an owner through the REST API.

Your own automations react to what an agent does too. When the agent creates a lead, a rule such as "New lead, then call task for today" starts just as it would for a lead from a web form. So agents and rules work together without you wiring them up.

• Activities from agents show on the timeline and on Today
• The same validation as the screens, never half saved
• Leads from MCP get the source mcp so you can filter on them
• Automations start on what an agent creates

Nobody wants an agent that can do anything. So in Lumo every agent runs under its own API key with rights per area. For each of the 24 areas you choose whether the key may read, write or both. Write does not include read, so a key that only creates leads cannot export your customer base. Managing webhooks is a separate right.

Every user creates their own keys, even a read-only user. But a key never goes above the rights of its creator. If a rep may not see colleagues' hours, neither can their agent. Only an owner can create a key with workspace:admin, and even that key acts as an admin at most, never as an owner.

You see the key once. After that only a hash is stored, so even someone with access to the database cannot recreate a key. The key goes in the Authorization header and is never read from the URL. Expires on gives it an end date, and Revoke switches it off at once.

The limits are firm. 600 requests per minute per key, then a clean 429 with the wait time. At most 1 MiB per request. Unknown fields are refused instead of silently ignored. After 30 failed attempts per minute from the same address, the door closes for a moment. Read more on security and privacy.

• Read, write or both across 24 areas, plus Manage webhooks
• Every user creates their own keys, never above their own rights
• Only an owner can give a key workspace:admin
• Keys are managed on screen, never over MCP
• 600 requests per minute, 1 MiB per request, Idempotency-Key for 24 hours

Not every team builds its own agent, and you don't have to. You can also set up an agent through the AI assistant in Lumo. You type what you want: "When a lead has had no activity for a week, plan a call for the owner today." The assistant turns that into an automation with a trigger, conditions and actions. It has 52 tools for this: 21 that read, 21 that prepare a draft and 10 that only act after your approval, such as switching on an automation or sending a campaign.

It always saves that automation switched off. Then it runs a test on a real record from your workspace and shows what would happen: Would run or Would not run, with the reason. Nothing is saved or sent during that test. If it looks right, the assistant asks for your approval to switch the rule on. Only when you click Approve and run does it go live.

From then on the rule keeps working, even when nobody is logged in. Rules for stalled deals and leads are checked every hour. That is the kind of agent most teams are really after: one that remembers an agreement and carries it out every day. More on what else the assistant can do is on the AI assistant page.

• The assistant builds an automation from a plain sentence
• New rules stay off until you approve
• A test on a real record writes and sends nothing
• Stalled-record rules are checked every hour

You don't see the result in the agent. You see it in your team's morning. What your external agents logged overnight and what your automations planned shows up on Today, per person, with anything overdue at the top. The account manager does not have to dig through a channel for what the agent suggested. It is on the customer.

Nothing goes out without someone knowing. An automation can send an email from a template, from the Gmail account of the record owner. The builder then warns that this sends a real email to the person on the record. Over MCP, every tool that sends email asks for confirm: true, and the assistant only sends a campaign after you approve. If you want a person to have the last word, let the rule create a task "Send the recap" instead. Then the account manager sends it.

A stalled deal reaches the same rule at most once a week. An agent that creates the same task every night would bury your team. With "Skip if such an open activity exists", a rule also avoids that when it is triggered twice. More on the rhythm of calls and follow-up is on Cadence.

• Work from agents and rules lands on Today, per person
• Email from an automation goes from the owner's Gmail, with a warning
• A stalled record reaches a rule at most once a week
• A rule skips when an open activity already exists