Cornersight, inside your agent.

Tool catalog

The tools below are the ones worth knowing to get started. Unlike the CLI, the MCP server has no separate published reference — your MCP client's own tool list is the authoritative one, since it is read from the server when you connect. Each tool calls one endpoint in the API reference.

Like the API, job-creating tools return exactly { "jobId", "statusTool": "get_job_status" } — no job status and never the result. The job-status vocabulary (pending | running | completed | failed) appears only on get_job_status responses, which is also the only place the result is available — even for the “immediate” engagement tools, always read it. The agent handles the polling loop for you.

Every array in an MCP response is cut to its first 10 entries — on every tool, not just the job ones — and resultTruncated is then true. This is an MCP-only limit that keeps a tool result from flooding the agent's context; the CLI and the REST API return the whole array. Every tool can reach the rest; what changes is the argument that gets you there.

list_sources, get_credits_usage and get_api_keys page the same way: pass rowOffset and follow resultWindow.nextRowOffset until it is null. Their filters — type, includeInactive, from/to — change which entries match rather than moving the window, and includeInactive makes the list longer. Where a response carries two arrays, one cursor drives both: an array short enough to fit the cap is returned whole in every window and marked windowed: false, so it is complete already and must not be summed once per page.

The spend has to be confirmed by the person, and the threshold is every create. There is no credit figure below which it is skipped, because what is being authorised is a commitment rather than an amount: track_keyword takes three scope fields — creditCap, captureMode, datePosted, the same three the dashboard gates behind its “Search scope” step — plus confirmSpend: true. The same rule applies on a resume (keywords matching an existing search re-cap that search) and on any update that raises what a day can cost. Without the confirmation the call is refused 409 spend_confirmation_required, and the refusal is the useful part: its body carries creditCap, captureMode, datePosted, estimatedDailyMax, remainingBalance and daysToExhaustAtCap. Show those numbers to the person and wait for an answer before retrying, then re-send the identical call with the confirmation added — never a smaller cap to make the refusal go away. A missing scope field is refused earlier, as 400 scope_required, whose field names which one and whose message states the exact JSON to add.

The tool's required list tells an agent which phase the contract is in. A required field in an MCP schema is enforced by the client, before the call is made — so during the roll-out's warning phase the four read as optional and the obligation lives in the descriptions instead, which keeps an old-style call reaching the server that can warn it: it still returns 201, now with a deprecations array naming what to add and the cut-over date. Relay that rather than discarding it. From the cut-over the same four are required in the schema and refused by the endpoint. An agent can move early on its own by sending contractVersion: "2026-11-01".

The cut-over is scheduled for 2026-11-01, and this is the notice of it. Until 2026-11-01 an old-style create — one that omits the three scope fields and confirmSpend — still returns 201/200 and carries a deprecations entry naming exactly what to add. From 2026-11-01 the same request is refused: a missing scope field is 400 scope_required naming the field, and a scope that is stated but not confirmed is 409 spend_confirmation_required — the same refusal a request pinned to contractVersion: "2026-11-01" already gets today, which is how an agent tests the new behaviour before the date. The exact change is four arguments: creditCap: 100, captureMode: "depth", datePosted: "PAST_WEEK", confirmSpend: true. Those three values are what the dashboard's “Search scope” step pre-fills, offered so they can be copied deliberately — they are not server-side defaults and nothing is chosen for the caller, so send the caps the person actually wants, and send confirmSpend only once they have heard the daily figure. The version string and the cut-over date are the same day, which they did not have to be: the version is what you pin, the date is what happens to you if you do not.

track_keyword creates a standing daily charge, and its reply says how big. Both the create and the resume carry estimatedDailyMax — the most one day of that search can cost in enriching credits, the same number the dashboard shows above its Confirm button — and daysToExhaustAtCap, the whole days the team's remaining balance funds at that rate. Relay the daily figure to the person who asked, before or as the search is created. The first sweep starts within seconds and charges, so an agent that waits until afterwards is reporting a bill rather than a price, and this tool has no confirmation step to fall back on. daysToExhaustAtCap: 0 is the warning and not the all-clear: the balance cannot fund one whole day at that cap, so the sweep just queued is the one that gets cut short. Both keys are omitted, never null and never 0, when there is no honest number — no usable creditCap, or a balance that could not be read — so test whether the key is present rather than reading a value out of it. list_sources reports the same two inside a keyword source's config.

Raw leads are read with their own tool. A source created or updated with enrichLeads: false keeps its leads raw: captured and charged exactly as before, one credit per new person per source, but never enriched. list_raw_leads is the only tool that returns them — list_leads and list_engagers never do — and it pages like list_leads. The switch needs no confirmSpend and applies to leads captured after it; on a raw source, the sync status's enrichment.completed counts the leads captured raw.

list_sources includes keyword availability in lastRun.postsAvailable (approximate provider total, which may double-count posts) and lastRun.caughtUp (whether every term returned only previously swept posts). Both are omitted for unmeasured runs.

For job results, page with rowOffset on get_job_status: resultWindow reports { rowOffset, rowsReturned, rowsInPage, nextRowOffset }, and you pass nextRowOffset back until it comes back null. It re-reads the result the job already stored, so it costs no LinkedIn call and no credits. Only then raise page on the reactions/comments tools — that one advances the provider by a whole page of 50. Stop on nextRowOffset: null, not on resultTruncated, which describes only the response in your hand.

Discover Influencers

Discover Influencers is a one-off search for the people who post about a topic and get engagement on it. Each person found is added as an Author lead and appears in Influencer Leads in the dashboard. Four tools cover it: discover_influencers starts a run, list_discover_runs lists them, get_discover_run reads one with its influencers, and delete_discover_run removes one. They call POST/GET /api/v1/discover and GET/DELETE /api/v1/discover/{id}; the full rules are under Discover Influencers.

• Topic: 1-10 keywords, and a post matching any of them counts (no AND/NOT). Each keyword is a separate LinkedIn search.
• Window: always the past month, sorted by relevance, so posts come from across the month; roughly 250-700 posts are read per keyword.
• Engagement: likes (all reactions) + comments per post; reposts and views are not counted. minEngagement applies to a person's average across their matching posts (usually one post). highestEngagement is their best post, which Influencer Leads ranks by.
• People only: company pages are skipped. At most maxInfluencers (1-500) are added, highest averages first; qualified above found means more qualified than the limit allowed.
• Countries: optional, up to 20. Only people whose LinkedIn profile is in one of them are added; short forms like UK, USA and UAE work, and a person with no country on their profile is left out. Profiles are looked up before anyone is added, at most min(500, max(100, 5 × maxInfluencers)) per run, at no cost.
• Credits: 1 per influencer added, once. Reading posts and country lookups are free.
• Lifecycle: running, then done or failed, usually within a few minutes. Job title, company and country are null until enrichment fills them shortly after capture. Deleting keeps the Author leads already added.

Never send confirmSpend on the first call. Without it the tool answers with a spend_confirmation_required error whose details.estimatedCredits is the most the run can cost. The agent says that figure, waits for a yes, then repeats the call with confirmSpend: true, the same rule as track_keyword.

// 1. discover_influencers (no confirmSpend) → error 409
{ "keywords": ["claude code", "ai agents"], "minEngagement": 50, "maxInfluencers": 25, "countries": ["UK"] }
→ { "statusCode": 409, "error": "This run can use up to 25 credits: ...",
    "details": { "error": "...", "code": "spend_confirmation_required", "estimatedCredits": 25 } }

// 2. the person agrees; the same call with "confirmSpend": true → the run
→ { "id": "7c9e6679-7425-40de-944b-e07fc1f90ae7", "state": "running", "countries": ["United Kingdom"], "found": 0, ... }

// 3. list_discover_runs {} → { "runs": [{ "id": "7c9e6679-...", "state": "done", "qualified": 31, "found": 25, ... }], "total": 1 }

// 4. get_discover_run { "id": "7c9e6679-..." }
→ { "run": { ... }, "influencers": [{ "name": "Jane Doe", "linkedinUrl": "https://www.linkedin.com/in/jane-doe",
     "jobTitle": "Founder", "company": "Acme", "country": "United Kingdom", "highestEngagement": 412,
     "avgEngagement": 268.5, "postCount": 2, "topPostUrl": "https://www.linkedin.com/feed/update/urn:li:activity:7381234567890123456/" }] }

// 5. delete_discover_run { "id": "7c9e6679-..." } → { "ok": true, "id": "7c9e6679-...", "deleted": true }

Find people in the UK who post about Claude Code and average at least 50 likes and comments. Up to 25 of them. Tell me the cost first.

MCP vs. the CLI and the REST API

The three surfaces reach the same endpoints and return the same fields. They differ in how many rows you get back, and in one case in what is available at all. The CLI and REST columns are identical throughout — the CLI is a thin client over the same API — so every difference below is something MCP does and they do not.

The three tools with no paging control are the ones to watch: list_sources, get_credits_usage and get_api_keys have filters but no argument that moves a window, so a team with more than ten sources, or spend on more than ten days, cannot see the rest of them over MCP. resultTruncated tells you it happened. Use the CLI or the REST API when you need the whole list — and note that the totals alongside those arrays (totalCharged, the key quota) are computed before truncation and stay correct, so never re-derive a total by summing the rows you were shown.

Connect a client

Add this server URL to your client. Nothing else is required — the client opens a Cornersight sign-in the first time it connects.

https://mcp.cornersight.io/mcp

Sign in (Claude, ChatGPT and other connector UIs)

1. Open your client's connector settings (Claude → Settings → Connectors, ChatGPT → Connectors).
2. Click Add custom connector, name it Cornersight and paste the URL above. Leave the OAuth client ID and secret fields empty.
3. Click Connect. Sign in to Cornersight, choose the team the connection should act on, and click Allow.

Only owners and members who can make changes can authorise a connection. You can switch team later by connecting again and choosing a different one.

API key in a header (Claude Code, Cursor, scripts)

Clients that let you set request headers can skip the sign-in and use an API key instead. Generate one in Cornersight → Settings → API key (it starts with cs_) and send it with the same URL. Either spelling below works — use whichever field your client exposes.

https://mcp.cornersight.io/mcp

X-API-Key: cs_your_key_here
# ...or, equivalently:
Authorization: Bearer cs_your_key_here

Keep the key in a header rather than in the URL. A URL travels through places a header does not — proxy and server access logs, browser history, and Referer headers — and each of those is a copy of a live credential you cannot retract.

Clients that take a URL and cannot sign in

If your client supports neither sign-in nor headers, put the key in the path instead — it authenticates identically. Treat the whole URL as a secret.

https://mcp.cornersight.io/mcp/YOUR_API_KEY

A key identifies your team, so a key connection acts on whichever team owns it.

Example prompts

Track the LinkedIn profile "demo-profile" and show me the enrichment result.

Get the reactions on post urn:li:activity:1234567890 and list the companies.

The agent calls the matching tool, waits for the job, and returns the data — you never touch the REST endpoints yourself.