What's new in the
Strata MCP Server.

Sending a large document. A scanned multi-page invoice, a full condition report, a set of building plans — a document past about 10 MB now travels by its own route rather than inside the message to your assistant. Your assistant asks for a one-time address, the file goes straight to it from where it already sits, and what landed comes back confirmed, checked byte for byte. Anything smaller carries on exactly as before. A large document can go against a supplier invoice you’re entering, against a plan, or against a task.

Five document actions say more about what they do. Entering a supplier invoice, uploading a supporting document and attaching a document to a task each name where the 10 MB line sits and what happens above it. Uploading a supporting document and setting up a large upload each also say what naming an existing invoice really does. No parameter changed and the 10 MB inline limit is unchanged.

A document sent against an invoice already entered arrives in an allocation queue. Naming an invoice that already exists puts the document in Urbanise’s For Allocation list rather than on the invoice, and it waits there for someone to place it by hand. There is no way through the API to attach a document to a supplier invoice already entered — the two actions that offer it now say so plainly and point at the plan instead, which creates the payable with the document already on it. That is the route for a scanned invoice arriving for the first time. In 1.1.0 uploading against an invoice was described as confirmed working; that is corrected here.

A large document is confirmed by its contents. The answer carries a fingerprint of the bytes that arrived, alongside the size and the record they went against, so the document in Urbanise can be checked against the one on your machine rather than taken on trust.

The ceiling is about 20 MB, and it is measured rather than assumed. Urbanise accepts a document up to a little under 20 MB, established by sending files of known size until the line was found, and a deployment now ships set to the largest size proven to pass. A file above it is refused before any of it is sent, and the refusal names the size of the file and the size of the limit side by side. The 32 MB ceiling on an ordinary request, set in 1.2.0, is unchanged and unrelated.

No change to what you can ask for. 91 actions covering all 139 Urbanise operations — one more than the last release, and the new one is the second that doesn’t touch Urbanise itself. Updating a supplier stays withheld, so 90 can be called. Five actions changed their published description. If you’d like your organisation’s server, book a demo and we’ll get you set up.

A large upload is authorised once, and briefly. The address issued for a document can be used once and expires fifteen minutes after it is given out. It carries the record it is for, so a document can’t be redirected to a different invoice or a different plan after the fact — and it is refused outright on a read-only deployment, or where large uploads are switched off for your organisation.

The document isn’t kept. It is held on the server only for as long as it takes to hand to Urbanise, then removed — whether the upload succeeded or not. Nothing of it is retained beyond the audit line recording that it happened.

An uncertain outcome is reported as uncertain. Where a document was sent in full and Urbanise then didn’t answer, or answered with an error, the reply says the outcome is unknown rather than reporting a plain failure. That distinction matters on a supplier invoice: a second attempt in that state is how a payable gets entered twice.

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.

Reading a plan’s budget now works. Every account in a fund, with the year’s budgeted and actual figures. A budget is asked for by the fund and by the date that fund’s financial year starts, because a sub fund can run a different year from the plan — a lift fund from 1 October, a car stacker from 1 November, where the plan itself runs July to June. Listed as unavailable in 1.1.0 and again in 1.1.1; available from this release.

Budget figures say which way they run. A negative figure is expenditure and a positive one is revenue other than levies, so a single account can appear twice in the same fund — once as a cost and once as a recovery. Account codes repeat as well: the same code can carry two quite different account names. Both are stated on the action, so a total built from a budget adds up the way a manager would add it.

A levy balance says which sign means owing. In Urbanise a negative balance is money owed and a positive one is credit — a levy raised or a penalty applied arrives negative, a receipt positive. The six actions that return a balance now say so: a lot ledger, a lot, a plan’s lots, an owner’s lots, and recording the sale of a lot or updating one.

Levies and penalties are separate running balances. A lot’s levy balance excludes penalties; the figure for the lot overall is the two added together. Worth knowing when quoting arrears, because penalties on foot are exactly when the difference matters.

Two ledger columns are named differently from the Urbanise screen. The administrative column is what Urbanise shows as “Administration”, and the sinking column is what it shows as “Maintenance”.

No change to what you can ask for. Still 90 actions covering all 139 Urbanise operations, with one — updating a supplier — withheld this release, so 89 can be called. Eight changed their published description. Creating a budget isn’t available, so entering a supplier invoice or accruing an expected cost still needs a budget set up in the Urbanise web application, and reading a provisional invoice stays unavailable while it’s checked again. If you’d like your organisation’s server, book a demo and we’ll get you set up.

Updating a supplier is withheld. Urbanise has confirmed that an update through its API clears three details it doesn’t return in the first place — a supplier’s email use, postal address and address use. Rather than rely on the warning carried in the action’s description since 1.2.1, the server declines the request before it is built, names the three details that would have been lost, confirms nothing in Urbanise changed, and points at the Urbanise web application, where the same edit is safe. The action stays listed, so the refusal comes with an explanation. It is held by its own gate, independent of the two on writes, and that gate is closed by default — a deployment can’t leave it open by omission.

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 failure with no explanation points at what to check. Where Urbanise declines a request and gives no reason for it, the reply now names the details that were sent as worth checking — a date in the wrong shape, or a fund named where a number belongs, lands here.

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, book a demo and we’ll get you set up.

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.

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.

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 a deployment ships read-only until your organisation opens both write gates. An existing connection keeps working across this release. If you’d like your organisation’s server, book a demo and we’ll get you set up.

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.

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. A detail you didn’t supply isn’t sent as a blank, so nothing you left alone is overwritten.

Eleven more ways to change your portfolio. 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.

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 a deployment ships read-only until your organisation opens both write gates. Every one of the 90 actions refreshed its published description in this release. If you’d like your organisation’s server, book a demo and we’ll get you set up.

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.

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. 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.

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. 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 a deployment ships read-only until your organisation opens both write gates. The wording of many actions changed in this release. If you’d like your organisation’s server, book a demo and we’ll get you set up.

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 ways to change your 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.

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.

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, book a demo and we’ll get you set up.

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.

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.

Deployed and connected. 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, book a demo and we'll get you set up.

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. A write action called directly is refused outright in any case.

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, and 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. Rotating one signing key immediately invalidates every outstanding connection.