grant-finder
Server Details
Find federal and public grants a business may qualify for, with eligibility and links.
- 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 3.7/5 across 12 of 12 tools scored. Lowest: 2.6/5.
Most tools target distinct domains (e.g., citizenship, collectibles, visas, employer benefits), but there is overlap between qualify_check, missed_credits_scan, and applyby_deadlines, all dealing with benefits/credits.
Naming patterns vary: some end with '_check', '_scan', '_appraise', '_match', and one is oddly named 'applyby_deadlines'. This inconsistency could confuse an agent.
With 12 tools covering a broad set of assistance verticals, the count is appropriate for a multi-purpose server, though it might benefit from consolidation.
Despite the server name 'grant-finder', there is no tool for general grant search (e.g., Grants.gov). The set covers diverse areas but lacks critical grant-related operations beyond R&D credits.
Available Tools
12 toolsapplyby_deadlinesCInspect
Given a household situation, return the application / recertification / reporting deadlines for the benefits the person likely qualifies for — each with its CFR/statute cite and administering body. The reminder annuity's data spine.
| Name | Required | Description | Default |
|---|---|---|---|
| householdSize | Yes | ||
| householdIncome | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, authorization requirements, or whether the tool is read-only. The cryptic phrase 'data spine' adds confusion rather than transparency.
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 first sentence is concise and informative. However, the second sentence 'The reminder annuity's data spine.' is cryptic and unnecessary, wasting space and reducing 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 absence of annotations and output schema, the description should provide more details on income type, time period, and expected benefits. It is incomplete and fails to equip the agent for correct usage.
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 schema description coverage at 0%, the description must compensate but only mentions 'household situation' without explaining the units or meaning of householdIncome and householdSize. The agent lacks crucial context to invoke correctly.
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 returns deadlines for benefits, including CFR/statute cites and administering body, given a household situation. However, the cryptic phrase 'The reminder annuity's data spine' slightly reduces clarity.
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?
No guidance on when to use this tool versus siblings (grail_appraise, grail_value, qualify_check). The description does not provide usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
charity_care_checkAInspect
Detect likely eligibility for a nonprofit hospital's charity-care / financial-assistance (501(r)) + state charity-care law + No Surprises Act, from income vs the Federal Poverty Level. FREE PATIENT INFORMATION — this care is free if you qualify; we never charge a patient to access it. Hands off to the hospital's financial-assistance office.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| wasEmergency | No | ||
| householdSize | Yes | ||
| gotSurpriseBill | No | ||
| householdIncome | Yes | ||
| billExceedsEstimate | No | ||
| hospitalIsNonprofit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses the purpose, emphasizes the free nature, and mentions a hand-off to financial assistance. However, it does not specify whether the tool is read-only, if data is stored, or any rate limits, leaving some behavioral aspects unclear.
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 three concise sentences with no superfluous content. Key information is front-loaded in the first sentence, and subsequent sentences add value (free nature, hand-off). Every word 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 the complexity (7 parameters, no output schema, no annotations), the description is incomplete. It does not explain return values or the format of 'detect likely eligibility'. The term 'hands off' is vague. Lacks details on how every parameter influences the result.
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% across 7 parameters. The description only references 'income vs the Federal Poverty Level', which explains householdIncome and householdSize implicitly. Other parameters (state, wasEmergency, etc.) are not described, leaving significant gaps in understanding their meaning and usage.
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 detects likely eligibility for a nonprofit hospital's charity-care and financial-assistance programs, including specific laws (501(r), state charity-care, No Surprises Act). It explains the mechanism (income vs FPL) and distinguishes itself from generic eligibility checks by focusing on hospital charity care.
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 use for checking charity-care eligibility but lacks explicit guidance on when to use this tool versus alternatives like 'qualify_check'. It does not provide exclusion criteria or mention prerequisites, leaving the agent to infer context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
citizenship_descentAInspect
Detect eligibility for a second citizenship by ancestry (Italy / Ireland / Poland / Germany), citing each country's descent rule + generational limit + the cut-off that most often breaks a claim. INFORMATION + DOCUMENT-CHECKLIST ONLY — recognition is decided by the foreign government; hands off to the consulate / a citizenship attorney.
| Name | Required | Description | Default |
|---|---|---|---|
| ancestryCountry | Yes | ||
| ancestorEmigratedYear | No | ||
| ancestorNaturalizedYear | No | Year ancestor naturalized abroad, or 'never'. | |
| nearestQualifyingAncestor | No | ||
| lineThroughFemaleBefore1948 | No | Italy 1948-rule: line passes through a woman before 1948. | |
| ancestorPersecuted1933to1945 | No | Germany Art. 116(2) restoration. | |
| bornBeforeAncestorNaturalized | No | ||
| parentWasOnForeignBirthsRegister | No | Ireland great-grandparent line. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses that the tool only provides information and checklists, not actual citizenship recognition, and suggests handoff. This adds behavioral context beyond just the purpose.
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-loading the purpose and immediately adding scope and limitations. Every sentence adds value with 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?
For a tool with 8 parameters and no output schema, the description explains its informational role, countries covered, and handoff advice. It is fairly complete, though it could optionally mention the output 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?
Schema coverage is 50%, but the description adds no parameter-specific information. It only describes the overall tool, leaving half of the parameters without additional context 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 the verb 'Detect eligibility' and the resource 'second citizenship by ancestry' with specific countries (Italy, Ireland, Poland, Germany), distinguishing it from sibling tools like visa_match or qualify_check.
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 states the tool provides 'INFORMATION + DOCUMENT-CHECKLIST ONLY' and that recognition is decided by the foreign government, advising handoff to consulate/attorney. This gives clear usage context but does not compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
grail_appraiseBInspect
PREMIUM. Full GrailQualify appraisal + eligibility-prep payload: live valuation with all comps & scrape date, scheduled-insurance under-coverage gap, grading worth-it call — each rule-cited with authority hand-off. Pay-per-call via x402 (USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| niche | No | ||
| query | Yes | ||
| perItemSpecialLimit | No | Your home-policy per-item valuables limit (USD). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry all behavioral context. It discloses that the tool is premium, pay-per-call via USDC on Base, and includes rule-cited authority hand-off. It does not mention error handling, response format, or if any destructive actions occur. The description adds some value but lacks full transparency.
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 a single, dense sentence with multiple hyphenated phrases, making it harder to parse. While it conveys a lot of information, it lacks structure (e.g., bullet points or separate sentences) and could be more concise without sacrificing 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?
No output schema exists, so the description must explain return values. It mentions components like 'live valuation', 'comps & scrape date', 'under-coverage gap', and 'grading worth-it call', giving a general idea. But it does not specify the format, data types, or how to interpret the results. For a complex tool, additional details would improve completeness.
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 33% (only perItemSpecialLimit is described). The description ties perItemSpecialLimit to 'scheduled-insurance under-coverage gap', adding business meaning. However, it does not explain the 'niche' or 'query' parameters beyond what the schema provides. The description partially compensates for the low schema coverage but is not fully explanatory.
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 that the tool performs a full appraisal including valuation, insurance gap analysis, and grading recommendation. It uses specific terms like 'live valuation', 'comps', and 'scheduled-insurance under-coverage gap'. However, the jargon may be unclear to some agents, and it doesn't explicitly contrast with siblings like grail_value or qualify_check.
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 it is a premium, pay-per-call tool best used when a comprehensive appraisal plus eligibility prep is needed. But it does not explicitly state when to use this tool over siblings, nor does it provide scenarios or prerequisites. The cost and payment method are mentioned, which is useful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
grail_valueAInspect
Value a collector's item from live retail + sold comps (DropWatch price-history) and return a confidence-tiered estimate with the comp shops and scrape date. Free preview of the value; the full appraisal+eligibility prep payload is the premium tool grail_appraise.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | No | ||
| query | Yes | Item name, be specific (set + type). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adequately explains output (estimate with confidence tier, comp shops, scrape date) and that it is a read-only preview. However, it does not mention authentication or rate limits.
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 sentences, front-loaded with purpose, efficient differentiation from sibling. 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?
For a simple tool with 2 parameters and no output schema, description covers return details and usage context. Could improve by explaining confidence tiers but overall adequate.
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 50% (only query described). Description does not explain the 'niche' parameter beyond the enum values, missing opportunity to compensate. Query description is clear.
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 values collector's items using live retail and sold comps, returns a confidence-tiered estimate with comp shops and scrape date. It distinguishes from the sibling tool grail_appraise by noting it is a free preview.
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 says when to use this tool (free preview) and directs to grail_appraise for full appraisal, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hr_benefit_scanAInspect
Detect under-used EMPLOYER benefits an employee qualifies for (dependent-care FSA, student-loan repayment, fertility/IVF, HSA match), from the plan + the employee's situation. EMPLOYER-PAYS B2B2C, ERISA-aware, non-medical — information + enrollment-nudge only; the plan administrator decides. Hands off to HR / the SPD.
| Name | Required | Description | Default |
|---|---|---|---|
| hasHdhp | No | ||
| planOffersHsa | No | ||
| hasStudentLoans | No | ||
| planOffersDcFsa | No | ||
| dependentsUnder13 | No | ||
| planOffersFertility | No | ||
| paysForDependentCare | No | ||
| interestedInFertility | No | ||
| employerOffersHsaMatch | No | ||
| planOffersLoanRepayment | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and effectively discloses key traits: ERISA-aware, non-medical, no decision-making, just nudges. It lacks mention of side effects like data storage, but for a scanning tool this is sufficient.
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 with no waste: the first states the action, the second provides context, the third gives the outcome. It is front-loaded but could be slightly more concise.
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 10 parameters, no output schema, and no annotations, the description adequately explains purpose and limitations but does not describe the output format or note that all parameters are optional (though implied). Minor gaps for complete agent 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%, so the description must compensate. It lists benefit examples but does not explain individual parameters (e.g., 'hasHdhp' or 'dependentsUnder13'), leaving the agent to infer meaning from schema names alone.
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 defines the tool as detecting under-used employer benefits (e.g., dependent-care FSA, student-loan repayment) based on the employee's situation. It distinguishes itself from siblings like 'life_event_scan' by focusing specifically on employer-paid, ERISA-aware, non-medical benefits.
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 the tool is 'information + enrollment-nudge only' and 'hands off to HR / the SPD', providing clear usage context. However, it does not explicitly state when not to use it or compare to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
life_event_scanAInspect
PREMIUM. The reversal mechanic: one life-event trigger (new-baby / bought-a-house / lost-a-job / moved-states / started-a-business) fans out across ALL relevant spine verticals (benefits, missed credits, student-loan relief, DPA) and returns every finding at once — each rule-cited with a free authority hand-off. Pay-per-call via x402 (USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | ||
| dependents | No | ||
| creditScore | No | ||
| employerType | No | ||
| filingStatus | No | ||
| householdSize | Yes | ||
| firstTimeBuyer | No | ||
| householdIncome | Yes | ||
| hasFederalStudentLoans | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the 'reversal mechanic' and that it returns findings across multiple verticals with citations. Since no annotations are provided, the description effectively conveys behavior, though it does not explicitly state read-only status or rate limits.
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, consisting of three sentences that front-load the key concept. Some marketing language like 'PREMIUM' and 'free authority hand-off' could be trimmed, but overall it is efficiently structured.
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?
Despite a clear high-level purpose, the description lacks details on parameter explanations, output format, and prerequisites. With 9 parameters and no output schema, the agent lacks sufficient guidance for correct invocation.
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, the description should explain parameters. It only adds context for the 'event' parameter by listing possible values, but fails to explain other essential parameters like householdIncome, householdSize, creditScore, etc.
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 that the tool takes a life-event trigger and scans across all relevant spine verticals, returning all findings at once with rule citations. This distinguishes it from siblings like 'missed_credits_scan' which may be limited to one vertical.
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 indicates it's a premium, pay-per-call tool, implying it should be used when a comprehensive scan is needed. However, it does not explicitly state when to use versus alternatives or provide when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
missed_credits_scanAInspect
Detect federal tax credits a household LIKELY qualifies for but commonly never claims — EITC (26 USC 32), Saver's Credit (25B), education AOTC/LLC (25A), Child & Dependent Care (21), and home energy (25C/25D) — each confidence-tiered with the exact IRS pub cited and the FREE IRS Free File / VITA hand-off. Detection & explanation only; never files a return.
| Name | Required | Description | Default |
|---|---|---|---|
| dependents | No | ||
| energyKind | No | solar/battery/heatpump/insulation/etc. | |
| energySpend | No | ||
| earnedIncome | No | ||
| filingStatus | No | ||
| childcareCost | No | ||
| householdSize | Yes | ||
| householdIncome | Yes | AGI (USD). | |
| investmentIncome | No | ||
| paidForChildcare | No | ||
| dependentsUnder13 | No | ||
| hasEducationExpenses | No | ||
| madeEnergyImprovement | No | ||
| retirementContribution | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states the tool is for detection and explanation only, and will never file a return. This is a key behavioral trait. However, it does not discuss auth needs, rate limits, or potential data usage, but the core behavior is well-disclosed.
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 a single paragraph that front-loads the main purpose and includes details on credits, confidence tiers, and hand-off. It is concise and avoids redundancy, though listing the credits could be more structured (e.g., bullet points) for 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 14 parameters and no output schema, the description should cover return format. It mentions confidence tiers and a hand-off to Free File/VITA, but does not describe the output structure (e.g., list of credits with confidence scores). This is a moderate gap for a scan tool.
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 input schema has 14 parameters with only 14% coverage (2 described). The description mentions credits that involve income, dependents, energy, etc., but does not explicitly map parameters to credit eligibility. For a complex tool with many parameters, the description adds minimal meaning beyond the schema, leaving an agent to infer parameter roles.
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 specifies the tool detects federal tax credits (EITC, Saver's Credit, etc.) that a household likely qualifies for but doesn't claim. It lists specific credits, mentions confidence tiers and IRS publications, and distinguishes from sibling tools (deadlines, appraisal, etc.) by focusing on detection and explanation 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 explicitly states 'never files a return', which is a clear when-not-to-use. However, it does not provide explicit guidance on when to use this tool versus siblings, though the sibling names suggest different purposes (deadlines, appraisal, etc.), making usage inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qualify_checkAInspect
Eligibility-navigator: given a household situation (income, size, filing status), return which federal/state benefits & credits the person LIKELY qualifies for but may be missing — each with a confidence tier (LIKELY/VERIFY/UNLIKELY), the exact governing rule cited inline, the verify-date, and the administering body to claim it FREE. Never a guarantee; never files for you.
| Name | Required | Description | Default |
|---|---|---|---|
| filingStatus | No | Tax filing status. | |
| householdSize | Yes | People in household. | |
| householdIncome | Yes | Annual household income (USD). | |
| onQualifyingProgram | No | Already on SNAP/Medicaid/SSI/etc. | |
| retirementContribution | No | IRA/401k contributed this year (USD). | |
| hasAffordableEmployerCoverage | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the tool returns likely qualifying benefits with confidence tiers, cites rules, and provides administering bodies. It also states it does not guarantee or file. While it doesn't cover authentication or rate limits, it gives sufficient behavioral insight for an agent.
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 a single dense sentence that efficiently covers inputs, outputs, and caveats. It is front-loaded with the tool's purpose ('Eligibility-navigator') and packs substantial information without unnecessary words. Slightly verbose but still concise.
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 (6 parameters, no output schema), the description compensates by detailing output components (confidence tiers, rules, dates, bodies). It covers purpose, inputs, and behavioral limits. Lacks explicit mention of error handling or edge cases, but is largely complete for an agent to use.
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 83%, so most parameters are already described in the schema. The description mentions income, size, and filing status, aligning with the schema. It does not add significant extra meaning beyond what the schema provides. The remaining parameters (e.g., retirementContribution) are not elaborated in the description but are covered in the schema, so 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 clearly states the tool's purpose: to check eligibility for federal/state benefits and credits based on household situation. It specifies the input factors (income, size, filing status) and output details (confidence tiers, rules, dates, administering bodies). The sibling tools have unrelated names (applyby_deadlines, grail_appraise, grail_value), so this tool is well-distinguished.
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 when to use (given household situation) and includes a caveat ('Never a guarantee; never files for you'), guiding appropriate use. However, it does not explicitly state when not to use or compare with sibling tools. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rd_grants_checkAInspect
Screen whether a startup/SMB likely qualifies for the federal R&D tax credit (26 U.S.C. 41 4-part test), the payroll-tax offset (qualified small business), and SBIR/STTR + state grants, from its activities. VIABILITY DETECTION ONLY — not a filing service, never takes a percentage; hands off to a CPA / the program office.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| preRevenue | No | ||
| isForProfit | No | ||
| hasW2Payroll | No | ||
| employeeCount | No | ||
| majorityUsOwned | No | ||
| activityTechnical | No | ||
| activityDescription | No | ||
| grossReceiptsThisYear | No | ||
| yearsWithGrossReceipts | No | ||
| facedTechnicalUncertainty | No | ||
| didExperimentationOrIteration | No | ||
| developingNewOrImprovedProduct | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool is non-filing and hands off to professionals, but lacks details on output format, side effects, or authentication needs. This is adequate but not comprehensive.
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, front-loading the core purpose followed by a critical disclaimer. No unnecessary information, though it could be slightly restructured for 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?
Despite the complexity (13 params, no output schema), the description does not explain what the tool returns, how to interpret results, or prerequisites. This leaves significant gaps for an agent.
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 input schema has 13 parameters with zero descriptions, and the description does not explain any of them. Given the low schema coverage, the description should compensate but fails to add meaning to the parameters.
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 screens startups for eligibility for federal R&D tax credit, payroll-tax offset, SBIR/STTR, and state grants. It uses a specific verb 'Screen' and lists distinct resources, distinguishing it from sibling tools which cover different domains.
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 clarifies that the tool is for viability detection only and explicitly states what it is not (a filing service). This helps set user expectations, though it does not compare directly to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
realtor_copilotBInspect
B2B (RESPA-safe SaaS): given a buyer's 8 fields, return the down-payment-assistance & loan programs (HFA DPA, FHA, VA, USDA, MCC) the buyer likely PASSes, sequenced in apply-order, each program administered by the HFA/approved lender. Flat-fee tool; no per-referral kickback, no lender steering.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| creditScore | Yes | ||
| propertyType | No | ||
| householdSize | No | ||
| purchasePrice | No | ||
| firstTimeBuyer | No | ||
| householdIncome | Yes | ||
| militaryOrVeteran | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the tool is flat-fee and RESPA-safe, but does not disclose behavioral traits such as whether it is read-only, any side effects, authorization needs, or error behavior. The description is insufficient for transparency.
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 relatively concise and front-loaded with the core purpose. It includes necessary compliance information. However, it could be more structured with clearer separation of usage and behavior.
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 has 8 input parameters, no output schema, and no annotations, the description lacks details on input constraints, output format, error handling, and what 'likely passes' entails. It is not complete enough for an agent to confidently invoke the tool without additional context.
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 must compensate. It adds context by stating the parameters are buyer's fields, but it does not explain each parameter's meaning, format, or how they are used in determination. The description adds some value but not enough to fully compensate for the lack of 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 returns down-payment-assistance and loan programs that a buyer likely qualifies for, sequenced in apply-order. It uses a specific verb ('return') and resource ('loan programs'), and distinguishes from sibling tools like qualify_check by focusing on DPA and specific loan types.
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 identifying eligible loan programs but does not explicitly state when to use this tool versus alternatives like qualify_check or applyby_deadlines. No 'when not to use' or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
visa_matchAInspect
Detect which U.S. visa categories likely fit a person's situation (O-1 extraordinary ability, EB-2 NIW, H-1B, family-based, EB-5), each with the governing statute (INA / 8 CFR) cited and a confidence tier. INFORMATION ONLY — not legal advice; every finding hands off to a licensed immigration attorney. Never files a petition.
| Name | Required | Description | Default |
|---|---|---|---|
| o1CriteriaMet | No | How many of the 8 O-1 criteria you meet. | |
| advancedDegree | No | ||
| usRelativeStatus | No | ||
| bachelorsOrHigher | No | ||
| exceptionalAbility | No | ||
| hasUsEmployerSponsor | No | ||
| investableCapitalUSD | No | ||
| usRelativeRelationship | No | e.g. spouse, parent, sibling. | |
| majorInternationalAward | No | ||
| nationalInterestEndeavor | No | Describe your endeavor of national importance (EB-2 NIW). | |
| yearsProgressiveExperience | No | ||
| fieldOfExtraordinaryAbility | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It clearly states the tool is information-only, does not file petitions, and requires an attorney for action. This is transparent about its non-destructive, advisory nature.
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 with 3-4 sentences covering purpose, statute citations, confidence tiers, and legal disclaimers. It is front-loaded with the main function, though the disclaimer repetition could be slightly tightened.
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 and no output schema, the description lacks details on outputs like confidence tiers or which categories are returned. It does not explain how inputs determine matches, leaving gaps for an agent using the tool.
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 only 25% (3 of 12 parameters have descriptions). The tool description does not explain individual parameters or how they map to visa categories; it only gives a high-level overview. The description adds minimal value beyond the schema for parameter meaning.
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 detects likely U.S. visa categories for a person's situation, listing examples like O-1, EB-2 NIW, H-1B, family-based, EB-5. It includes details about statute citations and confidence tiers, and distinguishes from sibling tools like citizenship_descent by focusing on visa matching.
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 context on what the tool does (information only, not legal advice, never files a petition) and hands off findings to an attorney, but it does not explicitly state when to use this tool versus sibling tools like applyby_deadlines or life_event_scan. Usage guidance is implied but lacks direct comparison.
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!