Skip to main content
Glama
agilesix

CommonGrants Grant Seeker

by agilesix
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

CommonGrants MCP App

Find grant opportunities across federal and state funding sources by asking for them in plain language, right inside Claude or ChatGPT.

Instead of visiting each grant portal, running multiple searches, and manually combining the results, you describe what you're looking for — "find workforce development grants closing in the next 90 days" — and the assistant searches every source at once, then hands you a ranked shortlist you can click through.

What's included

Developers can reuse the shared grant service for search, retrieval, and shortlist assembly without starting an MCP host.

The app searches these funding sources:

Source

What it covers

Simpler.Grants.gov

Federal grant opportunities from U.S. agencies

Pennsylvania

State grant opportunities from the Commonwealth of PA

California

State grant opportunities from California

Washington — FundHub

State grant opportunities from Washington

Maryland — Community Compass

State grant opportunities from Maryland

Results are always labeled with the source they came from, and every opportunity links back to the grantmaker's own page so you can verify details and apply.

For a normal shortlist, the assistant starts with a focused search and evaluates whether the results provide enough relevant coverage. Five or more clearly relevant candidates are ordinarily enough for a non-exhaustive shortlist. It expands the search only when the results are insufficient, ambiguous, or clearly incomplete, then hands the selected references to the presentation tool, which loads their full details in parallel.

All of this data is public, so there's nothing to sign up for and no account to connect — you add the app once and start searching.

Related MCP server: Grants.gov MCP Server

Quickstart

The app is hosted, so installing it means pointing your AI assistant at one URL:

https://mcp.cg.a6lab.ai/mcp

Claude

  1. Open Claude in your browser or desktop app.

  2. Go to Settings → Connectors.

  3. Click Add custom connector.

  4. Paste https://mcp.cg.a6lab.ai/mcp as the remote MCP server URL, give it a name like CommonGrants, and click Add.

  5. Start a new chat and ask for grants. Claude will ask permission the first time it uses the app.

Anthropic's step-by-step guide, including the extra steps a Team or Enterprise owner needs to take before members can add connectors: Get started with custom connectors using remote MCP.

ChatGPT

ChatGPT calls these apps, and adding your own currently requires turning on developer mode first:

  1. In ChatGPT, go to Settings → Security and login and turn on Developer mode.

  2. Go to Settings → Plugins and click +.

  3. Paste https://mcp.cg.a6lab.ai/mcp as the server URL and create the app.

  4. Start a new chat and ask for grants.

OpenAI's guide: Developer mode and MCP apps in ChatGPT.

On a ChatGPT Business or Enterprise workspace, a workspace admin publishes the app once (Workspace Settings → Apps) and everyone else finds it in their app list — individual members don't need developer mode.

Other assistants

Any tool that supports remote MCP servers can use the same URL. See TECHNICAL.md for running the app locally or connecting it to other clients.

Things to try

Once it's connected, ask your assistant things like:

  • "What federal grants are open for rural broadband?"

  • "Find workforce development grants in Pennsylvania closing in the next 90 days."

  • "Compare the eligibility requirements for the top three, and tell me which ones a small nonprofit could actually apply for."

  • "Which of these have no cost-sharing requirement?"

The assistant searches, narrows things down over a few turns, and then presents a single shortlist you can review and expand.

Roadmap

  • More data sources. Any funder that publishes a CommonGrants-compliant API can be added without changing the app, so the plan is to keep growing the list of participating states and federal programs.

  • Award data. Today the app searches open opportunities. Adding historical award data would let you see who has been funded before, at what amounts, and by which programs — useful context for deciding whether an opportunity is worth pursuing.

Have a source you'd like to see added, or found something confusing? Please open an issue.

Documentation

Licensed under MIT.

Available Tools

3 tools
get_opportunityGet grant opportunityA
Read-only

Get the full details of a specific grant opportunity by ID from one source.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe opportunity ID
sourceYesWhich source the opportunity belongs to

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and openWorldHint=true, and the description's 'Get the full details' is consistent. The description adds the context that it returns full details beyond the annotations, which are adequate. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no fluff, clear and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (two parameters, read-only, no output schema), the description is complete. It states what it does, the key parameters are covered, and sibling tools provide additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters having descriptions. The description's 'by ID from one source' maps to id and source but adds no additional meaning 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'full details of a specific grant opportunity', specifying the scope 'by ID from one source'. This distinguishes it from siblings like list_grant_sources (which lists sources) and search_opportunities (which searches across opportunities).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use: when you have an ID and source and need full details. However, it does not explicitly state when not to use or mention alternatives like searching or listing. The sibling names provide context, but the description itself lacks explicit guidance on exclusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_grant_sourcesList grant sourcesA
Read-only

List the CommonGrants-compliant APIs this server can search.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true. The description adds context that the output is specifically CommonGrants-compliant APIs, going beyond the annotation to clarify scope. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that conveys all necessary information without excess. Every word contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and no output schema, the description is sufficient. It clearly defines the tool's action and output type, and the siblings provide context. openWorldHint=false is already in annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is 100%. The description does not need to add parameter info, and with zero parameters, baseline is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists 'CommonGrants-compliant APIs this server can search,' using a specific verb and resource. It distinguishes from siblings (get_opportunity, search_opportunities) which focus on opportunities, not grant sources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is used to discover available APIs before searching. While it does not explicitly state when to use vs alternatives, the purpose is clear and no exclusion is needed for such a simple tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_opportunitiesSearch grant opportunitiesA
Read-only

Search for grant opportunities across CommonGrants sources.

Omit source to fan out across every source and get combined, labeled results. Provide source (see list_grant_sources) to target one.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax results per source
queryNoFull-text search query, e.g. 'workforce development'
sourceNoWhich source to query. Omit to search all.
statusesNoFilter by opportunity status

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds that results are 'combined, labeled' when fanning out, providing useful context 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences/paragraphs. Front-loaded: first sentence states core purpose with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with no output schema, description adequately covers multi-source behavior and parameter usage. Could mention return format, but not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. Description adds value by explaining the behavior of the 'source' parameter (fan-out vs targeting), which is not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Search' and resource 'grant opportunities across CommonGrants sources'. Distinguishes from sibling tools (get_opportunity, list_grant_sources) by indicating multi-source search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly explains when to omit 'source' to search all sources and when to provide it for targeting one. References list_grant_sources for available values, providing clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedget_opportunity
    • First observedlist_grant_sources
    • First observedsearch_opportunities
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool serves a distinct purpose: get_opportunity retrieves by ID, list_grant_sources enumerates available sources, and search_opportunities queries across sources. No confusion.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with clear, action-oriented names (get, list, search).

Tool Count4/5

Three tools is on the lower end but adequately covers the core workflow of listing sources, searching, and retrieving details. Slightly below the ideal 3-15 range but still reasonable for a focused server.

Completeness4/5

The tool surface covers essential grant-seeking operations. Minor gaps include lack of a dedicated list_all_opportunities tool, but search_opportunities without source effectively fills this role.

Maintenance

ActivityActive
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers