DealScanner
Server Details
Search real-estate deals, rank top areas, run rental/BRRRR/flip analysis, pull sold comps.
- 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 3.9/5 across 7 of 7 tools scored.
Most tools have clear distinct purposes, but get_property with strategy 'brrrr' may overlap with analyze_brrrr, causing minor ambiguity.
Naming conventions are mixed: some verbs (get_, search_), others are nouns (area_stats, whoami). Inconsistent pattern.
7 tools is well-scoped for an investment analysis server, covering core functionality without being excessive.
Covers key analysis and search tasks, but lacks tools for saving or managing user data, which may be out of scope.
Available Tools
7 toolsanalyze_brrrrAInspect
Run a BRRRR (buy-rehab-rent-refinance-repeat) analysis.
Provide either `address` to analyze an existing listing, or the raw inputs
(`purchase_price`, `rehab_cost`, `arv`, `monthly_rent`) for an ad-hoc deal.| Name | Required | Description | Default |
|---|---|---|---|
| arv | No | ||
| address | No | ||
| rehab_cost | No | ||
| monthly_rent | No | ||
| purchase_price | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only analysis, but does not disclose any side effects, permissions, or limitations beyond the analysis itself.
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 that front-load the core purpose and then break down usage modes. No extraneous 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?
No output schema or description of return values. The tool is an analysis, so what it outputs (ROI, cash flow, etc.) is important but omitted. Missing examples or edge cases.
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 0% description coverage. The description clarifies the purpose of 'address' vs raw inputs, but does not explain each parameter (e.g., ARV, rehab_cost) in detail, relying on self-explanatory names.
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 runs a BRRRR analysis, with two modes (address or raw inputs), and is distinct from sibling tools like get_property or get_comps.
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 explains when to use the tool and provides two usage modes, but lacks explicit guidance on when not to use it or direct comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
area_statsAInspect
Get aggregated market, sheriff, sold, and investment stats for one area.
Args:
name: Neighborhood or municipality name (e.g. "Point Breeze North").
area_type: "neighborhood" or "municipality".
Returns counts, median prices, average cap rate, and sold-comp metrics
for the area.| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| area_type | No | neighborhood |
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 burden. It describes the output ('counts, median prices, average cap rate, and sold-comp metrics') but does not disclose if the operation is read-only, any side effects, or authentication requirements. The purpose implies a safe query, but explicit safety traits are missing.
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 clear sentences plus a structured Args list. Every word serves a purpose; 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?
With no output schema and two simple parameters, the description covers inputs and output types (counts, median prices, cap rate, sold-comp metrics). However, it lacks detail on return format, units, or potential errors. Adequate for low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds an Args section explaining 'name' as a neighborhood or municipality name and 'area_type' as 'neighborhood' or 'municipality' with a default. This provides meaningful context beyond the raw 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 'Get aggregated market, sheriff, sold, and investment stats for one area' with a specific verb and resource. It implicitly distinguishes from siblings like get_property (single property) and get_comps (comparable sales) by focusing on aggregate stats for an area.
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?
No guidance on when to use this tool versus alternatives. Despite listing sibling tools like top_investment_areas or search_deals, the description does not mention when to choose area_stats over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_compsBInspect
Get recently sold comparable properties.
Args:
query: Address or area substring to match.
limit: Max results (1-100).| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but only states the tool 'Get recently sold comparable properties', which implies a read operation. It fails to mention rate limits, authentication needs, or what happens with empty results, leaving significant behavioral gaps.
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 extremely concise at three sentences with no wasted words. However, the 'Args' section is formatted as a list rather than prose, which is acceptable but slightly less structured than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description covers purpose and parameters but does not describe the return format or typical results. Given the complexity, this is adequate but incomplete for an agent to fully anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining 'query' as 'Address or area substring to match' and 'limit' as 'Max results (1-100)'. This adds clear meaning beyond the schema's property titles and defaults.
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 verb 'Get' and the resource 'recently sold comparable properties', which is specific and distinguishes this tool from siblings like 'get_property' (single property) and 'search_deals' (deals). The 'recently sold' qualifier adds further precision.
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 no guidance on when to use this tool versus alternatives such as 'get_property' or 'search_deals'. It lacks explicit when-to-use or when-not-to-use directives, leaving the agent to infer based on purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_propertyBInspect
Get the full DealScanner analysis for one property by street address.
Args:
address: Full property address.
strategy: "flip", "rental", or "brrrr".| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| strategy | No | flip |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. 'Get' suggests read-only, but no details on side effects, permissions, rate limits, or return behavior beyond 'full 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?
Two sentences plus an args block, efficient and front-loaded. Could be more structured but 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?
For a simple 2-parameter tool with no output schema, the description covers purpose and basic parameters well. Missing output description and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must add meaning. It mentions both parameters: address (required) and strategy with default 'flip' listing possible values. Adds some value but no format or constraints 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?
The description clearly states the verb 'Get' and the resource 'full DealScanner analysis for one property by street address'. It distinguishes from siblings like search_deals (multiple properties) and get_comps (comps).
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 this tool is for a single property analysis, but no explicit guidance on when to use versus siblings 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.
search_dealsAInspect
Search DealScanner investment properties.
Args:
query: Address, municipality, or neighborhood text to match.
strategy: Investment lens - one of "flip", "rental", "brrrr".
min_price / max_price: Listing price bounds (USD).
beds / baths: Minimum bedroom / bathroom count.
property_class: Comma-separated neighborhood grades (A,B,C,D).
source: "market" (listed) or "sheriff" (auction).
limit: Max results (1-100).
Returns a dict with `results`, `total`, and pagination info.| Name | Required | Description | Default |
|---|---|---|---|
| beds | No | ||
| baths | No | ||
| limit | No | ||
| query | No | ||
| source | No | market | |
| strategy | No | flip | |
| max_price | No | ||
| min_price | No | ||
| property_class | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides behavior details: returns a dict with results, total, pagination. It describes search logic (text matching) and parameter usage, though no mention of read-only nature or side effects.
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?
Structured as a clear bullet list of arguments with a returns line. Efficient and easy to parse, though slightly verbose (e.g., 'Investment lens - one of...' could be shortened).
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 all parameters and return format despite no output schema. Includes pagination info and parameter types, but omits default values and potential ordering/sorting details.
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 0%, but the description adds significant meaning for each parameter: explains strategy options, source meanings, property_class format, and limit range (1-100). This compensates fully for the lack of 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 clearly states 'Search DealScanner investment properties,' specifying the action and resource. It distinguishes from siblings like get_property (single property) and analyze_brrrr (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?
No explicit guidance on when to use this tool versus alternatives like get_property or top_investment_areas. The description implicitly suggests filtering, but lacks direct comparisons or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
top_investment_areasAInspect
Rank the best areas to invest (neighborhoods + municipalities).
Answers "where should I invest?" using DealScanner's market intelligence.
Args:
sort_by: Ranking metric - one of "cap_rate" (avg cap rate),
"roi"/"flip_watch" (projected flip ROI), "count" (inventory),
or "price" (lowest median price first).
limit: Number of areas to return (1-50).
Returns a dict with `areas` (name, type, cap_rate, roi, count,
median_price, ...) sorted by the chosen metric.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sort_by | No | cap_rate |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses return format and sorting behavior, fully transparent for a read-only query 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?
Concise, front-loaded purpose, structured with Args and Returns, 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, description adequately explains return dict; parameters fully specified; covers agent needs.
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?
Description adds value beyond schema by enumerating valid sort_by options and limit range, despite 0% schema coverage.
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 it ranks best areas to invest (neighborhoods/municipalities) and answers 'where should I invest?', distinguishing from siblings like area_stats or search_deals.
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 from the question it answers, but no explicit when-not or alternatives compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiAInspect
Return the identity and scopes of the current DealScanner API principal.
| 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 provided, the description carries full burden. It clearly states the output (identity and scopes), which is transparent. No side effects or access issues are mentioned, but for a read-only identity check, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that front-loads the purpose. 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 the zero parameters and no output schema, the description provides complete context: it returns the identity and scopes of the current principal. Nothing else is needed.
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 tool has no parameters, so schema coverage is 100%. The description adds value by explaining what the tool returns, which goes beyond the empty schema. Baseline 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 clearly states the tool returns identity and scopes of the current principal, which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'get_property' or 'search_deals' that deal with other 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?
The description implies usage when the agent needs to know the current identity or scopes. No explicit when-not or alternatives are given, but it's clear enough for a simple, parameterless 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!