Official hosted MCP server for the DoorProfit API — US crime, safety, and neighborhood data for any address, inside Claude, ChatGPT, Cursor, and any MCP-capable client.
https://api.doorprofit.com/mcpAsk your AI assistant "Is 500 Adams St in Tulsa safe?" and it answers with real data: a letter-grade safety score, recent incidents within 1,000 ft, neighborhood demographics, income, rent, home values, and more.
Tool | Description | Quota |
| Safety score (A+ to F), crime breakdown vs national average, recent incidents within 1,000 ft | 1 call |
| Demographics, income, home values, rent, cost of living, weather & disaster risk | 1 call |
| Registered offenders near a location (≤3 mi) or by name | 1 call |
| Your plan, usage, and remaining quota | Free |
Related MCP server: PropertyScoop MCP Server
Add https://api.doorprofit.com/mcp as a remote MCP server / custom
connector in your client. You'll be prompted to sign in to your DoorProfit
account and approve access. No keys to copy.
Get a free key at api.doorprofit.com/signup, then configure:
{
"mcpServers": {
"doorprofit": {
"url": "https://api.doorprofit.com/mcp",
"headers": {
"Authorization": "Bearer dp_your_api_key"
}
}
}
}Clients that only accept a URL can use
https://api.doorprofit.com/mcp?key=dp_your_api_key instead.
For clients that only speak stdio, this repository contains a small bridge that exposes the hosted server as a local process. It requires Node 18+.
{
"mcpServers": {
"doorprofit": {
"command": "npx",
"args": ["-y", "github:shawndoor/doorprofit-mcp"],
"env": {
"DOORPROFIT_API_KEY": "dp_your_api_key"
}
}
}
}Or with Docker:
docker build -t doorprofit-mcp .
docker run -i --rm -e DOORPROFIT_API_KEY=dp_your_api_key doorprofit-mcpThe bridge forwards every tool call to https://api.doorprofit.com/mcp and
pulls its tool definitions from the same place, falling back to the snapshot
in src/tools.json when the API is unreachable. Set DOORPROFIT_MCP_URL to
point it somewhere else. Run npm run sync-tools to refresh the snapshot
after the hosted tool definitions change.
The test address 500 Main St, Dallas, TX 75202 returns real data and
never consumes quota — perfect for kicking the tires.
Transport: Streamable HTTP (stateless)
Auth: OAuth 2.1 (authorization code + PKCE, dynamic client registration) or API key
Coverage: United States addresses (street address or lat/lng)
Quotas: tool calls are metered against your DoorProfit plan; free tier available, paid plans raise limits
Support: support@doorprofit.com
This repository contains the documentation and the open-source stdio bridge
for the hosted server. The data pipeline behind api.doorprofit.com is not
open source.
Report the plan, monthly and daily call usage, remaining quota, reset times, rate limit and overage status for the DoorProfit API key authenticating this session. Takes no arguments — it always describes the calling key, never another account. Call it when the user asks how many calls they have left, or after any other tool returns QUOTA_EXCEEDED or DAILY_LIMIT_EXCEEDED, to confirm the limit and reset time before suggesting an upgrade. This is the only tool that never consumes quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | No | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it explicitly states 'Takes no arguments — it always describes the calling key, never another account' and 'This is the only tool that never consumes quota,' two non-obvious behavioral traits an agent would otherwise not know. This is a strong addition; a 5 would require even richer detail on output structure or rate-limit nuances.
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 sentences, each earning its place: the first states the report contents and scope, the second gives concrete usage triggers, the third adds the unique no-quota-consumption trait. No filler, no repetition of schema information, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return-value details are handled structurally. The description covers what the tool reports (plan, usage, quota, resets, limits, overage), when to call it, its zero-argument nature, and its unique non-consuming property. For a 0-parameter read-only tool with strong annotations, this is 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?
There are 0 parameters, so the description's job is to confirm the no-argument contract, which it does explicitly ('Takes no arguments'). The baseline for 0 params is 4, and the description earns the extra point by explicitly stating the no-arguments contract and clarifying that it always operates on the calling key, removing ambiguity about what 'no arguments' might default to.
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 a specific verb ('Report') with a clear resource ('the plan, monthly and daily call usage, remaining quota, reset times, rate limit and overage status') and explicitly scopes it to 'the DoorProfit API key authenticating this session,' distinguishing it from any other-account tool. It clearly differentiates from siblings like get_crime_data and get_neighborhood_data, which handle different domains entirely.
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 when-to-use guidance: 'Call it when the user asks how many calls they have left, or after any other tool returns QUOTA_EXCEEDED or DAILY_LIMIT_EXCEEDED.' It also adds a concrete workflow suggestion ('before suggesting an upgrade'), giving the agent actionable context beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crime safety grade and incident history for one US address or coordinate pair: a letter score (A+ safest through F), a per-crime-type breakdown against the national average, and the individual incidents recorded within 1000ft over a rolling 90-day window. Use this for "is this address/neighborhood safe?" questions. Do NOT use it for demographics, income, rent or schools (use get_neighborhood_data) or for registered offenders (use search_offenders) — neither is included here. Pass either address or lat+lng, not both. US locations only; requires a DoorProfit API key and consumes 1 call from that key's quota, except for the free test address "500 Main St, Dallas, TX 75202".
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (use together with lng, as an alternative to address). | |
| lng | No | Longitude (use together with lat, as an alternative to address). | |
| address | No | Full US street address, e.g. "500 Adams St, Tulsa, OK". Provide either address OR lat+lng. |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| location | No | The resolved location for the query. |
| incidents | No | Recent crime incidents near the location. |
| test_mode | No | True when querying the free test address. |
| crime_score | No | Letter safety grade from A+ (safest) to F. |
| crime_numeric | No | 0-1 scale where 1 is safest. |
| crime_breakdown | No | Per-crime-type comparison vs the national average (e.g. assault, burglary, theft). |
| crime_description | No | Human-readable explanation of the score. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safe-read profile is well covered. The description adds meaningful context beyond annotations: quota consumption (1 call per key), a free test address exception, and data scope (rolling 90-day window, 1000ft radius). Doesn't describe pagination/limits on incident lists, but covers key behavioral traits.
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?
Reasonably compact single paragraph covering purpose, exclusions, alternatives, and constraints. Every sentence earns its place, though it is denser than strictly necessary and could be broken into shorter sentences for scanability. It is front-loaded with the core purpose then fills in usage nuance.
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?
An output schema exists so return-value explanation is not the description's job. For a moderate-complexity query tool with rich annotations, the description covers purpose, scope, constraints, quota cost, free test address, exclusions, and alternatives. Fully adequate for an agent to select and correctly invoke this 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 description coverage is 100%, so the schema already documents all three parameters well (lat, lng, address with mutual exclusivity). The description reinforces that address OR lat+lng should be passed, not both, and notes US-only locations. This aligns with the baseline-3 for high schema coverage; the description adds minimal supplementary meaning beyond reinforcing exclusivity.
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?
Purpose is explicit and specific: returns a crime safety grade (A+ through F), per-crime-type breakdown versus national average, and incidents within 1000ft over 90 days. It names the exact resource (crime data & safety score) and clearly distinguishes from siblings by spelling out exclusions.
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 when to use ('is this address/neighborhood safe?' questions) and explicitly names alternatives for excluded topics: get_neighborhood_data for demographics/income/rent/schools and search_offenders for registered offenders. Also warns against passing both address and lat+lng, and specifies US-only and API key/quota requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Profile of the neighborhood (or census block group) containing one US address or coordinate pair: demographics, median household income, home values, rent by bedroom count, education attainment, cost-of-living indices, climate and natural-disaster risk. Use this when the question is about who lives in an area or what it costs to live there. Do NOT use it for crime or safety scores (use get_crime_data) — no crime data is returned here. Pass either address or lat+lng, not both. The neighborhood field is null where no data exists for the location. US locations only; requires a DoorProfit API key and consumes 1 call from that key's quota, except for the free test address "500 Main St, Dallas, TX 75202".
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (use together with lng, as an alternative to address). | |
| lng | No | Longitude (use together with lat, as an alternative to address). | |
| address | No | Full US street address, e.g. "500 Adams St, Tulsa, OK". Provide either address OR lat+lng. |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| location | No | The resolved location for the query. |
| test_mode | No | True when querying the free test address. |
| neighborhood | No | Neighborhood data; null when no data exists for the location. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is established. The description adds valuable behavioral context beyond annotations: quota consumption (1 call), requires an API key, the neighborhood field can be null when no data exists, and a free test address exception. This is strong supplementary 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 information-dense but organized logically: what's returned, when to use, when not to use, input rules, edge case (null neighborhood), and constraints (US only, API key, quota). Front-loaded with the data profile. Slightly long but every sentence carries distinct 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?
For a read-only, idempotent, open-world tool with an output schema and 100% schema coverage, the description covers purpose, boundaries, input constraints, edge cases, and operational requirements. There's an output schema present, so return-value documentation is handled structurally. Nothing essential is missing for this moderate-complexity 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% (all 3 parameters documented in schema), so baseline is 3. The description adds the mutually-exclusive constraint between address and lat+lng and specifies address format with an example, going slightly beyond schema. However, it doesn't describe lat/lng ranges or precision requirements beyond what schema 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?
The description clearly states the verb+resource (Profile of the neighborhood/census block group) and enumerates the specific data dimensions returned: demographics, income, home values, rent, education, cost-of-living, climate/disaster risk. It also explicitly distinguishes itself from get_crime_data, a sibling tool, by stating what it does NOT return.
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 when-to-use guidance ('Use this when the question is about who lives in an area or what it costs to live there'), explicit when-not-to-use with the named alternative ('Do NOT use it for crime or safety scores (use get_crime_data)'), and input constraints ('Pass either address or lat+lng, not both', 'US locations only'). This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search US registered offenders in one of two modes. Location mode: pass address or lat+lng, plus an optional radius in miles (default 1, capped at 3); results include each offender's distance from the search point. Name mode: pass at least one of first_name, last_name or dob, optionally narrowed by city/state/zipcode — those three filters alone are not accepted. Location parameters take precedence when both are supplied. Use this only for registered-offender questions; for an overall safety grade use get_crime_data instead. Results are paginated (page, limit, max 100 per page) and each page requested requires a DoorProfit API key and consumes 1 call from that key's quota.
| Name | Required | Description | Default |
|---|---|---|---|
| dob | No | Date of birth, YYYY-MM-DD. | |
| lat | No | Latitude (use together with lng, as an alternative to address). | |
| lng | No | Longitude (use together with lat, as an alternative to address). | |
| city | No | City filter for name-based searches. | |
| page | No | Page number (default 1). | |
| limit | No | Results per page (default 50, max 100). | |
| state | No | Two-letter state code filter, e.g. "OK". | |
| radius | No | Search radius in miles for location searches (default 1, max 3). | |
| address | No | Full US street address, e.g. "500 Adams St, Tulsa, OK". Provide either address OR lat+lng. | |
| zipcode | No | Zipcode filter for name-based searches. | |
| last_name | No | Last name for name-based searches. | |
| first_name | No | First name for name-based searches. |
| Name | Required | Description |
|---|---|---|
| page | No | |
| radius | No | Search radius in miles (location searches only). |
| success | Yes | |
| offenders | No | |
| test_mode | No | |
| search_type | No | "gis" for location searches, "name" for name searches. |
| total_count | No | Total matching results. |
| total_pages | No | |
| offenders_count | No | Results on this page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is safe. The description adds valuable behavioral context beyond annotations: results include distance from search point, radius default/cap, pagination details (page, limit, max 100), and importantly that each page request requires a DoorProfit API key and consumes 1 call. This is meaningful disclosure beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely informative with no wasted sentences, covering modes, parameter grouping, precedence rules, exclusions, and API-usage implications in a compact form. It could be split into clearer sub-sections for readability, but every sentence earns its place and the critical information (mode selection, API key cost) 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?
Despite 12 parameters and no required fields, the description fully explains mode selection, parameter constraints, precedence, pagination, and API call costs. The output schema exists so return-value documentation is handled structurally. For a complex multi-mode tool, this is remarkably 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%, so the schema fully documents all 12 parameters. The description adds value by explaining parameter relationships and constraints beyond what the schema states: which params belong to which mode, the 'three filters alone not accepted' rule for city/state/zipcode, radius default/cap semantics, and pagination defaults. This exceeds the baseline 3 for full coverage documents.
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 (search) and resource (US registered offenders), and explicitly defines two operation modes (location and name) with their respective parameter requirements. It distinguishes itself from the sibling get_crime_data by specifying this tool is only for registered-offender questions.
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 when-to-use guidance and names the alternative (get_crime_data for safety grades). It also specifies mode-specific requirements — location needs address or lat+lng, name needs at least one of first_name/last_name/dob — and states that location takes precedence when both are supplied. This is model guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_api_usageget_crime_dataget_neighborhood_datasearch_offendersScored across 4 tools
Each tool targets a clearly distinct data domain: crime/safety, neighborhood demographics, registered offenders, and API usage. The descriptions explicitly cross-reference one another (e.g., 'use search_offenders, not get_crime_data') to prevent misselection. There is no overlap between any two tools.
Tools follow a consistent get_/search_ verb-noun pattern (get_crime_data, get_neighborhood_data, get_api_usage, search_offenders). get_ vs search_ is a minor semantic deviation where search_offenders conveys a different query mode, but the pattern is otherwise highly regular.
Four tools is a well-scoped surface for a neighborhood-data server. Each tool covers a distinct domain (crime, demographics, offenders, quota) and earns its place without bloat or redundancy.
The surface covers the three core residential-data questions (safety, demographics, offenders) plus operational quota management. Minor gaps exist — no school or transit data — but the stated domains are fully addressed and the free-test-address and pagination details suggest mature handling of edge cases.
US crime scores, incidents, neighborhood demographics, rent data, and offender search by address.
Access street-level crime reports, stop and search data, and outcomes across UK police forces
US ZIP code intelligence: demographics, weather, tax, crime, housing, voting, and more.
U.S. real-estate data: property records, AVM value + rent estimates, sale/rental listings.
