What's new in the
Strata MCP Server.

An update sends the whole record, and each action now says so. Correcting an owner’s details, updating a supplier, adding or updating a tenant, and correcting a supplier invoice each send Urbanise the complete record — so a detail left out of the request is cleared rather than kept as it was. All four now state that in their own description, and all four are marked as able to destroy something, so your assistant confirms with you before running one. In 1.1.2 each of the four published itself as safe; that is corrected here.

Updating a lot keeps what you leave out. Of the five actions that update a record, a lot is the one where Urbanise preserves a detail the request doesn’t mention. Its description now says so in its own right, rather than leaving the behaviour to be assumed from the others.

Correcting a supplier invoice sets its payment method and status each time. An entered supplier invoice can’t be read back before it’s written — Urbanise offers no lookup for one — and it requires both a payment method and a status on every update, so an update writes those two rather than preserving what the invoice already carried. Worth knowing where the payment method on an invoice matters.

An update names every detail it needs, all at once. A supplier needs a name, a status and at least one licence. An owner needs the name on title and a phone number. A lot needs its type and both unit entitlement figures. A tenant needs a phone number, and either a company or a first and last name. A supplier invoice needs an amount above zero, a plan, a payment method, a status and a supplier. Where one is missing you’re told which — all of them together, rather than one per attempt.

A tenant with no phone number on file stays as it is. Urbanise requires a phone number on a tenant update and accepts neither an empty one nor a placeholder, so a tenant recorded without one can’t be updated through the server for now.

A lot update leaves the building number alone. Urbanise declines a lot update that carries one, so the action’s description names it as a detail to leave out.

No change to what you can ask for. Still 90 actions covering all 139 Urbanise operations. Five of them — the four above and updating a lot — changed their published description in this release. If you’d like your organisation’s server, register your interest and we’ll be in touch.

A detail the server doesn’t recognise inside a record is refused rather than dropped. From 1.1.1, a filter or field name an action doesn’t use is refused rather than quietly ignored. That check read the details named alongside a request — and for every action that changes something the record itself arrives as one such detail, so anything nested inside it went unread. The check now reads inside the record too, and inside each entry of a list within it. A refusal names the exact position — the licence number on the first licence, say — and lists what that part of the record accepts, rather than what the action accepts overall. Insurance policy details, which are free-form by design, are left as they are. As in 1.1.1 this is a deliberate change: a detail that doesn’t exist comes back as an error, in place of a success that had quietly omitted it. Offline, 516 automated checks pass, 13 more than 1.2.0.

Receipting and payment runs stay unavailable. Receipting a levy or an invoice payment remains switched off, and payment runs stay closed. Both stay that way until they can be verified end to end.

The server now publishes four measurements of its own work. How long each action takes, recorded by name and by whether it succeeded; how many audit entries were written; how many were dropped; and how many requests the server declined to send. These are the numbers behind questions like whether the audit trail is keeping up — until now answerable only by reading raw activity after someone already suspected a problem. The measurements carry no plan number, no record identifier and no personal detail; those stay in the audit trail, where they belong.

No change to what you can ask for. Still 90 actions covering all 139 Urbanise operations, described exactly as they were in 1.1.2, and deployments still run read-only in early access while write operations continue to be verified against a live tenant. An existing connection keeps working across this release. If you’d like your organisation’s server, register your interest and we’ll be in touch.

A request for the audit trail covers up to 92 days at a time. In its detailed form the trail is gathered a day at a time, so a request spanning years became thousands of lookups inside a single action. Ninety-two days is a full quarter with room either side, and a longer history comes back over successive requests.

An update to the server waits for work already in progress. Shutdown now allows up to 90 seconds for anything in flight to finish, so a deployment can’t cut off a change to your portfolio part-way through. Most things you create in Urbanise can’t be removed afterwards, which makes an interrupted change the one worth ruling out.

The server now sets its own ceilings, deliberately. Sign-in requests are capped per caller, so a flood of guesses can’t be sustained and can’t lock out your own connection. The availability check answers from a short-lived cache rather than calling Urbanise afresh every time it’s asked. No more than sixteen requests to your portfolio run at once, with anything beyond that declined rather than held open. Request bodies over 32 MB are refused, and a rejected sign-in records only a bounded identifier. Ordinary use sits nowhere near any of these — a connection mints a token once and refreshes about hourly. Offline, 503 automated checks pass, 25 more than 1.1.2.

Every audited action is recorded, including under a burst of activity. Audit entries are now written in groups rather than one at a time, so sustained activity is captured in full. The daily tidy-up of expired entries works the same way and finishes in moments, so recording continues throughout rather than pausing while it runs.

Nothing in this release moves money. Receipting a levy or an invoice payment stays unavailable, and payment runs stay closed. Both remain switched off until they can be verified end to end.

A clear message when Urbanise can’t be reached. If the strata platform is unavailable, the reply names that as the reason and says whether your request was sent — the distinction that matters when the request would have changed something. Signing in retries by itself through a momentary blip, so a brief hiccup doesn’t fail the action you asked for.

A struggling connection is given room to recover. When calls to Urbanise start failing consistently, the server pauses briefly rather than adding to the load on a platform already in difficulty, then resumes on its own.

Raising a supplier invoice sends only the details you give it. Every action but this one shares a common way of building its request; raising a supplier invoice takes its own path because of how the attachment has to be sent, and it now builds its request the same way as the rest — details you didn’t supply aren’t sent as blanks. Confirmed by an automated check; no live invoice has yet run on this release.

Eleven more changes to your portfolio, confirmed against a live one. Twenty-five of the 44 actions that change something have now succeeded against a real strata portfolio, up from fourteen. Creating an owner; the full add–change–remove cycle for an owner’s associated contact; recording the sale of a lot; updating an owner; updating a supplier; adding a supplier; and the whole common-property rental chain — creating and updating a rental agreement, and raising the next rental invoice. Each was confirmed by a live call with the record read back afterwards. The count tracks how far the write path now reaches; verification of the remaining actions continues.

A missing detail is named before the request is sent. A supplier licence needs a type, a number and an expiry date; a one-off levy needs to say which kind of levy it is. Where one of those is missing, you’re now told which one straight away, rather than after a round trip.

Three requirements are now documented rather than discovered. Updating an owner needs a contact phone number. Recording disbursements needs a chargeable quantity alongside the three details already noted, and remains unavailable for now. Raising a one-off levy now returns a clear message naming the detail it needs. Each sits in the action’s own description, so your assistant can see it before it asks.

No change to what you can ask for. Still 90 actions covering all 139 Urbanise operations, and deployments still run read-only in early access while write operations continue to be verified against a live tenant. Every one of the 90 actions refreshed its published description in this release. If you’d like your organisation’s server, register your interest and we’ll be in touch.

Every action now publishes what it will and won’t do. All 90 declare whether they only read, whether they can destroy something, and whether running one twice is safe — and each states that it accepts only the details it names. What the server accepts is unchanged; what’s new is that the published description says so, so your AI tool can catch a mistake before making the call rather than after. Offline, 478 automated checks pass, 25 more than 1.1.1, and the whole published surface was re-checked by an independent schema validator — 172 schemas, no failures.

Nothing in this release moves money. Receipting a levy or an invoice payment stays unavailable, and payment runs stay closed. Both remain switched off until they can be verified end to end.

Broader compatibility across AI clients. Two actions — creating and updating an insurance policy — described the shape of their result in a way that stricter MCP clients don’t accept, and because a client of that kind validates the whole action list before offering any of it, those clients couldn’t load the server. Both now describe their result the same way every other action already did, so the full surface loads on strict and lenient clients alike. claude.ai was unaffected either way.

Adding a supplier now works. Every licence on a supplier needs a type, a number and an expiry date — all three, on each licence. With those supplied the action completes cleanly, confirmed by read-back against a live portfolio. Worth knowing if you compare against the Urbanise web application, which will save a licence with no expiry date where the API asks for one.

Updating a tenant or a supplier invoice needs one identifier, not two. Both actions take an identifier and the whole record, and Urbanise expects the record’s own id in both places. They now fill that in from the identifier you gave, and flag a mismatch if the two disagree, so a straightforward update goes through first time.

A test suite that runs itself across the whole action surface. 390 checks against a live portfolio, re-runnable on demand, and from this release the main way the server is checked rather than someone working through a plan by hand. It also grades a check that expected a refusal, so an action that wrongly succeeds is reported in its own right rather than folded into a pass count. Offline, 453 automated checks pass, 49 more than 1.1.0.

Actions now state the details they need. Creating an owner, disbursements, an insurance policy, a task or a user, and updating an insurance policy or an invoice, each need details that aren’t marked as required. Every one of those actions now names them, with the date it was last confirmed, so your assistant can supply them first time.

Reading a budget isn’t available yet. Listed in 1.1.0 as declined upstream, and re-tested this release to confirm it. It stays listed as unavailable and we’ll revisit it.

Payment gateway details need a configured gateway to confirm. The reading comes back as “no details exist” on every plan we test against, which is consistent with none being configured there. It stays open until it can be checked against a portfolio that has one.

No change to what you can ask for. Still 90 actions covering all 139 Urbanise operations, and deployments still run read-only in early access while write operations continue to be verified against a live tenant. The wording of many actions changed in this release. If you’d like your organisation’s server, register your interest and we’ll be in touch.

A detail the server doesn’t recognise is refused rather than ignored. If your assistant sends a filter or field name an action doesn’t use, that detail used to be dropped without comment — so owners named Clara and all owners returned the same list, with nothing to tell you which you had. Those requests are now refused, naming the detail and the spelling the action expects, so a filtered answer is genuinely filtered. Every reference to those names across the server — descriptions, error messages and instructions alike — was made consistent at the same time.

An empty record reads as empty. Where Urbanise legitimately returns nothing — a plan with no manager, for instance — that now comes back as an empty answer. This covered a whole class of reads rather than a single one.

A plan number that doesn’t match now says so. Ask for a plan that doesn’t exist and you’re told the plan number wasn’t found, so a typo is obvious straight away.

A record that already exists is described as such. Where a change is declined because the record is already there, the answer now names the clash rather than reporting the record as missing.

Three actions now state a detail they require. Each needed something its description didn’t mention; all three now name it, so your assistant supplies it up front.

Every failure returns a plain-language message and a reference. Whatever the cause — a request that wasn’t well formed, or something outside what we had anticipated — you get something readable, and a reference you can quote to us.

Thirteen write actions confirmed against a live portfolio. Creating and updating plans and lots, the full add–change–remove cycle for a user account, creating a tenant, creating a task and attaching a document to it, creating and updating an insurance policy, and attaching a document to an invoice — all now confirmed working against a real strata portfolio rather than a test double. Verification of the remaining write actions continues.

A record of what your assistant did. Every action taken through the server can now be recorded — who asked for it, which action, and what came back — and read back simply by asking. Urbanise keeps no history of this itself, so this is the only place that answer exists. It stays switched off until your organisation turns it on, and nothing is recorded before then. That’s the 90th action, and the only one that doesn’t touch Urbanise.

A declined request now tells you which field to fix. Where you previously saw only that Urbanise had refused the request, you now get the reason it gave. Urbanise reports validation problems in several different formats, and all of them are now read and passed on in plain language, along with the explanation it gives when something fails on its side. One endpoint returns no explanation at all, so for that one there is still nothing to pass on.

Clearer instructions on what each action needs. Creating a task now states up front that an assignee is required, and that it is an email address. Updating a lot and recording disbursements name the details they need, and owner lookups now point at the building-scoped search that matches names properly. Fewer requests are declined for a missing detail that was never asked for.

A small number of operations aren’t available yet. Creating an owner, a supplier or disbursements, creating and updating a supplier invoice, and reading a budget are declined upstream for now. Rather than leaving these to be discovered, they’re documented as unavailable, and we’ll revisit them as the API develops.

Early access, running read-only. Deployments run read-only while write operations continue to be verified against a live tenant. If you’d like your organisation’s server, register your interest and we’ll be in touch.

Every change is sent exactly once. A create, update or delete is now sent once and once only. It is never repeated when Urbanise is slow to answer or reports a problem, because a reported problem is not proof the change wasn’t applied — so there is no path to a duplicate record. Confirmed across every write in the verification pass: one action, one request.

Read-only stays read-only across updates. The two independent gates on writes are held on the deployment itself and are unaffected by routine updates, so what a connection is permitted to do no longer changes underneath you mid-session. Both gates must be deliberately opened before anything can be written, and closing them is a deliberate act too — worth knowing if you open them for a particular piece of work.

Payments and receipting stay closed. The receipting and payment-run actions are not available for use — they need more than the API currently exposes, and a payment batch can’t be created through it. Importing bank transactions is disabled permanently and will not be called — it is the one operation that carries no portfolio identifier, so we don’t rely on the usual wrong-portfolio safeguard to catch a misconfiguration. Nothing in this release moves money.

Attaching documents. Documents now state what kind of content they hold, which is what Urbanise needs in order to accept them. Uploading a document to a task, or against an invoice, is confirmed working live — both ways an invoice can be identified.

Insurance details are checked before they’re sent. The two insurance actions accept policy details only in the correct shape, so a malformed request is caught here rather than coming back as a puzzling error from Urbanise. Creating and updating a policy are both confirmed working.

89 things you can ask for, across the whole portfolio. Plans, lots, owners and committees; levy summaries, lot ledgers and arrears; budgets, funds, investments and disbursements; suppliers, preferred and blacklisted lists, insurance and work orders; tenants, common property and rentals; tasks, invoices, receipts and payment runs. Everything in the User Guide, in plain language.

Every Urbanise operation is covered, without 139 near-identical actions. Urbanise exposes most operations two or three times over — by plan number, by external reference, sometimes by property id. Those are collapsed into one action each, so your assistant picks the right one instead of guessing between three that look the same. All 139 operations are reachable through 89 actions.

Connect from any compliant AI client, unaided. The server runs its own secure sign-in, so a client like the claude.ai connector completes the whole connection on its own — no token pasted in out of band, and the connection survives its access lapsing rather than dropping you mid-session. Services that run unattended can still authenticate directly with a client id and secret.

Owner search points you at the one that matches names. Urbanise's portfolio-wide owner-name search doesn't match against the owner names it returns, so an empty result there now comes back with an advisory rather than a bare "no results" — your assistant redirects you to the building-scoped search, which matches names correctly, instead of reporting an owner as absent.

Failures come back as advice, not stack traces. When Urbanise refuses something, the reason is translated into something you can act on. Internal detail is logged on the server and never returned. Rate limits are honoured automatically, and long lists come back paged with an honest indication of whether there's more.

Early access is open. This first version is deployed and connected, running read-only while write operations are verified against a live tenant. If you'd like your organisation's server, register your interest and we'll be in touch.

Two independent gates on anything that writes. A connection holds either read access or read-and-write access, and separately, a whole deployment can be switched to read-only without touching a single credential. Either one alone stops every change; both have to be open for anything to be written.

A read-only connection can't even see the write actions. They're filtered out of the list your assistant reads, so it never offers something it isn't permitted to do — and never has to be trusted not to try. Verified on the staging deployment: 45 actions visible, and a write action refused outright when called directly anyway.

Eight actions are flagged as irreversible. Deleting an accrual, removing an owner's associated contact, deleting a user, and the five payment-run state changes are annotated so your assistant requires explicit human confirmation before any of them. Money movements — receipting levy and invoice payments, dispatching a batch — can't be reversed through the assistant either, and say so up front.

It can only ever reach your own portfolio. The strata client the server acts on comes from its configuration and is never something a request can supply. A test enforces that no action exposes it, so there's no path — accidental or otherwise — to another management company's data.

Only the actions you need. The server is organised into 16 groups, and any group can be switched off for a deployment. A manager with no need for payment-batch handling or user administration has those removed entirely, rather than relying on nobody calling them.

Credentials never sit in the open. Secrets live in a managed vault and are read with a managed identity — nothing in a repository, nothing in plain configuration. Passwords, client secrets and access tokens are never written to a log, and a test enforces it. Rotating one signing key immediately invalidates every outstanding connection.

The health check performs a real read. The readiness check now makes a genuine read against your tenant before reporting ready, rather than only confirming that credentials are present — so a deployment has to prove it can reach Urbanise to pass its release gate.