How to Use Agent Index With MCP: Where AI Agents Cannot Reach Yet

search_connectors

Search across both directories at once. Filters: <strong>platform</strong> (claude or chatgpt), <strong>category</strong> (canonical, e.g. healthcare, financial-services, developer-tools), <strong>authless</strong> (connectors that need no OAuth setup), <strong>can_act</strong> (only connectors that publish a capability list), and <strong>verified_tier</strong> (anthropic, partner or community - Claude only, where partner or anthropic means the vendor built it). Returns up to 50 rows.

Example prompt: &apos;Search connectors for scheduling tools on the Claude directory that need no auth&apos;. Use it to check whether a product or a niche already has an agent surface before you build against it.

• Free-text query runs over connector name, tagline and vendor.
• Only 330 of 7,000+ connectors are authless, so the authless filter returns a small, high-signal set.
• verified_tier is published on Claude listings only. ChatGPT listings carry no tier at all.

get_connector

Pull one connector in full by <strong>connector_key</strong>, which is formatted &apos;platform:native_id&apos; (for example claude:01af-... or chatgpt:plugins_6aa0...). Returns the description, vendor, auth posture, MCP endpoint, permissions, sensitive data types, and the connector&apos;s tools broken down by verb class.

Example prompt: &apos;Get the full connector record for claude:01af-...&apos;. The verb-class breakdown is the useful part: it tells you whether the connector can only read, or can also write, administer or transact.

• Verb classes are read, write, transactional, admin, meta and unknown.
• Across the whole corpus only 0.8% of declared tools are transactional, so a connector with one is unusual.

can_act is null, not false - read this before you filter

This is the single easiest thing to get wrong about this dataset. <strong>can_act is null when a connector publishes no capability list. Null means unknown, not &apos;cannot act&apos;.</strong> Only 46.9% of connectors declare tools at all, and on the ChatGPT side the figure is 12.7%, so the majority of the corpus is undisclosed rather than incapable.

Practically: filtering can_act to false will not give you &apos;connectors that cannot act&apos;, and treating a null as a false will make the ecosystem look far more read-only than the evidence supports. When you need a defensible statement, say &apos;does not publish a capability list&apos; rather than &apos;cannot act&apos;.

• can_act true: the connector publishes a capability list that includes a non-read tool.
• can_act null: the connector publishes no capability list. Unknown.
• 3,300+ of 7,000+ connectors declare tools. The other 3,750 are unmeasured, not empty.

get_agent_coverage

Per-category coverage, sorted weakest first. For each canonical category it returns how many connectors serve it, what share can do more than read, what share the vendor built themselves, and how many need no auth. Pass an optional <strong>category</strong> to restrict to one.

Example prompt: 'Get agent coverage sorted weakest first'. This is the fastest way to find categories where agents can look but not act, which is where the buildable work concentrates. Pair it with the pain point tools to confirm there is documented demand behind a thin category.

• Weakest-first ordering is deliberate: the interesting end of this table is the bottom.
• Healthcare is 2.0% of the corpus and legal 0.8%, which is where coverage is thinnest.

search_agent_ideas

Search generated product ideas scoped to a business vertical and the stack slot an agent cannot currently reach. Filters: <strong>vertical</strong> (slug, e.g. dental-practice, law-firm, field-service), <strong>idea_class</strong> (A is capability whitespace, B is corroborated by real complaints), <strong>min_novelty</strong>, and <strong>survivors_only</strong>, which defaults to true.

Example prompt: &apos;Search agent ideas for dental-practice&apos;. Leave survivors_only on unless you have a reason not to: 432 ideas were generated and 25 survived the adversarial kill pass, so turning it off returns mostly rejected material.

• Free-text query runs over title, thesis and the gap exploited.
• Survivors span 22 of the 54 verticals, so some verticals return nothing. That is a real result, not an error.
• Almost every survivor is a cross-system reconciliation or close layer rather than a connector.

get_vertical_readiness

The autopilot verdict per business vertical: can an agent run this business end to end, or only observe it. Pass a <strong>vertical</strong> slug (e.g. restaurant, saas-company) or filter by <strong>verdict</strong> (ready, one_piece_short, wide_open). Returns the verdict and the blocking stack slot.

Example prompt: 'Get vertical readiness for everything with a wide_open verdict'. Of 54 verticals, 20 are ready, 16 are one piece short and 18 are wide open. All 18 wide-open verticals are blocked at the same slot, the system of record. The full analysis is in the vertical whitespace study.

• The verdict is the supportable output. The numeric score clusters into bands and should not be quoted as a precise figure.
• Blocking slots are computed for the 18 wide-open verticals only. The one-piece-short band has no named blocking slot.

get_vertical_stack

The rows underneath a readiness verdict. get_vertical_readiness tells you a vertical is blocked and names one slot; this returns the whole stack: every slot an operator in that business runs on, in stack order, with how many vendors fill the slot, how many of those have an agent surface, and which slot is the blocking one. Pass a <strong>vertical</strong> slug.

Example prompt: &apos;Get the vertical stack for dental-practice&apos;. system_of_record is slot_order 0 in all 54 verticals, and no vendor in the corpus maps to it. That zero is the finding, not a gap in the data: it is why every wide-open vertical is blocked at the same place.

• Vendor counts are global to the slot rather than specific to the vertical, because per-vertical software categories are not populated. Every response carries that caveat.
• The response also carries the readiness verdict and the durability reason, so one call answers what is blocked and whether it will close on its own.

search_software_vendors

The 22,000+ G2 and Capterra vendors mapped to stack slots, filtered by whether they have an agent surface. Set <strong>has_agent_surface</strong> to false and you get the vendors nothing connects to, which is the build list. Filter further by <strong>slot</strong>, <strong>category</strong> or <strong>source</strong>.

Example prompt: &apos;Search software vendors in the scheduling slot with no agent surface&apos;. Coverage is thin everywhere: CRM is the best-covered slot at 18% and support the worst at 3.3%.

• A null connector means no connector matched by name, NOT proof that none exists. Most vendors are unmatched and matching is by normalized name only, so read absence as a lead rather than a fact.
• G2 has full alphabetical coverage. Capterra&apos;s scrape decays alphabetically, so its category counts must never be read as market coverage; rows from it carry that caveat.

Research workflows with Agent Index tools

The natural sequence is coverage first, then vertical, then ideas. Run get_agent_coverage to find a thin category, get_vertical_readiness to see which business types in it are blocked and where, then get_vertical_stack to see the slots underneath that verdict and search_software_vendors with has_agent_surface false for the vendors nothing connects to. Then search_agent_ideas for what survived the kill pass in that vertical, and finish with search_connectors to check what already exists around the gap.

Agent Index answers 'where can agents not reach'. Pair it with the pain point and opportunity tools to confirm the demand is documented, and with Stripe Index to confirm somebody is already paying in that niche. For the full multi-source pattern see the cross-source research guide, and for the complete tool list see the full MCP reference.

FAQ