Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Lanten MCP Server List all open work orders"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that connects AI assistants to the Lanten property management API. Use it with Claude, Cursor, Zed, or any MCP-compatible client to manage tenants, units, and work orders using natural language.
Get an API key — in your Lanten dashboard go to Settings → Developers and create a key.
Add to your MCP client config:
{
"mcpServers": {
"lanten": {
"command": "npx",
"args": ["-y", "@lanten-ai/mcp-server"],
"env": {
"LANTEN_API_KEY": "lk_your_api_key_here"
}
}
}
}For Claude Desktop this file lives at:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
For Claude Code run: claude mcp add lanten -e LANTEN_API_KEY=lk_your_key -- npx -y @lanten-ai/mcp-server
Restart your client and start chatting:
"List all open work orders for Flat 4, 12 Oak Street" "Create a new tenant: Jane Smith, jane@example.com, assign her to unit abc-123" "Mark work order WO-214 as completed"
Related MCP server: Buildium MCP Server
Tool | Description |
| List tenants with optional search and pagination |
| Get a single tenant by ID |
| Create a tenant, optionally linked to a unit |
| Update tenant fields (partial update) |
| Permanently delete a tenant |
Tool | Description |
| List property units with optional address search |
| Get a single unit by ID |
| Create a property unit |
| Update unit fields (partial update) |
| Permanently delete a unit |
Tool | Description |
| List work orders; filter by status, priority, tenant, or unit |
| Get a single work order by ID |
| Create a work order linked to a tenant/unit |
| Update a work order (status, priority, etc.) |
| Permanently delete a work order |
Priority levels: 0 Emergency · 1 High · 2 Medium · 3 Low
Statuses: reported · in_progress · completed · cancelled
Variable | Required | Description |
| ✅ | Your API key from Settings → Developers |
| — | Override the base URL (e.g. for self-hosted instances). Defaults to |
git clone https://github.com/lanten/mcp-server
cd mcp-server
npm install
npm run build
# Test with the MCP Inspector
LANTEN_API_KEY=lk_your_key npm run inspectorCreate a new tenant. Optionally assign them to an existing unit.
| Name | Required | Description | Default |
|---|---|---|---|
| firstName | Yes | First name | |
| lastName | Yes | Last name | |
| No | Email address | ||
| phoneNumber | No | Phone number | |
| notes | No | Internal notes | |
| unitId | No | UUID of an existing unit to assign this tenant to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states the creation action and optional assignment, omitting details like validation of unitId, side effects, auth requirements, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the main action and concisely adds the optional assignment detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 6 parameters, the description is minimal. It does not explain return values, error handling, or prerequisites beyond the schema, leaving the agent underinformed for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value beyond the schema. It mentions the optional unitId assignment, but the schema already describes 'unitId' as 'UUID of an existing unit'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new tenant'), with an optional assignment to an existing unit. It effectively distinguishes from siblings like 'create_unit' and 'update_tenant'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use or when-not-to-use guidance. It implies basic context (e.g., required firstName and lastName) but does not differentiate from alternatives like 'update_tenant' for existing tenants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new property unit.
| Name | Required | Description | Default |
|---|---|---|---|
| addressLine1 | Yes | Street address line 1 | |
| addressLine2 | No | Street address line 2 (flat number, etc.) | |
| city | Yes | City or town | |
| county | No | County or province | |
| country | Yes | Country | |
| postcode | Yes | Postal / zip code | |
| area | No | Area or region label (e.g. "North Zone") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the schema, such as whether new units get a generated ID, idempotency, or error states. For a creation tool, more context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence, five words). While it conveys the purpose, it could be slightly more structured without being verbose, but it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (7 simple string params) and no output schema, the description is adequate but lacks mention of what the tool returns or how to retrieve the created unit. Sibling tools like get_unit suggest read operations exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no further meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new property unit.' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_tenant or create_work_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, or any prerequisites (e.g., a property must exist). The description lacks context for the agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new work order (maintenance issue). Optionally link to a tenant and/or unit.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Short title describing the issue | |
| description | Yes | Full description of the issue | |
| priority | No | Priority: 0 = Emergency, 1 = High, 2 = Medium, 3 = Low | 2 |
| tenantId | No | UUID of the tenant who reported it | |
| unitId | No | UUID of the property unit affected | |
| availability | No | Free-text tenant availability window (e.g. 'weekday mornings') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Basic creation behavior described, but no disclosure of validation, error handling, authentication needs, or side effects. No annotations provided, so description carries burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Efficiently conveys core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description does not indicate return value or confirmation. Adequate but could mention that created work order is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. Description adds minimal value beyond 'optionally link to a tenant and/or unit', which is already implied by optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'create', resource 'work order', context 'maintenance issue', and optional links to tenant/unit. Distinguishes from sibling update_work_order and delete_work_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. While purpose is obvious, description lacks differentiation from update_work_order or prerequisites like tenant existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a tenant. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Tenant UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses permanence ('cannot be undone'), but lacks details on side effects (e.g., cascading deletes, access requirements). No annotations to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Essential information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter; covers irreversibility. Lacks details on effects beyond deletion, but adequate for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter with description 'Tenant UUID'; description does not add further meaning. Baseline 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'delete a tenant' with verb and resource. Distinguishes from sibling delete tools by specifying tenant specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies caution due to irreversibility, but no explicit guidance on when to use vs alternatives (e.g., update_tenant). No prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a property unit. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unit UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal disclosure beyond irreversibility; no mention of cascading effects, auth requirements, or side effects, which is important for a destructive operation with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no waste, front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-param delete tool with no output schema, the description covers core purpose and irreversibility, though return value is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no value beyond the schema's 'Unit UUID' description; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and resource 'property unit', distinguishing it from sibling tools like delete_tenant and delete_work_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes irreversibility but lacks explicit guidance on when to use this tool versus alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a work order. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Work order UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It states the deletion is permanent and cannot be undone, which is critical. However, no details on side effects, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the action and key warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-param deletion tool, the description covers the essential behavioral fact (permanent). Could mention return value or success indicator, but not critical given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter 'id' is described in schema. The description adds no extra meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Permanently delete a work order', specifying the action and resource. It distinguishes from siblings like create_work_order or update_work_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only warns about irreversibility but does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single tenant by ID, including their linked units.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Tenant UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the function, not behaviors like error handling, authorization, or whether units are nested. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, front-loaded with key info. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (1 param, no output schema). Description covers basic purpose but omits return format, error cases, or linked units structure. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter with a description ('Tenant UUID') at 100% coverage. Description adds no extra meaning beyond the schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb ('Get'), resource ('tenant'), scope ('single by ID'), and additional content ('including their linked units'). It distinguishes from list_tenants (plural) and get_unit (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when you have a tenant ID and need details with units, but no explicit guidance on when not to use or alternatives (e.g., list_tenants for multiple or search). Context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single property unit by ID, including current tenants.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unit UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it returns unit data and includes current tenants, which is useful. However, it does not mention that it is read-only (safe), any required permissions, or if there are side effects. The behavior is partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with verb and resource. Every word serves a purpose; no extraneous content. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool simplicity (1 param, no output schema), the description covers the core functionality. It lacks explicit mention of the return format or any pagination, but for a get-by-ID operation, the information is sufficient. Minor gap: could note that it returns a full unit object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter 'id' having a description 'Unit UUID'. The description repeats 'by ID' but adds no new semantics beyond the schema. According to guidelines, with high coverage the baseline is 3, and no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'single property unit by ID', and specifies the key inclusion of 'current tenants'. It distinguishes from sibling tools like list_units (multiple), create_unit/delete_unit (mutations), and tenant tools (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving a specific unit by ID, but does not explicitly state when to use vs alternatives, nor does it mention when not to use or provide exclusion criteria. The context of sibling tools makes the purpose clear but guidance is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single work order by ID, including tenant, unit, and attachments.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Work order UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It mentions the return includes tenant, unit, and attachments, which hints at the response shape. However, it does not disclose error conditions, authentication needs, or confirm the read-only nature beyond the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It conveys the core purpose and scope without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval operation with one parameter and no output schema, the description is mostly complete. It covers what the tool returns. It could be enhanced by explicitly stating that it is read-only, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is fully described in the schema (UUID format, required). The description does not add any additional meaning or context beyond the schema, so it meets the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action 'Get' and the resource 'work order by ID', and includes what is returned (tenant, unit, attachments). This effectively distinguishes it from siblings like list_work_orders or create_work_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single work order by ID but does not explicitly state when to use it versus alternatives (e.g., list_work_orders for multiple). No when-not or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tenants for the account. Supports free-text search across name, email, phone, and unit address. Returns paginated results.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search across name, email, phone, unit address | |
| page | No | Page number (default 1) | |
| pageSize | No | Results per page (max 50, default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions pagination and free-text search fields but lacks details on sorting, search behavior (e.g., partial match, case sensitivity), or output format. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with three optional parameters and no output schema, the description covers listing, search, and pagination. Missing details on output structure (e.g., array of tenants) but not critical. Mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal extra meaning: it repeats search fields already in schema and states 'Returns paginated results' which relates to page/pageSize. No significant new information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List tenants for the account' with specific resource and action. Distinguishes from sibling tools like get_tenant (single tenant) and list_units/list_work_orders (different entities).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates support for free-text search across specific fields, providing context on when to use the search parameter. No explicit exclusions or alternatives mentioned, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List property units for the account. Supports address search. Returns paginated results including current tenants.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search by address | |
| page | No | Page number (default 1) | |
| pageSize | No | Results per page (max 50, default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses pagination and inclusion of current tenants, but lacks details on search behavior (exact match vs fuzzy), sorting, rate limits, or potential empty results. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no fluff. Each sentence adds value: first states purpose, second adds key features (address search, pagination, current tenants).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool complexity is low with 3 optional params and no output schema. The description mentions 'including current tenants' but does not specify output structure (e.g., fields returned, pagination metadata like total count). Adequate for a basic list but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description only repeats schema info ('Supports address search' matches 'search by address'; 'Returns paginated results' matches page/pageSize). No new meaning added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('property units'), clearly distinguishing it from sibling tools like 'create_unit' and 'list_tenants'. It states scope ('for the account') and mentions key features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'get_unit' for a single unit, or 'list_tenants' for tenants). It does not provide when-not-to-use or contextual prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List work orders (maintenance issues) for the account. Filter by status, priority, tenant, or unit. Supports search by title or code.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search by title or work order code (e.g. WO-101) | |
| status | No | Work order status | |
| priority | No | Priority: 0 = Emergency, 1 = High, 2 = Medium, 3 = Low | |
| tenantId | No | Filter by tenant UUID | |
| unitId | No | Filter by unit UUID | |
| page | No | Page number (default 1) | |
| pageSize | No | Results per page (max 50, default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It explains the resource and filtering, but does not mention pagination behavior, response format, or any side effects. The schema covers pagination params, so the description is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that front-load the main purpose. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with optional parameters, the description covers the essential aspects: what the tool does, what filters are available, and the nature of the resource. It is complete enough for an AI agent to decide when to use it, especially with the schema providing additional detail on parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by grouping filters and clarifying that search is by title or code, which goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'work orders', and differentiates from sibling tools like get_work_order (single) by using 'List'. It also specifies that work orders are maintenance issues, adding clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for listing work orders with optional filters, which is the typical use case. However, it does not explicitly state when not to use it or compare with alternatives like get_work_order for individual records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing tenant. Only supplied fields are changed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Tenant UUID | |
| firstName | No | Updated first name | |
| lastName | No | Updated last name | |
| No | Updated email (null to clear) | ||
| phoneNumber | No | Updated phone number (null to clear) | |
| notes | No | Updated notes (null to clear) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the partial update behavior ('Only supplied fields are changed'), which is important. However, it does not mention authorization needs, error handling, or what happens if the tenant doesn't exist. Basic behavioral context is present but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no unnecessary words. Every sentence adds value: first states purpose, second clarifies partial update behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with 6 parameters (1 required) and no output schema, the description covers the essential purpose and partial update behavior. It lacks details on error responses, idempotency, or permissions, but these are not critical for a straightforward update. Overall adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already described in the schema. The description adds no additional meaning beyond the schema; it only reiterates that only supplied fields are changed. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing tenant' with the verb 'Update' and the resource 'tenant', and adds the key behavior 'Only supplied fields are changed'. This distinguishes it well from sibling tools like create_tenant or delete_tenant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to update a tenant, but does not explicitly state when not to use or mention alternatives. However, the context of sibling tools is clear, and the description is sufficient for a simple update operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing property unit. Only supplied fields are changed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unit UUID | |
| addressLine1 | No | Updated street address | |
| addressLine2 | No | Updated address line 2 (null to clear) | |
| city | No | Updated city | |
| county | No | Updated county | |
| country | No | Updated country | |
| postcode | No | Updated postcode | |
| area | No | Updated area (null to clear) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only discloses partial update behavior but omits side effects, error handling (e.g., if unit not found), authorization needs, or return value information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose. It is concise without being overly terse, but a bit more context could be added without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description is minimal. It clarifies partial update behavior, which is crucial, but lacks details on error conditions, idempotency, or what the response contains. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any new meaning beyond the schema's field descriptions; it only restates the partial update concept. No parameter-level elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action 'Update' and the resource 'existing property unit', with the additional behavior 'Only supplied fields are changed' indicating a partial update. This distinguishes it from sibling tools like create_unit (create vs update) and delete_unit (delete vs update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing unit, but lacks explicit guidance on when not to use (e.g., if the unit doesn't exist, use create_unit) or alternatives. The prerequirement that the unit must exist is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing work order. Only supplied fields are changed. Setting status to "completed" automatically records the resolved time.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Work order UUID | |
| title | No | Updated title | |
| description | No | Updated description | |
| status | No | Work order status | |
| priority | No | Priority: 0 = Emergency, 1 = High, 2 = Medium, 3 = Low | |
| tenantId | No | Updated tenant UUID (null to unlink) | |
| unitId | No | Updated unit UUID (null to unlink) | |
| availability | No | Updated availability window |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds valuable behavioral context: partial updates and auto-recording of resolved time when status is set to completed. Could be more complete (e.g., return value, auth).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for an update tool with 8 parameters and 2 enums. Lacks info on return value and error handling, but covers key behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description doesn't add extra parameter meaning beyond what's already in the schema. The only behavioral note about status is not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing work order and explains partial update behavior, distinguishing it from create/delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance, but it's clear for updating existing records. Sibling tools are listed but not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1create_tenantcreate_unitcreate_work_orderdelete_tenantdelete_unitdelete_work_orderget_tenantget_unitget_work_orderlist_tenantslist_unitslist_work_ordersupdate_tenantupdate_unitupdate_work_orderEach tool targets a specific resource and action (create, get, list, update, delete) with no overlap. Tenants, units, and work orders are clearly separated.
All tools follow a consistent verb_noun pattern using snake_case (e.g., create_tenant, list_work_orders). No deviations.
15 tools cover exactly the CRUD operations for three entities, which is within the ideal 3-15 range. No tool feels superfluous.
Full CRUD for tenants, units, and work orders, plus search and filtering in list operations. No obvious gaps in the property management domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI assistants to PayRent to manage landlord portfolios, confirming changes first.
Property management AI: work orders, vendors, appliances, and triage for Claude and ChatGPT.
Connects AI assistants to CloudQuell multi-cloud and AI cost, savings, anomaly, and budget data.
Connects AI assistants to QCDatabase.AI for everyday construction quality-control work.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lanten-ai/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
