Skip to main content
Glama

Check which IC Vault entries a company qualifies for (public)

ic_vault_match
Read-only

Evaluate a company profile against the Vault's eligibility predicates and get a THREE-VALUED answer per entry: 'eligible' (every stated gate is definitively met), 'ineligible' (a stated gate is definitively failed), or 'indeterminate' — which means WE CANNOT TELL FROM WHAT THE VENDOR PUBLISHES, and is a real answer, never a soft no. No auth required. Nothing is ever reported 'eligible' while any gate is unknown or unstructured: a missing profile field lands in unknown (supply it and the verdict may flip), and a gate the program states only in prose lands in manual_review (a human has to read it). A non-hit against a NAMED partner list is manual_review too, never a failure, because every published partner list in the corpus is partial. Every profile field is OPTIONAL — a partial profile is the normal case and returns more indeterminate, not an error. Accepts the same category/kind/status/evidence/freshness filters as ic_vault_list. Returns: { ok, total_considered, counts, matches[], notes }. Each match carries failed[], unknown[], manual_review[], missing_prerequisites[] and per-tier verdicts.

Input Schema

NameRequiredDescriptionDefault
kindNoSame filter as ic_vault_list.
as_ofNoYYYY-MM-DD for deadline checks. Defaults to today.
holdsNoVault entry ids you already hold — used for prerequisite checks (e.g. holding NVIDIA Inception unlocks downstream offers).
stageNoFunding stage label. Distinct from the raised amount — some programs gate on one, some on the other.
statusNoSame filter as ic_vault_list.
qualifyNoReturn only matches with this verdict. OMIT IT to see all three — asking only for 'eligible' hides the 'indeterminate' set, which is usually where the real options are.
categoryNoSame filter as ic_vault_list.
evidenceNoSame filter as ic_vault_list.
headcountNoPeople on the team. Checked against any entry that gates on team size.
domain_tagsNo'ai-native' is stricter than 'ai': the model is the product, not a feature. The corpus draws that line itself.
affiliationsNoAffiliations some programs REQUIRE (an academic grant, a 501(c)(3) discount).
jurisdictionNoISO-3166 alpha-2 of the operating entity, e.g. 'US'.
business_typesNoTypes some programs EXCLUDE. Declaring one may disqualify you from those.
cash_balance_usdNoCash on hand, USD. Orthogonal to funding raised.
has_domain_emailNoCompany-domain email. A gmail address fails these gates.
has_web_presenceNoLive website + active socials a reviewer will look at.
company_age_yearsNoYears since incorporation.
funding_raised_usdNoTotal raised, USD. 0 means bootstrapped.
has_working_productNoShipped something real, as opposed to still evaluating.
prior_participationNoVault entry ids whose program you have already taken. Distinct from being a customer.
existing_customer_ofNoVault entry ids you are already a paying customer of — for 'new customers only' gates.
partner_affiliationsNoInvestors / accelerators you are affiliated with. An EXPLICIT empty array is a statement (no affiliations ⇒ you cannot be on anyone's approved list) and fails referral gates; OMITTING the field is 'unknown' and does not.
verified_within_daysNoSame filter as ic_vault_list.
months_since_last_roundNoMonths since the most recent round CLOSED. Some programs require 'funded within 12 months' — a Series A from 3 years ago fails that while passing a stage gate.
has_institutional_backingNoSomebody institutional wrote a cheque. Says nothing about WHO — that is `partner_affiliations`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond annotations by explaining the three-valued semantics, why `indeterminate` is a real answer, how missing fields become `unknown`, how prose-only gates become `manual_review`, and why non-hits on named partner lists are never failures. It also states that every profile field is optional and describes the return shape.

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

Conciseness4/5

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

The description is dense and front-loads the central three-valued verdict model, which is appropriate for a 25-parameter eligibility tool. It is somewhat long and occasionally repetitive in emphasizing that `indeterminate` is not a soft no, but nearly every sentence adds behavioral context.

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 complex 25-parameter tool with no output schema, the description is complete enough: it explains the verdict model, missing-data behavior, auth expectation, partial-profile behavior, and the returned fields including `matches[]`, `failed[]`, `unknown[]`, `manual_review[]`, and per-tier verdicts.

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%, so the baseline is 3, but the description adds useful cross-parameter meaning: all profile fields are optional, missing fields affect verdicts via `unknown`, and the filter set mirrors ic_vault_list. It reinforces rather than duplicates schema semantics, especially around partial profiles and verdict interpretation.

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?

States a specific verb and resource: evaluate a company profile against the Vault's eligibility predicates. It immediately distinguishes its role from ic_vault_list by focusing on three-valued eligibility verdicts and by saying it accepts the same filters as the list tool.

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?

Gives clear usage context: no auth required, all profile fields are optional, and partial profiles are normal and return more `indeterminate` rather than errors. It also tells the agent to omit `qualify` to see all three verdicts. It does not explicitly say when to use this versus ic_vault_list beyond filter compatibility, so it falls short of a full when/when-not/alternatives statement.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.