MCP PropTech
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| N8N_API_KEY | No | n8n API key (if required by your instance) | |
| VENDOR_CONTACTS | No | JSON map overriding default vendor directory | |
| AGENT_INTERVAL_MS | No | Daemon poll interval in milliseconds | 300000 |
| ANTHROPIC_API_KEY | Yes | Claude API key (Required for the agentic loop) | |
| TWILIO_AUTH_TOKEN | No | Twilio auth token for WhatsApp integration | |
| TWILIO_ACCOUNT_SID | No | Twilio account SID for WhatsApp integration | |
| N8N_WEBHOOK_ESCALATE | No | n8n vendor escalation webhook URL | |
| TWILIO_WHATSAPP_FROM | No | Sender WhatsApp number (e.g., whatsapp:+14155238886) | |
| N8N_WEBHOOK_MAINTENANCE | No | n8n status-change webhook URL |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_open_ticketsA | Retrieves maintenance tickets from the property management system. Filters by status (default: all non-resolved), priority, category, and property. Returns tickets sorted by priority (emergency first) then recency. |
| update_maintenance_statusA | Updates the status of a maintenance ticket and records a history note. Fires an n8n webhook so your automation system stays in sync. Valid transitions: open→in_progress|awaiting_tenant|escalated, in_progress→awaiting_tenant|resolved|escalated, awaiting_tenant→in_progress|resolved|closed, escalated→in_progress|resolved, resolved→closed. |
| notify_tenantA | Sends a WhatsApp message to the tenant associated with a ticket. Supports five message templates: acknowledgement, scheduled, update, resolved, delay. Pass customMessage to override the template. Falls back to SMS if WhatsApp fails. Logs the notification to n8n and appends to ticket internal notes. |
| escalate_to_vendorA | Escalates a maintenance ticket to a specialist vendor. Selects the right vendor from the directory based on trade (plumbing, electrical, hvac, etc.), updates ticket status to 'escalated', triggers an n8n workflow that emails/WhatsApps the vendor, and sends the tenant an update message. Use overrideVendorPhone to assign a specific vendor instead of the default. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose with no overlap: escalate_to_vendor handles vendor escalation, get_open_tickets retrieves ticket data, notify_tenant sends tenant notifications, and update_maintenance_status updates ticket status. The descriptions specify unique actions and contexts, making misselection unlikely.
All tool names follow a consistent verb_noun pattern (e.g., escalate_to_vendor, get_open_tickets) using snake_case throughout. This predictable naming scheme enhances readability and agent usability without any deviations or mixed conventions.
With 4 tools, the count is reasonable for a property tech maintenance domain, covering key operations like retrieval, status updates, notifications, and escalations. It's slightly lean but well-scoped, as each tool serves a distinct function without redundancy.
The tool set covers core maintenance workflows: retrieving tickets, updating statuses, notifying tenants, and escalating to vendors. Minor gaps exist, such as no tool for creating new tickets or managing vendor directories, but agents can likely work around these with the provided tools.