CDC Social Vulnerability Index
Server Details
SVI scores and theme breakdowns by county and tract
- 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.4/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: compare_svi compares multiple counties, get_county_svi retrieves county-level data, get_most_vulnerable ranks counties by vulnerability, and get_tract_svi provides sub-county tract data. There is no overlap in functionality, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern (e.g., compare_svi, get_county_svi, get_most_vulnerable, get_tract_svi), using clear verbs and descriptive nouns. This uniformity enhances readability and predictability across the tool set.
With 4 tools, the server is well-scoped for its purpose of accessing CDC Social Vulnerability Index data. Each tool serves a specific and necessary function (comparison, retrieval, ranking, and sub-county analysis), with no redundant or missing operations, making the count ideal for the domain.
The tool set provides comprehensive coverage for querying SVI data, including operations for comparing counties, retrieving county and tract data, and ranking vulnerability. There are no obvious gaps; agents can perform all essential analyses within the domain without encountering dead ends.
Available Tools
4 toolscompare_sviAInspect
Compare SVI data across multiple counties.
Returns side-by-side SVI percentile rankings and key indicators for
the specified counties. Useful for comparing vulnerability across
service areas or peer counties.
Args:
fips_codes: Comma-separated 5-digit county FIPS codes (e.g. '53033,53053,53061').
year: SVI data year (default 2022, currently only 2022 available).| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| fips_codes | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output format (side-by-side percentile rankings) and critical data constraint (only 2022 available) beyond empty 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?
Front-loaded with purpose and return value, followed by targeted use case; Args section efficiently augments bare schema 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?
Complete for a 2-parameter tool; appropriately delegates detailed return value documentation to the output schema while summarizing the comparison format.
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?
Fully compensates for 0% schema description coverage by providing format examples (comma-separated FIPS codes) and value constraints (default year, availability).
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?
States specific action (compare SVI data) and scope (multiple counties), distinguishing it from single-county sibling tools.
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 clear context for use (comparing vulnerability across service areas or peer counties) but lacks explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_county_sviAInspect
Get CDC Social Vulnerability Index data for counties in a state.
Returns overall SVI percentile ranking and all four theme breakdowns
(socioeconomic status, household composition/disability, minority
status/language, housing type/transportation) plus key indicator
estimates for each county.
SVI values range 0-1 (percentile ranking); higher = more vulnerable.
Args:
state: Two-letter US state abbreviation (e.g. 'WA', 'CA').
county_fips: Optional 5-digit county FIPS code to get a single county.
year: SVI data year (default 2022, currently only 2022 available).| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| state | Yes | ||
| county_fips | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries full burden: explains return structure (four themes, percentiles), data semantics (0-1 scale, higher=more vulnerable), and availability constraints (only 2022 data available).
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?
Well-structured with purpose front-loaded; Args section clearly delineates parameters, though 'Args:' labeling is slightly informal and theme enumeration consumes space that could be in output schema.
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?
Comprehensive for the domain: explains SVI methodology (four themes), value interpretation, and parameter requirements; does not need to detail return values further given output schema exists.
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 0% schema description coverage, description compensates fully by providing formats, examples, and constraints for all three parameters (state abbreviation format, FIPS code length, year availability).
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?
Clear specific verb ('Get') and resource ('CDC Social Vulnerability Index data'), explicitly targets 'counties' which distinguishes from sibling get_tract_svi.
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?
Implies usage by specifying county-level granularity but lacks explicit when/when-not guidance regarding siblings (e.g., no mention to use compare_svi for comparisons or get_tract_svi for tract-level data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_most_vulnerableAInspect
Get the most vulnerable counties in a state ranked by SVI score.
Returns counties sorted by highest SVI percentile ranking for the
specified theme. Useful for identifying priority areas for grants
and community health interventions.
Args:
state: Two-letter US state abbreviation (e.g. 'WA', 'CA').
theme: SVI theme to rank by. Options: 'overall', 'socioeconomic',
'household' (composition/disability), 'minority' (status/language),
'housing' (type/transportation). Default is 'overall'.
limit: Number of counties to return (default 20, max 100).| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | Yes | ||
| theme | No | overall |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries full burden effectively by disclosing sorting behavior (highest SVI percentile), default values, max constraints (max 100), and theme option semantics (parenthetical descriptions of theme meanings).
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?
Well-structured with purpose front-loaded, followed by return behavior, use case, and parameter details; slight redundancy between first two sentences but otherwise every line 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 output schema exists, description appropriately summarizes return values (sorted counties) without detailing structure; covers all 3 parameters adequately for the tool's moderate 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?
With 0% schema description coverage, description fully compensates by providing detailed Args section explaining state format (two-letter abbreviation with examples), theme options (with domain-specific meanings), and limit constraints (default/max).
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?
Clear specific action (get/rank counties) with specific resource (vulnerable counties by SVI score), and distinguishes from siblings by emphasizing ranking/prioritization vs single lookups (get_county_svi) or comparisons (compare_svi).
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 clear context on when to use ('identifying priority areas for grants and community health interventions') though lacks explicit 'when not to use' or alternative pointers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tract_sviAInspect
Get tract-level CDC Social Vulnerability Index data within a county.
Returns overall SVI and all four theme percentile rankings for each
census tract in the specified county. Useful for identifying
sub-county areas of high vulnerability.
Args:
state: Two-letter US state abbreviation (e.g. 'WA', 'CA').
county_fips: 5-digit county FIPS code (e.g. '53033' for King County, WA).
year: SVI data year (default 2022, currently only 2022 available).
limit: Maximum number of tracts to return (default 50, max 500).| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| limit | No | ||
| state | Yes | ||
| county_fips | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return structure (overall SVI + four themes) and data limitations ('currently only 2022 available'), though omits error handling behavior.
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?
Well-structured with purpose front-loaded; Args section is necessary given schema deficiencies, though 'Args:' header is slightly redundant in MCP context.
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?
Adequately complete for moderate complexity (4 params) despite missing output schema details; covers all required inputs with examples.
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?
Fully compensates for 0% schema description coverage with detailed Args section including examples (e.g., '53033' for King County) and constraints (max 500).
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?
Specific verb-resource combination ('Get tract-level CDC SVI data') clearly distinguishes from siblings like get_county_svi through explicit granularity specification.
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 use case ('identifying sub-county areas') but lacks explicit when/when-not guidance or comparison to sibling alternatives.
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!