buildium-mcp

Buildium Get

buildium_get

Read-onlyIdempotent

Fetch data from any Buildium API endpoint without modifications. Use for read-only access, filter fields, paginate, or count records.

Instructions

Read any Buildium endpoint (GET). Cannot change anything.

Use this for every read that has no curated shortcut. It is a separate tool from buildium_call_endpoint so that a client can approve reads once and still ask about each write.

Input Schema

TableJSON Schema

Name	Required	Description
`path`	Yes	Buildium API path, e.g. "/v1/vendors" or "/v1/leases/12345".
`query`	No	Query-string parameters, e.g. {"statuses": "Active"}.
`fields`	No	Keep only these top-level fields in each record, e.g. ["Id", "Name"]. Buildium records are large and carry tax IDs and addresses you may not need.
`all_pages`	No	Follow pagination and return the records, up to 1000. Use it for totals and other aggregates; a figure from one page is wrong whenever there is more than one page.
`count_only`	No	Follow every page, up to 100,000 records, and return only how many there are. Use it for "how many" questions.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.2.1Sep 24, 2026

addedInput schema / properties / all_pages / description

Added value: +"Follow pagination and return the records, up to 1000. Use it for totals and other aggregates; a figure from one page is wrong whenever there is more than one page."

addedInput schema / properties / count_only / description

Added value: +"Follow every page, up to 100,000 records, and return only how many there are. Use it for \"how many\" questions."

addedInput schema / properties / fields / description

Added value: +"Keep only these top-level fields in each record, e.g. [\"Id\", \"Name\"]. Buildium records are large and carry tax IDs and addresses you may not need."

addedInput schema / properties / path / description

Added value: +"Buildium API path, e.g. \"/v1/vendors\" or \"/v1/leases/12345\"."

addedInput schema / properties / query / description

Added value: +"Query-string parameters, e.g. {\"statuses\": \"Active\"}."

Addedv0.2.0Sep 23, 2026

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is fully known. The description repeats 'Cannot change anything' and adds the approval-workflow rationale, but it does not add new behavioral detail such as error behavior, rate limits, or response characteristics beyond what schema/annotations already imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences achieve a lot: they state the domain, the safety constraint, the usage rule, and the distinguishing rationale versus the write-capable sibling. There is no filler or repetition that does meaningful work.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generic endpoint-reading tool with 5 richly described parameters, an output schema, and strong annotations, the description is complete enough. It would be hard for an agent to misuse this tool for a read when a curated shortcut is available, or to confuse it with the write-capable endpoint tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are already well documented. The description adds no parameter-level meaning beyond the schema, which is the expected baseline when the schema carries the full burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Read any Buildium endpoint (GET).' It immediately distinguishes itself from curated read shortcuts and from buildium_call_endpoint, so an agent can tell exactly what this tool is for. The phrase 'Cannot change anything' reinforces the read-only scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance: 'Use this for every read that has no curated shortcut.' It also explains the split from buildium_call_endpoint in terms of client approval of reads versus writes. This clearly routes an agent between generic reads, curated reads, and write calls.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.