LinkIntel

Store public reference posts as evidence under a topic and a named comparison cohort, so prepare_content_brief can use them. Only the "x" platform is supported for reference import today. Reads only the URLs supplied. It never searches the platform, connects an account, collects the user's own analytics, or publishes anything.

add_references

Look up a public X account's most recent original posts (replies and reposts excluded) and return their URLs, dates and short previews for the user to review. This draws on the same daily read budget add_references uses, and stores nothing: it never writes a reference, so it can be called freely to explore before anything is added. Only the "x" platform is supported today.

find_account_posts

Report LinkIntel readiness per capability: metric freshness, registered and measured post counts, connected corpus sources, owned-X connection status, LinkedIn connection status, remaining reference lookups, token expiry and today's API budget. The top-level connected field reports MCP connection status. Use linkedin_connected for LinkedIn readiness and the ready object to check specific capabilities. Call this before the first analysis and whenever a number looks wrong or surprisingly low.

get_data_status

The tool for questions about the user's own X posts: 'how did my posts do', 'what was my best post', 'which posts got the most engagement'. Returns, per post, impressions, likes, replies, reposts, quotes and bookmarks, plus the owner's non-public and organic metrics where available, read from stored, profile-scoped snapshots of the connected account. Covers recent original posts only, not replies or reposts. Use sort_by to rank the returned posts by recency, impressions, total engagement, or engagement rate. It never searches the platform, imports posts, makes a live platform request, or predicts reach.

get_owned_performance

Return X's published default ranking weights (what helps and what hurts, each with the commit link), the material weight changes from the last 14 days, and how to use them when drafting or reviewing a post. Reads stored data only and costs nothing: it never fetches X or GitHub live, and the values are defaults mirrored from X's open-source repo, synced daily. It describes what X's published ranking defaults reward in aggregate, not a reach prediction for any post. Use the signals as a final check that never overrides the evidence or the creator's voice. Only "x" has a readable source; other platforms return available: false.

get_platform_signals

List the stored reference topics and cohorts for this account, with which platform and how many posts each holds. Call this before prepare_content_brief so the topic and cohort are the exact stored labels rather than a guess, before add_references so a near-duplicate label is not created, and before remove_references (with include_posts) to see exactly which posts a removal would affect. Reads stored data only and costs nothing.

list_references

Prepare a stored-data writing brief for a topic and an explicitly named public X reference cohort. Costs nothing and never fetches: it reads references already stored by add_references, so call list_references first to use the exact stored labels. platform picks whose owned evidence the brief reads, because a post's length and structure do not transfer between platforms: "x" (the default) reads the creator's most recent stored X posts, which are not filtered to the topic, so the response asks the agent to read the excerpts and judge relevance itself; "linkedin" reads the creator's historical LinkedIn posts already tagged with this topic. The reference cohort is always public X posts, and the response says so plainly when platform is "linkedin" so that evidence is never mistaken for a same-platform comparison. Neither a LinkedIn connection nor a live platform fetch is required for cached references. Never searches X or predicts reach.

prepare_content_brief

Remove stored reference posts: specific posts by URL, or a whole topic and cohort group. Removing shapes every brief prepare_content_brief builds from what remains, so confirm the exact posts or group with the user first; call list_references with include_posts to show exactly what is stored before removing any of it. Prefer removing specific posts over a whole group where the user only meant to drop a few. Supply urls (optionally narrowed by topic and/or cohort) to remove those specific posts, or topic and cohort together with no urls to remove a whole group. It never searches or reaches any platform: it only deletes rows already stored by add_references.

remove_references