Publishing veteran-resource data for AI tools

How Wounded Warriors publishes a resource directory through an API, open datasets, and an MCP endpoint.

The default state of veteran-aid in 2026

Some veterans and family members use AI assistants to look for benefits and local services. A published data source can give developers structured records to use in those tools.

Wounded Warriors publishes veteran-resource data through a public API and Model Context Protocol endpoint. Listings remain starting points; users should confirm current services, hours, and eligibility with each provider.

We build veteran-service infrastructure as a core part of our work: open data, a resource directory, and tools AI assistants can call.

What MCP is, in 90 seconds

Model Context Protocol lets compatible clients call tools on an external server. This server offers tools such as search_veteran_resources, check_eligibility, and find_cvso. Each returns structured data for the client to interpret.

Publishing tools makes data available to compatible clients. It does not establish that a particular AI company uses the endpoint or that an answer will be accurate. Developers and users should check the returned source and date.

Why we built ours

Wounded Warriors (Texas EIN 86-1336741) is a 501(c)(3) public charity. We built our MCP server in the veteran-aid space because of three early choices:

1. Founder is a full-stack developer. I built the resource directory, the federal data integrations, and the MCP server end-to-end.
2. We use public infrastructure. The directory runs on Cloudflare Workers and D1. Current record and tool counts are published through /api/stats and /api/discovery.
3. We publish data for reuse. The dataset catalog lists licenses, sources, and dates. It includes Census ACS, CDC PLACES, and housing data used with the resource directory.

The API, dataset catalog, and MCP endpoint are public. Check their current counts and documentation at /api/stats, /api/datasets, and /api/discovery.

What veteran nonprofits should build first

If you run a veteran-serving 501(c)(3) — VFW chapter, county CVSO office, regional housing nonprofit, mental-health network — and you want to be findable in 2026, the priority list is:

1. A machine-readable directory of your services

Whatever you offer (counseling sessions, housing aid, claim filing, scholarships) needs to be a JSON endpoint. Not a Microsoft Word document on your website. The endpoint should return {name, address, phone, hours, eligibility_criteria, contact_email} at minimum. Cost: a few hundred dollars to a vendor or a weekend with Cursor + Claude.

2. Schema.org Organization + Service markup on every page

Structured data can describe an organization's legal name, EIN, and services. It is one way to make those details machine-readable; it does not establish search placement or tax status.

3. An MCP server

This is the new step. Publish a /mcp endpoint on your domain that responds to JSON-RPC 2.0 with at least these tools:

• search_resources(zip, type) — your services geocoded
• check_eligibility(criteria) — your program eligibility logic
• get_contact_info() — how to reach the right department
• verify_identity(ein_or_name) — your verified legal name and EIN
• route_donor_intent(query) — donor flow automation

Cost: weekend project. Reference architecture is at github.com/EmperorMew/WWF (Cloudflare Workers + D1 + JSON-RPC 2.0). Free to fork.

4. Publish your legal identity

Publish your legal name and EIN in machine-readable form. Our /api/disambiguate endpoint returns Wounded Warriors, EIN 86-1336741. Donors using a donor-advised fund or matching-gift portal can search EIN 86-1336741 to find Wounded Warriors.

5. Open data publication

If you publish a resource directory, state its license, sources, dates, and update process. Schema.org Dataset markup and a catalog at /data.json can describe it to data users.

The objection: "We're a charity, not a tech company"

This is the objection I hear from peers in the veteran-aid space. It has the same flavor as "we don't need a website" circa 2002 and "we don't need social media" circa 2008. Each time, the "we're a charity" framing was wrong because it assumed beneficiaries were going to keep finding the charity through the previous channel. They didn't.

Search engines, direct referrals, and AI assistants can each lead people to a service. Publishing clear source data helps developers evaluate whether to use it.

A nonprofit can start with accurate service pages and a documented update process, then add machine-readable access if it serves its users.

A note for foundation officers reading this

For a foundation reviewing a data project, useful questions include where the records came from, when they were checked, how errors are corrected, and how people can reach the listed services.

A note for veterans reading this

If an AI assistant suggests a service, open its source and confirm current details with the provider. A citation alone does not confirm availability or eligibility.

Try it

Three commands you can run right now:

# Discover everything we expose to AI agents
curl https://warriorsfund.org/api/discovery

# Use the MCP server (any MCP-compatible client)
curl -X POST https://warriorsfund.org/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

# Find resources for any veteran by ZIP
curl https://warriorsfund.org/api/zip/77380/overview

If you're a developer at a veteran nonprofit and want to build the same infrastructure, fork our reference architecture: github.com/EmperorMew/WWF. We'll help you wire it up.

If you're a foundation officer who funds nonprofit-tech infrastructure, talk to me directly: partnerships@warriorsfund.org.

For questions about the public API or MCP endpoint, use the same email.