DoorProfit Crime & Neighborhood Data
Server Details
US crime scores, incidents, neighborhood demographics, rent data, and offender search by address.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 4 of 4 tools scored.
Each tool targets a distinct aspect: API usage, crime safety, neighborhood demographics, and registered offenders. There is no overlap, and the descriptions clearly differentiate their purposes.
All tool names follow a consistent verb_noun pattern (get_api_usage, get_crime_data, etc.) using snake_case, making the set predictable and easy to understand.
With 4 tools, the server covers key functionalities without unnecessary bloat or deficiency. Each tool serves a clear purpose in the domain of crime and neighborhood data.
The set covers major data areas (crime safety, neighborhood stats, offenders, and API usage). A minor gap is the lack of historical crime trends, but the core querying needs are well-addressed.
Available Tools
4 toolsget_api_usageCheck API Usage & QuotaARead-onlyIdempotentInspect
Get the current plan, monthly/daily API call usage, remaining quota, and reset times for the configured DoorProfit API key. Free: does NOT consume quota. Call this when the user asks about their remaining calls or hits a quota error.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | |
| success | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, not destructive. Description adds 'does NOT consume quota', which is a behavioral detail beyond 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 concise sentences. Front-loaded with action and resource; second sentence provides usage guidance and a behavioral note. 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?
Has output schema, so return values are covered. Combined with annotations and description, the tool is fully specified for its zero-param interface.
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; schema coverage is 100%, and description adds no parameter info. Baseline for zero params 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?
Clearly states the tool retrieves current plan, usage, quota, and reset times. Siblings are unrelated (crime, neighborhood, offenders), so distinguishing is natural.
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 guides when to call: when user asks about remaining calls or hits quota error. No when-not-to-use, but purpose is narrow and siblings are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crime_dataGet Crime Data & Safety ScoreARead-onlyIdempotentInspect
Get the crime safety score (A+ through F), crime breakdown vs national average, and recent crime incidents within 1000ft of a US address or coordinates. Use this to answer questions like "is this address/neighborhood safe?". Consumes 1 API call from the user's DoorProfit quota.
| 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that each call consumes 1 API call from the user's DoorProfit quota, which is significant behavioral context not covered by 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?
Three sentences efficiently convey purpose, use case, and quota cost. No fluff, front-loaded with core functionality.
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 complexity (3 optional params, no required), schema is fully covered, annotations exist, and an output schema is present. The description explains what is returned (score, breakdown, incidents) and constraints (1000ft, US address), leaving no major gaps.
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?
With 100% schema coverage, baseline is 3. The description adds that the tool covers a 1000ft radius and reinforces the mutual exclusivity of address vs lat/lng, providing practical guidance 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 clearly states the tool retrieves crime safety scores (A+ to F), breakdown vs national average, and recent incidents, with a specific verb 'Get'. It distinguishes from sibling tools (get_neighborhood_data, search_offenders) by focusing on crime safety for addresses.
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 advises using the tool to answer questions like 'is this address safe?', providing clear context. It doesn't mention when not to use or alternatives, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_neighborhood_dataGet Neighborhood Demographics & EconomicsARead-onlyIdempotentInspect
Get comprehensive neighborhood data for a US address or coordinates: demographics, median income, housing values, rent estimates, education, cost of living, weather, and natural disaster risk. Consumes 1 API call from the user's DoorProfit quota.
| 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to repeat them. It adds value by noting the API call quota consumption, which is a behavioral trait not in annotations. No contradictions.
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-loads the purpose and data types, and includes a separate sentence for quota info. Every word contributes 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?
Given the presence of an output schema and annotations, the description covers the tool's purpose, input alternatives, data categories, and quota usage. It is sufficiently complete for an agent to understand when and how to invoke it.
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 lat, lng, and address. The description reiterates the choice between address and coordinates but does not add new semantic details beyond the schema. 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 uses a specific verb ('Get') and resource ('comprehensive neighborhood data') and is clearly distinguished from sibling tools like 'get_crime_data' by listing demographics, economics, weather, and disaster risk. It covers both address and coordinate inputs.
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 states inputs (US address or coordinates) and mentions quota consumption, but does not explicitly provide guidance on when to use this tool over siblings or when not to use it. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_offendersSearch Registered OffendersARead-onlyIdempotentInspect
Search registered offenders near a US location (address or lat/lng, radius up to 3 miles) or by name (first_name/last_name/dob, optionally filtered by city/state/zipcode). Consumes 1 API call from the user's DoorProfit 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, and not destructive. The description adds behavioral info about consuming 1 API call from the user's DoorProfit quota, which is useful beyond annotations. No contradictions.
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: first covers purpose and parameters, second notes quota. It is concise and front-loaded with key information, though slightly more structure could help.
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 12 parameters, two search modes, and existing output schema, the description covers main use cases, constraints, and quota. It could mention that no parameters are required, but otherwise 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 each parameter has a description. The description adds meaning by grouping parameters into location vs name search modes and stating constraints like radius max 3 miles, enhancing clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches registered offenders by location (address or lat/lng, radius up to 3 miles) or by name with optional filters. It distinguishes from sibling tools like get_crime_data and get_neighborhood_data which serve different purposes.
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 context on when to use this tool (searching offenders by location or name) and notes API call consumption. It does not explicitly state when not to use or list alternatives, but the purpose is well-defined.
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!