> ## Documentation Index
> Fetch the complete documentation index at: https://hired-claude-google-calendar-gmail-integration-bi7nna.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# CRM tools
> Fifteen tools over the companies you are talking to and the people at them, including their own timelines and ping dates.
`get_company` before writing anything about a company, so you add to the research rather
than replacing it — `update_company` replaces the `notes` field it is passed.
A company's `website` is their **own** domain, not a job-board link. Nothing else depends
on it, but it is what puts their logo on the pipeline, so it is worth setting whenever you
learn it.
`log_activity` takes either an `applicationId` or a `contactId`, never both. With a
contact id it becomes that person's history — their page shows it and their "last
touched" date moves. `update_contact`'s `nextFollowUpAt` is where "ping them in two
weeks" lives, and due pings surface in `list_follow_ups` alongside due applications.
[How companies and contacts work →](/concepts/crm)
The descriptions below are quoted **verbatim** from what the server sends a connected
assistant, which is why they address it rather than you. They are reproduced rather than
rewritten so this page cannot drift from what your assistant actually receives.
### `list_companies`
*List companies*
Every company on file, with how many applications and contacts each one has, plus lastAppliedAt (when you last applied there) and openApplications (how many are still live). Reach for this to answer 'who have I applied to', to find a companyId before get\_company, or to cut the list down to something specific before working through it. Every row carries its tags: industry, size, location and free tags, all as labels rather than the single strings they used to be. Everything below ANDs, so one call asks for 'fintech, remote, never applied'. search matches the name, the website, your notes and any tag name. filter is one cut and only one. industryIds, sizeIds and locationIds each take tag ids of that kind from list\_tags and match a company wearing ANY id in the group — so a group ORs inside itself and ANDs with the others. tagIds is the loose one: it matches a tag of any kind, which is what to use when you have an id and do not care which list it came from. missing finds the gaps worth fixing in one sitting, and those AND with each other. sort is name, applied, apps or people; every sort but name defaults to most-first, and companies you have never applied to sort last whichever way 'applied' points, because that is a question about the others. Ids only — call list\_tags first to turn 'fintech' into an id; a name here would narrow nothing and hand you every company as if that were the answer. Archived companies are never returned; list\_archive is where those are. Read-only: it saves nothing and creates no tags.
| Argument | Type | |
| ------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- |
| `search` | string | Match name, website, notes or any tag — industry and location included |
| `tagIds` | string\[] | Only companies wearing one of these tags, of any kind. Ids from list\_tags. |
| `industryIds` | string\[] | Tag ids of kind INDUSTRY. Matches a company wearing any of them. |
| `sizeIds` | string\[] | Tag ids of kind SIZE. |
| `locationIds` | string\[] | Tag ids of kind LOCATION. |
| `missing` | string\[] | Fields that are blank: website \| industry \| location. These AND with each other. |
| `filter` | enum | Cut the list: active \| applied \| never-applied \| with-contacts `active` · `applied` · `never-applied` · `with-contacts` |
| `sort` | enum | name \| applied \| apps \| people. Default name. `name` · `applied` · `apps` · `people` |
| `dir` | enum | asc \| desc `asc` · `desc` |
### `get_company`
*Get a company*
Everything on file for one company: website, industry, size, location, your research notes, every application you have with them, and every person on file who represents it — someone can represent more than one company, so a name here is not necessarily their day job. This is the tool to call before writing anything about a company, so you add to what is known rather than replacing it.
| Argument | Type | |
| -------- | ------ | ------------------------- |
| `id` | string | **required** — Company id |
### `create_company`
*Create a company*
Add a company before you have applied to them — somewhere to keep research while you decide. Applications create their company automatically, so reach for this only when there is no application yet. Names are unique per person; creating one that already exists is an error rather than a silent merge.
| Argument | Type | |
| ------------- | --------- | --------------------------------------------------------------------------------- |
| `name` | string | **required** — Company name |
| `website` | string | Their own site, e.g. stripe.com. This is what the logo comes from. |
| `industry` | string\[] | What they do, one or more: 'Fintech', 'Developer tools'. Tags — REPLACES the set. |
| `industryIds` | string\[] | Industry tag ids from list\_tags. Exact; wins over industry. |
| `size` | string\[] | Headcount or stage: '200-500', 'Series B'. Tags — REPLACES the set. |
| `sizeIds` | string\[] | Size tag ids. Exact; wins over size. |
| `location` | string\[] | Where they are, one or more. Tags — REPLACES the set. |
| `locationIds` | string\[] | Location tag ids. Exact; wins over location. |
| `tags` | string\[] | Anything else worth filing them under. REPLACES the set. |
| `tagIds` | string\[] | Company tag ids. Exact; wins over tags. |
| `notes` | string | Anything you have learned about them |
### `update_company`
*Update a company*
Change what you know about a company. Only the fields you pass are touched, but each one REPLACES what was there — notes especially, so call get\_company first and write back the whole thing if you are adding to research rather than replacing it. Industry, size, location and tags are lists of labels now rather than single strings: a company can be fintech AND developer tools, and in three offices. Each list replaces its own set and leaves the other three alone. Setting website is the single thing that makes their logo show in the pipeline; a job board URL is not their website.
**Overwrites or deletes.**
| Argument | Type | |
| ------------- | --------- | --------------------------------------------------------------------- |
| `id` | string | **required** — Company id |
| `name` | string | Company name |
| `website` | string | Their own site, e.g. stripe.com |
| `industry` | string\[] | What they do, one or more. REPLACES the set; an empty list clears it. |
| `industryIds` | string\[] | Industry tag ids from list\_tags. Exact; wins over industry. |
| `size` | string\[] | Headcount or stage. REPLACES the set. |
| `sizeIds` | string\[] | Size tag ids. Exact; wins over size. |
| `location` | string\[] | Where they are, one or more. REPLACES the set. |
| `locationIds` | string\[] | Location tag ids. Exact; wins over location. |
| `tags` | string\[] | Anything else worth filing them under. REPLACES the set. |
| `tagIds` | string\[] | Company tag ids. Exact; wins over tags. |
| `notes` | string | Research notes — replaces what is there |
### `delete_company`
*Archive a company*
Put a company in the archive. It leaves the CRM, every picker, every filter and the pipeline, and restore\_records brings it back for a set number of days — 30 by default — before it is deleted for good. Nothing is destroyed here. Every application still pointing at it goes into the archive with it and comes back with it; this used to refuse while those existed and no longer needs to. The people who represent it are NOT archived: somebody is a founder at one company and an advisor at another, so they keep every other company and simply lose this one. Returns how many applications went with it. To fold a duplicate employer into the one you are keeping without archiving anything, use merge\_companies.
**Overwrites or deletes.**
| Argument | Type | |
| -------- | ------ | ------------------------- |
| `id` | string | **required** — Company id |
### `preview_company_merge`
*Preview merging two companies*
What merging one company into another WOULD do, without doing any of it. Call this first, every time — merge\_companies is irreversible and takes an argument order that is easy to get backwards. Returns how many applications and contacts would move, which of them by role title, which blank fields on the survivor would be filled from the duplicate, and whether the duplicate's notes would be appended. Show that to the person before you merge. Read-only.
| Argument | Type | |
| ---------- | ------ | ---------------------------------------------------------------- |
| `keep_id` | string | **required** — Company id that SURVIVES the merge, with its name |
| `merge_id` | string | **required** — Company id that is folded in and then DELETED |
### `merge_companies`
*Merge one company into another*
Fix the same employer being on file twice — 'Stripe', 'Stripe, Inc.' and 'stripe' each holding a slice of the pipeline. Every application and contact on merge\_id moves to keep\_id, blank fields on keep\_id are filled from the duplicate, the duplicate's notes are APPENDED to the survivor's under a line saying where they came from, and then the duplicate row is deleted. DESTRUCTIVE and IRREVERSIBLE: the company at merge\_id ceases to exist, its page stops resolving, and nothing records afterwards which applications came from which side. Call preview\_company\_merge first and let the person confirm. The direction matters and is not guessable — keep\_id is the name that lives on. Nothing is de-duplicated: two identical role titles on the survivor is the correct result, not a bug. Note that a later create\_application naming the old spelling will simply create it again as an empty company.
**Overwrites or deletes.**
| Argument | Type | |
| ---------- | ------ | ------------------------------------------------------------ |
| `keep_id` | string | **required** — Company id that SURVIVES, keeping its name |
| `merge_id` | string | **required** — Company id that is folded in and then DELETED |
### `list_contacts`
*List contacts*
Recruiters, hiring managers, referrals and the friend who might put in a word. Reach for this to find a contactId before get\_contact or update\_contact, to see who you already know somewhere before an interview, or to build the list you are about to work through. Returns each person with `companies` — a list, because someone can be a founder at one place and an advisor at another — their `tags`, their next ping date, the application they are attached to, and their most recent logged activity. Everything below ANDs. search matches name, title, relationship, email, notes, employer names and tag names. filter is one cut and only one. companyIds matches anyone linked to ANY of those companies — linked, not employed by, so an advisor at one of them counts; companyId is the single-company shorthand for the same thing. tagIds takes CONTACT tag ids from list\_tags. quietDays is the networking question: everyone you have logged nothing against for at least that many days, counting from the day you added somebody you have never logged anything against at all, so people you filed and forgot come back rather than hiding behind a blank. missing finds the gaps: 'email' means nobody you can write to, 'tags' means filed under nothing so no tag filter will ever find them. sort is name, company (people with nobody on file last), ping (soonest first, no date last) or touch (longest since you logged anything, first). log\_activity with a contactId is what moves the last-touch date; update\_contact's nextFollowUpAt is what schedules the next ping. Archived people are never returned; list\_archive is where those are. Read-only; it saves nothing.
| Argument | Type | |
| --------------- | --------- | -------------------------------------------------------------------------------------------------------- |
| `applicationId` | string | Limit to one application |
| `companyId` | string | Limit to people linked to one company |
| `companyIds` | string\[] | Limit to people linked to any of these companies |
| `search` | string | Match name, title, relationship, email, notes, company or tag |
| `tagIds` | string\[] | Only people wearing one of these tags. Ids from list\_tags, kind CONTACT. |
| `quietDays` | number | Only people with nothing logged for at least this many days |
| `missing` | string\[] | Fields that are blank: email \| tags. These AND with each other. |
| `filter` | enum | Cut the list: ping-due \| with-application \| no-company `ping-due` · `with-application` · `no-company` |
| `sort` | enum | name \| company \| ping \| touch. Default name. `name` · `company` · `ping` · `touch` |
| `dir` | enum | asc \| desc `asc` · `desc` |
### `get_contact`
*Get a contact*
One person in full, with every company they represent (`companies`) and the application they belong to. Call this before update\_contact so you know what you are about to overwrite. Also returns their timeline — every call, coffee and reply logged with log\_activity, newest first — so 'when did I last talk to them' is answered from here.
| Argument | Type | |
| -------- | ------ | ------------------------- |
| `id` | string | **required** — Contact id |
### `update_contact`
*Update a contact*
Change a person's details. Only the fields you pass are touched, and each REPLACES what was there — read first with get\_contact if you are adding to notes, otherLinks, companies or tags rather than replacing them. A person can represent several companies at once, so `companies` is a list and REPLACES the whole set: to add one, read the current list, append, and pass it all back. An empty list detaches them from every company. `tags` behaves the same way. applicationId works the same way too, with an empty string to detach.
**Overwrites or deletes.**
| Argument | Type | |
| ---------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id` | string | **required** — Contact id |
| `name` | string | Their name |
| `title` | string | Their job title |
| `email` | string | Email |
| `phone` | string | Phone |
| `linkedin` | string | LinkedIn URL |
| `twitter` | string | X / Twitter — a URL or an @handle |
| `instagram` | string | Instagram — a URL or an @handle |
| `github` | string | GitHub profile URL |
| `website` | string | Their own site, blog or portfolio |
| `otherLinks` | string\[] | Anywhere else they are reachable that has no field of its own — Bluesky, Mastodon, a Substack. REPLACES the whole list, so read the current one from get\_contact first. |
| `relationship` | string | e.g. 'recruiter', 'hiring manager', 'referral' |
| `notes` | string | Notes — replaces what is there |
| `companyIds` | string\[] | Company ids. Exact; wins over companies. REPLACES the whole set. |
| `companies` | string\[] | Company names — everywhere this person represents. REPLACES the whole set; a name nothing matches is created. |
| `company` | string | Legacy single-company spelling. WARNING: this also REPLACES the whole set with just this one — read the current list from get\_contact first, or use companies. Empty string detaches every company. Ignored when companies is passed. |
| `tagIds` | string\[] | Tag ids, kind CONTACT. Exact; wins over tags. REPLACES the whole set. |
| `tags` | string\[] | Tag names — how they are filed. REPLACES the whole set; a name nothing matches is created. Empty list clears them. |
| `applicationId` | string | Application to attach to, or empty string to detach |
| `nextFollowUpAt` | string | ISO date to next get in touch — 'ping Sarah in two weeks' lives here. Empty string clears it. Due pings surface in list\_follow\_ups and on the dashboard. |
### `delete_contact`
*Archive a contact*
Put a person in the archive with their whole timeline — every call, coffee and reply logged against them. Nothing is destroyed, and restore\_records brings all of it back for a set number of days, 30 by default. The companies they represent and the application they were attached to are untouched; they simply stop appearing on either. To take somebody off one application without archiving them, use update\_contact with an empty applicationId.
**Overwrites or deletes.**
| Argument | Type | |
| -------- | ------ | ------------------------- |
| `id` | string | **required** — Contact id |
### `create_contact`
*Create a contact*
Save a person: recruiter, hiring manager, referral, friend at the company. Record every way you can reach them — linkedin, twitter, instagram, github, website, and otherLinks for anything else — because the one that matters is whichever they actually answer on, and a name with no way to contact it is a dead row. Pass `companies` for everywhere they represent, not just their day job: an angel who also advises two of your targets is three links, and each one is created if it does not exist yet. `tags` files them alongside everyone else you have labelled the same way.
| Argument | Type | |
| --------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `name` | string | **required** — Their name |
| `title` | string | Their job title |
| `email` | string | Email |
| `phone` | string | Phone |
| `linkedin` | string | LinkedIn URL |
| `twitter` | string | X / Twitter — a URL or an @handle |
| `instagram` | string | Instagram — a URL or an @handle |
| `github` | string | GitHub profile URL |
| `website` | string | Their own site, blog or portfolio |
| `otherLinks` | string\[] | Anywhere else they are reachable that has no field of its own — Bluesky, Mastodon, a Substack. REPLACES the whole list, so read the current one from get\_contact first. |
| `relationship` | string | e.g. 'recruiter', 'hiring manager', 'referral' |
| `notes` | string | Notes |
| `companyIds` | string\[] | Company ids, when you already have them. Wins over companies. |
| `companies` | string\[] | Every company they represent, by name. Any that do not exist yet are created. |
| `company` | string | Legacy single-company spelling. Ignored when companies is passed. |
| `tagIds` | string\[] | Tag ids from list\_tags, kind CONTACT. Exact; wins over tags. |
| `tags` | string\[] | How they are filed — 'referral', 'warm intro', 'ex-colleague'. Names; any that do not exist yet are created. |
| `applicationId` | string | Attach to this application |
### `tag_companies`
*Tag companies in bulk*
Add or remove tags across a set of companies in one act — 'these nine are all fintech', 'take Dream list off these four'. ADD and REMOVE, never replace: a bulk write that replaced the set would mean tagging nine companies as fintech quietly stripping the size, location and everything else off every one of them. Ids only, from list\_tags, and each must be a tag of kind INDUSTRY, SIZE, LOCATION or COMPANY — a tag of any other kind is refused rather than attached, because nothing in the app renders an application tag on a company and no picker could ever take it back off. Ids that are not this person's, or are in the archive, are skipped rather than failing the call. Returns which companies changed and which were skipped. Use update\_company when you are setting one company's lists deliberately; this is for a selection.
| Argument | Type | |
| -------- | --------- | ------------------------------------------------------------ |
| `ids` | string\[] | **required** — Company ids to change |
| `add` | string\[] | Tag ids to attach. Kind INDUSTRY, SIZE, LOCATION or COMPANY. |
| `remove` | string\[] | Tag ids to take off |
### `tag_contacts`
*Tag people in bulk*
Add or remove CONTACT tags across a set of people in one act — 'these six are all referrals'. ADD and REMOVE, never replace, for the same reason tag\_companies does not replace: a bulk overwrite loses every other label somebody already carries. Ids only, from list\_tags with kind CONTACT; a tag of any other kind is refused. Ids that are not this person's, or are in the archive, are skipped rather than failing the call. Use update\_contact when you are setting one person's tags deliberately.
| Argument | Type | |
| -------- | --------- | ------------------------------------ |
| `ids` | string\[] | **required** — Contact ids to change |
| `add` | string\[] | Tag ids to attach. Kind CONTACT. |
| `remove` | string\[] | Tag ids to take off |
### `schedule_contact_pings`
*Put people on the chase list*
Set one next-ping date across a set of people — 'chase everyone I met at the conference in two weeks'. Takes an ISO date; an empty string clears the date instead, taking all of them off the chase list. A date it cannot read is REFUSED rather than treated as empty, so a vague 'next Tuesday' fails loudly instead of silently unscheduling everybody in the batch. Due pings surface in list\_follow\_ups and list\_schedule alongside due applications. Ids that are not this person's, or are in the archive, are skipped. Use update\_contact's nextFollowUpAt for one person.
| Argument | Type | |
| -------- | --------- | -------------------------------------------------------------------- |
| `ids` | string\[] | **required** — Contact ids |
| `date` | string | **required** — ISO date to ping them, or an empty string to clear it |