Property maintenance triage and vendor packet generator.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.8/5 across 4 of 4 tools scored.
The tools draft_tenant_questions and generate_vendor_packet are distinct, but rank_urgency and triage_maintenance_issue both categorize maintenance urgency from issue text, making them nearly interchangeable. This overlap creates significant confusion for an agent trying to select the right tool.
All tool names follow a consistent snake_case verb_noun pattern (e.g., draft_tenant_questions, generate_vendor_packet, rank_urgency, triage_maintenance_issue). While the verbs are varied, the overall pattern is consistent and predictable.
With 4 tools, the server is well-scoped for a niche maintenance concierge purpose. Each tool addresses a specific step in the pre-dispatch workflow, and the count is within the ideal range for a focused toolset.
The set covers the main pre-dispatch tasks: drafting tenant questions, generating vendor packets, and classifying urgency. There are no major dead ends, though the redundancy between rank_urgency and triage_maintenance_issue suggests the surface could be streamlined. Missing actual dispatch scheduling is a minor gap given the concierge scope.
draft_tenant_questionsDraft Tenant QuestionsBUse this when a user wants questions to ask a tenant before maintenance dispatch.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| result | No | |
| preview | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds no behavioral context—it does not explain how the questions are generated, what the input text is used for, or what the output looks like. It relies entirely on annotations for safety and adds no insight into the tool's operation.
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 that is front-loaded with the usage trigger. It contains no redundant or vague language; every word contributes to explaining when to use the tool.
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?
While the tool is simple (one parameter, output schema present), the description omits the essential meaning of the input parameter. The agent knows when to use the tool but not how to invoke it correctly, making the overall context incomplete.
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 schema has 0% description coverage for the only parameter 'text', and the description does not explain its role or expected content. Without any characterization of the parameter, the agent cannot determine what value to provide.
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 tool's function: generating questions to ask a tenant before maintenance dispatch. It distinguishes itself from sibling tools like generate_vendor_packet and triage_maintenance_issue by specifying the exact use case.
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 an explicit trigger condition ('Use this when a user wants questions to ask a tenant before maintenance dispatch'). It does not mention alternatives or when not to use the tool, but the context is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_vendor_packetGenerate Vendor PacketAUse this when a user wants a vendor-dispatch information packet drafted from a maintenance issue.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| result | No | |
| preview | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context (e.g., that it drafts from a maintenance issue) but no details about output expectations or side effects. No contradictions with 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?
A single, front-loaded sentence that conveys the purpose and usage trigger without any redundancy. All words earn their 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?
For a simple tool with one parameter and an output schema, the description is adequate. It gives the trigger and source input. It could mention that the output is a draft requiring review, but the output schema likely covers return structure. Slight gap in explaining prerequisites or what happens after generation.
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 0%, so the description must compensate. It implies 'text' contains the maintenance issue but does not explicitly define what format or contents are expected. This adds some meaning but remains under-specified.
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 tool drafts a vendor-dispatch information packet from a maintenance issue. It distinguishes this from sibling tools like draft_tenant_questions, rank_urgency, and triage_maintenance_issue by specifying the exact deliverable and source input.
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?
It explicitly says 'Use this when a user wants a vendor-dispatch information packet drafted from a maintenance issue,' providing a clear trigger. However, it does not mention when not to use it or point to alternative tools for other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rank_urgencyRank UrgencyAUse this when a user wants maintenance urgency categorized from issue text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| result | No | |
| preview | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds no additional behavioral context such as return details or edge cases. It is not contradictory, but it adds little beyond the 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?
The description is a single, focused sentence with no unnecessary words. It is front-loaded with the usage condition and clearly communicates the tool's purpose.
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?
The tool is simple with one parameter and an output schema provided. The description covers the key use case and input semantics. Given the available annotations and output schema, it is adequately complete, though it does not elaborate on the output categories.
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 schema has no description for the 'text' parameter, but the description explicitly states that urgency is categorized 'from issue text', effectively clarifying that the text parameter is the issue text. This adds valuable meaning for a single parameter.
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 that the tool categorizes maintenance urgency from issue text, which is a specific action and resource. It does not explicitly differentiate from sibling tools like triage_maintenance_issue, but the focus on urgency ranking is distinct enough.
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 a clear trigger condition: use when the user wants maintenance urgency categorized from issue text. It does not mention when not to use it or alternatives, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
triage_maintenance_issueTriage Maintenance IssueAUse this when a user wants a maintenance issue categorized by urgency for human review.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| result | No | |
| preview | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by stating the output is 'for human review', implying no automatic action is taken. This goes beyond the annotations without 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the trigger condition and purpose, with no unnecessary words. It is front-loaded and concise.
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 simplicity (one string parameter, output schema present, annotations provided), the description covers the core purpose and when to use it. It does not detail the parameter semantics, but that is already penalized under parameter semantics. Overall, the description is reasonably complete for the complexity level.
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 input schema has zero description coverage (0%), and the description does not explicitly explain what the 'text' parameter should contain. Though it implies 'text' is the maintenance issue, it does not clarify format, examples, or any constraints. Since the description must compensate for the schema gap, this is a significant weakness.
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 that the tool categorizes a maintenance issue by urgency for human review, with a specific verb and resource. However, it does not explicitly distinguish this from the sibling tool 'rank_urgency', which likely performs a similar urgency categorization, so it stops short of a 5.
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?
It provides an explicit 'Use this when...' condition (when a user wants a maintenance issue categorized by urgency for human review), giving clear context. It does not mention when not to use or suggest alternative tools like 'rank_urgency', but the context is clear enough to warrant a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!