content-distribution-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation4/5
The three content generation tools (draft_post, generate_carousel, generate_thread) serve distinct formats but could cause minor hesitation when choosing between single posts versus threads. However, platform-specific parameters and format descriptions provide adequate separation. Other tools have clearly distinct purposes (analysis, repurposing, calendar management).
Naming Consistency5/5
All seven tools follow a consistent verb_noun snake_case convention (analyze_post_performance, draft_post, generate_carousel, etc.). The verb choices clearly indicate the action type (analyze, draft, generate, get, repurpose, schedule) without mixing styles or conventions.
Tool Count5/5
Seven tools is an ideal count for a content distribution system, covering the full lifecycle from creation (3 tools), analysis, repurposing, and scheduling/retrieval. Each tool earns its place without redundancy or bloat.
Completeness3/5
While content creation and predictive analysis are well-covered, the scheduling system lacks update and delete operations for the content queue (only get_content_calendar and schedule_content exist). There's also no immediate publish or retrieve historical performance data, creating dead ends for calendar management workflows.
Average 3.8/5 across 7 of 7 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-destructive write operation (readOnlyHint=false, destructiveHint=false). The description adds value by specifying the storage location (content-queue.json) and revealing that a 'status' field is tracked (not visible in inputs), but omits timezone handling, idempotency, or validation behavior.
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?
Two sentences, front-loaded with the core action. The second sentence earns its place by introducing the 'status' tracking concept, though it partially overlaps with the schema. Efficient but could be slightly more precise ('post' vs 'content' parameter).
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?
Adequate for a 4-parameter tool with complete schema annotations. However, given this is a scheduling tool with no output schema, the description should clarify what indicates success (return value) and timezone handling for the scheduled_time parameter. Gaps remain for operational completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description lists some parameters ('platform, scheduled date/time') but doesn't add semantic nuance beyond the schema (e.g., timezone assumptions, content length limits). Mentioning 'status' doesn't help interpret inputs since it's not an input 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 clearly states the action (save) and target (publishing queue/content-queue.json), and implies the workflow stage by mentioning the queue. However, it doesn't explicitly differentiate from 'draft_post' (a sibling tool), which could cause confusion about when to draft versus schedule.
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 provided on when to select this tool over alternatives like 'draft_post' or 'repurpose_content'. The description assumes the agent knows the content marketing workflow without indicating prerequisites (e.g., 'use this after content is finalized').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context about the time-bounded nature ('next N days') and scope ('all scheduled content'), but does not disclose pagination behavior, rate limits, or content state filters (e.g., whether drafts are included).
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?
Two efficient sentences with zero waste. Front-loaded with the core action ('View'), followed by scope clarification ('Shows all scheduled content'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with good annotations, the description adequately covers the operation and time scope. Minor gap: lacking description of return structure given no output schema exists, though 'shows... scheduled content' provides partial clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description references 'next N days' which loosely maps to the days_ahead parameter, adding semantic context about the look-ahead window, though this largely overlaps with the schema's own description.
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 uses specific verb 'View' with clear resource 'content calendar/queue', and effectively distinguishes from siblings like schedule_content (write operation) and analyze_post_performance (analytics vs calendar viewing).
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 explicit guidance on when to use versus alternatives like schedule_content or draft_post. While 'View' implies read-only usage, it does not state prerequisites, exclusions, or redirect users to sibling tools for write operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a safe, non-destructive operation. The description adds valuable context about the output structure ('title + body per slide') and available styles. However, given the lack of an output schema, it omits details about the return format (e.g., whether it returns JSON, markdown, or plain text arrays).
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 consists of two efficient sentences with zero waste. It is appropriately front-loaded with the core action (generation) and platform specificity, followed by capability details (styles). Every word earns its place.
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?
For a 3-parameter tool with good annotations, the description covers the essential purpose and style options. However, given the absence of an output schema, it should describe the return structure (e.g., 'returns an array of slides with title and body fields') to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is appropriately met. The description lists the three style options, but this merely echoes the enum descriptions already present in the schema. It adds no additional context about the 'topic' parameter requirements or 'slides_count' implications beyond the schema definitions.
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 provides a specific verb ('Generate'), clear resource ('LinkedIn/Instagram carousel slides'), and output format ('title + body per slide'). It effectively distinguishes from siblings like 'generate_thread' and 'draft_post' by specifying the carousel format and target platforms.
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 mentions supported platforms (LinkedIn/Instagram) and content styles, which implicitly guides usage. However, it lacks explicit guidance on when to choose this over siblings like 'generate_thread' or 'draft_post' (e.g., 'use this for multi-slide visual content vs. text threads').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavioral context beyond annotations: specifies exact return metrics (engagement score 0-100, hook strength, CTA strength, readability, suggestions). Annotations only indicate read-only safety; description explains what the analysis actually evaluates.
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?
Two sentences with zero waste: first states purpose, second details return values. Front-loaded and appropriately sized for a 2-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description compensates by detailing return structure (scores and suggestions). Adequate for a simple, read-only analysis tool with 2 well-documented parameters and clear safety annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage ('The post text to analyze', 'Target platform'). Description mentions 'post's text' aligning with the text parameter, but adds no additional semantic constraints, format details, or platform-specific behaviors beyond what the enum already provides. Baseline 3 appropriate for high schema coverage.
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?
Clear specific verb ('Analyze') with resource ('post's text'/'engagement') and distinguishes from siblings—all siblings are content creation/management tools (draft_post, generate_carousel, schedule_content) while this is analytical/evaluative.
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?
No explicit when-to-use or when-not-to-use guidance, nor naming of alternatives. Usage is implied by the analysis focus (vs. creation focus of siblings), but lacks explicit guidance like 'use before posting to optimize' or 'use instead of generate_carousel when evaluating existing text'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavioral context beyond annotations: specifies StressZero brand rules (tutoiement, max 3 emojis, 3-5 hashtags, short phrases) and persona identity (Emmanuel Gomes Soares). These constraints critically affect output generation. Aligns with readOnlyHint=true as generation is non-mutating. Does not mention output format or length limits.
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?
Two sentences with zero waste. First sentence establishes core function and scope; second sentence delivers essential brand/identity constraints. Information density is optimal—every word influences generation behavior or platform targeting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 100% schema coverage and no output schema, description successfully covers brand identity and platform constraints necessary for correct invocation. Minor gap: does not explicitly state that tool returns drafted post text (though implied by name), nor mentions if output includes suggested media or just copy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. Description adds semantic context by mapping parameters to brand constraints (e.g., 'tutoiement' affects tone parameter, '3-5 hashtags' constrains platform formatting), but does not explain specific parameter syntax or relationships between format/topic/cta_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?
Description uses specific verb 'Generate' with resource 'post' and lists exact platforms (LinkedIn, Instagram, X/Twitter, TikTok). Singular 'post' clearly distinguishes from sibling tools generate_thread (multi-post) and generate_carousel (multi-slide), while 'Draft' in title differentiates from schedule_content (publishing) and analyze_post_performance (analytics).
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?
Provides implied usage through the format enum options (hook_story, stat_choc, etc.) and brand constraints, but lacks explicit guidance on when to choose this over generate_thread for longer content or repurpose_content for existing material. No 'when not to use' exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true confirming safe text generation without side effects, the description adds valuable structural context about output format: numbered posts, transitions, hook/CTA structure. This behavioral detail about content organization supplements the annotations well. Does not contradict readOnlyHint status despite using 'Generate' (understood as text creation, not state mutation).
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?
Optimal two-sentence structure with zero redundancy. First sentence establishes platforms and general function; second sentence details output structure. Every phrase earns its place—platform alternatives, post numbering, transitions, and structural components (hook/CTA) are all front-loaded and essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage and readOnlyHint annotations, the description adequately explains output structure (numbered posts, transitions, CTA). Missing only explicit mention of return value format (string/text vs object), though this is reasonably inferred from 'Generate.' Appropriate scope for a 3-parameter generation tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description mentions platform support (X/Twitter/LinkedIn) and multi-post nature, but these merely echo the schema's existing enum values and parameter purposes. Does not add syntactic details, validation rationale (why 3-10 posts), or semantic guidance beyond what the schema already provides.
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?
Excellent specificity: 'Generate a multi-post thread' provides clear verb+resource, explicitly names target platforms (X/Twitter or LinkedIn), and distinguishes from sibling draft_post by emphasizing 'multi-post' structure. The additional detail about 'numbered posts with transitions, including hook, content posts, and CTA finale' precisely defines the output format.
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?
Provides implicit usage context by specifying 'multi-post thread' and platform options (linkedin/x), which suggests when to use this versus single-post tools. However, lacks explicit guidance contrasting with sibling draft_post or criteria for choosing between platforms. No 'when not to use' or explicit alternative recommendations provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint), the description adds valuable behavioral specifics: exact character limits for platforms (X: 280, etc.), automatic hashtag style conversion, and format handling. However, it omits what happens when content exceeds limits (truncation vs. error) and the return format.
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?
Two well-structured sentences with zero waste: first sentence establishes the core purpose, second details specific capabilities. Information is front-loaded and every clause earns its place.
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?
Given the lack of an output schema, the description should indicate what the tool returns (the adapted text). While it comprehensively covers input transformation logic, the omission of return value description leaves a gap for a tool with no output schema documentation.
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?
With 100% schema coverage, the baseline is 3. The description elevates this by providing the semantic context for the platform enums—specifically the character constraints and formatting rules that apply to each—adding meaning beyond the schema's basic 'Original platform' labels.
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 core action ('Take content... and adapt it') and resource, distinguishing it from sibling creation tools like 'draft_post' or 'generate_thread'. The specific mention of platform constraints (X, LinkedIn, Instagram) further clarifies the 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?
While the description implies usage by defining the transformation workflow, it lacks explicit guidance on when to choose this over 'draft_post' (create new) versus adapting existing content. No alternatives or exclusion criteria are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![content-distribution-mcp MCP server](https://glama.ai/mcp/servers/gomessoaresemmanuel-cpu/content-distribution-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gomessoaresemmanuel-cpu/content-distribution-mcp)

Score Badge

Copy to your README.md:

[![content-distribution-mcp MCP server](https://glama.ai/mcp/servers/gomessoaresemmanuel-cpu/content-distribution-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gomessoaresemmanuel-cpu/content-distribution-mcp)

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/gomessoaresemmanuel-cpu/content-distribution-mcp'

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