Letivo used NitroStack to expand its MCP server around the questions letting agents actually ask, bringing portfolio health, arrears, rent collection, viewings, and applications into one conversational, read-only workflow.
What this enables
- A letting agent can ask for a company-wide portfolio overview and get occupancy, arrears, and expiring leases in one answer.
- Arrears cases return already ordered by urgency, not as an unsorted list of overdue payments.
- The applications pipeline surfaces stalled and compliance-sensitive cases, such as an approved application still missing a right-to-rent check.
- Every read respects Letivo's existing per-user role and branch permissions — the MCP layer creates no new view of the data.
Adding tools because a question exists, not because an endpoint does
Letivo already had an MCP server before this project — eight tools against a REST API of roughly 200 endpoints. That was enough to prove an AI client could reach the system, but proving reachability isn't the same as making the experience useful to a letting agent trying to figure out what needs attention on a Monday morning.
The Phase 1 expansion started from five recurring operational questions instead of the API's structure: how is the portfolio doing, who is in arrears, how is rent collection tracking, which viewings need attention, and what's happening in the applications pipeline. The result is a read-only MCP layer shaped around a letting agent's working day, not around Letivo's endpoint list.
A portfolio overview has to combine data that lives in different places
Property count alone says very little. An agent needs occupancy, active leases, arrears, upcoming lease expiries, and viewing activity together, and those pieces usually live in different parts of a property management system. get_portfolio_overview does that aggregation before the model sees anything, so a broad question like "give me a company-wide overview and show me anything that needs attention" doesn't require the model to reconstruct the picture from raw records.
In the synthetic demo snapshot (dated 1 September 2026), the fixture portfolio shows 8 properties, 12 units, 8 occupied and 4 vacant, 8 active leases, 4 tenants in arrears, 2 leases expiring within 60 days, and 3 upcoming viewings. Those numbers are fixture data, not live customer figures — their purpose is demonstrating what one call can bring together, not proving a specific portfolio size. A portfolio widget presents the result as an operational view rather than a JSON dump.
Arrears, ordered for action rather than just totaled
Knowing the total overdue rent is useful. Knowing which case to look at first is more useful. get_arrears_summary returns the relevant cases ordered around urgency rather than as a flat list — in the demo fixture, four synthetic tenants account for £6,237.50 in arrears, with the highest-priority case at £2,700 and 62 days overdue.
That result can lead into get_rent_collection_summary, which reports how collection is tracking for a given month — the fixture shows £3,800 expected against £2,875 collected for August 2026, a 75.7% collection rate — and from there into list_rent_payments for the underlying overdue records, deliberately excluding payment methods and tenant contact data even where the source system contains them. The sequence — portfolio alert, arrears position, monthly collection, underlying payments — lets the conversation move from summary to detail without the agent needing to know which endpoint holds which piece.
Viewings and applications need context, not another record list
A list of every viewing isn't the useful answer; which upcoming viewings need attention is. list_viewings filters for the relevant period and status, keeping cancelled records from inflating the count and surfacing requested-but-unconfirmed viewings as something worth acting on.
Applications have the same problem in a different shape. A pipeline of six applications is easy to count and easy to skim past — it takes more attention to notice that one has sat in referencing for 12 days, or that an approved application is still missing a right-to-rent check. list_applications is built to preserve that context: in the demo, the pipeline shows two new applications, one in referencing, one approved, one rejected, one converted, with the stalled referencing case and the compliance gap both flagged. That turns "show me the applications" into "show me what in the pipeline deserves attention" — a more useful question for an agent to actually ask.
Where NitroStack fits
Letivo's property management system stays responsible for the property, tenancy, payment, and lettings data. The MCP application's job is deciding which parts of that data reach the AI, how they're grouped, and how the result is presented — and that's where the NitroStack SDK fits. The Phase 1 expansion groups tools into Portfolio, Finance, and Lettings modules rather than mirroring roughly 200 REST endpoints one by one, and four read-only widget surfaces — portfolio overview, arrears summary, lettings pipeline, viewings diary — sit directly on top of the tool responses through NitroStack's Widget SDK. A portfolio summary reads better as a compact panel; arrears benefit from visible prioritization; viewings belong in a diary view. The model can still explain a result in conversation — it just doesn't have to redraw the product in prose.
Permissions and boundaries stayed exactly where they were
Property data isn't something an MCP client should receive without knowing who's asking. In live mode, Letivo keeps its existing per-user API key authentication along with its role and branch permission model, so the MCP layer doesn't create a new universal view — a company-wide question like "show me our arrears" still resolves against whatever branch and organizational scope that specific user is permitted to see.
Phase 1 is also deliberately read-only: no maintenance actions, no write operations, nothing that changes a lease, an application, or a payment. The goal for this phase is visibility, which keeps the expansion easy to reason about and leaves write workflows for a later phase where preview, confirmation, and consequence can be designed properly.
Fixture mode keeps the demo real without real data
The project runs an explicit fixture-only mode (LETIVO_MODE=fixtures) that uses a synthetic snapshot instead of a live Letivo connection — no credential required, and every demo value belongs to the controlled fixture set. Widgets carry a synthetic-data badge rather than relying on a presenter to mention it. That matters because property records routinely contain financial and personally identifiable information, and a product demo shouldn't need a real agency account just to show that an arrears widget works. The server can also connect locally to NitroStudio, where MCP calls and their widget responses can be tested together.
Reusable takeaway
The useful pattern in Letivo's expansion is the change in abstraction, not the tool count. A platform can have roughly 200 REST endpoints and still let an agent ask "what needs attention across the portfolio" in plain language — as long as someone deliberately groups the underlying data around the questions people actually ask, keeps existing permissions intact, and reaches for a visual surface wherever reading rows of JSON would only slow the user down.
Teams building a similar layer on top of an existing operational API can look at the NitroStack SDK and NitroStudio for grouping tools and widgets around real workflows rather than endpoint structure.