AyHire

Hire engineers by what they shipped. Describe a role and AyHire finds developers from their public GitHub work, judges each against your criteria with links to the evidence, says who is open to work, and keeps your roles and shortlist. Remote server with OAuth sign-in.

View on ayhire.com

Hosted MCP Server

npx add-mcp 'https://ayhire.com/mcp'

Installs into Claude Code, Codex, Cursor and more

Documentation

Index of everything AyHire publishes for agents: https://ayhire.com/llms.txt

AyHire for agents

Most AI apps connect with AyHire's address, https://ayhire.com/mcp, and a sign-in: no key to copy. Agents that can run commands can paste one prompt instead, and scripts can use the HTTP API with a key.

Connect by address (sign in, no key)

AyHire's address: https://ayhire.com/mcp. Paste it into your AI app and sign in when AyHire opens. https://ayhire.com/mcp and https://ayhire.com/api/mcp are the same server.

Claude (web, desktop and mobile)

Add AyHire as a custom connector once. It then works on the web, in the desktop app and on your phone.

  1. In Claude, open Customize › Connectors, click + Add, then Add custom connector.
  2. Name it AyHire, paste this as the server URL, and click Continue. 
    https://ayhire.com/mcp
  3. If Claude shows the sign-in settings it found, click Continue. Under Authentication, choose Sign in now. Under OAuth client, choose Register automatically. Then click Add.
  4. AyHire opens. Sign in, pick the workspace it should use, and click Connect.
  5. In a chat, click + › Connectors and turn AyHire on.

Check it worked: Ask Claude: “Use AyHire to check who I'm signed in as.” It answers with your email.

To disconnect: Ask Claude to disconnect AyHire, or disconnect it in AyHire under Integrations › Connected apps. To remove it from Claude too: Customize › Connectors › AyHire › Remove.

  • On a Team or Enterprise plan, an Owner adds it first: Organization settings › Connectors › Add › Custom › Web. Then each person clicks Connect.
  • The free plan allows one custom connector.
  • If your dialog shows Advanced settings instead of these choices, leave the OAuth client ID empty.

Steps checked against Claude Help Center: custom connectors, Claude docs: connectors not in the directory and Claude docs: connector authentication on 15 Oct 2026. Not tried by hand with AyHire yet. Not checked: Whether Claude picks Register automatically on its own for a server like AyHire. The exact screens on Team and Enterprise plans.

ChatGPT

Add AyHire as a custom MCP server on chatgpt.com.

  1. Go to ChatGPT Plugins, click +, then Add custom MCP server.
  2. Name it AyHire and paste this as the Server URL. 
    https://ayhire.com/mcp
  3. For authentication choose OAuth. If it asks how ChatGPT should register, choose dynamic registration.
  4. Click I understand and want to continue, then Create as a plugin, and install it from your personal plugins.
  5. The first time it's used, AyHire opens: sign in, pick a workspace and click Connect.
  6. In a chat, type @ and pick AyHire.

Check it worked: Ask: “@AyHire who am I signed in as?” It answers with your email.

To disconnect: Ask ChatGPT to disconnect AyHire, or disconnect it in AyHire under Integrations › Connected apps. Then remove the plugin in ChatGPT's plugin settings.

  • Don't see Add custom MCP server? Turn on Developer mode in ChatGPT's settings. On a work account, your admin may have to allow it.
  • ChatGPT asks you before most AyHire searches, new analyses and anything that changes a role or a watch. Reading evidence, your roles, your shortlist and your watchlist runs straight away.
  • Custom MCP servers work on ChatGPT's website. Your workspace's rules can turn them off.

Steps checked against OpenAI: Add custom MCP server, OpenAI: Authentication and OpenAI: Plugins quickstart on 15 Oct 2026. Not tried by hand with AyHire yet. Not checked: Whether Developer mode is still needed, where its switch is, and which plans have it. The exact name of the registration choice. Whether AyHire works outside Work chats. Whether ChatGPT asks you to sign in to AyHire by itself, and when: OpenAI's docs describe a sign-in signal AyHire doesn't send yet.

Claude Code

One command, then sign in.

  1. Run this in your terminal: 
    claude mcp add --transport http --scope user ayhire https://ayhire.com/mcp
  2. Sign in: run claude mcp login ayhire, or type /mcp in Claude Code, pick ayhire and follow the browser. 
    claude mcp login ayhire
  3. AyHire opens in your browser. Sign in, pick a workspace and click Connect.

Check it worked: claude mcp list shows ayhire as Connected. Or ask Claude: “Use AyHire to check who I'm signed in as.”

To disconnect: Ask Claude to disconnect AyHire, then run claude mcp remove --scope user ayhire. (claude mcp logout ayhire only forgets the sign-in on this computer.)

  • Set it up with AyHire's setup prompt already? Then AyHire is connected: skip this. To sign in instead, ask Claude to disconnect AyHire, then run claude mcp remove --scope user ayhire first.
  • Using the AyHire plugin? It connects with its own key: skip this. To sign in instead, ask Claude to disconnect AyHire, then run /plugin uninstall ayhire@ayhire first. Its skills go with it.
  • --scope user makes AyHire available in every project.

Steps checked against Claude Code docs: MCP on 15 Oct 2026. Not tried by hand with AyHire yet.

Codex

One command to add AyHire, one to sign in.

  1. Run: 
    codex mcp add ayhire --url https://ayhire.com/mcp
  2. Then sign in: 
    codex mcp login ayhire
  3. AyHire opens in your browser. Sign in, pick a workspace and click Connect.

Check it worked: Type /mcp in Codex: ayhire is listed with its tools.

To disconnect: Ask Codex to disconnect AyHire. Then remove it from Codex (codex mcp --help lists the command).

  • Set it up with AyHire's setup prompt already? Then AyHire is connected: skip this.
  • Codex keeps AyHire in ~/.codex/config.toml.

Steps checked against Codex docs: MCP on 15 Oct 2026. Not tried by hand with AyHire yet. Not checked: How to sign out or remove a server in Codex: its MCP page doesn't say. Whether codex mcp login opens your browser by itself: its MCP page doesn't say.

Cursor

Add AyHire's address to Cursor's settings file, then sign in.

  1. Open ~/.cursor/mcp.json (create it if it's missing) and add AyHire. If the file already lists servers, add the ayhire entry inside mcpServers. 
    {
  "mcpServers": {
    "ayhire": { "url": "https://ayhire.com/mcp" }
  }
}
  2. Restart Cursor.
  3. Open Customize › MCPs and sign in to ayhire when Cursor asks. AyHire opens: sign in, pick a workspace and click Connect.

Check it worked: In Customize › MCPs, ayhire is on and lists its tools.

To disconnect: Ask Cursor's agent to disconnect AyHire, then remove ayhire in Customize › MCPs (or from mcp.json).

  • Set it up with AyHire's setup prompt already? Then AyHire is connected: skip this.
  • Cursor receives the sign-in on port 8787 of your computer. Keep that port free while you connect.

Steps checked against Cursor docs: MCP and Cursor help: MCP on 15 Oct 2026. Not tried by hand with AyHire yet. Not checked: The label of Cursor's sign-in button for a server added in mcp.json.

VS Code (GitHub Copilot)

Add AyHire as an HTTP server, then allow the sign-in.

  1. Open the Command Palette and run MCP: Add Server.
  2. Choose HTTP, paste this address, name it ayhire, and save it to Copilot Global so every project has it. 
    https://ayhire.com/mcp
  3. Or add it by hand to ~/.copilot/mcp-config.json (create it if it's missing). If the file already lists servers, add the ayhire entry inside mcpServers. 
    {
  "mcpServers": {
    "ayhire": {
      "type": "http",
      "url": "https://ayhire.com/mcp"
    }
  }
}
  4. Start the server when VS Code asks, and allow the sign-in. AyHire opens: sign in, pick a workspace and click Connect.

Check it worked: Run MCP: List Servers: ayhire is running. In Copilot Chat's agent mode, its tools are listed.

To disconnect: Ask Copilot to disconnect AyHire, then run MCP: List Servers, pick ayhire and remove it.

  • Set it up with AyHire's setup prompt already? That added AyHire to one project's .vscode/mcp.json only. These steps add it to every project.
  • If you set COPILOT_HOME, the file is in that folder instead of ~/.copilot.

Steps checked against VS Code docs: MCP servers on 15 Oct 2026. Not tried by hand with AyHire yet. Not checked: VS Code's sign-in prompt and how to sign out of one server: its MCP page doesn't describe them.

Gemini CLI

One command, then sign in from Gemini CLI.

  1. Run: 
    gemini mcp add --transport http --scope user ayhire https://ayhire.com/mcp
  2. Start Gemini CLI and sign in: 
    /mcp auth ayhire
  3. AyHire opens in your browser. Sign in, pick a workspace and click Connect.

Check it worked: Type /mcp in Gemini CLI: ayhire is listed with its tools.

To disconnect: Ask Gemini to disconnect AyHire first, then run gemini mcp remove --scope user ayhire.

  • Set it up with AyHire's setup prompt already? Then AyHire is connected: skip this.
  • Without --scope user, Gemini CLI adds AyHire to the current project only.

Steps checked against Gemini CLI docs: MCP servers on 15 Oct 2026. Not tried by hand with AyHire yet. Not checked: Whether removing the server also deletes Gemini's saved sign-in (it keeps tokens in ~/.gemini/mcp-oauth-tokens.json).

Set up with one prompt (agents that run commands)

Paste this into Claude Code, Codex, Cursor or any agent that can run commands:

Set up AyHire for me: fetch https://ayhire.com/setup.md with curl and follow it step by step.

The steps it follows: https://ayhire.com/setup.md. The key goes from the browser straight into a file on that computer and never appears in the chat.

Claude Code plugin

With access to the AyHire repository, the plugin does the same as the prompt:

/plugin marketplace add walidboulanouar/ayhire
/plugin install ayhire@ayhire

Any MCP agent

Agents that support MCP sign-in open AyHire in the browser the first time:

{"mcpServers":{"ayhire":{"type":"http","url":"https://ayhire.com/mcp"}}}

Or with an AyHire API key:

{
  "mcpServers": {
    "ayhire": {
      "type": "http",
      "url": "https://ayhire.com/api/mcp",
      "headers": { "Authorization": "Bearer YOUR_AYHIRE_API_KEY" }
    }
  }
}

Create a key at https://ayhire.com/app/integrations#keys after signing in. x-api-key: YOUR_AYHIRE_API_KEY works as well as the Authorization header. https://ayhire.com/mcp and https://ayhire.com/api/mcp are the same server.

Command line

ayhire login     # sign in in the browser and save a key on this computer
ayhire status    # check the saved key and which account it belongs to
ayhire logout    # revoke the key on AyHire and delete it from this computer

Signing out

Ask your agent to disconnect AyHire (the disconnect tool), or run ayhire logout. Either ends access on AyHire's side at once. Deleting ~/.config/ayhire/credentials.json by hand does not: the key keeps working until it is revoked. Keys and connected apps can also be revoked at https://ayhire.com/app/integrations.

HTTP API

curl "https://ayhire.com/api/search" \
  -H "x-api-key: YOUR_AYHIRE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "senior Rust backend engineer"}'

The core routes (analyze, search, candidates, shortlists), with request and response shapes: https://ayhire.com/api/docs. The MCP tools above cover the rest.

Tools

  • whoami: Check that AyHire is connected and which account is calling. Call this first when setting up or when other AyHire tools fail with an auth error.
  • disconnect: End this agent's connection to AyHire: the key or sign-in it uses stops working right away, on AyHire's side. Use it only when the user asks to sign out, log out, disconnect, remove or forget AyHire here. The AyHire website stays signed in; other agents stay connected unless they use the same key. After it, AyHire's tools stop working in this agent: don't try to sign in again unless the user asks to reconnect.
  • analyze_github_user: For someone in a role, use score_role_person instead (it also judges them against the role's criteria). Score a GitHub user's public work on 4 general dimensions (technical_depth, shipping_velocity, communication, gem_score; 0-10 each, total out of 40) with findings (what their work shows) and red flags, each with the GitHub links it rests on (claims without a source are dropped), and top skills. The analysis reads their own repos and their work on other people's projects (outside_work: commits and PRs by repo, last year). The scores are general: none is judged against a role, and where someone lives is never used. Returns a saved result if the user was analyzed in the last 30 days (free, cached=true); otherwise scrapes, scores and saves (takes 15-25s). Also returns activity: their GitHub contribution calendar for the last year, summarized (total, active weeks, streaks, busiest month, last active; null when GitHub has none). Set refresh=true only when the user asks for a fresh analysis. Parameters: username (required), refresh, persist.
  • analyze_github_users: Analyze up to 25 GitHub users in one call and get them back ranked, best total first (totals are out of 40), each with the four general scores, a summary, top skills and red flags. Saved analyses from the last 30 days are free and instant. Up to 4 new analyses start per call (about 20-35 s together); anyone else comes back in pending: call again with those. New analyses count toward the hourly limit (20); when it's spent the rest come back in limited with limit_resets_at (without a plan: limit_reason says so). Use it to compare a shortlist or to score the people find_people_behind_repos returned. Parameters: usernames (required).
  • score_candidate: For someone in a role, use score_role_person instead (it also judges them against the role's criteria). Lightweight version of analyze_github_user that never writes to the database. Uses a saved result if one is fresh; otherwise scrapes and scores without saving. Parameters: username (required), refresh.
  • find_people_behind_repos: Find the developers who build open-source projects: searches GitHub for repositories (most stars first) matching a query, topic or language, then lists the people who contributed most to them, ranked by how many of those repos they build and how much they contributed. Bots and AI coding agents are excluded. Pass repo ('owner/name') for the people behind one exact project, or org ('vercel') for the people behind an organization's repos (each person has public_member; false only means not shown as a member). Mining several seed repos one after another is often the best way to find strong people. location keeps people whose GitHub location is in one of the places, plus people who list no location, marked location_match: 'unknown' (unknown is never a mismatch; location_unknown: 'exclude' leaves them out). page reads the next set of repos. With role_id, people the role has already seen are left out (unless include_seen) and the search goes in the role's history. Free (GitHub only). Parameters: query, repo, org, topic, language, min_stars, created_after, pushed_after, repo_limit, people_per_repo, limit, page, location, location_unknown, role_id, include_seen.
  • search_people: Search GitHub profiles: words matched against name, login and bio (e.g. 'rust database', 'GTM engineer', 'AI adoption'; GitHub needs every word to match, so use one to three), a location (a city, a country, or a region such as Europe), language of their repos, minimum followers or repos. Each person comes back with bio, location, company, followers, the hireable flag and their top 3 own repos. Good for roles where profiles say more than repos, and for a location constraint; for engineers, mining the contributors of seed repos (find_people_behind_repos) is often stronger. Returns the exact query run and the total; pass next_cursor as cursor for more. With role_id, people the role has already seen are left out (unless include_seen) and the search goes in the role's history. Free. Parameters: query, location, language, min_followers, min_repos, sort, cursor, limit, role_id, include_seen.
  • search_repos: Search GitHub repositories by words, topic, language, owner org, stars and dates, most stars (or most recently updated) first, 30 a page, each with description, stars, topics, owner type and dates. Use it to find seed lists (awesome lists, community directories), the projects a role would work on, or small serious repos (no star floor by default), then mine their people with find_people_behind_repos(repo=...). Topic searches are usually cleaner than keywords; every word must match, so use few. Returns the exact query run. Free. Parameters: query, topic, language, org, min_stars, created_after, pushed_after, sort, page.
  • search_commits: Find who actually wrote commits matching some words, e.g. 'smartlead webhook', 'hubspot sync', 'mvcc snapshot isolation', optionally inside one repo or org. People come back grouped, most matching commits first, with up to 3 example commits each (repo, subject, UTC day, link) and how many repos their matching commits are in. Commits in forks are skipped (counted as in_forks) unless you name the repo. Good for finding practitioners whose work is spread over many small repos. Commits whose email isn't linked to a GitHub account are only counted (unattributed). With role_id, people the role has already seen are left out (unless include_seen) and the search goes in the role's history. Free; uses GitHub's search (about 30 a minute). Parameters: query (required), repo, org, page, role_id, include_seen.
  • get_person_evidence: Everything a recruiter would click through on GitHub to judge someone, in one call, each item with its link: profile and profile README, their repos (code, prose such as playbooks and lists, or forks) with descriptions, how they worked on their top repos (commits, active days, how many made with an AI coding agent), their work on other people's projects from the contribution graph (last year), pull requests they opened to other repos (grouped, merged counts, titles), orgs, activity month by month, and, with role_id, the repos the role's search found them through and their history there. Read live from GitHub, free, about 5 s. Use it to check a claim or judge fit yourself; unknown lists what GitHub could not show this time (unknown is not a weakness). Compact by default (own repos only, forks counted; shorter lists); detail: 'full' for everything. Whole READMEs: read_readme. All PRs or commits: list_pull_requests, list_commits. Parameters: username (required), role_id, detail.
  • read_readme: The whole README of any public GitHub repo (up to 30,000 characters, with truncated=true beyond), with its link. Read the work itself before you judge it: what the project does, how serious it is, how well it is explained. Free. Parameters: repo (required).
  • contribution_profile: What a developer actually did in one repo, in one call: merged pull requests (count, first and last, the newest 10 with size and links), the code areas those PRs touched (e.g. core/mvcc 22, core/translate 9), PRs still open, PRs of others they reviewed, their commits there (catches people who commit directly), and their rank among its contributors. Use it to check a claim like 'core contributor to the storage engine' or to see someone's real area in a big project. Free, live, about 3 s. Parameters: username (required), repo (required).
  • list_pull_requests: Pull requests a developer opened, newest first, 30 a page, each with its repo, title, link, state, whether it was merged and the start of its description. Narrow to one repo ('owner/name') or a state (open, closed, merged). Use it to see what they actually changed in projects they don't own. Free; uses GitHub's search, which allows about 30 searches a minute. Parameters: username (required), repo, state, page.
  • list_commits: A developer's commits in one repo (theirs or anyone's), newest first, 30 a page: subject, date, link, co-authors named in the commit, and whether it was made with an AI coding agent. Use it to see what they did in a project and how they work. Free. Parameters: username (required), repo (required), page.
  • enrich_person: For one GitHub user: LinkedIn URL, headline and current companies, a work email, and their X profile, with the source and confidence of each. Uses GitHub first (free), then paid lookups (usually $0.001-0.015, up to ~$0.03 with deep=true). Saved and reused for 30 days (cached=true is free). Use it on people the user is seriously considering, not on every name in a list. deep=true also searches the X bio and by name + company. Parameters: username (required), deep, find_email, refresh.
  • check_availability: Is this GitHub user already employed or open to work? Combines their current LinkedIn role, the company on their GitHub profile and GitHub's 'available for hire' flag. Returns a cautious verdict (employed, employed_but_open, open_to_work, likely_employed, unknown) with the evidence. Runs the same lookups as enrich_person (and saves them), so calling both costs nothing extra. Parameters: username (required), deep.
  • search_candidates: Plain-language search over developers AyHire has already analyzed (semantic similarity plus score ranking), e.g. 'senior Rust backend engineer with distributed systems experience'. Only finds people analyzed before; use analyze_github_user to add someone. Parameters: query (required), limit, threshold, filters.
  • list_roles: The roles (open positions) in your current workspace (or workspace), newest first, each with counts of picks, set aside, not looked at yet and shortlisted. Parameters: workspace.
  • create_role: Create a role (an open position) to source people for. AyHire suggests its criteria from the title and brief (what the role needs, each with an importance: must, important or nice; people are judged against them) unless you pass criteria, and turns the title and brief into a starting GitHub search unless you pass query/language. The role goes in your current workspace (or workspace) and also appears in the AyHire web app. Parameters: title (required), brief, query, language, created_after, criteria, workspace.
  • set_role_criteria: Replace a role's criteria: what the role needs, each judged from someone's public work, with an importance (must, important or nice). Use the user's words; specific beats generic ('Storage engine internals', not 'Strong engineer'). People judged against the old criteria show as out of date until score_role_person judges them again. The web app shows the same criteria. Parameters: role_id (required), criteria (required).
  • suggest_role_criteria: Suggest criteria for a role from its title and brief, without saving them: show them to the user, then save with set_role_criteria (as they are or changed). Useful when the brief changed or the current criteria feel off. Parameters: role_id (required).
  • get_role: A role and everyone in it, ranked: picks first (people judged against the role's criteria by the evidence of fit, then the rest by the general strength of their public work; ranking_basis says which), then set aside (public evidence against a must-have), then people not looked at yet. This is the final order: call it after scoring. Each person has AyHire's call (headline, one-line why, one thing to check), their verdict per criterion with links, your decision, notes, availability and total score. Compact by default (shorter reasons, up to 2 links a verdict, at most 25 people not looked at yet); detail: 'full' for everything. Use it to answer 'who should I talk to first?'. Parameters: role_id (required), include, detail.
  • find_people_for_role: Run the role's own search and save everyone it finds to the role. A role with a search plan (search_plan in get_role: the role's mix, tools and 3-6 searches read from its brief) runs every search in it: repos about the work, repos using the tools, profiles that say the job, and the tools' own maintainers (kept apart as builders). Each search is answered from AyHire's own index of people first and searched live on GitHub only where the index is thin or older than a month. Each person comes with why_found, source (index or GitHub just now) and a relevance (area fit, the brief's similarity, quality, feedback). Older roles run one search: people behind the top repos matching its words and language. role. People the role has already seen are left out, so each round brings new people (include_seen to bring them back); page 2 and on read the next repos. Returns everyone found with name, company, location, GitHub 'hireable' flag, followers, the matching repos they build and how much. To choose people yourself instead, use the search tools with role_id (search_people, find_people_behind_repos, search_commits) and add_people_to_role. Nothing is scored yet: call score_role_person for the people worth a closer look. Free (GitHub only). Pass query/language to search differently this time. Parameters: role_id (required), query, language, page, location, location_unknown, include_seen.
  • add_people_to_role: Add people you chose (from any search, or ones you know) to a role, each with a one-line reason in plain words: why they fit this role, from their work (e.g. 'Wrote the MVCC layer of turso: 103 merged PRs titled mvcc'). The role keeps the reason and how they were found, shown in the web app and in get_role. Up to 25 at a time. People already in the role keep their decision and notes; a new reason replaces the old one. Then score_role_person scores them. Parameters: role_id (required), people (required), found_via.
  • score_role_person: Analyze one person (4 general scores, summary, red flags; reads their own repos, their work on other people's projects and the repos the role's search found them through), judge them against the role's criteria (each verdict with links to its evidence; unknown is never a negative), and check whether they're available, then return them with AyHire's call and their place among the picks so far. Someone not in the role yet is added first (pass reason). A saved analysis is free and instant; a new one takes 15-25 seconds and counts toward the hourly limit (20 analyses), so score the people worth it, not everyone. The order changes as you score more people: call get_role for the final ranking. If a call times out, call it once more: when the analysis finished in the meantime, the retry is instant and free. Parameters: role_id (required), username (required), reason.
  • decide: Record a decision on someone in a role: shortlisted, not_now, or none (undo). Optionally add a note. Decisions are shared with everyone in the role's workspace. Shortlisted people show up in get_shortlist and in the web app's Shortlist. Parameters: role_id (required), username (required), decision (required), note.
  • get_shortlist: Everyone shortlisted in your current workspace (or workspace), across its roles (the same list as the web app's Shortlist), most recent first, with AyHire's call and the notes. Parameters: workspace.
  • watch_person: Watch someone in your current workspace (or workspace), with or without a role. About once a day AyHire re-checks their public GitHub profile and activity, and each change you asked about shows on Home and in list_watches with the link where it was seen. rules (default: all): open_to_work (GitHub “available for hire” turns on, or bio/LinkedIn headline says #OpenToWork), job_change (the company on their GitHub profile changes; their LinkedIn employer when AyHire reads it), says_looking (bio/headline says looking for, seeking or available for new work), new_work (public activity after 30+ quiet days, a new public repo or a release). paid_checks=true also re-reads their LinkedIn every 14 days when AyHire already has it: a paid lookup, about $0.005 each, within AyHire's limits. Ask the user before turning it on. Watches are shared with the workspace's team. AyHire can't watch for posts (e.g. about leaving a job): it doesn't read them. Parameters: username (required), rules, paid_checks, role_id, workspace.
  • unwatch_person: Stop watching someone in your current workspace (or workspace). Their daily checks stop for this workspace. Parameters: username (required), workspace.
  • list_watches: Everyone watched in your current workspace (or workspace): what each watch is for, when AyHire last checked, and the latest change with its link. Each watch's may_fit lists open roles in this workspace the person may also fit, from AyHire's index of their public work (no model, never location), with the reason and its link; added is true once they are in that role (don't add them again). Add someone with add_people_to_role. Parameters: workspace.
  • list_workspaces: Your AyHire workspaces and which one is current. A workspace holds roles and their shortlist: one per company you hire for, shared with that company's team. Every account has a personal one. Each shows its company's email domain and logo when it has one, and waiting_to_join lists workspaces you asked to join that an owner hasn't let you into yet.
  • switch_workspace: Make one of your workspaces the current one, for this agent and the web app. Role tools then list and create there. To act in another workspace for a single call, pass workspace to that tool instead. Parameters: workspace (required).
  • create_workspace: Create a workspace for another company you hire for, and switch to it. Its roles and shortlist are kept apart from your other workspaces. Parameters: name (required).
  • list_workspace_members: Who is in your current workspace (or workspace), with their role (owner or member), and, if you own it, the invites still open. Parameters: workspace.
  • invite_to_workspace: Invite a teammate by email into a workspace you own (not your Personal one): they get an email from AyHire with a link, sign in with that address and join, then see its roles, picks and shortlist. The link is also returned so you can share it another way; it works for 7 days. Pass send_email=false to only get the link. Inviting the same address again sends a new link. Parameters: email (required), workspace, role, send_email.

Cards in the chat

In apps that show MCP Apps (Claude, ChatGPT, VS Code), score_role_person, analyze_github_user, get_role and get_shortlist also draw a small card: the person or the ranked calls, with links. The text answer is the same everywhere; the card is an extra. It travels in the result's metadata, which the MCP Apps spec says is not for the model.

How to use the tools well

  • To source people: find_people_behind_repos first, then analyze_github_user only on the few worth a close look.
  • enrich_person and check_availability spend a paid balance; use them on people being seriously considered.
  • Present contact data with its source. A LinkedIn with confidence "guess" was matched by name and company and may be the wrong person; say so.
  • Saved results from the last 30 days are free. New analyses are limited to 20 an hour.