Environmental justice screening indicators, pollution burden, and demographic vulnerability
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.
Average 4.4/5 across 5 of 5 tools scored.
Each tool serves a clearly distinct purpose: demographics, environmental indicators, county EJ summary, state EJ summary, and point-location EJ data. No two tools are likely to be confused despite all relating to EJScreen.
All tools follow a consistent 'get_' prefix followed by a descriptive noun phrase. The pattern is uniform, making it easy to predict tool behavior from names.
Five tools is appropriate for the scope of providing EJScreen data access. Each covers a necessary aspect of the domain without unnecessary redundancy.
The set covers demographic, environmental, county/state summaries, and point-based EJ screening. A minor gap is the lack of a direct block-group lookup by ID, though county/state filtering partially addresses this.
get_demographic_indicatorsAInspectGet demographic vulnerability indicators by block group.
Returns demographic data including minority percentage, low income
percentage, linguistic isolation, education levels, and age
distributions. These are the demographic components used in
EJScreen's EJ index calculations.
Args:
state: Two-letter US state abbreviation (e.g. 'WA', 'CA').
county_fips: Optional county FIPS code (3-digit or 5-digit).
If omitted, returns state-level results sorted by
highest demographic index.
limit: Maximum number of block groups to return (default 50, max 500).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | Yes | ||
| county_fips | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the data types returned (minority %, low income %, linguistic isolation, education, age), the default limit of 50 with max 500, and the state-level behavior when county_fips is omitted. While it doesn't discuss error cases or performance, the core behavior is 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?
The description is well-structured with a clear first sentence, a concise list of data contents, and a compact Args section that covers all parameters. It is appropriately sized and front-loaded, though the Args block could arguably be tightened without losing clarity.
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 moderate complexity (3 params, output schema present), the description is complete enough: it specifies the primary behavior, the data categories, and parameter semantics. The output schema likely covers return shape, so not explaining return structure is acceptable. Missing explicit alternatives is the only gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema provides no descriptions (0% coverage), the description compensates by explaining each parameter: state format with examples, county_fips format and optionality, and limit default/max. This adds meaning beyond the schema and helps the agent construct correct calls.
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 ('demographic vulnerability indicators by block group'), clearly distinguishing it from sibling tools like get_environmental_indicators or get_ej_county_summary. It also ties the tool to EJScreen's EJ index calculations, providing unique scope.
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: returns demographic indicators, can be limited to a county or state-level when county_fips is omitted, and sorted by highest demographic index. It does not explicitly state when to use this over alternatives, but the context is sufficient for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ej_county_summaryAInspectGet EJ indicators for census block groups in a county.
Returns EJScreen environmental justice data for block groups within
the specified county, sorted by highest overall environmental burden.
Includes environmental indicators, demographic data, and EJ indexes.
Args:
state: Two-letter US state abbreviation (e.g. 'WA', 'CA').
county_fips: County FIPS code, either 5-digit full (e.g. '53033')
or 3-digit county portion (e.g. '033'). If 3 digits,
state FIPS is prepended automatically.
limit: Maximum number of block groups to return (default 50, max 500).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | Yes | ||
| county_fips | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the sort order (highest overall environmental burden), the types of data included, and the automatic FIPS code handling. However, it does not explicitly state side effects or permissions, though 'Get' and 'Returns' imply a read-only 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 front-loaded with the purpose and then provides structured parameter documentation with examples. It is concise, with no filler, and every sentence adds useful 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?
The tool has an output schema, so return value details are not required, but the description still describes the output categories and sorting. Together with thorough parameter docs and clear scope, the description fully equips an agent to invoke the tool 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 0%, but the description thoroughly documents each parameter: state format with examples, county_fips with both 5-digit and 3-digit handling including auto-prepending, and limit with default and max. This fully compensates for the schema's lack of 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 a specific verb ('Get'), names the resource ('EJ indicators'), and specifies the scope ('census block groups in a county'). This clearly distinguishes it from siblings like get_ej_state_summary (state-level) and get_demographic_indicators (demographics only).
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 clearly states the tool is for county-level data and describes the output, but does not explicitly name alternatives or provide exclusion criteria. Agents can infer when to use it based on the county scope, but the description lacks direct '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.
get_ej_data_by_locationAInspectGet EJScreen environmental justice data for a specific location.
Uses the EPA EJScreen REST broker to retrieve EJ screening indicators
for a point location with a buffer distance. Returns environmental
indicators, demographic data, and EJ indexes.
Args:
latitude: Latitude of the location (e.g. 47.61).
longitude: Longitude of the location (e.g. -122.33).
distance: Buffer distance in miles around the point (default 1.0).
| Name | Required | Description | Default |
|---|---|---|---|
| distance | No | ||
| latitude | Yes | ||
| longitude | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the EPA EJScreen REST broker and the types of data returned, but does not disclose limitations, error handling, rate limits, or any side effects (though the operation appears read-only from 'Get' and 'retrieve'). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-organized: a clear one-sentence purpose, a brief implementation/context sentence, a return summary, and a structured parameter list. The REST broker detail is useful context and does not seem wasteful.
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 moderate complexity and the presence of an output schema (which covers return details), the description provides sufficient context: purpose, parameter semantics, and a high-level summary of returned data. It does not need to explain return values in depth. The only gap is lack of explicit alternative tool guidance.
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 provides a full Args section with examples and defaults for all three parameters (latitude, longitude, distance). This adds clear meaning beyond the bare schema and fully compensates for the missing 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's purpose: 'Get EJScreen environmental justice data for a specific location' with specifics about point location and buffer distance. It distinguishes from siblings like county/state summary tools by emphasizing point-based location and returning combined environmental, demographic, and EJ index 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 for point-based queries ('for a point location with a buffer distance') but does not explicitly mention alternatives or when not to use this tool. Sibling tools (e.g., get_ej_county_summary) are not referenced, so the guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ej_state_summaryAInspectGet a state-level overview of EJ indicators across block groups.
Returns the most environmentally burdened block groups in the state,
sorted by PM2.5 percentile. Useful for identifying areas with the
highest environmental justice concerns.
Args:
state: Two-letter US state abbreviation (e.g. 'WA', 'CA').
limit: Maximum number of block groups to return (default 100, max 500).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears responsibility. It discloses that the tool returns 'most environmentally burdened block groups' and that results are 'sorted by PM2.5 percentile,' which is meaningful behavior beyond the schema. It does not discuss error handling or output shape, but the output schema covers return details.
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 plus a compact Args list; no filler. The tool's purpose and key parameters are 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?
The tool is simple (2 params, 1 required), and an output schema exists. The description covers the essential behavior, sorting, and parameter constraints, making it sufficient. It could add a note about if no state match, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section explains both parameters: 'state' requires a two-letter abbreviation with examples, and 'limit' specifies maximum block groups with default 100 and max 500. The schema only provides type/default, so this is high-value semantic detail.
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 starts with 'Get a state-level overview of EJ indicators across block groups' and specifies output: 'most environmentally burdened block groups... sorted by PM2.5 percentile.' This clearly distinguishes from siblings such as get_ej_county_summary and get_ej_data_by_location.
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?
It states the tool is 'Useful for identifying areas with the highest environmental justice concerns,' providing clear context. It does not explicitly name alternatives or exclusions, but the state-level framing plus sibling names make the intended scope apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_environmental_indicatorsAInspectGet specific environmental indicators by block group.
Returns environmental indicator values and state percentiles for
block groups. Can filter to a specific indicator type or return all.
Args:
state: Two-letter US state abbreviation (e.g. 'WA', 'CA').
county_fips: Optional county FIPS code (3-digit or 5-digit).
If omitted, returns state-level results.
indicator: Optional specific indicator to focus on. Options:
'pm25', 'ozone', 'diesel', 'cancer', 'respiratory',
'traffic', 'lead', 'superfund', 'hazwaste',
'wastewater', 'rmp', 'ust'. If omitted, returns all.
limit: Maximum number of block groups to return (default 50, max 500).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | Yes | ||
| indicator | No | ||
| county_fips | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what the tool returns (environmental indicator values and state percentiles), the scope behavior (state-level when county omitted), filtering capabilities, and a default/max limit. It doesn't mention error handling or data source caveats, but covers key behavioral aspects.
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 efficiently front-loaded with the core purpose, followed by a concise summary sentence, then a structured Args list. Every sentence adds value; the length is justified by the detail needed for parameter options, with no fluff or 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 covers all essential aspects for a tool with 4 parameters, including parameter semantics, defaults, filtering options, and scope behavior. An output schema is present, so return structure doesn't need explanation. It is complete for an agent to select and invoke the tool 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 0%, so the description fully compensates. It documents all four parameters: state with examples, county_fips with format and behavior, indicator with a complete enum list, and limit with default and max. This goes well beyond the minimal schema information.
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' with a specific resource ('environmental indicators') and scope ('by block group'), immediately distinguishing it from sibling tools that focus on demographic indicators or county/state summaries. The first sentence is specific and informative.
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 for when to use the tool: to retrieve environmental indicators for block groups, with optional county and indicator filters, and state-level fallback behavior. It doesn't explicitly name alternative tools or exclusion criteria, but the context is sufficient for an agent to differentiate usage.
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.
No comments yet. Be the first to start the discussion!