> ## Documentation Index
> Fetch the complete documentation index at: https://docs.briksync.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect an AI Assistant

> Connect Claude, ChatGPT, or any MCP-compatible AI assistant to your BrikSync PropOS data — read-only and suggest-only, never a direct write.

BrikSync PropOS exposes an MCP endpoint so an AI assistant — Claude, ChatGPT, or any other client that speaks the Model Context Protocol — can work with your organisation's data directly, using the same API key you'd use for the REST API.

<Warning>
  The same rule applies here as everywhere else in this API: **your assistant can read your data and
  it can suggest changes, but it can never change anything on its own.** Every suggestion it makes
  lands in your approval queue in BrikSync and waits for a person to approve it. If an assistant
  ever reports that it "updated" or "created" something directly, that is a description error on the
  assistant's part — nothing was actually changed.
</Warning>

***

## Endpoint

```
POST https://briksync.com/api/mcp
```

This is a single endpoint outside the versioned `/api/v1` path, since it speaks the MCP protocol rather than plain REST.

***

## Authenticating

Use the same API key described in [Authentication](/api/authentication), sent the same way — as a bearer token:

```
Authorization: Bearer <your-api-key>
```

Whatever assistant or client you're connecting, look for where it lets you configure a custom MCP server or connector, and set:

* **Server URL:** `https://briksync.com/api/mcp`
* **Authentication:** Bearer token, using your BrikSync API key

There is no separate MCP-specific key — the key you created under **API & Automation** works for both the REST API and this endpoint. The scopes on that key decide exactly which tools the assistant can see and use.

***

## What the assistant can do

An assistant connected this way gets access to a set of tools, generated from the same collections described in [Reading Data](/api/reading-data). Which tools it actually sees depends on the scopes your key holds — a key without `payments:read`, for instance, won't offer a payments tool at all.

**Read tools** — one pair per collection:

| Collection             | Tools                                                   |
| ---------------------- | ------------------------------------------------------- |
| Properties             | `list_properties`, `get_properties`                     |
| Units                  | `list_units`, `get_units`                               |
| Tenant contact records | `list_tenants`, `get_tenants`                           |
| Leases                 | `list_leases`, `get_leases`                             |
| Payments               | `list_payments`, `get_payments`                         |
| Maintenance requests   | `list_maintenance_requests`, `get_maintenance_requests` |
| Documents              | `list_documents`, `get_documents`                       |

**Suggestion tools:**

| Tool              | What it does                                                                                        |
| ----------------- | --------------------------------------------------------------------------------------------------- |
| `propose_changes` | Suggests one or more changes for a person to approve. Does not change any data.                     |
| `list_proposals`  | Lists the suggestions made so far and their status (still waiting, applied, dismissed, or expired). |

These map directly onto [Reading Data](/api/reading-data) and [Suggesting Changes](/api/suggesting-changes) — the same pagination, filtering, and approval model applies whether you're calling the REST API yourself or an assistant is calling it on your behalf through these tools.

***

## What happens when the assistant suggests something

When your assistant calls `propose_changes`, BrikSync records the suggestion exactly as it would from a direct API call — nothing is applied. The assistant is told plainly that the change is only a suggestion awaiting approval, and a well-behaved assistant will tell you the same thing. The suggestion then shows up in **API & Automation** in BrikSync for a person to review, alongside suggestions from any other integration.

<Tip>
  If you're asking your assistant to make several related changes — for example, updating rent
  across a few units — ask it to send them as one suggestion. That way whoever reviews it in
  BrikSync sees the whole set as a single decision, rather than several unrelated items to approve
  one at a time.
</Tip>

***

## Data your assistant sees

An assistant only ever sees records belonging to your own organisation, filtered further by the access level and scopes on the key it's using — the same boundaries described in [Authentication](/api/authentication) and [Reading Data](/api/reading-data). Tenant contact records are limited to name, email, phone, and status; document contents are not accessible; and there is no tool anywhere in this API that scores, ranks, or screens a person.

***

## Next steps

<CardGroup cols={2}>
  <Card title="Reading Data" icon="database" href="/api/reading-data">
    See exactly what each collection returns.
  </Card>

  <Card title="Errors & Limits" icon="gauge" href="/api/errors-and-limits">
    What happens when a request fails or a limit is hit.
  </Card>
</CardGroup>