ContentIn for Agents

List people who engaged with the user's posts

list_leads

Read-onlyIdempotent

List the people who engaged with THIS user's own LinkedIn posts — their name, headline, LinkedIn profile, how they engaged, what they commented, which posts pulled them in, and ContentIn's ICP fit score. Use it to answer 'who is engaging with me', to find warm contacts, or to see which posts attract the right audience. REACTIONS ARE INCLUDED: a single like creates a lead, so a lead with no comments is completely normal and does not mean something is missing. ABOUT THE SCORE: icp_score is computed BY CONTENTIN, by comparing the person's LinkedIn headline against this user's stated ideal customer profile. It is an estimate from a headline, not verified data about who they are. classified: false with icp_score: null means ContentIn HAS NOT SCORED THIS LEAD YET — report it exactly that way. It does NOT mean the person is a poor fit; those are different claims and only one of them is supported. When icp_score_source is 'user_override' the number is the user's own labelling, not ContentIn's. Results are ordered by ContentIn's computed score when you sort by icp_score, so a lead the user has manually re-labelled keeps its computed position while reporting their number. Page with before/before_id; profiles routinely have thousands of leads. (Pro plan)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_leads"
  }
}

Input Schema

Name	Required	Description
`sort`	No	Ordering, always descending. Default 'last_interacted' (most recent engagement first).
`limit`	No	How many leads to return (1-100, default 50).
`before`	No	Paging cursor: pass back the next_before value from the previous response, VERBATIM, together with before_id. Do not build this yourself, and do not reuse a cursor across a different sort or filter set.
`search`	No	Free-text match against the lead's name and headline.
`status`	No	Filter by the user's lead funnel state. Default is everything EXCEPT 'dismissed' — the user already said no to those, so ask for them explicitly if you really need them.
`before_id`	No	Paging cursor: the next_before_id from the previous response, copied EXACTLY. It is an opaque token, not a lead id — do not construct, shorten or edit it, and do not reuse one from a query with a different sort. An invalid or stale token is rejected rather than answered, so if that happens just call the tool again with no paging values.
`min_icp_score`	No	Only leads scoring at least this (0-100). Applied to the user's override where they set one, otherwise to ContentIn's score. Leads that have not been scored yet are excluded by this filter.
`interacted_since`	No	ISO-8601 date. Only leads who engaged on or after this.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 11, 2026

changedInput schema / properties / before_id / description

Previous value: -"Paging cursor: the next_before_id from the previous response. Always send it alongside before, otherwise leads sharing a score or a timestamp can be skipped."New value: +"Paging cursor: the next_before_id from the previous response, copied EXACTLY. It is an opaque token, not a lead id — do not construct, shorten or edit it, and do not reuse one from a query with a different sort. An invalid or stale token is rejected rather than answered, so if that happens just call the tool again with no paging values."

AddedSep 24, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only annotations, the description discloses important behavior: reactions count as leads, commentless leads are normal, ICP scores are ContentIn estimates from headlines, unscored leads report classified false with null score, and user_override changes the meaning of the score. It also notes pagination behavior and expected volume ('thousands of leads'), which materially affects correct use.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the description is organized into useful behavioral caveats, especially around reactions and ICP scoring. It is somewhat long and repeats paging guidance already covered by the schema, but the length is mostly justified by the score and engagement nuances.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden and does so well: it explains the returned fields, normalizes commentless leads, clarifies score provenance and unscored behavior, and covers pagination and plan limitations. An agent has enough information to call and interpret this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics for the icp_score sort: results use ContentIn's computed score even when the displayed value is a user override. The paging and score caveats are useful, though most other parameter details are already fully documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: list people who engaged with THIS user's own LinkedIn posts. It enumerates the returned fields (name, headline, profile, engagement type, comments, posts, ICP fit score) and distinguishes this from broader post-listing siblings by emphasizing engagement with the user's posts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear when-to-use guidance: answer 'who is engaging with me', find warm contacts, or see which posts attract the right audience. It does not explicitly name an alternative tool or state when not to use this one, so it falls short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ContentIn for Agents tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.