atlas-social-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: generate_calendar creates content plans, get_analytics retrieves performance data, get_recent_posts shows post history, list_accounts displays connected accounts, post_now publishes immediately, and schedule_post schedules future posts. The descriptions clearly differentiate their functions, eliminating any ambiguity.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., generate_calendar, get_analytics, schedule_post) using snake_case throughout. The verbs (generate, get, list, post, schedule) are appropriate and predictable for their actions, creating a coherent naming convention across the set.
Tool Count5/5
With 6 tools, this server is well-scoped for social media management, covering key workflows like content planning, analytics, account management, and posting (both immediate and scheduled). Each tool earns its place without redundancy, making the count appropriate for the domain.
Completeness4/5
The tool set provides strong coverage for core social media operations, including content generation, analytics, account listing, and posting. A minor gap exists in update/delete operations for posts or accounts, which agents might need to work around, but the surface supports essential workflows without dead ends.
Average 3.2/5 across 6 of 6 tools scored.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get') but doesn't specify permissions, rate limits, data freshness, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior, warranting a low score.
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 that front-loads the purpose without unnecessary details. It avoids waste but could be slightly more structured to include usage context. This earns a 4 for being appropriately concise.
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 complexity of analytics tools, no annotations, and no output schema, the description is incomplete. It lacks details on data aggregation, platform-specific nuances, or return values, making it inadequate for full agent understanding. A score of 2 reflects this significant gap.
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?
The description adds no parameter-specific information beyond what the input schema provides, which has 100% coverage for the single parameter 'days'. The baseline is 3 when the schema does the heavy lifting, as the description doesn't compensate with additional syntax or format details.
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 tool's purpose with specific verbs ('Get social media performance analytics') and resources ('impressions, reach, likes, comments, shares across all connected platforms'). It distinguishes from siblings like 'get_recent_posts' by focusing on analytics rather than content retrieval. However, it doesn't explicitly differentiate from all siblings, keeping it at a 4 rather than a 5.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_recent_posts' or 'list_accounts'. It lacks explicit context about prerequisites, timing, or exclusions, leaving the agent to infer usage based on the purpose alone. This minimal guidance scores a 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While it mentions viewing posts with status and performance metrics, it doesn't disclose critical behaviors such as authentication requirements, rate limits, pagination (beyond the 'limit' parameter), error handling, or whether the data is real-time or cached. For a read operation tool with zero annotation coverage, this leaves significant gaps.
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 that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured (e.g., by explicitly separating status and metrics). Every part earns its place, but minor improvements in clarity are possible.
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 tool's moderate complexity (retrieving posts with status and metrics), lack of annotations, and no output schema, the description is minimally adequate. It covers what data is returned but lacks details on behavioral traits, error cases, or output structure. It meets the bare minimum for a read operation but leaves room for improvement in 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?
The input schema has 100% description coverage, with the 'limit' parameter clearly documented. The description doesn't add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain default behavior beyond the schema's 'Default: 10' or clarify format constraints). Baseline 3 is appropriate when the schema does the heavy lifting.
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 tool's purpose: 'View recent posts published through Atlas Social with their status (published/scheduled/failed) and performance metrics.' It specifies the verb ('view'), resource ('recent posts'), and scope ('published through Atlas Social'), but doesn't explicitly differentiate from sibling tools like 'get_analytics' or 'list_accounts' which might also retrieve post-related data.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_analytics' (which might provide deeper metrics) or 'post_now'/'schedule_post' (which are for creating posts), nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It mentions 'AI adapts content per platform,' which hints at automated content modification, but doesn't cover critical aspects: whether scheduling requires specific permissions, if posts can be edited/canceled after scheduling, rate limits, error handling, or what the response looks like (since no output schema). For a mutation tool with zero annotation coverage, this is a significant gap.
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 extremely concise—two short sentences that are front-loaded with the core purpose. Every word earns its place: the first sentence defines the action, and the second adds a key behavioral trait (AI adaptation). There's no redundancy or fluff.
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 complexity (a mutation tool with 7 parameters, no annotations, and no output schema), the description is incomplete. It lacks behavioral details (e.g., permissions, reversibility), usage context versus siblings, and output expectations. While the schema covers parameters well, the description doesn't compensate for missing annotation and output information, making it inadequate for safe and effective use.
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 description coverage is 100%, so the schema already documents all 7 parameters thoroughly (e.g., 'text' as content, 'platforms' as array, 'schedule_time' as ISO 8601). The description adds minimal value beyond the schema—it implies multi-platform support and AI adaptation but doesn't provide additional syntax, format details, or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
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 tool's purpose: 'Schedule a social media post for a specific future date and time.' It specifies the verb ('schedule'), resource ('social media post'), and temporal scope ('future date and time'). However, it doesn't explicitly differentiate from sibling tools like 'post_now' (immediate posting) or 'generate_calendar' (calendar-related), though the scheduling focus is implied.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'post_now' for immediate posting or 'get_recent_posts' for retrieval, nor does it specify prerequisites (e.g., authentication, platform setup) or exclusions (e.g., scheduling limits). Usage is implied by the name 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the output format ('daily topics, hooks, optimal posting times, and platform recommendations') but lacks details on permissions, rate limits, data sources, or potential side effects. For a generative tool with no annotation coverage, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence that front-loads the core purpose and output details. It avoids redundancy and wastes no words, though it could be slightly more structured by separating purpose from output specifications.
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 tool's complexity (generative with 5 parameters) and lack of annotations and output schema, the description is moderately complete. It covers the purpose and output format but misses behavioral context and usage guidelines. For a tool without structured output documentation, more detail on return values would be beneficial.
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 description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as examples or usage tips. Baseline 3 is appropriate when the schema handles all parameter documentation.
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 purpose with specific verbs ('generate a complete 30-day social media content calendar') and resources ('daily topics, hooks, optimal posting times, and platform recommendations'). It distinguishes itself from sibling tools like get_analytics, get_recent_posts, and schedule_post by focusing on comprehensive calendar generation rather than analytics retrieval, post listing, or scheduling 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, ideal scenarios, or exclusions, nor does it reference sibling tools like schedule_post or post_now for comparison. The agent must infer usage from the purpose alone without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool lists accounts and shows status/readiness, but doesn't cover critical aspects like whether this requires authentication, rate limits, pagination, error handling, or what 'status' entails. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 perfectly concise with two clear sentences that each add value. The first sentence states the core purpose, and the second adds important context about what information is included. There's zero wasted text or redundancy.
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 tool's simplicity (0 parameters, no output schema, no annotations), the description provides adequate basic information about what the tool does. However, for a tool that presumably returns account data, the lack of output schema means the description should ideally mention what specific information is returned (beyond just 'status'), but it doesn't fully compensate for this gap.
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 description coverage, so the schema already fully documents the lack of inputs. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. This meets the baseline expectation for parameterless tools.
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 tool's purpose: 'List all connected social media accounts and their status' specifies the verb (list) and resource (connected social media accounts). It distinguishes from siblings by focusing on account listing rather than analytics, posting, or scheduling. However, it doesn't explicitly differentiate from potential similar tools like 'get_accounts' if they existed.
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?
The description provides no guidance on when to use this tool versus alternatives. While it mentions 'Shows which platforms are active and ready to post,' this doesn't help an agent choose between list_accounts and sibling tools like get_analytics or get_recent_posts. There's no mention of prerequisites, timing, or comparative use cases.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the core behavior (immediate posting with AI adaptation) and lists supported platforms, which is valuable. However, it doesn't disclose important behavioral traits like authentication requirements, rate limits, error handling, or what happens when posting fails on some platforms. The description doesn't contradict annotations (none exist).
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 efficiently structured in two sentences: the first states the core functionality, the second lists supported platforms. Every element earns its place - the AI adaptation detail is crucial context, and the platform list helps users understand scope. No wasted words or redundant information.
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 complex 8-parameter mutation tool with no annotations and no output schema, the description provides adequate but incomplete context. It covers the what (posting with AI adaptation) and where (platform list), but lacks information about return values, error conditions, authentication needs, or platform-specific constraints (like Instagram requiring media). The 100% schema coverage helps, but behavioral aspects are underspecified.
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 description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions platform support and AI adaptation (which relates to the 'adapt_per_platform' parameter), but doesn't provide additional meaning for parameters like 'brand_name' or 'media_url'. This meets the baseline 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?
The description clearly states the tool's purpose with a specific verb ('Post content') and resource ('to social media platforms immediately'), distinguishing it from siblings like 'schedule_post' (immediate vs scheduled posting) and 'generate_calendar' (planning vs execution). It explicitly mentions the AI adaptation feature, which adds specificity beyond basic posting.
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 provides clear context for when to use this tool: for immediate posting with AI adaptation across platforms. It implicitly distinguishes from 'schedule_post' (immediate vs scheduled) and 'get_recent_posts' (posting vs retrieval), but doesn't explicitly state when NOT to use it or name alternatives like 'schedule_post' for delayed posting scenarios.
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:

[![atlas-social-mcp MCP server](https://glama.ai/mcp/servers/chrismole310/atlas-social-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrismole310/atlas-social-mcp)

Score Badge

Copy to your README.md:

[![atlas-social-mcp MCP server](https://glama.ai/mcp/servers/chrismole310/atlas-social-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrismole310/atlas-social-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/chrismole310/atlas-social-mcp'

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