sparkshare-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SPARKSHARE_URL | No | The SparkShare site URL (for local development `http://localhost:3031`). | |
| SPARKSHARE_API_KEY | No | A `sk_live_u_…` API key, used before the saved key. Normally you run `sparkshare-mcp login` instead, which saves a key in `~/.sparkshare/credentials.json`. | |
| SPARKSHARE_CREDENTIALS_FILE | No | Path to the credentials file (defaults to `~/.sparkshare/credentials.json`). |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_accountsA | List the accounts the user can publish to: the LinkedIn profiles (and Facebook Pages and Instagram professional accounts, where available) they connected on SparkShare, plus "x" (always available; the post waits for the user). Returns the ids publish_post needs. |
| publish_postA | Publish one post, optionally with images or a video, to some of the user's accounts. Facebook, Instagram and LinkedIn are published immediately and cannot be undone from here; X waits for the user (the SparkShare browser extension fills it in, or a compose link with the text). Only call this after the user has seen the exact text for each target and the media, and said yes. Every target is checked first: if any has a problem, nothing is published and the problems are listed. |
| upload_mediaA | Upload one image or video ahead of publish_post and get its id. Use it for videos and other large files, one call per file, so no single call runs long; then pass the ids in publish_post media. Nothing is posted. Uploaded files are kept for 30 days. |
| get_mediaA | Check an uploaded image or video: whether it is ready to publish (videos are processed for a minute or two after upload_media), its size and length. |
| get_postA | Show where a post went and the link to each published copy. Use it for targets publish_post reported as still publishing. |
| recent_postsA | List the user's most recent posts with their status per account. Check it before retrying a publish_post that failed without a post id, so nothing is posted twice. |
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 6 tools
Each tool has a distinct role in the publish workflow: upload_media vs get_media split by action (upload vs status check), and publish_post vs get_post vs recent_posts split cleanly by intent (publish, look up by id, list when no id exists). The descriptions explicitly state when to prefer one over the other, leaving little room for misselection.
Five of six tools follow a verb_noun pattern (upload_media, get_post, list_accounts, publish_post, get_media), but recent_posts breaks it by using an adjective_noun listing name instead of list_recent_posts. The deviation is minor and still readable, but it's a real inconsistency in an otherwise predictable scheme.
Six tools is well-scoped for a social publishing server: two media tools, two discovery tools, one publish action, and one status check. Nothing appears redundant, and each tool maps to a step an agent would actually take.
The core lifecycle is covered: list accounts, upload and validate media, publish, then verify outcomes via get_post/recent_posts. Gaps remain around post management — no edit, delete, cancel, or scheduling tool — though the descriptions indicate published posts are intentionally irreversible from here, so these are minor workable gaps rather than dead ends.