Skip to content

README: surface 'JD fallback when web fails' value prop #11

@prPMDev

Description

@prPMDev

Context

A recurring pattern emerged in user testing: when a company's Ashby/Greenhouse/Lever page fails to render fully in a browser (common for SPAs, slow loads, or geo-blocked content), ats-index fetches the complete JD directly via the public API.

Example from a session:

"ShiftKey's Ashby page didn't render the full JD. Let me try the Ashby API directly."

This is a core value prop — arguably the top one for any workflow involving AI assistants that scrape or browse — but the README doesn't highlight it. Users discover it organically.

Proposal

Add a "Why use ats-index?" section near the top of the README (before "How it works"), covering:

  • Full JDs when browsing fails — SPAs, slow loads, auth walls, geo-restrictions don't block ats-index
  • Structured data, not HTML soup — salary, location type, department, normalized markdown
  • No keys, no browsers — just public APIs, runs anywhere
  • Unified schema across platforms — one shape, three (soon more) ATSes

Acceptance

  • Section lives before "How it works"
  • One concrete example (or generic framing) showing when ats-index succeeds where scraping fails
  • Doesn't inflate README past readability (keep tight, 4 bullets max)

Why this matters for MCP

The README becomes the tool description the AI assistant reads. If the doc undersells the "fallback when browsing fails" angle, AIs won't know to reach for ats-index in exactly the situation where it's most valuable.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions