Connect: your organisation as tools for AI clients
Connect gives your organisation one address that AI clients can use: https://nibor.io/connect/<organisation-slug>/mcp. Whoever signs in there gets the organisation's Nibor apps, and the external systems an admin has registered, as governed tools, under their own identity.
Connecting a client
- Claude.ai: Settings, Connectors, Add custom connector, paste the address, sign in to Nibor and allow the connection for your organisation.
- ChatGPT: Settings, Connectors, Create, paste the address, choose OAuth, sign in to Nibor and allow.
- Claude Code: create a personal token on the Connect tab of your Workspace, then run
claude mcp add --transport http nibor-org https://nibor.io/connect/<slug>/mcp --header "Authorization: Bearer <token>". - Cursor and other editors: the same personal token in an
mcp.jsonentry; the Connect tab shows the snippet.
Personal tokens are shown once, can expire, and can be revoked from the same tab. Browser clients use OAuth, so no token is copied anywhere.
What the tools are
- For every Nibor app you belong to: list, read, create, update and delete on each model, plus the app's server functions, all under your own membership and role.
nibor_apps,nibor_whoami,searchandfetchacross your apps.nibor_companyandnibor_resolve: the organisation map, and "where does this live and how is it keyed"; see ONAS. Every entity comes with the endpoints you may run for it.nibor_search_toolsfinds external endpoints by what they do, andnibor_callruns one by system key and endpoint name. Pinned endpoints are also listed asext_*tools; everything else is reached throughnibor_call, so a company with hundreds of endpoints costs a handful of tool descriptions per turn.ext_<system>_<endpoint>: the endpoints of registered external systems.
External systems
An organisation admin registers a system on the Connect tab, picking a system type when there is one (Unit4 ERP, Dalux, Fortnox, Accounted, or any other API) so the vendor details are filled in, with its base address, auth style (bearer, basic, header or query key, OAuth2 client credentials for a machine client, or OAuth2 consent where a person such as the finance administrator approves the connection at the vendor by pressing Connect Fortnox) and credential; imports its endpoints from an OpenAPI document or adds them by hand; chooses which endpoints to expose and how many tools the system may contribute; and presses Test. Read endpoints are exposed by default, write endpoints never by import. The credential is stored encrypted and used only by the platform; the vendor sees the organisation's service account, Nibor's audit log sees the person.
Members reach an external system only through a grant: in the Access section an administrator grants a person, a team or everyone read or write access to a system, optionally limited to entities of the company map, with personal data behind its own switch. Nothing is reachable until granted; admins and owners always can. Write tools are marked destructive so your AI client asks before running them, and every call and refusal is in the audit trail with the person's name.
The map does not have to be written by hand. With every system registered and its endpoints imported, an administrator presses Generate: the platform reads each system's endpoints, its stored specification and the administrator's notes, and proposes what each system is the source of truth for, which business objects the endpoints serve, what each endpoint is for and when to use it, and the words people use. Nothing is applied until an administrator accepts it in the review queue, where a proposal can be edited first or rejected for good. Regenerating proposes only what is new or different. With the organisation owner's explicit switch (Portal, Organization, named in your agreement) an administrator can also analyse with samples: a few records from each read endpoint, never personal data and never stored, so the model can propose the relations between systems (a Dalux project number stored as the Fortnox project code).
A relation the administrator confirms can be promoted to a composite tool: one tool on the hub (cx_<name>) that fetches from one system, then another, and returns the joined answer in one call, for example the overdue supplier invoices of a Dalux project. Composites run read endpoints only and are listed only to people whose grants cover every step.
The company map keeps versions: an administrator publishes one from the Connect tab, sees what changed since, and can restore an earlier version, which puts back the curated entities, terms, endpoint purposes and system roles of that moment.
Hand-over: Nibor curates first, then your administrator
A new company map is usually curated twice: first by Nibor as your external CTO, then by your own administrator. Both use the same product; the curator is simply an administrator of your organisation. The sequence, and what each step leaves behind:
- Register the systems on the Connect tab from a system type (Unit4 ERP, Dalux, Fortnox, Accounted, or any other API), set the credential or press Connect for a consent-based system, import the endpoints, press Test. Leaves: systems with green status.
- Generate the map and work through the review queue: accept, edit or reject every proposal. Leaves: entities with a source of truth, endpoint purposes, vocabulary, and a first map version.
- Analyse with samples if the owner switched sampled reads on, and accept the relations that hold. Leaves: confirmed relations.
- Promote the relations people ask about most into composite tools and test each one. Leaves:
cx_tools on the hub. - Grant access under Access: everyone, a team or a person, per system, read first. Leaves: a hub where each person sees exactly what they may use.
- Publish a version with a message and hand the queue over: your administrator continues from the same tab, and the audit trail shows who accepted what.
Audit
Every call through the hub is recorded in the organisation's audit log: who called which tool on which app or system, whether it succeeded and how long it took.