AskRentAI

Get Tenant Notes

get_tenant_notes

Read-onlyIdempotent

History notes logged on a tenant — the running staff commentary.

Pulls /Tenants/{id}/HistoryNotes (rent-increase notices, payment arrangements, manager comments) newest-first — context not visible elsewhere. Find the TenantID with list_tenants. limit caps the notes shown (default 30, max 200).

``location`` (optional): a Rent Manager Location ID, a comma-separated
list, or ``"all"`` to run across every Location on this connection (see
``list_locations``). Blank = all Locations if the connection has several,
else its only Location. Output is labelled per Location; a Location that
can't be reached is listed as skipped. IDs (property, tenant, ...) belong
to one Location, so pass that Location when you filter by one.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tenant_id": "<tenant_id>"
    },
    "name": "get_tenant_notes"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`location`	No
`tenant_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / location

Added value: +{
+  "default": "",
+  "title": "Location",
+  "type": "string"
+}

First observedOct 19, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description still adds substantive behavior: newest-first ordering, a default of 30 with a hard cap of 200, and the multi-location fan-out semantics where blank means all locations on multi-location connections, results are labelled per location, and unreachable locations are reported as skipped. The only gap is that pagination beyond the limit and error handling are not described.

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?

Front-loaded with the resource and the endpoint, then the key ordering and limit facts, then the location caveats. Every sentence — including the note examples and the 'IDs belong to one Location' warning — carries information an agent needs to call this correctly; no filler.

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?

Output schema exists, so return shape need not be repeated; the description instead spends its budget on the genuinely hard part of this tool, the multi-location fan-out and its skip semantics. For a read-only three-parameter getter, nothing an agent needs is missing.

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

Parameters4/5

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

Schema coverage is 0%, so the description must carry the parameter burden, and it does for two of three. 'limit' gets a default and maximum, 'location' gets accepted forms (single ID, comma-separated list, "all", blank fallback) plus the important warning that IDs belong to one location. 'tenant_id' is only implied through 'Find the TenantID with list_tenants', with no statement of type or format.

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?

States a specific verb and resource ('History notes logged on a tenant — the running staff commentary'), names the endpoint, and enumerates the note types (rent-increase notices, payment arrangements, manager comments). This clearly separates it from get_tenant, get_tenant_ledger and get_tenant_udfs, which cover identity, money and custom fields rather than narrative history.

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?

Gives a positive routing rule — 'context not visible elsewhere' — and tells the agent to resolve the tenant key via list_tenants and the location via list_locations. It does not explicitly exclude the sibling tools that also read tenant data, but the implicit guidance about what only this tool returns is strong and actionable.

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

All AskRentAI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?