Allows scheduling and analytics for Bluesky posts via Metricool.
Allows scheduling and analytics for Facebook posts via Metricool.
Allows scheduling and analytics for Instagram posts via Metricool.
Allows scheduling and analytics for Threads posts via Metricool.
Allows scheduling and analytics for TikTok posts via Metricool.
Allows scheduling and analytics for YouTube posts via Metricool.
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., "@mcp-metricool Schedule a tweet for tomorrow at 9 AM about our new product."
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.
An MCP server for builders who want to schedule posts, check analytics and find the best posting times in Metricool from an MCP client.
MCP server for Metricool — schedule social media posts, get analytics, and find optimal posting times.
Get started · Tools · Environment variables · Report an issue
Tool | Description |
| List all connected brands/accounts |
| Schedule a post (LinkedIn, Instagram, Facebook, etc.) |
| View pending scheduled posts |
| Get post performance metrics |
| Find optimal posting times based on engagement |
Related MCP server: meta-mcp
npm install
npm run buildMETRICOOL_TOKEN=your-api-token
METRICOOL_USER_ID=your-user-idGet your API token from: Metricool → Settings → API
{
"mcpServers": {
"metricool": {
"command": "node",
"args": ["path/to/mcp-metricool/dist/index.js"],
"env": {
"METRICOOL_TOKEN": "your-token",
"METRICOOL_USER_ID": "your-user-id"
}
}
}
}LinkedIn, Twitter/X, Facebook, Instagram, YouTube, TikTok, Threads, Bluesky — depends on what's connected in your Metricool account.
MIT. Built by Dojo Coding.
Get LinkedIn post performance metrics from Metricool. Returns impressions, engagements, top posts, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| brandId | Yes | The Metricool brand/account ID | |
| endDate | No | End date for analytics range (YYYY-MM-DD format) | |
| startDate | No | Start date for analytics range (YYYY-MM-DD format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden and does not deliver: nothing about auth/account requirements, rate limits, pagination, default date window, or whether the operation is read-only (implied by 'Get' but never stated). It only hints at return contents.
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 short, front-loaded sentences with no filler. The trailing 'etc.' is slightly vague but does not bloat the text.
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?
With no output schema, the description must at least sketch the return payload; it does so briefly ('impressions, engagements, top posts, etc.'). However, it leaves the time-range behavior and metric scope under-specified for an analytics tool, which is the main remaining gap.
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 description coverage is 100%, so brandId, startDate, and endDate (including the YYYY-MM-DD format) are already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 is appropriate.
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?
States a specific verb and resource ('Get LinkedIn post performance metrics from Metricool') and lists representative outputs. It is distinguishable from siblings like metricool_get_best_time and metricool_schedule_post, though it never names an alternative to differentiate itself explicitly.
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?
No guidance on when to call this versus sibling tools, no mention of whether a date range is optional or what happens if startDate/endDate are omitted, and no prerequisites. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get optimal posting times for LinkedIn based on historical audience engagement patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| brandId | Yes | The Metricool brand/account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does add one useful behavioral fact — results derive from historical engagement data, implying sparse or empty output for new/low-activity brands — but it never states that this is a read-only operation or whether a minimum data history is required.
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?
A single, front-loaded sentence with zero filler; the purpose and its basis are stated up front. It is appropriately sized for a one-parameter retrieval tool.
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?
No output schema exists, so the description would ideally sketch the return shape (e.g., a ranked list of time slots) and note the LinkedIn-only scope, since there is no platform parameter to make that explicit at call time. It is adequate for a simple read but leaves these gaps.
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 (brandId) and schema description coverage is 100%, so the schema already documents it fully. The description adds no syntax, format, or lookup guidance for brandId beyond what the schema provides, matching the baseline-3 rule for high-coverage schemas.
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?
States a specific verb ('Get') and resource ('optimal posting times') and scopes it to LinkedIn with a rationale (historical audience engagement patterns). This distinguishes it from the generic metricool_get_analytics and the scheduling siblings, though it never names them explicitly.
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?
No guidance on when to use this versus metricool_get_analytics or how it relates to metricool_schedule_post. The agent must infer that this is a pre-scheduling recommendation step purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all brands/accounts connected to Metricool. Returns brand IDs needed for other operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the read-only listing nature implicitly and the output purpose (brand IDs), but says nothing about pagination, auth requirements, or whether the list is scoped to the authenticated user.
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 short sentences, zero waste, front-loaded with the action and resource. Every sentence earns its place.
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 zero-parameter discovery tool with no output schema, the description covers what it lists and what the result is used for. Minor gap is the absence of any note on return shape or scoping, but the core need is met.
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 tool takes zero parameters, so there are no parameter semantics to document. Baseline of 4 applies for a no-arg tool.
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?
States a specific verb ('List') and resource ('brands/accounts connected to Metricool'), and the second sentence clarifies the return value's purpose. An agent can distinguish this from siblings like get_analytics or get_scheduled_posts without inspecting any schema.
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 phrase 'Returns brand IDs needed for other operations' implies this is a prerequisite/discovery step, which is useful implied guidance. However, it never explicitly states when to call this versus alternatives or any prerequisites beyond that hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all scheduled posts for a brand from Metricool. Shows pending posts in the queue.
| Name | Required | Description | Default |
|---|---|---|---|
| brandId | Yes | The Metricool brand/account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it does little: it does not say whether results are paginated, sorted, or bounded, which matters for a claim of returning 'all' posts. The only added context is that the queue contains pending posts, which is a small clue about return contents but not about retrieval behavior, auth, or limits.
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 short sentences, zero filler, with the core action front-loaded and the clarifying content detail immediately after.
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 one-parameter read tool with no output schema and no annotations, the description is close to sufficient. The remaining gap is operational detail (pagination or limits on 'all' posts) rather than anything an agent needs to form the call.
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 description coverage is 100% and there is a single required parameter, so the schema already documents brandId. The phrase 'for a brand' reinforces that meaning but adds no format, source, or example detail beyond the schema.
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?
States a specific verb and resource ('Get all scheduled posts for a brand') and clarifies the content as 'pending posts in the queue.' It is distinguishable from metricool_schedule_post (a write) without opening the schema, but it never explicitly contrasts itself with any sibling.
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?
There is no statement of when to use this tool versus metricool_get_analytics, metricool_get_best_time, or metricool_get_brands, nor any prerequisite guidance (e.g., call get_brands first to obtain brandId). Usage is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a LinkedIn post via Metricool. Returns the scheduled post ID and details.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The post content (LinkedIn text post) | |
| brandId | Yes | The Metricool brand/account ID to post from | |
| dateTime | Yes | Scheduled date/time in ISO 8601 format (e.g., 2024-01-15T10:00:00) | |
| imageUrl | No | Optional URL to an image to include with the post | |
| timezone | No | Timezone for the scheduled time (default: America/Costa_Rica) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that a scheduled post ID and details are returned, but says nothing about authentication/connection requirements, whether past dates are rejected, timezone handling behavior, or rate limits — significant gaps for a mutation 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?
Two short sentences with the core action front-loaded and no filler. It is appropriately sized, though the second sentence is minimal value given no output schema exists.
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 mutation tool with no annotations and no output schema, the description is minimally adequate — it states the action and that an ID/details are returned. It omits prerequisites and failure/edge-case behavior an agent would need to invoke it reliably.
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 description coverage is 100%, so the schema already documents all five parameters including the timezone default. The description adds no syntax, format, or constraint detail beyond what the schema provides, so the baseline of 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?
States a specific verb ('Schedule') and resource ('LinkedIn post via Metricool'), naming both the platform and the scheduling nature. This clearly distinguishes it from the read-only siblings (get_brands, get_scheduled_posts, get_analytics, get_best_time).
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 gives no guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., needing a valid brandId from metricool_get_brands, or using get_best_time to pick a slot). Usage is only implied by the verb.
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.
v1.0.0metricool_get_analyticsmetricool_get_best_timemetricool_get_brandsmetricool_get_scheduled_postsmetricool_schedule_postScored across 5 tools
Each tool targets a distinct action: listing brands, finding best times, scheduling, retrieving scheduled posts, and fetching analytics. No two tools overlap in purpose, so an agent can easily select the right one.
All tools use the metricool_ prefix followed by a consistent snake_case verb_noun pattern (get_brands, get_best_time, schedule_post, get_scheduled_posts, get_analytics). The convention is predictable and uniform.
Five tools are well-scoped for a LinkedIn social media management integration, covering the essential operations without unnecessary bloat. Each tool earns its place in the workflow.
The surface covers reading brands, scheduling posts, listing scheduled posts, and analytics, but lacks update or delete/cancel operations for scheduled posts. This is a notable gap for lifecycle management, though core workflows are partially supported.
A hosted MCP server for planning, scheduling, media, analytics, and social publishing.
Official TimeToPost MCP server for social post drafting, scheduling, publishing and approval queues.
Social media MCP: publish, schedule & analyze posts on TikTok, Instagram, YouTube, LinkedIn & X
