compareCoverage
ChatGPTDiscover the report levels a client organization has and compare what each one covers, to understand the differences between levels and choose the right level for a use case. Report levels (tiers of background-check depth) and their coverage are custom per organization — never assume a fixed catalog; always discover first. Two-step usage: (1) call with NO levelIds to list the org's available report levels (each with id and name) and the coverage groups (report sections such as LEGAL, REGULATORY, KEY_PEOPLE). (2) call again with levelIds set to a subset of those ids to get a coverage matrix: every coverage item, grouped by section, with a per-level isCovered/isAvailable flag plus the item description and limitations. Use differencesOnly:true to return only items whose coverage differs across the chosen levels (the quickest way to see what a higher level adds). Optional groups restricts to specific sections. Because coverage varies by jurisdiction, levels are compared within a SINGLE jurisdiction (mirroring the UI): pass jurisdictionId to choose one, or omit it to use the org's default jurisdiction — the one actually used is echoed back as jurisdiction. Discovery mode also lists the org's jurisdictions. Coverage is computed for a PERSON subject by default; set entityType:"COMPANY" for company reports (coverage differs by entity type). Coverage reflects what a level includes, not findings for any individual subject.
compareCoverage
ChatGPTDiscover the report levels a client organization has and compare what each one covers, to understand the differences between levels and choose the right level for a use case. Report levels (tiers of background-check depth) and their coverage are custom per organization — never assume a fixed catalog; always discover first. Two-step usage: (1) call with NO levelIds to list the org's available report levels (each with id and name) and the coverage groups (report sections such as LEGAL, REGULATORY, KEY_PEOPLE). (2) call again with levelIds set to a subset of those ids to get a coverage matrix: every coverage item, grouped by section, with a per-level isCovered/isAvailable flag plus the item description and limitations. Use differencesOnly:true to return only items whose coverage differs across the chosen levels (the quickest way to see what a higher level adds). Optional groups restricts to specific sections. Because coverage varies by jurisdiction, levels are compared within a SINGLE jurisdiction (mirroring the UI): pass jurisdictionId to choose one, or omit it to use the org's default jurisdiction — the one actually used is echoed back as jurisdiction. Discovery mode also lists the org's jurisdictions. Coverage is computed for a PERSON subject by default; set entityType:"COMPANY" for company reports (coverage differs by entity type). Coverage reflects what a level includes, not findings for any individual subject.
exportActionItems
ChatGPTExport 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
ChatGPTExport 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.
exportPdf
ChatGPTGenerate a PDF export for Clarity 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.
exportPdf
ChatGPTGenerate a PDF export for Clarity 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).
getActionItems
ChatGPTList action items - tracked follow-ups Clarity 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' _ids as itemIds (also for "tell me more / dive into these"). Tenant- and permission-scoped.
getActionItems
ChatGPTList action items - tracked follow-ups Clarity 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' _ids as itemIds (also for "tell me more / dive into these"). Tenant- and permission-scoped.
getCompanyEmployees
ChatGPTFind 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.
getCompanyEmployees
ChatGPTFind 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.
getMonitoringFeed
ChatGPTRead 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. 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 source(s), the dates it was first/last seen, a match-confidence band, a per-finding review state, and relatedFlags[] (each flag has a numeric level, is system- or analyst-added, and is enriched with the action items opened on it and their status). 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.
getMonitoringFeed
ChatGPTRead 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. 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 source(s), the dates it was first/last seen, a match-confidence band, a per-finding review state, and relatedFlags[] (each flag has a numeric level, is system- or analyst-added, and is enriched with the action items opened on it and their status). 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.
getProfiles
ChatGPTList or resolve subjects (people or companies) for the calling org. FIRST searches the org's OWN Clarity profiles, tenant-scoped (the data behind Clarity's main dashboard list). A profile is the top-level entity Clarity maintains per subject — a person or company — that aggregates everything known about that subject across all of its reports and stays current as reports are added, refreshed, upgraded, or monitored. Each row carries a reports[] array: a report is one produced report at a given report level (type), and a single profile may hold several report levels plus refreshed/upgraded versions of the same report — the profile rolls them all up into aggregate fields such as flag/result counts, monitoring state, latest identification date, and workflow status. name_query is an OPTIONAL free-text token-prefix filter over subject names (the same matcher the dashboard search box uses); OMIT it to list all profiles in the org. Paginate the account list with limit and cursor (page number as a string). If name_query is given but matches NO profile in the account, the tool resolves the subject from Intelligo's wider data instead, so the caller still gets a result. The top-level source reports which happened — "account" (the org's own profiles) vs "intelligo_data" (resolved from Intelligo's data, NOT in the account). EACH returned profile carries inAccount, plus hasReports/reportCount — whether Clarity already holds BACKGROUND REPORTS on the subject (derived from its report version history; an empty history means none). profileType (person|company, default person) only affects resolution from Intelligo's data (which currently supports people only); the optional firstName/lastName/jobTitle/company hints help pinpoint the subject there. Account rows are returned verbatim from the profile aggregation (profileId, title, subTitle, status, reports[], monitoringCount, isMonitored, …) — not a flattened shape. Every account profile ALSO carries a versionHistory[] array — the complete chronological list of that subject's reports. Whereas reports[] shows only the LATEST published report of each category, versionHistory[] ALSO includes older, superseded reports (flagged isOldVersion: true). An old version almost always means the client refreshed the subject (re-ran the same report level later) or upgraded it to a higher report level — tell the two apart via each entry's scrapingPackageName (the level/tier, e.g. Advantage - Level 1 vs Advantage - Level 3), since isOldVersion alone does NOT encode refresh-vs-upgrade. Each entry's searchId joins back to a reports[].searchId and can be passed to getReportContent, so a skill can read both an old and the current report to compare a refresh.
getProfiles
ChatGPTList or resolve subjects (people or companies) for the calling org. FIRST searches the org's OWN Clarity profiles (the data behind Clarity's dashboard list), tenant-scoped; if name_query is given but matches NO account profile, the subject is resolved from Intelligo's wider data instead so the caller still gets a result. Omit name_query to list all profiles in the org; paginate with limit + cursor. Read the top-level source to know which happened: "account" (the org's own profiles) vs "intelligo_data" (resolved from Intelligo's data, NOT in the account). 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[]. INTELLIGO_DATA rows carry the normalised subject fields with no profileId/versionHistory; a company row carries an id — pass it to getCompanyEmployees to list that company's people. reports[] is the LATEST report of each category; versionHistory[] is the full chronological list including superseded reports (isOldVersion: true). An old version usually means the subject was refreshed (same level re-run later) or upgraded (moved to a higher level) — tell them apart via each entry's scrapingPackageName (the tier), since isOldVersion alone does not encode which. Each reports[]/versionHistory[] entry has a searchId (pass to getReportContent) and a direct reportLink.
getProjects
ChatGPTBrowse Clarity projects — a project is a named aggregation of profiles. Two modes: • Omit `projectId` → list projects. Returns { projects: [...] }, the calling user's accessible projects (name, timestamps, labels, collaborators, and a flag/profile-count summary). Optionally narrow with name (case-insensitive substring) and page with limit/cursor. This is the correct way to answer "show my projects". • Provide `projectId` → one project in full. Returns the project's metadata, rollup counts, permissions, feed notifications, and profiles[] — verbatim profile rows whose reports[] searchId chains into getReportContent. Tenant- and permission-scoped to the caller.
getProjects
ChatGPTBrowse Clarity projects — a project is a named aggregation of profiles. Two modes: • Omit `projectId` → list projects. Returns { projects: [...] }, the calling user's accessible projects (name, timestamps, labels, collaborators, and a flag/profile-count summary). Optionally narrow with name (case-insensitive substring) and page with limit/cursor. This is the correct way to answer "show my projects". • Provide `projectId` → one project in full. Returns the project's metadata, rollup counts, permissions, feed notifications, and profiles[] — verbatim profile rows whose reports[] searchId chains into getReportContent. Tenant- and permission-scoped to the caller.
getReportContent
ChatGPTRead a Clarity report's content as the client sees it rendered in the UI, returned as structured JSON per tab. A report is identified by its searchId — obtain it from getProfiles first: each profile's reports[] array carries the searchId of every report level it holds. Two-step usage: (1) call with ONLY searchId to discover the report — returns metadata plus the list of available tab names (e.g. EXECUTIVE_SUMMARY, LEGAL, KEY_PEOPLE). (2) call again with tabs set to the subset you want; each requested tab is rendered live and returned as structured JSON (sections → tables / lists / key-values / text). Each returned item carries an id (its data-item-id) — pass those ids to the getSources tool to retrieve the sources (publishers + links) behind the item. Rendering is slower than a plain data read, so request only the tabs you need (max 10 per call). Unknown tab names are rejected with the available list; a per-tab render failure is reported in an errors[] array rather than failing the whole call. PDF-only reports are handled automatically: the tabs param is ignored and the call returns the report's extracted PDF text (as a PDF_REPORT tab) plus the structured EXECUTIVE_SUMMARY tab.
getReportContent
ChatGPTRead a Clarity report's content. A report is identified by its searchId — get it from getProfiles (each profile's reports[] carries the searchId of every level it holds). THREE modes: (1) DISCOVER — call with only searchId: returns report metadata plus the available tab names (e.g. EXECUTIVE_SUMMARY, LEGAL, KEY_PEOPLE), and a light actionItems list (all kinds: flags, review, refresh/upgrade/add_monitoring) for the subject — type/status/name + link; full enriched detail via the getActionItems tool. (2) TAB SUMMARIES — call with tabs (max 10): each tab returns {type, counts, breakdown, items[]}, a FLAT item list — each item carries its uuid, title, flagLevel + flagSeverity, confidence ('1'-'4'), flags (with any action-item status), inline sources, notes, comments, dates, and its cleaned data inlined. FLAG SEVERITY: flag levels 1-2 = red, 3 = yellow, 4 = info (blue) — an info flag is informational only, NOT a risk, and does NOT make a profile "flagged" (only red/yellow count). The whole response is size-capped (~44k chars): an item that did not fit ships with dataTruncated: true (identity + categorical signal only) — fetch it in full via mode 3. For TOTALS always use the never-truncated breakdown; never tally items[], which may be degraded. (3) DRILL-IN — call with itemIds (1-50 uuids taken from summary items; tabs is ignored when present): returns each item's full stored record. Use it for items flagged dataTruncated: true. Ids that exist but did not fit the cap come back in omittedItemIds — re-request those in smaller batches. Every response carries a top-level reportLink (the Clarity portal URL). Do NOT call this for the monitoring entry (a reports[] entry with _id: "MONITORING"): it is an internal monitoring-setup search with no readable report — read monitoring with getMonitoringFeed instead.
getSources
ChatGPTRetrieve the underlying sources behind report items — the publishers and links each item's data was drawn from. Item ids come from getReportContent: every rendered item carries an id (its data-item-id). Pass one id to cite a single item, several ids for a few items, or every item's id from a tab/report to cite the whole thing. Returns, per item, a list of sources where name is the source/publisher and urls are its links. Item ids that don't exist, or that belong to a report the caller is not authorized to read, are returned in notFoundItemIds.
semanticSearch
ChatGPTSearch the org's due-diligence reports by MEANING — the ENTRY POINT when you don't yet know which subject or report to look in. Pass ONE concrete topic (e.g. "financial fraud", "sanctions or PEP exposure", "violent crime arrests"). When the question points at a report area, also set sections to rank that tab higher (e.g. court cases → ["LEGAL"], adverse media → ["NEWS"], sanctions/PEP → ["REGULATORY"]). Returns matched reports best-first, each with searchId, profileId, bestSimilarity (0–1), and sections → passages: the VERBATIM report text that matched, with a per-passage similarity. The passages ARE the evidence — read them to answer; you usually do NOT need to re-open the report. NEXT STEP: act on the searchIds returned HERE. To read more of a specific hit, call getReportContent with THAT searchId directly — it already is the report id, so do NOT call getProfiles to look it up and do NOT list profiles. Use getProfiles(profileId) only to view the whole subject. total = how many matched; if it exceeds the number returned, tell the user and raise limit or narrow the topic. Auto-scoped to your org. LIMITS: vague/multi-topic phrases ("red flags", "anything concerning") retrieve poorly — for a broad ask, run a few concrete topics and merge. Hits are topical CANDIDATES, not confirmed findings: a high score on a screening section (sanctions, PEP, watchlist) usually means the report HAS that section, not that the subject is flagged — confirm the actual finding in the passage text. It IGNORES query constraints (dates, locations, counts, exact names, AND/OR) and cannot count, enumerate, compare, or prove absence; no hits ≠ absence. For an exact name or case number, prefer getProfiles.
semanticSearch
ChatGPTSearch the org's due-diligence reports by MEANING — the ENTRY POINT when you don't yet know which subject or report to look in. Pass ONE concrete topic (e.g. "financial fraud", "sanctions or PEP exposure", "violent crime arrests"). When the question points at a report area, also set sections to rank that tab higher (e.g. court cases → ["LEGAL"], adverse media → ["NEWS"], sanctions/PEP → ["REGULATORY"]). Returns matched reports best-first, each with searchId, profileId, bestSimilarity (0–1), and sections → passages: the VERBATIM report text that matched, with a per-passage similarity. The passages ARE the evidence — read them to answer; you usually do NOT need to re-open the report. NEXT STEP: act on the searchIds returned HERE. To read more of a specific hit, call getReportContent with THAT searchId directly — it already is the report id, so do NOT call getProfiles to look it up and do NOT list profiles. Use getProfiles(profileId) only to view the whole subject. total = how many matched; if it exceeds the number returned, tell the user and raise limit or narrow the topic. Auto-scoped to your org. LIMITS: vague/multi-topic phrases ("red flags", "anything concerning") retrieve poorly — for a broad ask, run a few concrete topics and merge. Hits are topical CANDIDATES, not confirmed findings: a high score on a screening section (sanctions, PEP, watchlist) usually means the report HAS that section, not that the subject is flagged — confirm the actual finding in the passage text. It IGNORES query constraints (dates, locations, counts, exact names, AND/OR) and cannot count, enumerate, compare, or prove absence; no hits ≠ absence. For an exact name or case number, prefer getProfiles.
submitMcpFeedback
ChatGPTSubmit feedback about THIS MCP server's own tools, so the Intelligo team can improve them. Intelligo Clarity's first MCP server - capturing tool feedback is high value. WHEN to call (any of these): - a tool returned an error, or wrong / irrelevant results; - the user is frustrated or confused, or repeats a request that just failed; - the user praises or criticises a tool, or wishes one existed ("I wish there was a tool for X"); - you are about to report a task complete and a tool got in the way. VALID feedback targets THIS server's tools, e.g. "semanticSearch returned irrelevant passages", "I wish there was a tool to list monitoring subjects". INVALID - do NOT submit: complaints about the report DATA / findings, the AI model itself, or the IDE / client. Only feedback about THIS server's tools. source="user": the feedback is the human's - quote their exact words in quote. source="agent": you (the agent) observed a tool misbehave - put your own one-line observation in quote. PRIVACY: never put report content, a subject's name, or any personal data in quote or context. Describe the TASK TYPE ("running a due-diligence report"), not who it concerns. Feedback is stored by Intelligo for product improvement only. Call at most once per distinct issue; never re-submit something already reported this session.
submitMcpFeedback
ChatGPTSubmit feedback about THIS MCP server's own tools, so the Intelligo team can improve them. Intelligo Clarity's first MCP server - capturing tool feedback is high value. WHEN to call (any of these): - a tool returned an error, or wrong / irrelevant results; - the user is frustrated or confused, or repeats a request that just failed; - the user praises or criticises a tool, or wishes one existed ("I wish there was a tool for X"); - you are about to report a task complete and a tool got in the way. VALID feedback targets THIS server's tools, e.g. "semanticSearch returned irrelevant passages", "I wish there was a tool to list monitoring subjects". INVALID - do NOT submit: complaints about the report DATA / findings, the AI model itself, or the IDE / client. Only feedback about THIS server's tools. source="user": the feedback is the human's - quote their exact words in quote. source="agent": you (the agent) observed a tool misbehave - put your own one-line observation in quote. PRIVACY: never put report content, a subject's name, or any personal data in quote or context. Describe the TASK TYPE ("running a due-diligence report"), not who it concerns. Feedback is stored by Intelligo for product improvement only. Call at most once per distinct issue; never re-submit something already reported this session.
