Provides tools to retrieve public Instagram post metrics (views, likes, comments) and profile information (followers, following, posts, avatar) via the guest API.
Attempts to retrieve post metrics but currently returns a login_required status as Threads requires a logged-in session.
Allows fetching metrics (views, likes, comments) for public TikTok posts, with support for short links.
Enables retrieval of YouTube video metrics (views, likes, comments, publish date, title, author, thumbnail) and profile data (subscribers, following, posts, verified status).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pulse-mcp metrics for https://youtu.be/dQw4w9WgXcQ"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Pulse — a free, agent-first social-post metrics API. Give any MCP client (Claude Desktop, Cursor, …) the numbers behind any public post: hand it a URL, get back views, likes, comments, and the publish date as clean JSON. No signup, no API key.
{ "mcpServers": { "pulse": { "command": "npx", "args": ["-y", "pulse-mcp"] } } }That's it — drop it in your MCP config and your agent has five new tools.
Tool | Input | Output |
| one post URL (short links like |
|
| many URLs (mixed post + profile URLs welcome) | the same, one per URL (partial failures don't fail the batch) |
| one post or profile URL (+ optional | the recorded growth curve — |
| one profile URL | account-level metrics — |
| many profile URLs (max 50) | same as |
Example — ask your agent "how did this video do?" with a link, and it gets:
{
"platform": "youtube",
"views": 1781088936,
"likes": 19147197,
"comments": null,
"publishedAt": "2009-10-25T06:57:33.000Z",
"title": "Rick Astley - Never Gonna Give You Up (Official Video)"
}Related MCP server: meta-mcp
Platform | Returns | Notes |
YouTube | views, likes | |
X / Twitter | views, likes, comments, shares (retweets), quotes, bookmarks | views via X's own guest API (tweets since ~Dec 2022) |
TikTok | views, likes, comments, shares | |
Bluesky | likes, comments, shares (reposts), quotes | public AppView API; Bluesky has no view counts |
Mastodon | likes, boosts, replies | per-instance public REST API (major instances) |
views, likes, comments | public posts via the guest API | |
Threads | post metrics need a login | post metrics → |
— (posts need login) | post metrics → |
It reads each platform's own public pages from a residential IP, so it sees what a browser
sees — and it's honest about the edges: a deleted/private post comes back content_unavailable,
a login-walled one login_required, never a silent row of zeros.
Free — no account, no key, no wallet.
PULSE_API_URL — override the backend (defaults to https://pulse.walls.sh).
Built in public as Wall #002 of walls.sh. Docs: https://pulse.walls.sh/docs ·
machine-readable: /llms.txt · OpenAPI.
MIT.
Get the recorded metrics history of a post OR a profile — the growth curve. Every fresh metrics fetch records a { t, views, likes, comments, shares, quotes, bookmarks } snapshot (profiles: { t, followers, posts }); this returns the series (oldest first). Pass since (ISO-8601 or unix ms) to get only the points after that moment — poll the delta, not the whole series. An empty series means the URL hasn't been fetched yet: call metrics or profile on it to start the series.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The public post or profile URL. | |
| since | No | Optional — ISO-8601 date or unix milliseconds; only points after this moment are returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses return format (series with fields for posts and profiles), ordering, and behavior for unfetched URLs (empty series). It does not mention authentication or side effects, but it's a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct sentences: first states purpose and return, second explains 'since' parameter, third explains empty series case. Each sentence adds value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description explains the return format, the 'since' parameter usage, and the empty series behavior. This is sufficient for an agent to use the tool correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond: explains the 'since' parameter for delta polling, and hints at return fields. The URL parameter is described as public post or profile URL. This provides useful context for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the recorded metrics history of a post or profile, the growth curve, and specifies the return format (series of snapshots) and ordering (oldest first). It distinguishes from siblings by focusing on history vs. current metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: to get history, and when to use alternatives: call metrics or profile if the series is empty. It also explains the 'since' parameter to poll delta, avoiding fetching the whole series.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a public social post's metrics. Give a post URL (YouTube, X/Twitter incl. view counts, TikTok incl. photo posts, Bluesky, Mastodon (major instances), Instagram, Threads, LinkedIn — short links like vm.tiktok.com and t.co resolve automatically) and get normalized { platform, views, likes, comments, shares, quotes, bookmarks, publishedAt, title, author, thumbnail } — shares = reshares (X retweets, TikTok shares, Bluesky reposts); quotes = quote posts (X, Bluesky); bookmarks = saves (X). Free.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The public post URL (short links OK). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description covers behavioral traits: explains normalization of fields (shares, quotes, bookmarks), mentions it's free, and implies read-only access. Lacks details on rate limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph packed with information, no filler. Could benefit from bullet points for platforms or output fields, but remains clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description fully explains inputs, outputs, and supported platforms. Completeness is high, though including expected response format or error cases would elevate further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'url', schema describes it as 'The public post URL (short links OK).' Description adds meaning: resolves short links automatically and lists compatible platforms, exceeding the schema's coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a public social post's metrics' with a specific verb and resource, and lists supported platforms and output fields, distinguishing it from sibling tools like metrics_batch and profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: provide a post URL, short links resolve automatically, lists supported platforms. Implicitly distinguishes from batch tool, but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metrics for many posts and/or profiles in one call. Pass an array of URLs (max 50, mixed post and profile URLs welcome); returns { count, results }, order preserved — each result is the metrics object or { url, error }.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Public post URLs (max 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses max 50 items, mixed types allowed, order preservation, and response format including error handling. Lacks details on rate limits or authentication, but core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, efficient and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return structure despite no output schema, but could detail metrics object fields. Covers error responses. Parameter is well explained, though sibling contrasts are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds max 50 constraint and mixed types beyond schema description ('Public post URLs'). However, schema description contradicts tool description by only mentioning posts. This inconsistency reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get metrics for many posts and/or profiles in one call', distinguishing it from singular sibling tools like 'metrics' and 'profile_batch'. Specifies batch capability and return structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for batch operations with 'in one call' and 'max 50', but does not explicitly contrast with singular 'metrics' tool or specify when not to use it. No direct alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get account-level metrics for a profile URL — { platform, handle, name, followers, following, posts, likes, verified, avatar }. Live: YouTube channels (subscribers), TikTok users (exact counts + total hearts), Instagram accounts (exact counts), X accounts (followers/following/posts), Bluesky accounts (exact counts), Mastodon accounts (exact, major instances). Threads/LinkedIn profiles need a login.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The profile URL (e.g. youtube.com/@handle, tiktok.com/@user, instagram.com/user). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It mentions that some platforms require login and which have exact counts, but does not disclose rate limits, error handling, or side effects. The read-only nature is implied by 'Get...metrics'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose and fields, then platform-specific details. Every sentence adds value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is reasonably complete, covering returned fields and platform nuances. It omits potential error conditions (e.g., invalid URLs) but is adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'url' is fully described in the schema with examples. The tool description does not add additional semantics beyond what the schema provides, but the schema itself is adequate. Score at baseline given 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves account-level metrics for a profile URL and lists the returned fields. It does not explicitly differentiate from siblings like 'profile_batch' or 'metrics', but the purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides platform-specific usage notes (e.g., Threads/LinkedIn need login) but does not explicitly say when to use this tool over alternatives like 'profile_batch' or 'metrics'. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get account-level metrics for many profile URLs in one call — same as profile but up to 50 URLs at once. Mixed platforms welcome (YouTube, TikTok, Instagram, X, Bluesky, Mastodon). Returns { count, results }, order preserved — each result is a profile object or { url, error }. Useful for comparing follower counts across a list of creators/accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Profile URLs (max 50, mixed platforms OK). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses return structure ({ count, results }), order preservation, and error handling (profile object or { url, error }). However, it omits details on idempotency, rate limits, or side effects, which are needed for a batch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and key constraints. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return format and error behavior. With one well-documented parameter and low complexity, the description covers all necessary information for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'urls' with 100% description, specifying type, max items, and mixed platforms. The description reiterates this without adding new semantic meaning. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves account-level metrics for multiple profile URLs in one call, specifying it is like the 'profile' tool but supports up to 50 URLs. It lists compatible platforms (YouTube, TikTok, etc.), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contrasts with the sibling 'profile' tool by highlighting batch capability and mixed platforms. It provides a use case (comparing follower counts across creators), but does not explicitly mention when not to use this tool or how it differs from 'metrics_batch'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.11.0historymetricsmetrics_batchprofileprofile_batchScored across 5 tools
Each tool has a distinct purpose: single metrics vs historical series vs batch metrics vs single profile vs batch profile. No overlap in functionality.
Consistent noun naming for singletons (metrics, profile, history) and noun_batch for batch variants (metrics_batch, profile_batch). Clear and predictable pattern.
5 tools cover the core operations for social media metrics retrieval: single and batch for posts and profiles, plus history. Well-scoped without excess.
Covers essential retrieval operations, but lacks an explicit endpoint to list supported platforms or trigger a refresh. Minor gap for an otherwise complete surface.
Social media MCP server: your Instagram, TikTok, YouTube, LinkedIn and Threads history for your AI.
Hosted MCP for X/Twitter and Reddit. 12 read-only tools, no API keys, free during beta.
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
Free remote MCP server for fetching public web pages through a rotating proxy pool.
