Skip to main content
Glama
Sign In

ContentIn for Agents

by io.contentin
OverviewDiscussionsAdmin

List comments the user left on other posts

list_my_comments
Read-onlyIdempotent

List the comments this user has left on OTHER people's LinkedIn posts, newest first, with the comment urn and a direct link to each one. Use it to review their commenting activity, to find a conversation they joined, or to hand the identifiers to another tool. HOW THIS DATA IS COLLECTED, and what you must not claim because of it: ContentIn reads these comments from a scrape that runs ONCE A DAY, so a comment can be up to 24 hours old before it appears here, and the scrape can miss one. History starts when this profile became a paying ContentIn account with a LinkedIn URL on file — there is nothing from before that. So if a comment the user is sure about is not in the list, say that ContentIn has not picked it up yet; do NOT tell them they did not write it. REACTOR IDENTITIES ARE NOT AVAILABLE. ContentIn stores how many likes and replies each comment got, never WHO liked or replied. If you are asked who engaged with a comment, say that ContentIn only has the counts — do not guess at names. Thousands of rows are normal, so page with before/before_id rather than asking for everything. (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_my_comments"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoISO-8601 date. Only comments written on or before this.
fromNoISO-8601 date. Only comments written on or after this.
limitNoHow many comments to return (1-100, default 50).
beforeNoPaging 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 from a different query — it is only valid for the same filters and sort.
searchNoFree-text match against the comment text and the excerpt of the post it was left on.
before_idNoPaging cursor: the next_before_id from the previous response. Always send it alongside before, otherwise comments written in the same second can be skipped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations to disclose data provenance that materially changes how results should be interpreted: a once-daily scrape (up to 24h lag, possible misses), a history floor tied to paid-account activation, absence of reactor identities (counts only, never who), and Pro-plan gating. It even prescribes the correct wording when a comment is absent, which is unusually valuable for an agent reporting to a user.

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?

Purpose is front-loaded in the first sentence and the remaining caveats are grouped under clear headings. It runs long with heavy ALL-CAPS emphasis ("REACTOR IDENTITIES ARE NOT AVAILABLE", "ONCE A DAY"), which is dense but each block conveys a distinct constraint that would otherwise cause a wrong answer.

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

Completeness4/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 does the necessary work of saying what a row contains (comment urn, direct link) and what is not stored (reactor identities) while pointing at the stored like/reply counts. It never explicitly states that the response carries the next_before/next_before_id cursor values the paging params depend on, leaving that inference to the schema text.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter (from/to, limit, search, before/before_id) is already fully explained in structured data. The description only reinforces the paging advice by noting that thousands of rows are normal; it adds no new meaning about date formats, matching behavior, or cursor construction. Baseline 3 applies where the schema carries the weight.

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?

States a specific verb and resource ("List the comments this user has left") with an explicit scope qualifier ("on OTHER people's LinkedIn posts") and a sort order (newest first). It also names what comes back (comment urn, direct link), so an agent can separate this from list_posts or any post-analytics sibling without opening the schema.

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?

Gives three concrete use cases: reviewing commenting activity, finding a conversation joined, and handing identifiers to another tool. It also sets an operational rule (page with before/before_id rather than requesting everything) and a fallback behavior when a comment is missing. It stops short of explicitly naming an alternative sibling for the "filter differently" case, so it is not a full when/when-not map.

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 toolsInspect
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.

Resources