Summary
When invoking the MCP server (tc-mcp install-style integration into a Claude Desktop/Cowork session) against a live TenantCloud account, four of the seven list_* tools fail with a generic An error occurred invoking '<tool_name>'. and surface no further detail to the MCP client. get_user_info and list_contacts work normally on the same session, same auth, same account — so the failure is endpoint-cluster-specific, not a connectivity, auth, or session issue.
Two parameter-handling bugs are also present and worth flagging in the same issue, since they're observable from the working calls.
Environment
TenantCloud subdomain: sagamore (Sagamore Management Co.)
Account type: company / multi-property landlord (sub-50 unit portfolio, southwest Florida)
MCP host: Claude Desktop / Cowork (single user session)
OS host of the MCP wrapper: macOS (Apple Silicon Mac mini)
Wrapper installed via the tc-mcp install flow per the project README
All calls below issued in a single uninterrupted session, same auth state
Working calls (baseline — confirms auth, session, and account are reachable)
get_user_info()
→ {"id":64190,"subDomain":"sagamore","email":"@sagamoremgt.com",
"firstName":"TenantCloud","lastName":"Forman","isCompany":true,
"company":"Sagamore Management Co.", ...}
list_contacts(role="tenant")
→ {"data":[ ...12 tenant records... ],"count":12}
list_contacts(role="professional")
→ {"data":[ ...12 vendor / contractor records... ],"count":12}
Failing calls (all return An error occurred invoking '...'.)
list_properties()
list_properties(maxResults=5)
list_units(occupancy="occupied", maxResults=3)
list_units(occupancy="vacant", maxResults=3)
list_leases(status="active", maxResults=3)
list_transactions(status="paid", category="income", maxResults=3)
list_transactions(status="overdue", category="income", maxResults=3)
The MCP wrapper surfaces only the generic An error occurred invoking ''. string — no HTTP status, no upstream response body, no exception type. Whatever the underlying client throws is being swallowed before it reaches the MCP transport. Surfacing the inner exception (or at minimum the HTTP status code and a short body excerpt) would make this kind of failure self-diagnosing for users.
For both list_units calls, the failure persists across both occupied and vacant values — so it isn't param-value-specific; the endpoint cluster itself is the issue.
For list_transactions, the failure persists across two valid status × category combinations — same conclusion.
Wrapper-level parameter handling: two bugs
- maxResults is silently dropped
list_contacts(role="tenant", maxResults=3) returns count: 12 with all 12 records in data. Same call with maxResults=100 returns the same 12. The parameter is either being dropped before transmission to the upstream endpoint, or the upstream endpoint doesn't accept it under the name being sent. Documented behavior in the schema description (Maximum number of results to return (default 100)) implies it should be a working pagination control.
- role on list_contacts may also be dropped
list_contacts(role="tenant") and list_contacts(role="archived") returned identical payloads — same 12 IDs, same status:2 on every record, same ordering. If role were being honored server-side, "tenant" and "archived" should not produce identical results. Three possibilities, in order of likelihood:
The wrapper is dropping the role parameter before transmission, just like maxResults, and the server is returning some default unfiltered or default-filtered view in both cases.
The wrapper is sending it under a parameter name the server doesn't recognize.
(Less likely) role=tenant and role=archived are server-side aliases for the same view, in which case the schema documentation needs to be corrected.
Either way, the published interface (four role values: tenant / professional / moved_in / archived) is not reflecting actual behavior.
Note: list_contacts(role="professional") does return a different 12-record payload (vendors instead of tenants), so some role-discrimination is happening. That's consistent with possibility 1 above if tenant happens to be the server's default and archived is unrecognized.
Repro
Any TenantCloud account where the company has at least one property, one unit, one active lease, and one paid transaction should reproduce the four failing calls. The two parameter-handling bugs reproduce on any account with more than one contact.
What would help
In rough priority order:
Surface the underlying exception. Even if the upstream endpoints are genuinely broken (TenantCloud changed their internal API shape, etc.), the wrapper currently hides the diagnostic information that would tell us which. Wrapping inner exceptions and forwarding the status / message would make this dramatically easier to triage.
Confirm whether the four failing endpoints are still functional against any live account in the maintainer's testing, or whether TenantCloud has recently changed shape on these routes. (TenantCloud has no public API contract, so changes are not announced.)
Audit maxResults and role parameter forwarding in list_contacts — both look like they're being dropped client-side, independent of the larger property/unit/lease/transaction problem.
Happy to provide additional repro detail (raw exception text from a direct .NET client invocation, packet capture of the upstream call, etc.) — let me know what's most useful.
Summary
When invoking the MCP server (tc-mcp install-style integration into a Claude Desktop/Cowork session) against a live TenantCloud account, four of the seven list_* tools fail with a generic An error occurred invoking '<tool_name>'. and surface no further detail to the MCP client. get_user_info and list_contacts work normally on the same session, same auth, same account — so the failure is endpoint-cluster-specific, not a connectivity, auth, or session issue.
Two parameter-handling bugs are also present and worth flagging in the same issue, since they're observable from the working calls.
Environment
TenantCloud subdomain: sagamore (Sagamore Management Co.)
Account type: company / multi-property landlord (sub-50 unit portfolio, southwest Florida)
MCP host: Claude Desktop / Cowork (single user session)
OS host of the MCP wrapper: macOS (Apple Silicon Mac mini)
Wrapper installed via the tc-mcp install flow per the project README
All calls below issued in a single uninterrupted session, same auth state
Working calls (baseline — confirms auth, session, and account are reachable)
get_user_info()
→ {"id":64190,"subDomain":"sagamore","email":"@sagamoremgt.com",
"firstName":"TenantCloud","lastName":"Forman","isCompany":true,
"company":"Sagamore Management Co.", ...}
list_contacts(role="tenant")
→ {"data":[ ...12 tenant records... ],"count":12}
list_contacts(role="professional")
→ {"data":[ ...12 vendor / contractor records... ],"count":12}
Failing calls (all return An error occurred invoking '...'.)
list_properties()
list_properties(maxResults=5)
list_units(occupancy="occupied", maxResults=3)
list_units(occupancy="vacant", maxResults=3)
list_leases(status="active", maxResults=3)
list_transactions(status="paid", category="income", maxResults=3)
list_transactions(status="overdue", category="income", maxResults=3)
The MCP wrapper surfaces only the generic An error occurred invoking ''. string — no HTTP status, no upstream response body, no exception type. Whatever the underlying client throws is being swallowed before it reaches the MCP transport. Surfacing the inner exception (or at minimum the HTTP status code and a short body excerpt) would make this kind of failure self-diagnosing for users.
For both list_units calls, the failure persists across both occupied and vacant values — so it isn't param-value-specific; the endpoint cluster itself is the issue.
For list_transactions, the failure persists across two valid status × category combinations — same conclusion.
Wrapper-level parameter handling: two bugs
list_contacts(role="tenant", maxResults=3) returns count: 12 with all 12 records in data. Same call with maxResults=100 returns the same 12. The parameter is either being dropped before transmission to the upstream endpoint, or the upstream endpoint doesn't accept it under the name being sent. Documented behavior in the schema description (Maximum number of results to return (default 100)) implies it should be a working pagination control.
list_contacts(role="tenant") and list_contacts(role="archived") returned identical payloads — same 12 IDs, same status:2 on every record, same ordering. If role were being honored server-side, "tenant" and "archived" should not produce identical results. Three possibilities, in order of likelihood:
The wrapper is dropping the role parameter before transmission, just like maxResults, and the server is returning some default unfiltered or default-filtered view in both cases.
The wrapper is sending it under a parameter name the server doesn't recognize.
(Less likely) role=tenant and role=archived are server-side aliases for the same view, in which case the schema documentation needs to be corrected.
Either way, the published interface (four role values: tenant / professional / moved_in / archived) is not reflecting actual behavior.
Note: list_contacts(role="professional") does return a different 12-record payload (vendors instead of tenants), so some role-discrimination is happening. That's consistent with possibility 1 above if tenant happens to be the server's default and archived is unrecognized.
Repro
Any TenantCloud account where the company has at least one property, one unit, one active lease, and one paid transaction should reproduce the four failing calls. The two parameter-handling bugs reproduce on any account with more than one contact.
What would help
In rough priority order:
Surface the underlying exception. Even if the upstream endpoints are genuinely broken (TenantCloud changed their internal API shape, etc.), the wrapper currently hides the diagnostic information that would tell us which. Wrapping inner exceptions and forwarding the status / message would make this dramatically easier to triage.
Confirm whether the four failing endpoints are still functional against any live account in the maintainer's testing, or whether TenantCloud has recently changed shape on these routes. (TenantCloud has no public API contract, so changes are not announced.)
Audit maxResults and role parameter forwarding in list_contacts — both look like they're being dropped client-side, independent of the larger property/unit/lease/transaction problem.
Happy to provide additional repro detail (raw exception text from a direct .NET client invocation, packet capture of the upstream call, etc.) — let me know what's most useful.