Intelligo

Classify a subject company / fund / operating business into one of the 9 subject-sector buckets: Fund Manager / Investor, Technology & Software, Healthcare & Life Sciences, Financial Services & Fintech, Industrial & Materials, Consumer & Retail, Energy & Climate, Real Estate & Hospitality, Other / Unclassified. Returns the sector, a confidence score (0–1), and a source tag (cache | tier0_inline | uncached). When the source is "uncached" and the confidence is 0, the caller should treat the subject as genuinely unclassified and ask the user. These are the same 9 values `get_scoping_area` accepts as `primarySubjectSector` — when scoping a new background check, classify here (or map Intelligo industry data yourself) and pass the sector along.

classify_subject_sector

Discover the org's report levels, jurisdictions and add-ons, and compare what each level covers. All **custom per org**: never assume a fixed catalog. Add-on availability is JOINT in level × jurisdiction × entityType. Step contract for a NEW check: (1) no `levelIds` → the org's `levels`, `jurisdictions`, coverage `groups`, `addOns` — a CATALOG of names to propose, NOT an availability list; restricted entries carry `appliesToLevelIds` + jurisdiction hints; levels flagged `notAvailableForFcra` must never be offered for an FCRA candidate. PERSON discovery adds `fcraAvailable` — if true, before scoping a person search ask: "Is this search being conducted for employment purposes in the US?"; offer formType "FCRA" only on an explicit yes. If false, never mention FCRA. (2) with `levelIds` (+ `jurisdictionId`, `entityType`) → each `comparedLevels[]` entry carries `offerableAddOnIds` — the EXACT add-ons selectable with that level there (names in `addOnDetails`) — propose ONLY from this set. (3) optionally re-compare with `addOnIds` to verify (`appliedAddOnIds`; failures in `unavailableAddOns` with hints), then present the scope for approval and draft via `createNewSearch`. Monitoring is per subject type, not per level: obey `monitoring.status` (the output schema carries its contract); never offer it for an `isMonitored` subject. Compare mode also returns the coverage matrix: items by section, per-level `isCovered`/`isAvailable`, description, limitations. `differencesOnly:true` keeps only rows that differ across levels; `groups` filters sections. Levels are compared in ONE jurisdiction (`jurisdictionId`, else the org default, echoed as `jurisdiction`); those not offered there land in `unavailableLevels` with `availableJurisdictions`. Defaults to PERSON; set `entityType:"COMPANY"` for companies — the offerable set changes with it. Rows and add-ons are DIFFERENT id-spaces: a row titled like an add-on (e.g. "Analyst Review") is NOT that add-on. Coverage is what a level *includes*, not findings on a subject.

compareCoverage

Prepare an Intelligo background-check search as a DRAFT on one or more subjects. IMPORTANT: this does NOT run a real search — it fills in the steps, saves a DRAFT and returns its Intelligo link. The user must open it, review (Review & Submit, in Intelligo) and submit there for the search to run. Make sure they understand this. Steps, in order: • Subjects (step 1) — put people in `people` and companies in `companies` (both optional; ≥1 subject overall). Do not ask Person vs Company: the array is the kind. Several of each allowed. • FCRA (person form type) is org-gated: offer ONLY if compareCoverage returned `fcraAvailable: true` — then FIRST ask: "Is this search being conducted for employment purposes in the US?"; use formType "FCRA" only on an explicit yes, else never mention FCRA. • `reportTypeIds` (step 2) — report types, REPORT_LEVEL ids from compareCoverage; one global list applied to every compatible profile. Omit ONLY for a monitoring-only draft. • `addOnsByJurisdiction` (step 2, OPTIONAL) — add-ons keyed by jurisdiction id → add-on ids, e.g. { "301": [331] }; ids from compareCoverage `addOns`. User picks per jurisdiction, or none (omit/{}). NOT report levels. • `monitoringPackageIds` (step 2, OPTIONAL) — monitoring, ids from compareCoverage `monitoring.packages`; each lands on every subject it fits, and `monitoring.notApplied` in the reply says who was skipped (relay it). • Project link (step 3, OPTIONAL) — attach every profile to ONE project: pass BOTH `projectId` AND `projectName` (from getProjects, or createProject). Omit both for none. • `draftName` (required) — ask at the end; default to the single profile's name, else a shared one. BEFORE CALLING: show the gathered scope as a TABLE (per-profile fields, report types, add-ons, monitoring, project, draft name) and get EXPLICIT approval; only call after the user confirms. Scope is validated BEFORE creation: on failure no draft exists and { success:false, errors } is returned — relay the specifics, do not retry.

createNewSearch

Create a new Intelligo **project** — a named aggregation of profiles — in the calling user's organization. The creator is granted access automatically. • `name` (required) — the project name. Names are unique per organization; if one already exists the tool returns `{ success: false, message }` rather than creating a duplicate. • `profiles` (optional) — **searchIds** to seed the project with, i.e. the numeric `searchId` carried by a profile's `reports[]` (e.g. from getProfiles / getReportContent). Omit to create an empty project. On success returns `{ success: true, data }` with the created project. This tool **writes** — it creates a record.

createProject

Export **action items** to an Excel (`.xlsx`) workbook and return a **presigned download URL** (valid ~30 minutes) — the downloadable counterpart of `getActionItems`. Use this when the user asks to DOWNLOAD / EXPORT / "get an excel/spreadsheet of" action items (e.g. "download the open monitoring flags to excel"); use `getActionItems` to READ them inline instead. Same filter vocabulary as `getActionItems`, all optional and AND-ed together: - `types`: `flag`, `review`, `refresh`, `upgrade`, `add_monitoring` (omit for all kinds). - `status`: `OPEN`/`IN_PROGRESS` (unresolved) and/or `RESOLVED`/`IMMATERIAL` (addressed). - `origins`: origin LABELS, e.g. `["monitoring"]`; matched case-insensitively against the org's origin names. No match -> nothing is exported and `availableOrigins` lists the valid labels to retry with. - `profileId` (the profile's own id from getProfiles, NOT a report `searchId`) and/or `projectId`; omit both for the whole org. - `startDate`/`endDate` (ISO) -> only items created in that window. MONITORING FLAGS to excel -> `types:["flag"]` + `origins:["monitoring"]`. Surface the returned `downloadUrl` as a link. Tenant- and permission-scoped to the caller.

exportActionItems

Generate a PDF export for Intelligo report(s)/profile(s) **or** a whole project and return a **presigned download URL** (valid ~30 minutes). Provide EXACTLY ONE target: • **`profileIds`** → export the report(s) for those profiles. One report yields a PDF; multiple yield a `.zip`. • **`projectId`** → export the whole project. `exportMode: SINGLE_PDF` merges every profile into one document; `MULTI_PDF` returns a `.zip` (ignored for `profileIds`). The five `include*` flags mirror the UI export checkboxes — confirm with the user which to enable before calling. Tenant- and permission-scoped to the caller; surface the returned `downloadUrl` as a link. Monitoring is an ongoing feed, not a static report, and is NEVER exported: the `reports[]` entry `_id: "MONITORING"` is an internal monitoring-setup search, and only the static reports listed in `pdfReadyReports` are exportable. When `pdfReadyReports` is empty (e.g. the profile has only a monitoring-setup search, or its reports are still in progress) this tool errors with "No Searches Found", so do NOT call it; instead tell the user there is no exportable report yet (a monitoring feed is read with `getMonitoringFeed` and is never part of a PDF export).

exportPdf

List **action items** - tracked follow-ups Intelligo raises on reports/monitoring. Each has a `status` (OPEN, IN_PROGRESS, RESOLVED, IMMATERIAL; last two = addressed), `profileId`, timestamps, `updatedBy`, `origin` codes + decoded `originLabels`, and a `link`. Users won't say "action item" - route plain language via `types`: - flags / red flags still open / audit flags -> `types:["flag"]` (open = `status:["OPEN","IN_PROGRESS"]`). - report reviewed? / who reviewed it / not reviewed -> `types:["review"]` (reviewed = `RESOLVED`; reviewer = `updatedBy`/`updatedAt`). - ANY recommendation question - "do you have recommendations?", "what do you recommend for X?", "what should I do with this subject?", "needs a refresh/upgrade/monitoring?" -> `types:["refresh","upgrade","add_monitoring"]`. "Recommendation" means Intelligo's TRACKED ones, NOT your own advice: fetch them here FIRST, never infer from flag counts. Each carries `recommendation.reasons` (why) + `recommendation.triggeringFindingCount`. The raw triggering-finding ids are NOT returned (opaque internal ids, never for the user); to see the findings use the item's `link` or drill in via its `_id`. Scope with `profileId` (the profile's own id from getProfiles, NOT a report `searchId`) and/or `projectId`; omit both for the whole org. Narrow with `status`. Omit `types` for all kinds. MONITORING FLAGS: "are the monitoring flags handled / who resolved them?" -> `origins:["monitoring"]` + `types:["flag"]`, read `status`/`updatedBy`. `origins` matches the org's origin names case-insensitively; no match -> empty with valid `availableOrigins`. (For what is NEW this period use the monitoring FEED tool.) LINKS: ALWAYS render each item's `link` (verbatim) without being asked - it deep-links to the triggering finding, else its report tab, else the profile. DETAIL: a short page (<=5) gives each item its full `detail` (`detailIncluded:true`); otherwise drill in by passing the rows' `_id`s as `itemIds` (also for "tell me more / dive into these"). Tenant- and permission-scoped.

getActionItems

Find the people who work at a company, from Intelligo's data. Takes a company `id` (NOT a name), so results are ALWAYS scoped to exactly one company: FIRST call `getProfiles` with `profileType: "company"` to resolve the company and read its `id`, then pass that `id` here. Optional filters narrow the list: `role` (wildcard — "marketing" matches "Marketing Manager", "VP of Marketing"), `seniorities`, `departments`, and `locationCountry`. Returns matching employees with their role, seniority, departments, industries, location, and tenure dates. The company is validated against the dataset FIRST: when it is NOT in the dataset, `found` is false and `employees` is empty (meaning there is no data for it — NOT that nobody matched). NOTE: this LISTS people at a company; to resolve a single named subject (and learn whether the org already has reports on them) use `getProfiles`. Each employee carries a `linkedinUrl` (their LinkedIn profile; null when the source has none) and the response a top-level `companyLinkedinUrl`. RENDER these links in your answer (e.g. a LinkedIn column) for every employee you present, even when not asked — never just SAY that links exist.

getCompanyEmployees

Read Clarity's **monitoring feed** — the consolidated stream of new findings from ONGOING MONITORING of the org's subjects. Once a subject is placed under monitoring, Clarity keeps re-scanning sources and records each newly-detected material event as a *finding*. These findings are exactly what Clarity emails as monitoring **alerts**, so a user's "alerts" / "new alerts" means these feed items. This is the data behind Clarity's monitoring dashboard — the answer to "what has changed across my portfolio?". Use this tool for WHAT IS NEW / what changed in a window (time-scoped by when monitoring picked a finding up). It is NOT the place to reconcile flag STATUS: for whether monitoring flags are still OPEN or already HANDLED, who handled them and when, or an audit by status, use `getActionItems` with `types:["flag"]` and `origins:["monitoring"]`. Each finding is tied to a monitored subject (`profileId` + `profileDetails`) and carries its sources, first/last-seen dates, a match-confidence band, a review state, and `relatedFlags[]` (each with a numeric `level`, system- or analyst-added, enriched with the action items opened on it). All filters are optional and AND together; omit them all for a portfolio-wide feed (see each parameter). Paginate with `limit` (default 20) and `cursor` (page number as a string); findings are ordered newest-seen first. For subject-level questions ("which subjects are most flagged?"), read the feed and group findings by `profileId`/`profileDetails`. Tenant- and permission-scoped to the caller. Monitoring is an ongoing feed — NOT a static report. For a subject's produced reports use `getReportContent` / `exportPdf` instead. AFTER presenting findings you MAY OFFER to mark them reviewed via `updateMonitoringFindings` — that tool WRITES, so call it only once the user explicitly confirms WHICH findings, and pass all of the confirmed ones in a single call. Never mark a finding reviewed just because it was shown or discussed.

getMonitoringFeed

Resolve or list subjects (people or companies) for the calling org. THREE entry points, and they do NOT behave alike. (1) `linkedinUrl` — pass it VERBATIM whenever the user gives a LinkedIn URL, never drop it: resolves that ONE subject from public records by exact lookup, SKIPPING the account search (see that param for the follow-up). (2) `name_query` — searches the org's OWN Intelligo profiles FIRST (the dashboard list, tenant-scoped); ONLY if nothing matches does it fall back to public records. (3) Neither — lists the org's own profiles; paginate with `limit` + `cursor`. NO fallback in this mode: an empty filtered list is a real empty result. Read the top-level `source` to know which happened: "account" (the org's own profiles) vs "public_records" (third-party, NOT Intelligo data). ACCOUNT rows are returned verbatim from the profile aggregation (`profileId`, `title`, `subTitle`, `status`, `reports[]`, `monitoringCount`, `isMonitored`, …) and each also carries `inAccount`, `hasReports`/`reportCount`, a `profileLink`, and a `versionHistory[]`. PUBLIC_RECORDS rows carry the normalised subject fields with no `profileId`/`versionHistory`, plus a `linkedinUrl` source link; a **company** row carries an `id` — pass it to `getCompanyEmployees` to list that company's people. For a NEW background check this is step 1: resolve the subject here, feed `get_scoping_area` (company `id` → `primarySubjectId`, website → `primarySubjectWebsite`), then `get_scoping_profiles` → `compareCoverage` → `createNewSearch` (draft). `reports[]` is the LATEST report of each category; `versionHistory[]` is the full chronological list including superseded reports (`isOldVersion: true`). Each `reports[]`/`versionHistory[]` entry has a `searchId` (pass to `getReportContent`) and a direct `reportLink`. An `_id: "MONITORING"` entry is monitoring setup, not a report — exclude from counts, never read or export. Pick entries via `status`.

getProfiles