Homie

List the authenticated user's second-degree network: people connected to one of your own first-degree contacts, but whom you don't know directly. Each entry names the bridging connector (`viaConnector`) and the warmness on the connector→person edge, so you can see who could introduce you. Ordered warmest first. Pass `viaConnectorId` (a person id from list_first_degree_connections) to narrow to that connector. Coverage is bounded: `totalCount` counts people within the scanned window (not the entire network), and `capped: true` means bridge or per-connector edge limits were reached. Requires a user-scoped MCP token; organization API keys are not supported. Default limit 20, max 50; page with `nextOffset`.

list_second_degree_connections

List the authenticated user's own target lists, most recently updated first. Returns each list's id, name, matched company count, unmatched imported-company count, and timestamps. Use this before rename_target_list, add_company_to_target_list or remove_company_from_target_list to resolve the targetListId. Requires a user-scoped MCP token; organization API keys are not supported.

list_target_lists

Add one of the authenticated user's own first-degree connections to their prioritized list, meaning the people they consider key relationships. This is a WRITE: it adds a strong priority signal to that connection's warmness score (recalculated immediately), moves the person to the top of the priority list, and, if that person also has a Homie account, promotes them to an accepted advocate so they appear as an available connector. Only call it when the user explicitly asks to prioritize, star, or flag someone; do not call it to 'improve' scores on your own initiative. Identify the person with `personId` (the id returned by list_first_degree_connections, search_people, or get_person); `connectionId` is accepted as an alternative for ids that came from a ghost opportunity's bestPath. Only the user's own first-degree connections can be prioritized, so second-degree people are rejected. Calling it again after it is at the top is a no-op and returns alreadyPrioritized: true. Requires a user-scoped MCP token; organization API keys are not supported.

add_prioritized_connection

Remove one company's membership from one target list owned by the connected user. Use only when the user asks for this removal. Resolve targetListId with list_target_lists and companyId with search_companies; use get_target_list when current membership is needed. Accepts the returned Homie id or LinkedIn companyId. Does not delete the company or list, rename the list or remove other members. If already absent, returns changed:false. Requires a user-scoped MCP token with mcp:write; organization API keys and other users' lists are rejected.

remove_company_from_target_list

Rename one target list owned by the connected user to the requested name. Use only when the user asks to rename it. Resolve targetListId with list_target_lists first. Does not create a list or change its company membership. Repeating the same name returns changed:false. Requires a user-scoped MCP token with mcp:write; organization API keys and other users' lists are rejected.

rename_target_list

Look up company records in Homie by name, industry, or HQ location. Use to resolve a company ID for a target list or expand company details. For who we know at a company or a way to reach its employees, use search_warm_paths instead.

search_companies

Use this when looking up a known contact by name/email, disambiguating a person or resolving an ID before a profile brief or explicit relationship change. Substring matches name, email, position and current company across the organization's first- and second-degree network. Use search_network for natural-language role/location/industry criteria and search_warm_paths for an introduction to someone. Each result includes degree ('first' or 'second'); first means direct to someone in the organization, not necessarily the current user. A current-company match does not establish previous employment.

search_people

Search stored sales prospects recommended by Homie for the connected organization. Match query against prospect name, company and position; return existing recommendations with customer-profile fit, buying-intent signals and available introduction paths. Results sort by relevancy by default. Use for finding recommendations at a company or matching a role. This is a read-only search: it does not scan the whole network, discover or change opportunities, or send messages. Use search_network for broader prospecting and search_warm_paths for an introduction to a specific person or company. Default limit 20, max 50; paginate with nextOffset.

search_sales_opportunities

Use this when the user wants a set of people to approach: sales prospects, design partners, investors to pitch, candidates to recruit, advisers/experts, agencies/providers, distribution partners, journalists, speakers or podcast guests. Examples: 'Which seed investors should I pitch?', 'find a founding engineer we could hire', 'who could advise us on enterprise sales?', 'who should I meet in Helsinki?', or 'scan our network for fintech CTOs'. No Homie or network keyword is required when actual people are requested. Searches existing professional contacts using natural-language criteria; general fundraising advice, a job description, company facts or technical-network scans do not need this tool. Preserve the user's criteria. Read get_icp for sales qualification; do not impose sales ICP on other goals. Profile matches do not establish availability, investment interest, attendance, past employment or willingness to help. For a named company/person use search_warm_paths instead. Personal-only search uses networks ['user']; default includes all permitted networks. This does not start a crawler, import data or create opportunities. No pagination or aggregate network analytics; results are limited to the requested count.

search_network

Use this when the user wants to reach a named company or person: "How can I reach Stripe?", "get me a meeting with [company]", "who do we know at X?", "reach their CFO", a job referral, an introduction to an investor/partner/journalist, or relationship context before meeting someone. Also use for comparing routes into specified accounts and contextual follow-ups. No Homie, network or intro keyword is required. A company request maps to prospectCompany with organization scope; prospectRoles narrows only roles the user requested. A known sales target does not require ICP qualification before finding a route. For an open-ended set of people to approach, use search_network. Public support/contact details, product login, directions and general company research alone do not need private network data. With a user token, low-score connections may automatically be queued for background AI rescoring (up to ten per call), which persists updated warmness scores and breakdowns. Return current evidence without waiting; use check_warmness_rescore only if the user later asks for an update. Connector responses are compact: raw factor breakdowns and image URLs are omitted; scores, hop signals and identities are retained. Pages fit a 12 KB JSON budget and may contain fewer paths than limit; always paginate with nextOffset, never offset + limit. For a named company, use one organization-scoped call for all permitted teammates; do not loop through members with search_network/asUserId. Find warm intro paths to exactly one target person OR company. By default it searches from everyone in the organization; narrow the source with `scope` or `fromUserIds`, and narrow how the target is reached with `connectionTypes`. Each path includes warmness scores and human-readable signal labels showing the relationship evidence. Pass prospectPersonId, prospectLinkedinId, prospectName (optionally with prospectCompany for disambiguation), or prospectCompany. Common scopings: my own network only = scope 'me'; paths through my first-degree connections = scope 'me' + connectionTypes ['second_degree']; people I already know directly = scope 'me' + connectionTypes ['direct']; a specific colleague's network = fromUserIds ['<their user or person id>']. In company mode, people the organization has already requested an intro to are excluded and counted in `excludedIntroRequested`; in person mode nothing is filtered, but the prospect is annotated with introRequested. Always inspect `coverage.capped`: a true value means bounded employee or graph scans may have omitted paths. Warmness says who is reachable, not who is worth reaching, so call get_icp first when prospecting and rank the results against it. Default limit is 20; pass limit up to 50 when the user asks for more paths. To fetch more results, call again with the `nextOffset` value returned in the previous response (or any explicit `offset`). Read `outcome`: `found` means at least one genuinely warm route (warmness > 0) was returned; `no_paths` means the target is reachable-in-name-only with no warm route; `target_not_found` means no such person/company is in the org's network. A `no_paths` result may still carry `paths` — cold routes whose connector→target hop scores 0 — so a path list alone is NOT proof of a warm route; always inspect each path's own warmness and null hop scores before calling it a warm intro, especially with includePossiblePaths. On `no_paths`/`target_not_found` the result carries a human-readable `message` and, when the org has any warm contacts, `fallbackConnections` — the organization's warmest reachable people as alternative starting points. Relay the `message` and offer the fallbacks as the org's closest existing contacts; never present them as a path to the requested target, and never report an empty result as 'they know no one'.

search_warm_paths

Remove one of the authenticated user's first-degree connections from their prioritized list. This is a WRITE and the inverse of add_prioritized_connection: it withdraws the priority signal from that connection's warmness score (recalculated immediately). It does not revoke advocate status that was granted when the person was prioritized. Only call it when the user explicitly asks to unprioritize, unstar, or unflag someone. Identify the person with `personId` or `connectionId`, exactly as for add_prioritized_connection. Calling it for someone who is not prioritized is a no-op and returns removed: false. Requires a user-scoped MCP token; organization API keys are not supported.

remove_prioritized_connection