Connect external AI clients with the MCP server

The Model Context Protocol (MCP) is an open standard that lets an external AI client talk to your tools and data through a defined set of actions. Lavori runs a remote MCP server so that an MCP-aware client, such as Claude, can work with one of your organizations directly.

When connected, the client gains access to the same kinds of actions the in-app AI assistant uses: it can list your projects, tasks, schedule, billing records, directory, and analytics. With the right opt-ins it can also create and update certain records. Everything the client sees and does is scoped to one organization that you choose when you connect.

• Read tools cover projects and structure, tasks, schedule, billing and budgets, directory, and analytics.
• Write access is off by default and only becomes available when an organization admin opts in and you approve it.
• Messaging tools, content-writing tools, and delete operations are never exposed over MCP, regardless of scope.

Every connection starts from the connector URL. Sign into Lavori and open Settings, then MCP Connections. The page shows your connector URL along with a Copy button and a live indicator confirming the server is reachable.

This is the address you paste into your MCP client. A status badge next to it checks the server's health so you can confirm it is up before you start. If the badge reports a problem, you can retry the check from the same page.

Connecting a client is a quick OAuth flow. You stay in control the whole way: you sign in, you pick which organization to share, and you approve exactly what the client can do.

• In Claude.ai, open Settings, then Connectors, then Add custom connector.
• Paste the connector URL copied from your Lavori MCP Connections page.
• Claude redirects you back to Lavori. If you are signed out, you sign in first, then land on the consent screen.
• On the consent screen, choose the organization to connect and, optionally, narrow to a single team.
• Click Allow. Claude is returned to its connector flow and the connection is established.
• Back in Claude, ask it to use Lavori, for example What projects do we have right now, to confirm it works.

A connection is always bound to a single organization, picked on the consent screen. The client can only see data from that organization and cannot pivot to another one mid-session.

If the chosen organization has teams, you can optionally narrow the connection to one team. With a team selected, tools that filter by team, such as projects, tasks, schedule, billing, and directory, return only that team's data; tools without a team relation still return organization-wide results. Leaving the default of all teams keeps the connection at the organization level.

Read access is always part of a connection. On the consent screen it appears as the mcp:read scope and covers projects, tasks, schedule, billing, directory, and reporting.

Write access is separate and off by default on every consent. A toggle on the consent screen, Allow this client to modify data, requests the mcp:write scope, which lets the client create and update projects, tasks, events, shifts, contacts, status transitions, and assignments. Turning it on reveals a second toggle, Also allow billing changes, which requests the mcp:write:billing scope for creating and updating quotes, invoices, and budgets.

Granting write at consent time is not enough on its own. Your organization's admin must have enabled MCP write for the request to succeed. If write has not been enabled for the organization, authorization fails and Lavori shows a clear error explaining why.

• mcp:read reads your Lavori data and is always included.
• mcp:write creates and modifies projects, tasks, events, shifts, contacts, status transitions, and assignments.
• mcp:write:billing creates and modifies quotes, invoices, and budgets, and is a strict sub-grant of write.

Write access is gated at the organization level so that mutations cannot be granted by a single user acting alone. An admin enables it from Organization settings, under the MCP write access card.

There are two switches. Allow MCP write access turns on the mcp:write scope for the organization. A second switch enables billing write specifically, allowing the mcp:write:billing scope. Billing write depends on general write being on; turning write off automatically clears billing write.

The MCP server re-checks these settings on every request. Turning a switch off cuts off in-flight connections that relied on it, so you do not have to wait for any token to expire. When a connection's access renews, its effective scope is recalculated against the organization's current settings, so re-enabling a switch restores access automatically on the next renewal.

The Active connections list on the MCP Connections page shows every client authorized to your organizations. Each row names the client, the organization it is bound to, any team scope, the approved scopes shown as badges, when it was last used, and when it was added. Write and billing-write scopes are highlighted so elevated connections are easy to spot.

Revoke any connection from its row. Lavori asks you to confirm, then the client immediately loses access; in-flight requests fail and the client must reconnect to use Lavori again. Revocation takes effect right away rather than waiting for a token to expire.

Each connection has an Activity button that opens a side panel of recent events for that connection only. You see the OAuth lifecycle, such as when access was issued, renewed, or revoked, along with any replay attempts, and each entry shows the action, severity, IP address, user agent, timestamp, and related details.

Tool invocations are also recorded by default, so you can see what the client actually did, though an operator can turn that recording off at the server level. The activity view is private to the connection's owner.