Skip to main content

MCP Server

The Skywalk MCP server lets Claude read your AppFolio® portfolio. Once connected, Claude can answer questions about your properties, tenants, leases, and financials in plain English.

Setup guides​

To connect your AI Assistant, please refer to the setup guides:

The rest of this page describes how our MCP server works.

How it works​

Our MCP gives your AI Agent new tools to query your AppFolio® data. Skywalk allows the agent to pull data on properties, units, vacancies, rent rolls, tenants, and financial statements. Our server gives Claude general-purpose tools for fetching data:

Tools

Claude knows to sequence these tools on its own, it calls:

  1. skywalk_list to see what's available, then
  2. skywalk_describe to learn a report's parameters and columns, then
  3. skywalk_read to pull the data. You don't need to call the tools yourself — you just ask a question, and Claude picks the right tools to answer.

Two ways to narrow your data​

Every report can return a lot of rows. There are two complementary ways to get to just the numbers you care about, and Claude chooses between them for you:

  • Report parameters (params) — filters applied on the server before the data is fetched, such as a single property or a date range. These are the cheapest and fastest way to narrow results, so prefer them whenever possible. Each report defines its own parameters (some are required, some are "one of these"); skywalk_describe lists them.
  • SQL (sql) — a query applied to the rows after they are fetched, for filtering, projecting specific columns, or aggregating (totals, averages, group-by). Use SQL when you want to summarize or transform the data rather than just narrow it.

A good rule of thumb: use parameters to reduce how much data comes back, and SQL to shape or summarize what came back.

Shaping results with SQL​

When Claude passes a sql query to skywalk_read, it runs against the fetched report as a table named report. The full SQL dialect is available — column selection, WHERE filters, GROUP BY, aggregates, window functions, and CTEs — so questions like "total NOI by property this quarter" or "the five units with the highest balances" resolve in a single call.

A few things to know:

  • Read-only. Only SELECT-style queries are allowed. Anything that would modify data is rejected.
  • Reference the table as report. For example: SELECT * FROM report WHERE balance > 0.
  • Money and percentages are numbers. Columns that AppFolio® formats as text — like $1,234.56 or 12.3% — are converted to plain numbers so that SUM(), AVG(), and comparisons work directly. This means those values come back as numbers (e.g. 1234.56) rather than formatted strings.

What you get back​

  • Results are CSV. Each response has a header row of column names, a short preamble line showing the report and row count, and — when the report has report-level totals — a Summary: line.
  • Retrieval errors. Reports are returned in full. If a result is too large to return, the server responds with an error that tells you the row count and size and suggests how to trim it (narrow the params, add a LIMIT, or aggregate with SQL). If you ask a broad question and get a size error, narrow to a single property, or instruct your assistant to work through the data smaller chunks (shorter date ranges, individual properties, etc.)
  • Freshly synced data. A result tagged status: updating means AppFolio® was still syncing when Claude read it; retry in a minute for final figures. Figures are read live and can lag AppFolio® by a few minutes.
  • Dates are US MM/DD/YYYY in both what you provide and what you get back (e.g. 07/10/2026).

Security & best practices​

  • Keep your API keys private. Treat it like a password. Anyone who has it can read your AppFolio® data through Claude.
  • Narrow broad questions. Because reports return in full, a portfolio-wide question over a long date range can pull a large amount of data. Scoping to a property or a date range keeps answers fast and avoids size errors.