Your own MCP servers

MCP (Model Context Protocol) is the open standard for giving an AI tools. If your core banking, ticketing or document system has an MCP server, an admin can add it by URL and Lucy gets its tools, under the same permissions as every other connector.

Use cases and example usage

An MCP server turns a system of yours into tools Lucy can use, with your permissions and approvals around it. Typical examples:

System	Example server	Say this
Ticketing	Your service desk	“Open a ticket for the printer on floor 3 and tell me the number.” (write tool, set to ask)
Core banking or ERP	A read-only query server	“What is the open balance of account 4711 and when was it last reconciled?” (read tool, allow)
Document store	A policy or contract repository	“Find our current outsourcing policy and list the sections that mention exit plans.”
CRM	Client records	“Summarise the last five interactions with Acme and the open opportunities.”
Internal knowledge base	A wiki or handbook	“What is our process for onboarding a new fund? Cite the page.”
Whiteboard or planning tools	Board and task systems	“Create a board for the Q4 close and add the six tasks from this checklist.”

Design tips for useful servers

• Make reads cheap and writes explicit. Mark read-only tools as read-only so they need no prompt, and keep writes on ask.
• Name tools for the job. find_invoice is better than query. Lucy chooses tools by name and description.
• Return what a person would want to read. Short, structured results beat raw dumps.
• Keep scopes narrow. Give the server only the access the use case needs.

A complete example

An admin connects the service desk server and sets search_tickets to allow and create_ticket to ask. A user types “Is anyone already working on the VPN issue?” and Lucy answers from live tickets. Then “Open one for me” produces an approval card showing the ticket text and the host that receives it. One click creates it.

Sign-in options

Option	How it works
None	The server needs no credentials.
Shared by the organisation	One header and value (for example an API key) is stored sealed and sent on every call.
OAuth, per person	Each person signs in at the server themselves (OAuth with PKCE). Their token is stored per person and used only for that server.

Configure it (admins)

1. Admin → Connectors → Add MCP server. Enter a name and the https URL.
2. Choose the sign-in option and, for a shared key, paste it. Lucy stores it sealed and shows only a hint afterwards.
3. Run the test. Lucy lists the server’s tools, or tells you why it could not.
4. Set each tool’s permission. Anything that writes or deletes should be ask.

Built-in protections

• Only public https servers. The address must be https and resolve to public addresses, checked when you save and again on every connection, so DNS cannot point it inside your network. No redirects, no proxy.
• Bounded calls. Each call times out after 60 seconds and responses are cut at 1 MiB. Nothing partial is ever returned.
• Changed tools need review. If a server changes a tool’s description, input schema or behaviour, Lucy marks the tool changed, caps it at ask and keeps it away from agents until an admin reviews it. A server cannot quietly turn a harmless tool into a dangerous one.
• Privacy by default. The server learns nothing about your organisation or the person. It receives only its own credentials and the call’s arguments.
• Clear approvals. The approval card names the server and the host that receives the arguments.
• Visible health. The connector page shows when it last worked and why it failed. If a server is down, Lucy says so instead of guessing.

Members’ own servers

If you turn on Member servers, people may add servers for themselves only. Those servers are never shared with colleagues or agents, and are deleted with the person.

Building a server? See Developers → Connectors and MCP.