Skip to main content
Glama

Rent Manager: Send text

rent-manager_send_text

Rent Manager: Text a tenant through Rent Manager texting. Sends one text message to one tenant through Rent Manager texting. The tenant needs a contact set up with SMS enabled. The text goes out under your Rent Manager account. By default you confirm each call; you can switch that off for this tool. Reaches other people: confirm with the user before each call. Needs the user's Cotlet API key with access to this app.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYesText message to the tenant.
tenant_idYesTenant ID from list_tenants.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Adds real behavioral context beyond the annotations: the text goes out under your Rent Manager account, the tenant must have SMS-enabled contact set up, default per-call confirmation (toggleable), and the auth requirement of a Cotlet API key with app access. These complement openWorldHint and the write (readOnlyHint=false) signals rather than contradicting them.

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

Conciseness3/5

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

Front-loaded with the core action, but the opening two sentences are redundant repetitions of the same send-one-text-to-one-tenant statement. The later sentences earn their place, but the lead is bloated.

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 mutation tool with no output schema, the description covers prerequisites, confirmation behavior, account attribution, and auth needs. An agent has enough to invoke it correctly; only return/confirmation-of-delivery behavior is unaddressed.

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 coverage is 100% and both parameters are already documented in the schema (message text, tenant_id from list_tenants). The description implies one-tenant/one-message scope but adds no format, length, or content guidance beyond the schema, so baseline 3 is appropriate.

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

Purpose4/5

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

States a specific verb+resource: sending one text message to one tenant via Rent Manager texting. Clear which provider and action, though the first two sentences restate the same thing and add nothing new. No explicit sibling differentiation, but the rent-manager prefix plus scope is unambiguous.

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 concrete prerequisites ('tenant needs a contact set up with SMS enabled') and process guidance ('confirm each call', confirm with user before calling). Does not name a when-not or an alternative tool, but the preconditions and confirmation requirement provide solid usage context.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources