sticker-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| send_stickerA | Send an expressive sticker (meme/表情包) that renders as an image in the chat. Use this proactively whenever a sticker would make the reply more fun or expressive — reacting to good/bad news, greeting, teasing, celebrating, comforting. Pick |
| list_available_stickersA | List every sticker in the library with its id, name and emotion/scene tags. Call this once early in a conversation (or when send_sticker reports no match) so you know which moods you can express; afterwards you can call send_sticker directly. |
| add_stickerA | Add an image to the sticker library from an existing public http(s) image URL only. Do not pass data:image URIs or base64 here. If you have the user's attached image bytes/file, call create_sticker_upload instead and upload the original bytes directly to this sticker library. Do not use third-party image hosts. If the user already described what the image is, do not spend tokens visually analyzing it; use the user's description to choose the name and tags. If the user did not describe it, inspect the image enough to choose a short name plus 1-8 emotion/scene tags. Supported formats: png / jpeg / gif / webp / avif, max 8MB. |
| create_sticker_uploadA | Create a one-time upload URL on this sticker library for the user's attached image bytes/file. Use this when adding a sticker from an attachment. After this tool returns, upload the original image bytes directly to uploadUrl with HTTP PUT and Content-Type image/png, image/jpeg, image/gif, image/webp, or image/avif. The sticker is saved as soon as the PUT succeeds; do not call add_sticker afterwards. Do not upload the image to third-party image hosts. Do not curl the MCP endpoint. If the user already told you what the image is, skip visual analysis and use that description for the name and tags. If not, inspect the image enough to name and tag it. The URL expires in 10 minutes. |
| add_sticker_by_pathA | Add a new sticker from an image file on this computer (local/stdio mode only). Use when the user gives a local file path. Supported: png / jpeg / gif / webp / avif, max 8MB. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| sticker-view | Inline sticker rendering for chat. |
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: listing, sending, and three ways to add stickers (URL, attachment, local path). The descriptions explicitly delineate when to use each add variant, so an agent should never be unsure which tool fits.
All names follow a verb_noun snake_case pattern, but 'list_available_stickers' and 'create_sticker_upload' are slightly more verbose than the simple 'send_sticker' and 'add_sticker'. Minor deviations exist, but the pattern is still readable and predictable.
Five tools is well within the ideal 3-15 range. Each tool covers a distinct aspect of sticker management—listing, sending, and adding via three different input sources—without unnecessary redundancy.
The core use case (list and send stickers) is fully covered, and adding stickers supports the three common input types. Missing delete/update operations are minor gaps for a sticker library, but they don't hinder the primary functionality.