Skip to main content
Glama
blackwaxxx

buildium-mcp

by blackwaxxx

Buildium List Gl Accounts

buildium_list_gl_accounts
Read-onlyIdempotent

Get general ledger account IDs needed to post rent charges and financial transactions. Specify all_pages when counting or aggregating.

Instructions

List general ledger accounts. You need these IDs to post rent charges and other financial transactions.

Set all_pages=true when counting or aggregating.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
fieldsNo
offsetNo
all_pagesNo
exclude_fixturesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already cover the safety profile via readOnlyHint, idempotentHint, and destructiveHint. The description adds the all_pages hint and downstream ID purpose, but does not elaborate on pagination behavior, field filtering, or fixture exclusion. No contradiction with annotations.

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?

Two sentences with no filler: the first states the core purpose and why it matters, the second gives a single actionable parameter rule. The key information is front-loaded and every sentence earns its place.

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

Completeness4/5

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

For a read-only list tool, the purpose and the important all_pages behavior are covered, and the annotations plus output schema supply the safety and return-value context. The unexplained auxiliary parameters prevent a 5, but the description is sufficient for basic correct invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but only all_pages gets semantic guidance. The other parameters — limit, offset, fields, and exclude_fixtures — are left to their names and defaults, which is a clear gap for a five-parameter tool.

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?

Description leads with a specific verb and resource ('List general ledger accounts') and immediately clarifies the downstream use ('You need these IDs to post rent charges and other financial transactions'). This differentiates it from sibling list tools by domain and purpose.

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

Usage Guidelines4/5

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

The second sentence gives a clear conditional usage instruction: 'Set all_pages=true when counting or aggregating.' This provides actionable context for a key parameter, but it does not discuss when to avoid this tool or point to alternatives, so it stops short of a 5.

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