Services: database, MCP server, HTTP API
How a service is created in the Outpost, shared in MeinGPT, and then used in an assistant.
Besides folders, an Outpost can also pass through services: a database, a local MCP server, or an internal HTTP API. For the email and calendar of your own Exchange Server there is a dedicated service type: Exchange mailboxes. A folder delivers searchable text; a service delivers a live connection — MeinGPT sends a request to your system when needed and gets the answer back at the moment it's needed.
Services are not enabled by default
A service only appears once the controlled services preview is enabled for your workspace. Without that, sharing in the Outpost shows only A folder as an option.
Three steps, in three places
Unlike a folder, sharing it in the Outpost alone isn't enough — a service passes through three stations before anyone can use it:
| Where | What | |
|---|---|---|
| 1 | In the Outpost | Share the service — provide the target or connection URL and decide what it releases. |
| 2 | In MeinGPT | Grant people, teams, or the whole organization access to the reported service under Shares. |
| 3 | In the assistant | Enable the connector in the assistant editor — only then can a response actually use it. |
Credentials and the local target URL never leave the Outpost machine. Only the name, service type, and what you mark as allowed in step 1 reach MeinGPT — never the password from a connection URL or the target itself.
In the Outpost: share the service
Choose the service type
Shares tab → Share. With the services preview enabled, a menu opens with these choices: A folder, A database, Exchange mailboxes (on-premises), An MCP server, and An HTTP API. Pick the matching service type. For Exchange, follow the Exchange mailboxes guide instead of the steps below.
Set up the connection
The wizard first asks for a name — it later appears exactly like this in MeinGPT and in chat, so pick something understandable (e.g. "Playwright MCP" rather than an internal shorthand).
Database system: PostgreSQL, MySQL, or Microsoft SQL Server.
Connection URL (stored locally) — depending on the system, e.g.:
postgresql://user:pass@host:5432/db
mysql://user:pass@host:3306/db
sqlserver://user:pass@host:1433/db
The field is masked like a password field and is never shown again after saving — not even in MeinGPT. Use a dedicated database role for this service rather than a personal account.
Microsoft SQL Server: named instances and SQL Server Express
-
Named instances such as
SERVER\SQLEXPRESSare not supported in the connection URL, because the Outpost does not use the SQL Server Browser service. Use the host name with the instance's fixed TCP port instead, e.g.sqlserver://user:pass@SERVER:1433/db. -
SQL Server Express ships with TCP/IP disabled and uses dynamic ports. In SQL Server Configuration Manager, enable TCP/IP under the instance's protocols, clear TCP Dynamic Ports under IP Addresses → IPAll, enter a fixed TCP Port, and restart the service. Port 1433 only works if no default instance on the server already uses it; otherwise pick another one, e.g. 14330.
-
Authentication: Only SQL Server logins with username and password are supported, not Windows authentication. Switch the server to "SQL Server and Windows Authentication mode" and create a dedicated login that has only the
db_datareaderrole in the database. As long as you don't allow writes (INSERT, UPDATE, DELETE), the Outpost checks that the login cannot write: logins such assa,db_owner,db_datawriter, or logins with EXECUTE rights on procedures are rejected with "The selected read-only access needs a role that cannot write". -
Encryption: The connection is encrypted by default and validates the server certificate. For that, SQL Server needs a certificate of its own:
- The host name from the connection URL must be in the certificate (subject alternative name or CN). If the URL contains an IP address, the certificate must list it as an IP address in the subject alternative name. As a DNS name or in the CN it does not count; a host name in the URL is usually simpler.
- The certificate is either issued by a certificate authority whose root the Outpost machine trusts, or self-signed, e.g. with
New-SelfSignedCertificate. Import a self-signed certificate on the Outpost machine incertlm.mscunder Trusted Root Certification Authorities. If it only sits under Personal, the Outpost does not trust it. - Restart the Outpost after the import. It reads the certificate store only at startup.
- The certificate SQL Server uses without its own configuration never passes the check: SQL Server generates it anew at every service start, and it does not carry the host name.
More on the Outpost machine's certificate store: Your own root certificate. Only as a stopgap, append
?trustServerCertificate=trueto the URL: the connection stays encrypted, but the server's identity is no longer verified. No URL parameters other thanencryptandtrustServerCertificate(eachtrueorfalse) are allowed. -
Special characters such as
@,:,/,?,#, or%in the username or password must be URL-encoded, e.g.@as%40. -
Invalid URL: If the check reports "Configuration is invalid", the share can't be re-checked. Remove it and add it again with the corrected URL.
Set the access level
You decide what the service may release on the same screen — differently per service type:
Released tables, one per line in schema.table format, e.g.:
public.customers
public.orders
* acts as a wildcard for the schema or the table — the default value *.* releases every table at first; narrow it down to the tables you actually need. Up to 500 entries.
Entries are case-sensitive: write the schema and table exactly as they are named in the database (e.g. public.Customers if the table is called Customers).
Below that: SELECT is always allowed for every listed table. INSERT, UPDATE, and DELETE are individually toggleable checkboxes — they then apply to all listed tables together, not per table.
Write access: what applies to every call
- One statement per call. The assistant runs exactly one
INSERT,UPDATEorDELETE.RETURNING, upserts (such asON CONFLICTorMERGE), structure changes likeDROPorTRUNCATE, and several statements in one call are rejected. - No confirmation. The assistant writes without asking, as soon as the service is enabled for it and the person is allowed to work with it. Turn on only the statements it actually needs.
- The role stays the limit. Once writing is enabled, the Outpost no longer checks that the role can only read. Give the database role write rights on the released tables only.
Review and add
The last step summarizes the name, service type, target, and the access you just set. Add registers the service with MeinGPT — it isn't visible to anyone yet. That's the next step.
In MeinGPT: share the service
Grant access
Settings → Outposts → Manage → Shares. The service is listed there alongside the folders in the same list, marked with a lightning-bolt icon. Click Access and add the people or teams who may use it — or share it with the whole organization. As long as you don't share the service, only your workspace admins can use it (shown as Admins only). Admins always have access and can't be excluded.
In the assistant: enable the connector
Assistants only, not plain chat
An Outpost service can only be enabled in an assistant. It does not appear in the connector picker of a plain chat ("+" menu or @ menu). Create an assistant, enable the service there, and start the chat through that assistant.
Turn on the connector
Open the assistant editor, Tools → Connectors section. A service you've shared appears there tagged "via Outpost" — enable the row to let the assistant use it. There's no separate login or connection to make here: the connection already exists, this step only grants usage permission for this assistant.
For an MCP server, the released tool list can be narrowed further per assistant here — never widened beyond what you set in the Outpost. General information on tools and connectors in the assistant editor: Assistants.
After that, any response using this assistant can call the service — run a database query, execute an MCP tool, or hit one of the released HTTP routes — within the limits you set in the Outpost.
Put database hints in the assistant's instructions
The model sees the tables through the schema lookup but does not know the quirks of your database. Write them into the assistant's instructions (see Assistants) and name the service there explicitly.
PostgreSQL: names with uppercase letters
PostgreSQL converts unquoted names to lowercase. If a table or column is called Customers or OrderDate, it must be wrapped in double quotes in the query: SELECT "OrderDate" FROM public."Customers". Without them the query fails. Give the assistant a sentence such as: “Always wrap table and column names containing uppercase letters in double quotes, e.g. public."Customers"."
When a connection doesn't work
"Registered" and "reachable" are two separate states — a service can appear in MeinGPT and still not respond, for example because the local target isn't running right now. How to narrow that down with Check connection in the Outpost console, and what the most common error messages mean, is at Check a database, MCP, or HTTP service.