Which integrations are available for this server?

Allows managing and publishing media to Instagram, including uploading videos and images, listing recent uploads, and tracking status. Enables media uploads and management for TikTok, including video and image publishing and status monitoring. Provides tools for uploading and managing videos on YouTube, with status tracking and content management.

How do I use XenonFlare MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@XenonFlare MCP Server Upload a video to my TikTok account from this URL" 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.

XenonFlare MCP Server

by Xenon-Flare

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

XenonFlare MCP Server

NPM Version License: MIT Build Status

A Model Context Protocol (MCP) server for interacting with the XenonFlare API. This server allows AI assistants (like Claude) to manage your social media content, list channels, and automate media publishing directly from your chat interface.

🚀 Features

Channel Management: List connected social media accounts (Instagram, YouTube, TikTok, etc.).
Profile Management: Manage account profiles (groups of accounts for focused posting).
Media Uploads: Upload videos and images via URL with granular platform configurations.
Status Tracking: Monitor the progress of your media uploads in real-time.
Content Management: List and delete recent uploads directly through your AI assistant.

🔗 Resources

Main Website: xenonflare.com
Documentation: docs.xenonflare.com
API Reference: docs.xenonflare.com/api-reference
Developer Dashboard: xenonflare.com/developer/api-keys

📦 Installation

For Users (Claude Desktop)

Get your XenonFlare API Key from the XenonFlare Dashboard.
Open your Claude Desktop configuration file:
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the XenonFlare MCP server to the mcpServers object:

{
  "mcpServers": {
    "xenonflare": {
      "command": "npx",
      "args": ["-y", "@xenonflare/mcp-server"],
      "env": {
        "XENONFLARE_API_KEY": "your_api_key_here"
      }
    }
  }
}

For Developers

Clone the repository:

git clone https://github.com/Xenon-Flare/mcp-server.git
cd mcp-server

Install dependencies:
```
npm install
```
Build the project:
```
npm run build
```
Run locally:
- Create a .env file based on .env.example:
  cp .env.example .env
- Add your XENONFLARE_API_KEY to the .env file.
- Start the server:
  npm start

🛠 Available Tools

list_channels: List connected social accounts.
list_profiles: List account profiles.
upload_video: Upload a video via URL.
upload_image: Upload an image via URL.
get_video_status: Get status for a specific video.
get_image_status: Get status for a specific image.
list_videos: List recent video uploads.
list_images: List recent image uploads.
delete_video: Delete a video upload.
delete_image: Delete an image upload.

⚙️ Configuration

The server expects the following environment variables:

XENONFLARE_API_KEY: Your XenonFlare API key (Required).
XENONFLARE_API_URL: The XenonFlare API base URL (Optional, defaults to https://api.xenonflare.com).

📄 License

MIT © XenonFlare

Available Tools

10 tools

delete_imageC

Delete an image upload.

ParametersJSON Schema

Name	Required	Description	Default
`imageId`	Yes

TDQS

C2.1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are available, and the description only states the action without any behavioral details like permanence, side effects, or required permissions. The description fails to disclose important traits beyond the basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short at one sentence, which is under-specified for a deletion tool. While concise, it sacrifices necessary information, making it minimally useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema, no annotations, and a single undocumented parameter, the description is highly incomplete. It does not address prerequisites, return values, or consequences of deletion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter 'imageId' has no description in the schema (0% coverage), and the tool description does not mention it at all. The description adds no semantic value or context for the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Delete an image upload' clearly states the action (delete) and the resource (image upload), distinguishing it from sibling tools like delete_video. However, it lacks specificity about scope or constraints, preventing a top score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, such as checking image existence before deletion or considering irreversibility. The usage context is implied but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_videoC

Delete a video upload.

ParametersJSON Schema

Name	Required	Description	Default
`videoId`	Yes

TDQS

C2.3/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided and the description fails to disclose any behavioral traits (e.g., irreversibility, side effects, permissions).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise but underspecified; the single sentence omits crucial context, making it insufficient rather than efficiently informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, and no parameter descriptions, the tool definition is severely incomplete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description adds no meaning to the single parameter 'videoId' (e.g., what constitutes a valid ID).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Delete a video upload' uses a clear verb and specific resource, distinguishing it from sibling tools like delete_image.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_image_statusC

Get status for a specific image id.

ParametersJSON Schema

Name	Required	Description	Default
`imageId`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must disclose behavior. It only says 'Get status' without explaining whether this is a read-only operation, what side effects exist, or what the response contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (one sentence), which is concise but at the cost of completeness. It is not overly verbose, but it sacrifices essential details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter and no output schema, the description should explain what 'status' means or the structure of the response. It fails to do so, leaving the agent with insufficient information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, and the description does not clarify what 'imageId' represents (e.g., a URL, database ID). It adds minimal meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Get status') and resource ('specific image id'), and it effectively distinguishes from sibling tools like get_video_status or upload_image.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as list_images or get_video_status. The description lacks any context about appropriate scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_video_statusA

Get status for a specific video id.

ParametersJSON Schema

Name	Required	Description	Default
`videoId`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the full burden. It states 'Get status' which implies a read-only operation, but offers no additional details about behavior (e.g., authentication needs, rate limits, or side effects). This is minimally adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one required parameter and no output schema. The description covers the basic purpose but lacks information about possible statuses, response format, or potential errors. It is adequate for a minimal tool but could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions 'specific video id' which aligns with the parameter name 'videoId' but adds no further meaning about format, constraints, or semantics. The parameter name already conveys its purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get status') and the specific resource ('a specific video id'). It distinguishes the tool from siblings like 'get_image_status' (different resource) and 'list_videos' (different scope).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used to retrieve the status of a specific video but provides no guidance on when to use it versus alternatives like 'list_videos' or 'get_image_status'. No exclusion criteria or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_channelsB

List connected social accounts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does, but does not disclose any behavioral traits such as whether it returns a list of IDs, names, or other properties, or if there are any side effects. For a tool with zero annotations, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at three words. It is front-loaded and to the point. However, the brevity sacrifices some completeness, but for a zero-parameter tool, it is acceptable. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no output schema, and no annotations, the description should compensate. It does not explain what the output looks like (e.g., list of channel IDs, names, or URLs), nor how the results relate to sibling tools like upload_image. This lack of completeness limits the agent's ability to effectively use the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, and schema description coverage is 100% (0 params). The description does not add parameter-level details, but since there are none to describe, the baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List connected social accounts' clearly states the action (list) and the resource (connected social accounts). It is a specific verb+resource, but it lacks detail on what constitutes a 'channel' or which social platforms are included. It does not explicitly differentiate from sibling tools, but the sibling tools are about images/videos, so the purpose is relatively clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, context, or exclusions. Since there are no parameters and no sibling tools with similar purposes, the lack of usage guidelines is a notable gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_imagesC

List recent image uploads.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`limit`	No
`status`	No
`platform`	No

TDQS

C2.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full responsibility for disclosing behavior. It fails to mention pagination, filtering (via status/platform), or response structure. The agent is left uninformed about side effects or auth needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While extremely concise, the description is under-specified. It lacks necessary details and structure, failing to provide a front-loaded summary of what the tool does beyond the bare minimum.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, no output schema, and no annotations, the description is vastly incomplete. It does not define 'recent', explain parameters, or describe the return value, leaving the agent to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain any of the four parameters (page, limit, status, platform). The agent cannot infer how to use these filters or pagination.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and resource 'recent image uploads', distinguishing it from sibling tools like upload_image or delete_image. However, 'recent' is vague and could be more precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool vs alternatives like list_videos or get_image_status. The description implies it is for listing recent uploads but lacks explicit context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_profilesA

List all account profiles (groups of accounts).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It states 'List' which implies read-only, but does not disclose authentication needs, rate limits, or pagination behavior. Acceptable for a simple tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no redundancy or unnecessary words. The description is optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description does not hint at the return format or structure of profiles. While the tool is simple, adding a brief note about what fields are returned would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema coverage. The description adds value by explaining that profiles are 'groups of accounts', which aids understanding of the resource type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'all account profiles', with additional context that profiles are groups of accounts. It distinguishes this tool from siblings like list_channels, list_images, and list_videos.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates use for listing profiles, but does not explicitly mention when to use vs alternatives. Since no alternatives exist for profiles, the ambiguity is low.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_videosC

List recent video uploads.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`limit`	No
`status`	No
`platform`	No

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must convey behavioral traits. It implies a read-only listing but does not specify sorting, pagination details, or what 'recent' means. No side effects or auth requirements are mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise but under-specified. It lacks necessary detail without being overly verbose, but it could be improved with a bit more information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no schema descriptions, no annotations, and no output schema, the description is incomplete. It fails to explain filtering by status or platform, pagination, or the meaning of 'recent', leaving significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 4 parameters (page, limit, status, platform) with 0% description coverage. The description adds no meaning to these parameters, leaving the agent to infer their purpose without context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and the resource 'recent video uploads', distinguishing it from sibling tools like list_images and list_channels. However, the term 'recent' is vague and could be more precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like get_video_status or delete_video. There is no mention of use cases or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

upload_imageC

Upload an image via public URL with platform-specific configurations.

ParametersJSON Schema

Name	Required	Description
`imageUrl`	Yes	Publicly accessible URL to the image file
`title`	No
`description`	No
`platforms`	No
`profileId`	No	Optional: Use a pre-defined profile for accounts
`scheduledAt`	No	ISO date string
`instagram`	No
`tiktok`	No
`linkedin`	No
`pinterest`	No

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must fully disclose behavior. It only states 'upload' without confirming it as a write operation, auth requirements, rate limits, or what the response contains. This is insufficient for a complex tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single efficient sentence with no wasted words. However, it sacrifices critical information for brevity, so it is not perfectly front-loaded with essential context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 10 parameters, nested objects, and no output schema, the description is grossly incomplete. It fails to explain how to configure each platform, the purpose of autoPublish, scheduling, or profiles. The agent cannot form a correct invocation from this description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 30%, yet the description adds no parameter-level detail. It mentions 'platform-specific configurations' vaguely, without explaining the nested objects or enum options. The agent lacks meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (upload), resource (image), and method (via public URL). It distinguishes from sibling tools like delete_image, get_image_status, and list_images, which are different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like upload_video. The description does not mention context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

upload_videoC

Upload a video via public URL with platform-specific configurations.

ParametersJSON Schema

Name	Required	Description
`videoUrl`	Yes	Publicly accessible URL to the video file
`title`	No	Internal title
`description`	No	Internal description
`platforms`	No
`profileId`	No	Optional: Use a pre-defined profile for accounts
`scheduledAt`	No	ISO date string
`youtube`	No
`instagram`	No
`tiktok`	No
`linkedin`	No
`pinterest`	No

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It does not disclose behavioral traits such as success/failure responses, processing time, auth requirements, side effects, or how the public URL is handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence, 9 words). It is front-loaded and to the point, earning its place without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's high complexity (11 params, nested objects, no output schema, no annotations), the description is severely incomplete. It fails to explain return values, error conditions, or the overall workflow of uploading to multiple platforms.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 45%, meaning many parameters lack descriptions. The description adds minimal context (URL must be public, configs are platform-specific) but does not elaborate on how to use parameters correctly or their relationships.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Upload a video via public URL with platform-specific configurations' clearly states the action (upload video) and the resource (video via URL), and the mention of platform-specific configs distinguishes it from sibling tools like delete_video or upload_image.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like upload_image, or how to choose between using profileId vs manual platform configs. No when-to-use or when-not-to-use context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv1.0.0May 27, 2026
- First observeddelete_image
- First observeddelete_video
- First observedget_image_status
- First observedget_video_status
- First observedlist_channels
- First observedlist_images
- First observedlist_profiles
- First observedlist_videos
- First observedupload_image
- First observedupload_video

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation5/5

Each tool targets a distinct resource (image, video, channel, profile) and action (delete, get status, list, upload), with no overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (e.g., delete_image, list_channels, upload_video).

Tool Count5/5

10 tools cover the core upload, delete, status, and list operations for images and videos, plus listing channels and profiles—well-scoped for the server's purpose.

Completeness4/5

Covers all major operations for image/video management (CRUD except update, which is typical for immutable uploads), but lacks individual get for channels and profiles (only list provided).

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ChirpieOAuth
io.github.Firefloco
Post, schedule, and track social posts on X, Bluesky, LinkedIn, Instagram and more from AI agents.
Social Media App Automation
1
Post BridgeOAuth
io.github.jackfriks
Schedule and publish social media posts to 10 platforms from your AI agent
Social Media App Automation
114
AntworkOAuth
io.antwork
Draft, schedule, and publish social posts for your workspace straight from your AI.
Social Media Marketing
2
AutopostingOAuth
ai.autoposting
Schedule, generate and publish social posts to X, LinkedIn, Instagram, Threads and YouTube
Social Media App Automation
1

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Xenon-Flare/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server