CRE Intelligence
Server Details
Live CRE analysis: Federal Reserve rates, Census 1/3/5-mile demographics, DCF models, IC memos.
- 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 10 of 10 tools scored.
Each tool targets a distinct aspect of CRE analysis: lease abstraction, rent roll analysis, DCF modeling, risk flagging, deal memo generation, and separate data sources for market, rates, inflation, and demographics. No overlapping purposes; descriptive names and descriptions clearly differentiate them.
All tools follow a consistent verb_noun pattern in snake_case: abstract_lease, analyze_rent_roll, build_dcf_model, flag_lease_risks, generate_deal_memo, and six 'get_' tools for data retrieval. The naming convention is uniform and predictable.
10 tools is well within the ideal range of 3-15. The tool count covers the essential workflows for CRE underwriting without being excessive or sparse, each tool adding clear value.
The tool set covers the full lifecycle of CRE deal analysis: lease abstraction, rent roll analysis, financial modeling (DCF), risk assessment, memo generation, and macroeconomic/demographic data retrieval. There are no obvious missing operations for the stated domain.
Available Tools
10 toolsabstract_leaseAInspect
Extract all key terms from a commercial lease document. Returns term, base rent schedule, escalations, TI allowance, CAM structure, renewal options, termination rights, exclusivity, co-tenancy, and red flags.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Raw text copied from a commercial lease PDF |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 burden. It lists return outputs but does not mention side effects, permissions, or any behavioral traits beyond being a read 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 two sentences front-loading purpose and listing outputs, with 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 the simple one-parameter input and presence of an output schema (implied by context signals), the description adequately covers the tool's functionality, though it could mention the output schema reliance.
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% for the single parameter 'text', and the description adds no additional meaning beyond what the schema already provides ('Raw text copied from a commercial lease PDF').
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 'Extract all key terms from a commercial lease document' with a specific verb and resource, distinguishing it from sibling tools like 'analyze_rent_roll' or 'build_dcf_model'.
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 extracting lease terms but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_rent_rollAInspect
Extract structured tenant and lease data from a rent roll document. Paste the text content of your rent roll PDF here (copy-paste from PDF reader). Returns tenant list, suite/SF, lease dates, monthly rent, escalations, and options.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Raw text copied from a rent roll PDF | |
| property_name | No | Optional property name for context |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Lists output fields (tenant list, suite/SF, dates, rent, options), disclosing what the tool returns. Does not mention destructive actions, which is acceptable for a read-only extraction tool.
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: first defines purpose, second provides usage and output overview. No redundant information; every sentence 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 has 2 parameters (both documented), an output schema (doesn't need return value explanation), and the description covers key extracted fields. Missing details on error handling or formatting requirements, but adequate for a simple extraction 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%, meaning both parameters already have descriptions. The description adds no additional meaning; it merely restates the schema ('Raw text copied from a rent roll PDF' and 'Optional property name for context'). 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 'Extract structured tenant and lease data from a rent roll document,' specifying the verb and resource. It distinguishes from siblings like abstract_lease by focusing on rent roll extraction.
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 instructions on how to use (paste text from PDF) but lacks guidance on when not to use or alternatives. No explicit comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_dcf_modelAInspect
Build a levered DCF model using live Federal Reserve rates. Automatically fetches current SOFR to derive the loan rate if not provided. Returns: annual cash flows, IRR, equity multiple, cash-on-cash, DSCR, and exit analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| loan_rate | No | Loan interest rate % — if None, fetches live SOFR + 175bps | |
| noi_year1 | Yes | Year 1 Net Operating Income ($) | |
| equity_pct | No | Equity as % of purchase price (default 35%) | |
| hold_years | No | Hold period in years (default 10) | |
| exit_cap_rate | No | Exit cap rate % — if None, uses entry cap + 25bps (conservative) | |
| purchase_price | Yes | Acquisition price ($) | |
| noi_growth_rate | No | Annual NOI growth rate % (default 3.0) | |
| amortization_years | No | Loan amortization period (default 30 years) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 automatic fetching of SOFR rates when loan_rate is not provided and lists expected outputs (cash flows, IRR, etc.). It does not cover error handling or performance, but the main behaviors are transparently communicated.
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 concise sentences. The first sentence immediately states the core purpose, and the second summarizes key outputs. No filler or redundancy—every sentence 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 high schema coverage (100%) and presence of an output schema, the description is complete. It adequately explains the tool's function and outputs, leaving no critical gaps for an AI agent to invoke it correctly.
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 baseline is 3. The tool description reiterates the automatic fetching behavior already in the schema (e.g., loan_rate default logic) but does not add new semantic information beyond what the parameter descriptions 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 builds a levered DCF model using live Federal Reserve rates, which is a specific verb-resource combination. It is easily distinguished from sibling tools like abstract_lease or analyze_rent_roll, which focus on different aspects of real estate analysis.
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 does not explicitly state when to use this tool or when to avoid it. It implies usage for DCF modeling but lacks guidance on alternatives or context. The sibling tools are not directly competing, but no exclusions or when-not-to-use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flag_lease_risksAInspect
Analyze a parsed rent roll for investment risks. Feed the output from analyze_rent_roll directly into this tool. Returns: rollover risk, tenant concentration, credit risk, and actionable recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| rent_roll_json | Yes | JSON string from the analyze_rent_roll tool output |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description lists outputs (rollover risk, tenant concentration, credit risk, recommendations), adding behavioral context. Could explicitly state it is a read-only analysis.
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, no fluff, front-loaded with action and resource.
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?
Output schema exists (not shown), so return values are covered. Description adequately covers purpose, input, and output for a simple 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?
Single parameter 'rent_roll_json' described as 'JSON string from the analyze_rent_roll tool output'—schema coverage is 100% and description adds meaningful source context.
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 states 'Analyze a parsed rent roll for investment risks' with a specific verb and resource. It clearly distinguishes from sibling tools like analyze_rent_roll.
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 instructs 'Feed the output from analyze_rent_roll directly into this tool', providing clear context on when to use it and its dependency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_deal_memoAInspect
Generate a formatted CRE acquisition memo / Investment Committee memo. Automatically pulls live rates from FRED and demographics from Census Bureau to provide real market context — not guesses.
| Name | Required | Description | Default |
|---|---|---|---|
| noi | Yes | Net Operating Income ($) | |
| asking_price | Yes | Asking price ($) | |
| property_type | Yes | Multifamily / Office / Retail / Industrial / Mixed-Use | |
| property_address | Yes | Full property address | |
| rent_roll_summary | No | Optional: paste output from analyze_rent_roll or flag_lease_risks | |
| additional_context | No | Any additional deal notes, seller info, market color |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 transparently discloses that it pulls live rates from FRED and demographics from Census Bureau, indicating it relies on external data sources. It does not contradict any 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 with clear front-loading of purpose and unique features. Every sentence is informative 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?
The description explains the tool's output (formatted memo with live data) and its data sources. Given the existence of an output schema and 6 parameters, it provides sufficient context for an agent to understand when and what to expect, though it could mention output format briefly.
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 noting that rent_roll_summary can accept output from related tools (analyze_rent_roll, flag_lease_risks), but does not elaborate on other parameters beyond schema 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 uses the specific verb 'generate' and identifies the resource as a 'formatted CRE acquisition memo / Investment Committee memo'. It distinguishes from sibling tools by highlighting automatic pulling of live rates and demographics, making its unique value clear.
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 the tool is for generating memos with live market context, contrasting with siblings that only provide raw data. However, it lacks explicit guidance on when not to use it or direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_cre_market_dataAInspect
Get Commercial Real Estate price index and broader market data from the Federal Reserve. Returns CRE price trends, office/retail/industrial vacancy proxies, and credit spreads. Provides macro context for deal underwriting and cap rate analysis.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It describes return content but omits details like data freshness, caching, or rate limits. For a simple read-only tool, adequate but could be more 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?
Three concise sentences: action/source, returned data, use case. No repetitive or filler content. Efficiently communicates 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?
Given zero parameters and presence of an output schema, description covers key aspects: data source, contents, and application. Could mention whether data is current or historical, but overall 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?
Tool has zero parameters, so baseline is 4. Description adds no param info, which is acceptable since schema coverage is trivially 100% and no parameters exist.
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 'Get' and specific resource 'Commercial Real Estate price index and broader market data from the Federal Reserve'. Lists concrete data types (price trends, vacancy proxies, credit spreads) distinguishing from sibling tools like get_current_rates or get_inflation_data.
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?
States tool 'provides macro context for deal underwriting and cap rate analysis', clearly indicating appropriate use. Lacks explicit when-not-to-use instructions, but context is sufficiently specific for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_current_ratesAInspect
Get live interest rates from the Federal Reserve (FRED). Returns SOFR, 10-year Treasury, 5-year Treasury, Fed Funds Rate, and 30-day SOFR average. Also calculates implied cap rate ranges based on current treasury spreads.
Use this BEFORE any DCF model or loan underwriting. These are real-time numbers Claude cannot access on its own.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that data is real-time from FRED, includes calculated cap rate ranges, and implies no destructive actions. Complete transparency for a read-only data tool.
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 earning its place: purpose, details, usage, value. Front-loaded and efficient 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 zero parameters and presence of output schema, description fully explains what the tool provides and why it's useful. No gaps for the agent.
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?
No parameters exist (0 params, 100% schema coverage). Per guidelines, baseline is 4. Description adds no parameter info 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 the tool gets live interest rates from FRED, lists specific rates (SOFR, Treasury yields, Fed Funds Rate), and mentions calculating cap rate ranges. It distinguishes itself from sibling tools by focusing on interest rates and their use in financial modeling.
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 instructs to use this tool before any DCF model or loan underwriting, and highlights that it provides real-time numbers Claude cannot access on its own, giving clear context for 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.
get_inflation_dataAInspect
Get current CPI and rent inflation data from the Federal Reserve. Returns overall inflation, shelter inflation, and rent-specific CPI with YoY changes. Use this to calibrate rent growth assumptions in your DCF model — don't guess.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: it returns overall inflation, shelter inflation, and rent-specific CPI with YoY changes from the Federal Reserve. This is sufficient for a read-only tool with no parameters, though more detail on data frequency or caching could be added.
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 key purpose, and every word adds value. 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?
Given the tool has no parameters and an output schema exists, the description is mostly complete. It specifies what data is returned and how to use it. Minor gap: could mention data update frequency or limitations.
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 parameters (100% coverage), so the description naturally adds no parameter semantics. Per guidelines, baseline for 0 parameters is 4.
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 specific verb 'Get' and resource 'CPI and rent inflation data from the Federal Reserve', clearly stating the tool's purpose. It distinguishes from sibling data tools like get_current_rates and get_cre_market_data by focusing on inflation metrics.
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 recommends use for calibrating rent growth assumptions in DCF models ('don't guess'), providing clear context. However, it lacks explicit when-not-to-use instructions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_demographicsAInspect
Get Census Bureau demographics for any US property address. Returns median income, population, employment rate, housing vacancy, median rents, and education levels for the census tract.
This is address-specific data from the actual Census tract — not estimates. Claude cannot access this without the MCP. For 1/3/5-mile trade-area rings, use get_radius_demographics instead.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Full US property address (e.g. "1234 Main St, Charlotte, NC 28202") |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that data comes from actual Census tract (not estimates) and that Claude cannot access without the MCP. It lists returned fields but does not mention rate limits, auth requirements, or potential missing data. Still, the description adds meaningful behavioral context beyond schema.
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?
Description is four sentences, front-loaded with the main action and purpose. Every sentence adds value: data content, accuracy note, MCP access, and sibling tool reference. No redundant or unnecessary text.
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 (1 parameter, output schema present, clear sibling distinction), the description covers all necessary context: what it does, what it returns, how it differs from related tools, and a note on data source. Output schema handles return value details, so description is fully adequate.
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 'address' parameter with a descriptive example. Description reinforces that the address must be a US property address but adds no new parameter-specific semantics beyond what schema already provides.
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 explicitly states 'Get Census Bureau demographics for any US property address,' listing specific data points (median income, population, etc.). It distinguishes from sibling 'get_radius_demographics' by noting that this tool returns address-specific data from the actual Census tract.
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?
Clearly states the tool is for address-specific demographics and directs users to 'get_radius_demographics' for trade-area rings. It implicitly tells when not to use this tool. However, no explicit prerequisites or when-not-to-use scenarios are provided beyond the sibling reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_radius_demographicsAInspect
Get aggregated Census demographics for radius rings around a US property address — the standard 1/3/5-mile trade-area format used in CRE site analysis. Aggregates every census tract whose centroid falls within each radius: population, household-weighted median income, employment rate, college attainment, housing vacancy, renter share, and median rent.
Use this for trade-area / site analysis. Use get_market_demographics for the single census tract immediately around the address.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Full US property address (e.g. "1234 Main St, Charlotte, NC 28202") | |
| radii_miles | No | Comma-separated radii in miles (default "1,3,5", each capped at 15) | 1,3,5 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the aggregation method (census tracts whose centroid falls within radius) and lists all output metrics. Although it doesn't explicitly state read-only behavior, the context implies non-destructive data retrieval. With no annotations, the description mostly carries the transparency burden well.
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 four focused sentences. It front-loads the purpose, then explains the aggregation method, lists output metrics, and provides usage guidance. 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 the tool has an output schema (so return values are documented externally), the description covers all necessary aspects: what it does, how it works, what metrics are returned, and when to use vs sibling. No gaps remain.
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 add additional meaning beyond what the schema already provides for the two parameters (address and radii_miles). It mentions radii but schema already has description, default, and constraints.
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 aggregated Census demographics for radius rings around a US address, specifying the standard 1/3/5-mile trade-area format. It distinguishes from sibling get_market_demographics, making the 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 explicitly says to use this tool for trade-area/site analysis and directs users to get_market_demographics for a single census tract. This provides clear when-to-use and when-not-to-use guidance.
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!