viralnote-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VIRALNOTE_API_KEY | Yes | Your ViralNote API key, generate at https://viralnote.app/developers/auth | |
| VIRALNOTE_API_BASE | No | Override for staging/self-hosted instances | https://viralnote.app/api/v1 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_postsA | List the user's posts. Returns post objects with id, caption, status, target platforms, scheduled time, and attached media ids, plus a |
| get_postA | Fetch a single post by id, including its full per-platform publish results (success or error per platform). Use after list_posts to inspect one post in detail, or after publish_post to check how delivery went. Returns an error if the id does not exist or belongs to another account. |
| create_postA | Create a new post as a draft or schedule it for automatic publishing. With status='draft' (or is_draft=true) the post is saved with no publish time; with scheduledFor set it is queued and publishes automatically at that time. Returns the created post object including its id. Media must already exist in the library — call import_media or list_media first to get a media id. The user must have connected each target platform (verify with list_social_accounts if unsure). To publish an existing draft immediately, use publish_post rather than creating a new post. |
| update_postA | Edit a draft or scheduled post before it publishes. Send only the fields to change — omitted fields keep their current values. Returns the updated post object. Posts that are already publishing, published, or failed cannot be edited. Common uses: reschedule by passing a new scheduledFor, fix a caption, swap attached media, or convert a draft to scheduled by passing status='scheduled' together with scheduledFor. |
| delete_postA | Permanently delete a post by id. If the post is scheduled, this cancels the pending publish. This does not retract content already delivered to social platforms — it only removes the ViralNote record. Irreversible: confirm with the user before deleting. Use update_post instead if the goal is to fix or reschedule a post. |
| publish_postA | Publish an existing draft post to all of its target platforms immediately, skipping the schedule queue. Only valid on posts with status='draft' — returns an error for scheduled or already-published posts. Returns the post with delivery kicked off; individual platforms can still succeed or fail independently, so follow up with get_post or list_post_results to confirm the outcome. |
| list_mediaA | List items in the user's media library. Returns each item's id, name, type, and folder, plus a |
| import_mediaA | Import a file into the media library so it can be attached to posts. Two modes: (1) URL mode — pass |
| delete_mediaA | Permanently delete a media library item by id. The file cannot be recovered — confirm with the user before deleting. Use list_media to find the item's id and verify it is the right file (check name and type) first. |
| list_social_accountsA | List the social accounts connected to the user's ViralNote account: platform and account identity for each. Takes no parameters. Use before create_post to confirm the intended target platforms are actually connected — posting to an unconnected platform fails. Note that connecting or disconnecting accounts happens in the ViralNote dashboard UI (OAuth); it cannot be done through this API. |
| list_analyticsA | List published posts with their latest per-platform metrics: views, likes, comments, shares, and engagement. Metrics are collected periodically by ViralNote, so values are the most recent snapshot rather than real-time. Use to report on content performance or find top-performing posts; use list_post_results instead when the question is whether delivery succeeded. Paginated via cursor. |
| list_post_resultsA | Check delivery outcomes: returns recent published or failed posts with each platform's individual result (success, or the error that occurred). Pass postId to inspect one post's delivery; omit it to scan recent posts filtered by status. Use after publish_post to verify delivery, or when the user asks why a post didn't appear on a platform. For engagement metrics rather than delivery status, use list_analytics. |
| list_webhooksA | List all webhook subscriptions on the account: each subscription's id, target URL, and subscribed events. Takes no parameters. Use to find a webhookId before delete_webhook, or to check whether an event is already covered before calling create_webhook (avoids duplicate subscriptions). |
| create_webhookA | Subscribe a URL to ViralNote event notifications. ViralNote sends an HTTP POST with a JSON payload to the URL each time a subscribed event fires — for example post.published when a post goes live, or post.failed when delivery errors. Returns the created subscription including its id. The URL must be an HTTPS endpoint you control and that is publicly reachable. Check list_webhooks first to avoid duplicating an existing subscription. |
| delete_webhookA | Delete a webhook subscription by id. The target URL immediately stops receiving event notifications. Irreversible, but a subscription can be recreated with create_webhook. Use list_webhooks to find the id and confirm which URL/events it covers before deleting. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Every tool has a clearly distinct purpose. For example, create_post, publish_post, and update_post are well-differentiated: one creates, one publishes, one edits. The list tools (posts, post_results, analytics, media, webhooks, social_accounts) each target different data, avoiding confusion.
All 15 tools follow a consistent verb_noun pattern in snake_case: create_post, delete_media, list_analytics, etc. No mixing of conventions (e.g., camelCase or vague verbs like 'process'), making the tool surface predictable and easy to navigate.
15 tools is well-scoped for a social media scheduling service. The set covers core operations on posts, media, webhooks, analytics, and social accounts without unnecessary overlap or bloat.
The tool surface covers the main lifecycle: create, read, update, delete for posts and media; plus publishing, analytics, and webhook management. Minor gaps exist (e.g., no single media fetch by id, no tool to retry failed posts), but agents can work around them effectively.