LTS MCP Server
Server Details
A Model Context Protocol server that provides Philippine License to Sell (LTS) verification data to LLMs. Built on Cloudflare Workers with Supabase.
Public, read-only, no authentication required. Data sourced from the Department of Human Settlements and Urban Development (DHSUD) License to Sell registry and cross-referenced with published real estate projects on REN.PH.
- 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.2/5 across 12 of 12 tools scored. Lowest: 3.5/5.
Each tool targets a distinct aspect of LTS data (by city, developer, law, region, etc.) with no overlapping purposes. The descriptions clearly delineate their unique use cases.
All tools follow the consistent pattern 'lts_<descriptive_noun_or_phrase>' using snake_case. The naming is uniform and predictable, aiding agent selection.
With 12 tools, the set is well-scoped for a data query and analysis server. Each tool serves a clear function without redundancy or overload.
The tool set covers all necessary query dimensions (city, developer, law, region, expiry, stats, trends) and includes a search, check, and project-level view. No obvious gaps for a read-only analytics server.
Available Tools
12 toolslts_by_cityAInspect
Rank cities by LTS count with province, region, law breakdown, active/expired split, and top developer per city. Groups by city+province to avoid merging same-name cities across provinces. Use for housing pressure indices, city-level market analysis, and identifying emerging development hotspots. Cross-reference with PSGC MCP for city classification and population. Capped at 25k rows; check truncated flag and narrow filters if true.
| Name | Required | Description | Default |
|---|---|---|---|
| law | No | Filter by housing law: BP220 (socialized/economic) or PD957 (open market) | |
| year | No | Filter by LTS issue year | |
| limit | No | Max cities to return, sorted by count desc | |
| region | No | Filter to a specific DHSUD region |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses grouping by city+province to avoid name collision, row cap of 25k, and truncated flag. No annotations provided, so description carries burden; but does not explicitly state read-only nature, which is implied.
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: purpose, use cases, constraints. Front-loaded with verb and resource, 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?
Covers grouping, row cap, truncated flag, and use cases. Lacks output format details but no output schema exists; cross-reference partially compensates. Adequate for a 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 no extra meaning to parameters beyond what schema already provides (law, year, limit, region).
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 'Rank cities by LTS count' with detailed breakdown (province, region, law, etc.), distinguishing it from siblings like lts_by_developer or lts_by_region.
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 mentions use cases (housing pressure indices, market analysis, hotspots) and provides cross-reference to PSGC MCP. Also notes row cap and truncated flag check for filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lts_by_developerAInspect
Rank developers by LTS count with regional footprint, law breakdown, and active/expired split. Use for developer intelligence, competitive analysis, and identifying which developers dominate specific regions or housing segments. Capped at 25k rows; check truncated flag and narrow filters if true.
| Name | Required | Description | Default |
|---|---|---|---|
| law | No | Filter by housing law: BP220 (socialized/economic) or PD957 (open market) | |
| year | No | Filter by LTS issue year | |
| limit | No | Max developers to return, sorted by count desc | |
| region | No | Filter to a specific DHSUD region |
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 discloses the 25k row cap, the need to check the truncated flag, and suggests narrowing filters. This provides essential behavioral info for a read tool, though sorting order is implicit.
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 three concise sentences, front-loading the core purpose, then use cases, then behavioral notes. Every sentence adds value with no redundancy.
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 no output schema and 4 optional parameters, the description covers the main behavior (ranking, breakdowns, cap). The 'active/expired split' is mentioned but not detailed, which is a minor gap.
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 does not elaborate on individual parameters beyond what the schema provides, nor does it add novel context for the 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?
The description clearly states the tool ranks developers by LTS count with regional footprint, law breakdown, and active/expired split. This is distinct from sibling tools like lts_by_city or lts_by_law, making its purpose unambiguous.
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 specific use cases (developer intelligence, competitive analysis, identifying dominant developers) and advises checking the truncated flag and narrowing filters when capped. It lacks explicit when-not-to-use instructions but gives adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lts_by_lawAInspect
Break down LTS records by housing law (BP220 socialized/economic vs PD957 open market). Shows regional distribution per law and year-over-year shift in BP220 share (when no year filter). Use for housing policy analysis and socialized housing supply tracking. Capped at 25k rows; check truncated flag and narrow filters if true.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Filter by LTS issue year. Omit for YOY shift calculation | |
| region | No | Filter to a specific DHSUD region |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses cap at 25k rows and truncated flag, plus behavior change when no year filter. Provides context beyond schema, but could mention response structure or data freshness.
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, front-loaded with main purpose. Every sentence adds value without redundancy.
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?
Covers key aspects: breakdown by law, regional distribution, YOY shift, data cap, and truncated flag. No output schema, but description sufficiently prepares agent for use.
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 has 100% coverage with descriptions for both params. Description adds value by stating year should be omitted for YOY shift, which is not in schema. Region description is clear but adds no extra beyond 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?
Description clearly states the tool breaks down LTS records by housing law (BP220 vs PD957) and shows regional distribution per law and year-over-year shift. Distinct from siblings like lts_by_region which only filters by region.
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 says 'Use for housing policy analysis and socialized housing supply tracking.' Also explains when to omit year for YOY shift calculation. However, does not explicitly state when not to use or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lts_by_regionAInspect
Aggregate LTS records by DHSUD region. Returns count, market share, law breakdown (BP220/PD957), and active/expired split per region. Use for State of RE reports and regional housing market analysis. Cross-reference with PSGC MCP search for population data to compute per-capita density. Capped at 25k rows; check truncated flag and narrow filters if true.
| Name | Required | Description | Default |
|---|---|---|---|
| law | No | Filter by housing law: BP220 (socialized/economic) or PD957 (open market) | |
| year | No | Filter by LTS issue year | |
| status | No | Filter by derived LTS status: active (expiry >= today) or expired |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It discloses the 25k row cap, truncated flag behavior, and the types of returned aggregates. No contradictions with structured data.
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?
Four sentences, each adding value: first sentence states function and outputs, second provides usage context, third offers cross-reference, fourth covers limits. No waste, front-loaded effectively.
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 no output schema, the description adequately outlines return values (count, share, breakdowns) and limitations. Provides cross-reference and usage guidance. Could benefit from specifying exact field names or structure, but overall sufficient for an aggregation 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 applies. The description mentions filtering by law and status in the context of breakdown, but the schema already describes each parameter with comparable detail. Minimal added value 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?
Clearly states the tool aggregates LTS records by region, specifies output metrics (count, market share, law breakdown, active/expired split), and distinguishes from siblings like lts_by_city or lts_by_developer which operate on different groupings.
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?
Provides explicit use cases (State of RE reports, regional housing analysis) and cross-reference guidance with PSGC MCP. Mentions the 25k row cap and truncated flag for handling limits. Lacks explicit when-not-to-use or comparison to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lts_checkAInspect
Check if a specific LTS number exists in the system. Returns whether it exists in lts_records, in project_lts, or both. Includes full record details when found.
| Name | Required | Description | Default |
|---|---|---|---|
| ltsNumber | Yes | The LTS number to look up (e.g., 'LS 0001234') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns existence flags and full record details. With no annotations provided, it carries the full burden and adequately describes the output behavior, but could mention error handling for invalid formats.
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: first states purpose, second details output. No redundant information, earnestly 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?
For a simple lookup tool with one parameter, no output schema, and no nested objects, the description fully covers what the tool does, what it returns, and how it differs from siblings.
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 'ltsNumber' is already fully described in the schema (100% coverage). The description does not add additional semantics 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?
The description clearly states the action ('Check if a specific LTS number exists') and the resource ('in the system'). It specifies the output (existence in two tables and full record details), distinguishing it from sibling tools that query by other criteria like city or developer.
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 have a specific LTS number to verify, and the sibling list suggests alternatives for other query types. However, it does not explicitly state when not to use or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lts_expiry_riskAInspect
Find LTS records expiring within a given number of days. Returns records sorted by urgency (soonest first) with days remaining, plus summary counts by region and developer. Use for compliance monitoring, renewal pipeline tracking, and risk assessment. Capped at 25k rows; check truncated flag and narrow filters if true.
| Name | Required | Description | Default |
|---|---|---|---|
| law | No | Filter by housing law: BP220 (socialized/economic) or PD957 (open market) | |
| days | No | Look-ahead window in days from today (default 90) | |
| region | No | Filter to a specific DHSUD region |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses sorting behavior, summary counts, row cap (25k), and a truncated flag. With no annotations, the description covers key behavioral traits, though it omits potential side effects or authentication requirements.
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 states purpose and output format, second suggests use cases, third notes limits and corrective action. No wasted words and front-loaded with key 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?
For a tool with no output schema, it adequately describes return structure (sorted records with days remaining, summary counts). Missing details on exact record structure, but sufficient for an AI agent to understand what to expect.
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 already describes all parameters (100% coverage). Description adds output semantics (summary counts by region and developer) and clarifies that 'days' defines the look-ahead window, enhancing understanding beyond 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?
Describes finding LTS records expiring within a given number of days, sorted by urgency, with summary counts. Explicitly states use cases (compliance monitoring, renewal pipeline, risk assessment), distinguishing it from sibling tools that filter by other criteria.
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?
Provides explicit use cases and a cap warning with guidance to narrow filters if truncated. Does not explicitly exclude alternative sibling tools, but the context and purpose clearly differentiate when 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.
lts_filtersAInspect
Get available filter values for LTS queries. Returns distinct regions and cities from the verification queue. Optionally filter cities by region. Use this before calling lts_queue or lts_search with region/city filters to get valid values.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | If provided, only return cities within this region |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the tool returns distinct regions and cities, with optional filtering by region. It does not describe side effects, authentication, or rate limits, but for a simple read-only query tool, this level of transparency is 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 three sentences long, each serving a distinct purpose: stating the tool's main function, describing the output, and providing usage guidance. There is no redundancy, and the information is 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?
Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It explains the output ('distinct regions and cities'), the optional filtering, and the context for use. No additional details are necessary.
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 100% description coverage for the single parameter 'region.' The description reiterates the schema's meaning ('Optionally filter cities by region') but does not add additional semantic detail beyond what the schema already provides. Baseline of 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 tool's purpose: 'Get available filter values for LTS queries. Returns distinct regions and cities from the verification queue.' It specifies the verb 'Get,' the resource 'filter values,' and the scope 'for LTS queries,' differentiating it from sibling tools like lts_queue or lts_search that perform queries.
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 explicit usage guidance: 'Use this before calling lts_queue or lts_search with region/city filters to get valid values.' It specifies when to use the tool and mentions the related tools, but does not explicitly state when not to use it or list alternatives beyond the mentioned ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lts_projectAInspect
Get the complete LTS picture for a single project: all LTS records with computed fields (is_expired, days_until_expiry), summary counts, and the primary LTS number. Pass either a project UUID or a project name (fuzzy matched).
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Project UUID. Takes priority over projectName if both provided | |
| projectName | No | Project name or slug for fuzzy lookup. Use when you don't have the UUID |
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 behavioral burden. It discloses that it returns computed fields (is_expired, days_until_expiry), summary counts, and the primary LTS number. It also mentions fuzzy matching for the name parameter. This is fairly transparent for a read-only tool, though authorization needs are not mentioned.
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, well-structured sentence that conveys all key information upfront. Every clause serves a purpose: what the tool returns, how to call it (two parameter options), and additional context (fuzzy matching). 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 tool with two parameters and no output schema, the description is complete. It details the return value (computed fields, summaries, primary number) and the two input methods. The absence of an output schema is compensated by the description's specificity about what 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?
Both parameters are already described in the schema (100% coverage). The description adds significant value: it explains the priority order (projectId takes precedence) and the fuzzy lookup behavior for projectName. It also clarifies the return type—'complete LTS picture'—which goes beyond schema definitions.
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 retrieves 'the complete LTS picture for a single project' with specific computed fields and summaries. It distinguishes itself from sibling tools like lts_records (which likely lists multiple) by emphasizing 'single project' and 'primary LTS number'.
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 explicitly says to pass either a project UUID or a project name (fuzzy matched), and notes that projectId takes priority. While it doesn't explicitly list when not to use this tool vs alternatives, the 'single project' scope implies it's for individual project queries, not bulk or filtered searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lts_recordsAInspect
Browse LTS records from DHSUD with filters. Shows normalized records with confidence levels. Filter by confidence (high/medium), linked status (has project_id), region, or text search. Use expiringWithinDays to find records expiring soon.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results | |
| linked | No | true = linked to project, false = unlinked | |
| offset | No | Pagination offset | |
| region | No | Filter by region (use lts_filters to get valid values) | |
| search | No | Text search: project name, LTS number, or developer | |
| sortBy | No | Sort field | created_at |
| sortOrder | No | Sort direction | desc |
| confidence | No | Filter by data confidence level | |
| expiringWithinDays | No | Show records with expiry date within N days from today |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only browse operation but does not explicitly state that there are no side effects, nor does it disclose permissions, rate limits, or data mutability. This is inadequate for complete transparency.
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: first states purpose, second lists filters, third gives specific usage. It is front-loaded and free of fluff, though a bit more structure (e.g., bullet points) could improve readability.
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 moderate complexity with 9 parameters and no output schema, the description adequately explains the core functionality and key filters. It covers browsing, normalization, confidence levels, and expiring items. Pagination details are covered in the schema. Some differentiation from siblings is implicit but not explicit.
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 100% description coverage, so each parameter is documented. The description adds value by grouping filters and explaining the expiringWithinDays parameter beyond the schema. This enhances understanding without redundancy.
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 browses LTS records with filters, specifying the verb 'Browse' and resource 'LTS records'. It distinguishes from sibling tools by listing specific filters like confidence, linked status, region, and text search, which are not collectively present in the siblings.
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 guidance on when to use filters such as 'Filter by confidence' and 'Use expiringWithinDays to find records expiring soon'. However, it does not explicitly state when not to use this tool versus its siblings like lts_by_region or lts_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lts_searchAInspect
Search across DHSUD LTS records and published projects by name, LTS number, developer, or city. Returns matches from both lts_records and published projects. Universal entry point for LTS data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results per category | |
| query | Yes | Search term: project name, LTS number, developer name, or city | |
| offset | No | Pagination offset |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions that results come from both lts_records and published projects, but lacks details on ordering, case sensitivity, or result structure. This is 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?
The description is concise, two sentences with no wasted words. It front-loads the core action and scope, making it 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?
The description explains that results come from two sources and serves as a universal entry point, but without an output schema, it does not describe the result format or pagination behavior. For a tool with 3 parameters, this is 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 coverage is 100% with clear descriptions for each parameter. The tool description does not add meaning beyond the schema; it merely reiterates the search criteria. 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 that the tool searches across DHSUD LTS records and published projects by various criteria, positioning it as a universal entry point. However, it does not explicitly distinguish it from specialized sibling tools like lts_by_city or lts_by_developer.
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 broad use as a universal entry point but provides no explicit guidance on when to use this tool versus alternatives. Given the existence of specialized siblings, the description should mention that for specific filters, dedicated tools may be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lts_statsAInspect
Get system-wide LTS statistics. Returns two sections: (1) lts_records stats (total, by confidence, linked/unlinked, active/expired, unique developers/cities), and (2) project LTS stats (total records, verified, expired, expiring within 30 days, projects with LTS).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It details the return structure (two sections with lists) but does not disclose any behavioral traits like authentication needs, performance characteristics, or idempotency. For a read-only tool with no parameters, this is adequate 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 consists of two sentences, both front-loaded with key information. No wasted words; every clause adds value.
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 no output schema, the description adequately explains the two sections. However, it does not mention format (e.g., JSON), potential empty results, or performance implications. Slightly incomplete for a comprehensive understanding.
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 no properties, so schema description coverage is 100%. The description adds no parameter information because there are none, but baseline for 0 params is 4. No additional value needed.
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 'Get system-wide LTS statistics' and enumerates the two sections with specific metrics. It distinguishes from sibling tools like lts_by_city or lts_by_developer, which focus on filtered views.
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 overall stats but does not explicitly state when to use this tool versus siblings or provide when-not-to-use guidance. Alternatives exist but are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lts_trendsAInspect
Show LTS issuance trends over time with annual or quarterly granularity. Returns period counts with law breakdown, peak period, and year-over-year growth percentage. Use for housing supply pipeline analysis and market timing. Capped at 25k rows; check truncated flag and narrow filters if true.
| Name | Required | Description | Default |
|---|---|---|---|
| law | No | Filter by housing law: BP220 (socialized/economic) or PD957 (open market) | |
| region | No | Filter to a specific DHSUD region | |
| to_year | No | End year (inclusive) | |
| from_year | No | Start year (inclusive) | |
| granularity | No | Time bucket granularity | annual |
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 a 25k row cap and advises checking the truncated flag, which is a notable behavioral constraint. It also outlines return values. It lacks explicit statements about side effects or permissions, but given the read-only nature implied, this is 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 three sentences, front-loading the main purpose and key details. Every sentence adds value: purpose, return values, use case, and a constraint. 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?
Given no output schema, the description adequately explains return values (counts, law breakdown, peak period, growth percentage) and a constraint (capped rows). It covers the essential functionality for a trend-analysis tool with 5 optional 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% with descriptions for each parameter. The description adds context about the output (e.g., law breakdown) but does not enhance parameter meaning beyond what the schema already provides, so 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 tool shows 'LTS issuance trends over time' with granularity options, and specifies what it returns (period counts, law breakdown, peak period, YoY growth). This distinguishes it from siblings like lts_by_city or lts_by_region, which focus on other dimensions.
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 explicitly says 'Use for housing supply pipeline analysis and market timing,' providing a clear use case. However, it does not mention when not to use it or suggest alternative sibling tools for other purposes.
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!