Posthell
Server Details
Social media scheduler for AI agents: draft posts into a human-approved queue for 15 networks.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: creating drafts, retrieving growth analytics, listing posts, and shaping content. There is no functional overlap.
All names follow a verb_noun pattern with underscores, but verbs vary (create, get, list, shape). The pattern is consistent, though 'shape_post' is less conventional.
Four tools is slightly below average for a social media scheduling server but still covers core workflows. The count feels reasonable and not excessive.
Core operations (create draft, list posts, get analytics, generate content) are present. Minor gaps like update/delete drafts exist, but the tool set covers the primary use cases.
Available Tools
4 toolscreate_draftQueue a draft postAInspect
Save a post as a DRAFT in the user's posthell queue. It is never published by this tool - the user approves it in the dashboard. Optionally propose a publish time (pre-fills their scheduler) and limit which platforms it targets (default: every connected account).
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The post text | |
| platforms | No | Limit to these platforms (default: all connected accounts) | |
| proposedTime | No | Suggested publish time, ISO 8601. Only a suggestion - pre-fills the user's scheduler. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently discloses that the tool only saves drafts and does not publish, emphasizing user approval in the dashboard. It also notes default behavior for platforms. This is sufficient behavioral transparency for a non-destructive, user-initiated action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose. Each sentence adds essential information without redundancy. No wasted words, making it easy for an AI agent to quickly grasp the tool's function and key nuances.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description provides adequate context: it explains the draft lifecycle (not published, user approval), parameter options (platform filter, proposed time with default behavior), and the overall workflow. It could be improved by mentioning what is returned, but it is largely complete for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline of 3. The description adds value by explaining the draft context, that the tool never publishes, and clarifying default platform behavior (every connected account). It also reinforces the optional nature of proposedTime ('pre-fills their scheduler'). This extra context elevates the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'create_draft' and title 'Queue a draft post' clearly indicate the tool's function. The description explicitly states it saves a post as a DRAFT in the user's posthell queue and never publishes, distinguishing it from any publish tool. Sibling tools (get_growth, list_posts, shape_post) are clearly different, reinforcing purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool: to create drafts. It explains that the draft is never auto-published and requires user approval. It also mentions optional parameters for publish time and platform limits, giving context on how to customize usage. However, it does not explicitly state when not to use or provide alternatives, but given the sibling tools, this is less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_growthGet follower growthAInspect
The user's follower counts and 7-day growth per connected network, plus which network is growing fastest. Use this to decide where a post matters most or to report progress.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the returned data (follower counts, growth, fastest network) but does not disclose operational aspects like whether the operation is read-only, caching, rate limits, or authentication requirements. This is adequate for a simple data retrieval tool but lacks complete behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences totaling 28 words, with the first sentence clearly stating the tool's purpose and the second providing usage guidance. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a straightforward read tool, the description sufficiently conveys the data returned and its use case. It could benefit from specifying whether growth is in absolute numbers or percentage, but it is functionally complete for an AI agent to decide to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description need not explain any. With zero parameters, the baseline is 4, and the description provides no additional parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves follower counts and 7-day growth per connected network, and identifies the fastest growing network. This distinctively separates it from sibling tools which manage posts and drafts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using the tool to decide where a post matters most or to report progress, providing clear context. It does not mention when not to use or alternative tools, but the sibling tools are sufficiently different that this is not a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_postsList recent postsAInspect
Read the user's recent posts and drafts with per-platform status. Published posts include engagement metrics (likes, comments, shares, engagementRate - impressions on plans with full analytics) once analytics have synced. Use it to avoid duplicating a topic AND to learn which topics performed before drafting the next post.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 15) | |
| status | No | Filter by status (posted and published are synonyms) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the read-only nature and that analytics sync may cause delays, but fails to mention pagination or time range boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a use-case directive. No fluff, front-loaded, each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the main purpose and key output features (engagement metrics, per-platform status), but lacks details on output structure and default time range. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for 'limit' and 'status'. The description adds no extra value beyond the schema, achieving the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads recent posts and drafts with per-platform status and engagement metrics. It distinguishes itself from siblings (create_draft, get_growth, shape_post) as a read-only listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly guides use: 'Use it to avoid duplicating a topic AND to learn which topics performed before drafting the next post.' It doesn't mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shape_postShape notes into post anglesAInspect
Turn rough notes about what the user did (shipped a feature, fixed a bug, hit a number) into 2-3 finished social-post angles in the user's voice. Grounded only in the notes - never invents facts. Uses one AI generation from the user's monthly quota.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | Yes | Raw notes about what the user did. Rough is fine. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses important behavioral traits: the tool is grounded only in notes, never invents facts, and uses one AI generation from the user's monthly quota. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that are front-loaded with the main action. Every sentence adds value without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description briefly mentions output shape (2-3 angles) and includes quota usage, though it lacks detailed output structure. This is adequate for the tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. The description adds helpful examples (shipped a feature, fixed a bug, hit a number) beyond the schema's 'Raw notes' description, providing useful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: converting rough notes into 2-3 finished social-post angles in the user's voice. It specifies the input (notes) and output (angles), and is distinct from sibling tools like create_draft which would produce actual posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when you have rough notes and want post angles. It does not explicitly state when not to use or provide alternatives, but the context is clear given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!