MCP · Claude, ChatGPT, Cursor

Every Abide.Rent operation, as a tool for your AI assistant.

Abide.Rent runs a Model Context Protocol (MCP) server. Each operation of the product API is a tool that calls that same API, as the person who connected the assistant, in the one account they chose: properties, tenancies, certificates, deposits, rent reviews and comparable lettings, notices and tribunal referrals, repairs, contractors, documents, reports, tasks and the team. The person chooses read only or read and make changes. Connecting an assistant needs Portfolio or the free trial; Solo, the free plan, cannot connect one.

Host

https://mcp.abide.rent/mcp

Streamable HTTP. OAuth 2.1 sign-in only: the person chooses one account, and read only or read and make changes.

Protocol

2026-07-28 (also 2025-03-26 to 2025-11-25)

tools/list never includes serve.

Assistants connect only by signing in (OAuth): API keys are for the REST API and are refused here. A read-only connection lists and calls only tools that read. Whatever the access, some operations are never tools: signing in and credentials, approving assistants, API keys, payments and plan changes, closing or transferring the account, and signing or serving a notice. No tool registers a property on the PRS Database or files anything with a tribunal: an assistant can prepare the register pack or draft a tribunal statement, and a person sends it. What an assistant reads is sent to the company that runs it, under its terms. Abide.Rent is not listed in a connector directory: add it as a custom connector.

Connect

Connect an assistant

  1. In Claude, ChatGPT or Cursor, add a custom connector (MCP server) with the address https://mcp.abide.rent/mcp.
  2. When it opens Abide.Rent, sign in. You see which assistant is asking and where it will send you back.
  3. Choose the one account it may read. For an agency or landlord account only its owner can allow it; a tenant can connect their own tenancy.
  4. Choose Read only or Read and make changes and select Allow. Remove it any time from Your account → Connected assistants.

Every assistant signs in as a person; API keys are refused here (they are for the REST API). Discovery: the server answers without a token with 401 and resource_metadata; the authorisation server supports PKCE (S256), dynamic client registration and the iss response parameter.

432 tools is more than some clients load at once. Add ?toolsets=properties,repairs to the address to list only those toolsets (plus whoami, find_tools and run_tool). The assistant finds anything else with find_tools and calls it through run_tool, with the same checks and permissions.

Tools

Built in

whoami

Live

Which person and account the connection uses, and whether it may only read or may also make changes.

find_tools

Live

Searches every tool this connection may use by keyword and gives each match's arguments, for assistants that load only some toolsets or cannot see them all.

run_tool

Live

Calls any tool by name, for a client that did not load it (a tool limit, or a short toolsets list). The same checks and permissions apply as a direct call.

prepare_prs_registration

Live

Prepares a property’s PRS Database register pack: what GOV.UK’s “Register your rental property” service will ask for, ready or missing, with the window, deadline and yearly fee. It reads only. No tool registers a property: the landlord registers on GOV.UK.

serve, sign

Never a tool

There is no tool to serve or sign a notice, or to sign a document, and there will not be one. A person does that in the product.

Every tool

432 tools in 19 toolsets

One tool for each of the API’s 449 operations an assistant may use, each calling that same operation. 195 only read; the rest change records and appear only on connections allowed to make changes. The toolset key is what ?toolsets= takes.

All 432 tools. Search, or open a toolset.

The properties on the account, their tenancies, tenants and occupiers, who on the team looks after each, sales and changes of agent, and read-only share links.

16 read, 22 change?toolsets=properties

The agency's landlord clients, their addresses for notices, the monthly compliance statements written for them, the weekly summary, and a landlord's own portfolio.

15 read, 8 change?toolsets=landlords

The records kept on each tenancy - move-in and move-out checklists, inventory and check-out reports, Right to Rent checks, guarantees, agreement to email service of notices, tenants' forwarding addresses, sharers leaving, and incidents kept as possession evidence.

9 read, 16 change?toolsets=tenancies

What is due across properties and tenancies (certificates, deposits, notices, inspections and more), who answers for each duty, PRS Database readiness, reminders, deadline evidence packs, and legal holds that stop records being deleted.

5 read, 5 change?toolsets=compliance

Gas safety records, EICRs, EPCs, licences and other certificates on each property, the tenants' copies, bulk upload, and the business's own memberships and registrations.

5 read, 9 change?toolsets=certificates

Property inspections booked with notice and carried out, their reports, and repeating inspection schedules that create tasks.

3 read, 5 change?toolsets=inspections

Repairs reported by tenants or staff, the target dates they carry, the account's contractors, the jobs sent to them, and landlord approval for jobs over the maintenance limit.

13 read, 22 change?toolsets=repairs

Section 13 rent reviews from pricing to landlord approval, the evidence-based rent range for an area, local market insight, and published First-tier Tribunal rent decisions.

18 read, 18 change?toolsets=rent_reviews

Section 13 rent increases (Form 4A) and Section 8 notices (Form 3A) prepared as drafts, served notices recorded and evidenced, what happened after service, possession steps, tenants' notices to quit, and written statements of terms. Signing and serving stay with a person in the app.

11 read, 18 change?toolsets=notices

Tenancy deposits and their protection, prescribed information, proof of payment, holding deposits under the Tenant Fees Act 2019, and settling the deposit at the end of a tenancy (deductions, the tenants' answers, the landlord's approval, scheme disputes and release).

7 read, 26 change?toolsets=deposits

Each tenancy's rent account (schedule, payments, running balance and arrears), payments recorded by hand or from a bank CSV, arrears for possession grounds, the agency's rent roll, and the workspace's own Abide.Rent plan and invoices.

13 read, 6 change?toolsets=money

Tenants' requests to keep a pet (Renters' Rights Act 2025) - submitted by a tenant or recorded for them, further information within the 28-day answer period, a superior landlord's consent, the landlord side's written decision, and withdrawal.

2 read, 6 change?toolsets=pets

Documents drafted from the workspace's templates and sent for signature in order (statements of terms, management agreements, letters), the templates and clause library behind them, emails sent from Abide.Rent, and replies to them routed to the person responsible. Signing itself is done by each signer.

12 read, 15 change?toolsets=documents

Notes on properties, tenancies and other records (internal, or shared with the landlord), mentions and pins, tasks with owners and due dates, moving a person's properties to colleagues, and hiding rows from your own lists.

8 read, 16 change?toolsets=notes_tasks

Workspace reports and registers (compliance risk, evidence gaps, arrears, notices, deposits, Right to Rent, voids and more), the dashboard and today's priorities, rent increase opportunities, who was told what and when, and the audit history of any record.

10 read, 0 change?toolsets=reports

The workspace's team and seats, invitations to tenants and landlords, holiday cover, leave, the on-call rota, the team calendar, working hours and closure days, branches, scorecards, joiners' onboarding, and planning a colleague's exit. Giving or changing anyone's access stays with an owner in the app.

17 read, 23 change?toolsets=team

Exporting the workspace's records, background data jobs (imports and exports), bulk actions over many records at once, saved views of the app's lists, and the filterable fields of each list.

13 read, 8 change?toolsets=workspace

Your own profile and notification choices, your in-app notifications, the workspace's business details and logo, its set-up profile and getting-started checklist, and support tickets with Abide.Rent.

12 read, 12 change?toolsets=account

For a named tenant connected from the tenant portal - their tenancies, the landlord or agent, rent, deposit, notices served on them, pet requests, and the safety certificates given to them.

4 read, 1 change?toolsets=my_tenancy
What is never a tool (138 API routes)
  • Signing in and passwords. Signing in, signing up, passwords and sessions. An assistant is already signed in through its own connection and never handles a password or one-time code.
  • Your sign-in and open workspace. Linking a Google sign-in is a credential change made by the person in the app.
  • Your sign-in and open workspace. Unlinking a Google sign-in is a credential change made by the person in the app.
  • Your sign-in and open workspace. Changing the password is a credential change made by the person in the app.
  • Your sign-in and open workspace. Switches the open workspace in the app. An assistant connection is fixed to the one account the person chose.
  • Accepting invitations. Reads an invitation by its emailed token, for the person invited. Not used through an assistant connection.
  • Accepting invitations. Accepting an invitation joins a workspace as the person invited, using the emailed token. Done by that person in the app.
  • Abide.Rent staff console. The Abide.Rent staff (superadmin) console. An assistant connection is always one customer account and never the platform view.
  • Approving assistants. Approving and removing assistants. Only the signed-in person may grant or revoke an assistant connection; an assistant cannot approve or remove itself.
  • API keys. API keys are credentials. They are issued and revoked by the account owner in the app, never through an assistant.
  • Closing or transferring the account. Transferring or closing the whole account is irreversible and stays with the account owner in the app.
  • Serving and signing notices. Signing a notice is never available over the API or MCP. A named person signs in the app.
  • Serving and signing notices. Serving a notice is never available over the API or MCP. A person serves it and records how in the app.
  • Payments and plan. Changing the plan or billing period changes what the customer pays. Done by the owner in the app.
  • Payments and plan. Starts a card payment. Payments are made by the owner in the app.
  • Payments and plan. The declaration that the customer buys as a business (UK VAT reverse charge) is a statement the owner makes personally.
  • Payments and plan. Opens the Stripe billing portal, a signed link to the card and invoices. Managed by the owner in the app.
  • Payments and plan. Records that a person tried a locked feature in the app, for the upgrade prompt. Only meaningful in the app.
  • Private calendar address. The private calendar address is a secret URL; creating or reading it through an assistant would hand the secret to the assistant provider. Managed in the app.
  • Device notifications. Push notifications for this browser or phone. Tied to a device, not something an assistant has.
  • Links for people without an account. A no-sign-in link for someone without an account (contractor, signer, tenant, a person given a share or unsubscribe link). The token in the address is the credential; an assistant works through its own connection instead.
  • Payments and plan. A development and test helper that fakes a billing outcome. Refused outside development.
  • Payments and plan. Cancelling the subscription is a payment decision made by the owner in the app.
  • Payments and plan. Resuming the subscription restarts payments. Done by the owner in the app.
  • Provider webhooks. Inbound webhooks from Stripe and ZeptoMail, signed by the provider. Not something a person or assistant calls.
  • Payments and plan. Applying a promotion code changes what the customer pays. Done by the owner in the app.
  • Sign-up referral codes. A public referral-code lookup used on the sign-up page before anyone has an account.
  • Payments and plan. Changing plan takes a payment or changes the price. Done by the owner in the app.
  • Signing documents. An electronic signature must be the signer’s own act, made in the app. An assistant never signs for anyone.
  • Webhooks. Sets where Abide.Rent sends account data, and hands out the signing secret. The owner configures it in the app, so an instruction hidden in a document or message can never redirect data elsewhere. Outbound webhooks are not switched on yet.
  • Connections to other systems. Connectors to other systems are not built yet (the API answers that they are not available). When they are, connecting one handles that system’s credentials, which stays with the owner in the app.
  • Webhooks. Outbound webhooks are not built yet and are hidden in the app until they are. A tool that lists, reads or removes a webhook would tell an assistant that webhooks exist and have delivered when nothing is ever sent; what is there stays with the owner in the app until webhooks are real.
  • Connections to other systems. Connectors to other systems are not built yet and are hidden in the app until they are. A tool that lists a connection or its sync runs, records a decision on one or removes it would tell an assistant that a Reapit or PayProp connection exists and syncs when nothing is ever synced; what is there stays with the owner in the app until connectors are real.
  • Public share links. Creates a public link to a property’s compliance record that opens without signing in. A person creates it in the app, so an assistant can never publish records.
  • Signing documents. Declining to sign is the signer’s own act, recorded with their device as evidence, like signing. The signer does it in the app.
  • Abide.Rent support desk. The email audit across every workspace, for Abide.Rent platform staff only. Customers read their own emails per property, notice or pet request.
  • Who has access. Changing what a person may do in the workspace (their seat, or serving notices) is done by an owner in the app. An assistant never grants or changes access.
  • Who has access. Removing a person from the workspace is done by an owner or manager in the app. An assistant can plan an exit (start_offboarding) but not carry it out.
  • Who has access. Giving a former team member their sign-in back is done by an owner in the app. An assistant never grants or changes access.
  • Who has access. Carrying out an exit moves the person's work and closes their access. A person does it in the app after reviewing the plan.
  • Who has access. Branch membership decides which properties a branch-limited seat can see. An assistant never grants or changes access.
  • Who has access. Branch reach decides whether a seat sees every branch's properties. An assistant never grants or changes access.
  • The in-app assistant. The in-app assistant answers a person's questions in Abide.Rent with its own daily allowance. A connected assistant reads the same records directly with the other tools.
  • Set-up screens. Records what the person did on the app's set-up screens (a tour seen, a step skipped). It describes the person's own use of the app, so an assistant does not record it for them.
  • Abide.Rent support desk. Changing a ticket's status, priority, type or tags is for Abide.Rent support staff. Customers reply to or close their tickets.
  • Abide.Rent support desk. The support desk's internal event history, for Abide.Rent support staff only.
  • Links for people without an account. There is no government API for the PRS Database, so nothing can be filed. An assistant uses prepare_prs_registration and the landlord registers on GOV.UK; a tool named for registering would invite an assistant to say a property was registered when it was not (GAP-FIX G7).
Rules we do not bend

The model is another client

The person's permissions, nothing more

A tool calls the same API as the app, as the person who connected it, in the one account they chose. Seat roles, legal holds and plan limits apply exactly as in the app.

Read only, or read and make changes

The person chooses on the consent page. A read-only connection never sees a tool that changes anything, and the API refuses one if it is tried.

Isolation still applies

An agency connection will not see a dual-role landlord’s other tenancy. Roles stay separate.

The owner decides

For an agency or landlord account only its owner can connect an assistant, because tenants’ details go to the assistant’s provider. Each person can see and remove their connections.

Serving and signing are never tools

An assistant can draft, check and prepare. Signing and serving a notice, and signing a document, stay with a named person in the product.

Not legal advice

A model that quotes the ledger is still not a solicitor. Check every form against the current version on GOV.UK before you serve it.

For language models, today

Read these first

mcp.json

Discovery file: the server address, the protocol versions, how sign-in works, and every toolset.

/mcp.json

llms.txt

A short map of the public site for language models.

/llms.txt

llms-full.txt

Longer excerpts of the same pages. Still not legal advice.

/llms-full.txt

OpenAPI 3.1

The product API contract the tools call. There is no /serve route.

/openapi.json

MCP and AI questions

Do you have an MCP server?

Yes. Add https://mcp.abide.rent/mcp as a custom connector in Claude, ChatGPT or Cursor and sign in. Every API operation an assistant may use is a tool. The assistant works in one account, with your permissions, read only or read and make changes as you choose. Serving or signing a notice, payments and changing who has access are never tools. Abide.Rent is not listed in connector directories.

Can my AI assistant make changes, or only read?

You choose when you connect it. Read only lets it look things up and report. Read and make changes lets it also log repairs, add notes and tasks, record payments, raise contractor jobs and send reminders, within what your role allows. Every change is recorded under your name. To switch, remove the connection and connect again.

Can the assistant use Abide.Rent together with Gmail, Outlook or Xero?

Yes, if your assistant has those connectors too. Claude or ChatGPT can, for example, read which certificates expire from Abide.Rent and draft the emails in Gmail, or check the rent roll against payments in your accounts software. Each connector is approved separately in the assistant, under that provider’s terms.

Can I connect an assistant with an API key instead of signing in?

No. The MCP server only accepts assistants that sign in as a person, so every action has a named person, their chosen account and their chosen access. API keys are for the REST API, for systems rather than people.

Which plan do I need to connect an AI assistant?

Portfolio or the free trial, for an agency or landlord account; only the account owner can connect one. Tenants can connect an assistant to their own tenancy free.

Can ChatGPT or Claude serve a notice?

No. Serving a notice is never available through the API and will never be an MCP tool. A person records service in the product.

Where should a language model read from?

Start at /llms.txt, then /llms-full.txt for longer excerpts. The product API is described at /openapi.json and /platform/reference. Nothing here is legal advice. Tribunal figures need the Open Government Licence attribution.