LodgeDeck
Server Details
STR legality, permits and lodging tax by city, each field cited to its source jurisdiction.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.3/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: eligibility check, tax retrieval, rules retrieval, and jurisdiction listing. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (check_str_eligibility, get_lodging_tax, get_str_rules, list_jurisdictions) with clear prefixes.
Four tools is well-scoped for the domain of short-term rental regulations. Each tool serves a necessary function without redundancy or gaps.
The tools cover the main information needs for short-term rental regulations: eligibility, tax, rules, and available jurisdictions. Minor gap: no tool for address-specific lookups, but the core domain is well-covered.
Available Tools
4 toolscheck_str_eligibilityAInspect
Deterministic verdict on whether a short-term rental is allowed in a jurisdiction for a given use type, with the requirements, cautions, a confidence and the citations behind them. No model: same input always gives the same answer, and when the governing rules are unknown it says so rather than guessing. Free, no API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Jurisdiction slug or "City, ST" string. | |
| use_type | Yes | primary_residence | whole_home | adu | unhosted. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It transparently discloses deterministic behavior ('same input always gives same answer'), honesty when rules are unknown, and that it is free with no API key needed. This goes beyond a simple purpose statement.
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 concise, with three sentences that efficiently convey purpose and key traits. It is front-loaded but could be slightly more structured. No redundant information.
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 two simple parameters, no output schema, and no annotations, the description adequately explains what the tool returns (requirements, cautions, confidence, citations). It provides sufficient context for an AI agent to understand the tool's capability.
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 additional meaning to the parameters beyond what the schema provides. No parameter-specific elaboration is given.
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 provides a deterministic verdict on short-term rental eligibility in a jurisdiction for a given use type, including requirements, cautions, confidence, and citations. It distinguishes from sibling tools like get_lodging_tax (tax info) and get_str_rules (rules) by emphasizing a verdict with confidence and citation.
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 obtaining a reliable verdict on rental eligibility but does not explicitly state when to use this tool versus alternatives like get_str_rules or get_lodging_tax. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lodging_taxAInspect
Return the lodging / occupancy tax for one jurisdiction: state rate, local transient occupancy tax, the combined rate a guest pays, whether the cleaning fee is taxable, and whether the marketplace collects and remits. Every field is { value, source, confidence }; unconfirmed fields are null. Free, no API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Jurisdiction slug (e.g. san-diego-ca) or a "City, ST" string. |
Tool Definition Quality
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 every field has a format (value, source, confidence), unconfirmed fields are null, and that it is free with no API key needed. This provides good behavioral context without needing 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 sentences, no wasted words. First sentence lists all returned fields, second explains format and pricing. Front-loaded with essential information.
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 one parameter, no output schema, and no annotations, the description covers input format, output content and structure, and authentication (free, no API key). Nothing significant is missing for a simple query 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 baseline 3. Description adds a concrete example of the city parameter format (slug or 'City, ST'), which adds marginal value beyond the schema's description.
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?
Explicitly states it returns lodging/occupancy tax for one jurisdiction, listing specific fields like state rate, local tax, combined rate, and taxable cleaning fee. Clearly differentiated from siblings like `check_str_eligibility` and `get_str_rules` which cover eligibility and rules, not taxes.
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?
Implied usage: when you need tax information for a specific jurisdiction. No explicit 'when not to use' or comparison to sibling tools. The context signals show sibling tools exist but the description doesn't guide the agent on choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_str_rulesAInspect
Return the short-term rental rules for one jurisdiction: whether a licence is required, primary-residence rule, annual night cap, zoning restriction, listing-number display rule, registration URL and enforcement notes. Every field is an object { value, source, confidence }; an unconfirmed field is value:null with confidence:"unverified", never guessed. Free, no API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Jurisdiction slug (e.g. austin-tx) or a "City, ST" string. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully discloses return format (object with value/source/confidence), handles unconfirmed fields, states 'never guessed,' and notes free access with no API key.
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 efficiently convey purpose, data structure, and constraints without superfluous content.
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 simple tool (1 param, no output schema), the description covers all necessary aspects: return fields, data format, and usage constraints (free, no key).
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 repeats the schema's parameter info without adding new semantic details.
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 specifies the exact resource (short-term rental rules for one jurisdiction) and lists specific fields returned, clearly distinguishing from siblings like check_str_eligibility or get_lodging_tax.
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 rules for a single jurisdiction, but does not explicitly state when to use it over the listed sibling tools, though the field list helps differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_jurisdictionsAInspect
List every US short-term-rental jurisdiction LodgeDeck covers, with its slug, city, state and a coverage count of how many rule and tax fields are confirmed. Call this first to learn which slugs the other tools accept. Optional q filters by city or state name. Free, no API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Optional case-insensitive filter over city and state name. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behavioral details: it returns slug, city, state, coverage count, and notes it is free with no API key needed. This is transparent for a listing operation, though missing explicit mention of read-only nature.
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?
Three concise sentences: first defines purpose and output, second gives usage guidance, third documents parameter and cost. Every sentence adds value with no redundancy or 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?
Given the tool has one optional parameter and no output schema, the description fully covers input, output fields, and usage context. It explains why to call this first, fulfilling completeness 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 description coverage is 100% for the single parameter 'q', which already describes the case-insensitive filter. The description adds 'by city or state name' but does not significantly enhance understanding beyond the schema.
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 'List every US short-term-rental jurisdiction LodgeDeck covers' using a specific verb and resource. It distinguishes this tool from siblings like check_str_eligibility or get_lodging_tax, which perform different functions.
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?
Explicitly states 'Call this first to learn which slugs the other tools accept,' providing clear usage guidance. It also mentions the optional filter, giving complete context for when and why to use this tool.
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.
Discussions
No comments yet. Be the first to start the discussion!