mixpost-mcp-server

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation4/5
Most tools target distinct resource-action pairs (posts, tags, media, accounts). The only potential confusion is between mixpost_schedule_post and mixpost_add_post_to_queue, but their descriptions clarify the difference (specific time vs. queue placement). Overall, tool boundaries are clear.
Naming Consistency5/5
All tools follow a consistent mixpost_<verb>_<noun> pattern using snake_case and a common prefix. Verbs like list, get, create, update, delete are used uniformly across resources, making the API predictable and easy to navigate.
Tool Count4/5
With 20 tools, the server is slightly heavy but appropriate given the breadth of the domain (posts, media, tags, accounts). The tool count reflects the need for CRUD operations on multiple resources without becoming excessive or unwieldy.
Completeness4/5
The tool surface provides thorough coverage for posts (create, update, approve, schedule, queue, delete, bulk delete) and full CRUD for tags. Minor gaps exist, such as missing account management (creation/deletion) and media upload, but these are likely handled outside the MCP server scope.
Average 3.2/5 across 20 of 20 tools scored. Lowest: 2.4/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 is failing
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

Behavior1/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 only states 'Create a new social media post' and fails to mention critical behaviors such as whether the post is immediately published, scheduled, or added to a queue, or how the 'schedule_now' and 'queue' parameters affect behavior. This is a significant transparency gap 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which is concise but under-specified. It lacks any structural elements such as prerequisites, examples, or context. The brevity is not effective because it omits essential usage details, making it more of a title than a helpful description.
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 complexity (9 parameters, no output schema, no annotations), the description is woefully incomplete. It does not explain the overall workflow, how accounts and versions interact, or the implications of scheduling and queue options. The description alone would not sufficiently guide an agent in selecting and invoking this tool correctly.
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 provides descriptions for all 9 parameters, covering 100% of them. The tool description adds no additional parameter-level information beyond what the schema already contains. Since schema coverage is complete, the baseline score of 3 is appropriate; the description neither enhances nor detracts from parameter understanding.
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 uses the specific verb 'Create' and the resource 'social media post', clearly stating the tool's primary function. It differentiates from update/delete/list operations among siblings, though it does not explicitly distinguish from schedule_post or add_post_to_queue, which could also involve creating posts. Overall, the purpose is clear and unambiguous.
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 does not mention whether to use it for immediate posting, scheduling, or queuing, nor does it reference any sibling tools. The single sentence is purely definitional and lacks any contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 merely says 'Approve a social media post' without mentioning what approving entails: state changes, reversibility, permission requirements, or downstream effects such as publication. This lack of detail is a significant gap for a workflow-related action.
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 a single sentence, but it is under-specified, essentially restating the tool name without adding value. It lacks the necessary context about usage and behavioral effects, making it insufficient rather than 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?
For a simple tool with one parameter and no output schema, the description is still incomplete. It omits crucial workflow context, such as when approval is appropriate and what happens to the post upon approval. The absence of annotations further compounds the incompleteness.
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 already describes postUuid with 100% coverage. The description adds no extra meaning beyond the schema, aligning with the baseline 3 for full schema coverage. No parameter-specific nuances or formats are mentioned.
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 'Approve a social media post' clearly states the action (approve) and the resource (social media post). It is distinct from all sibling tools, which include create, update, delete, schedule, and queue actions, making the approval operation's purpose unambiguous.
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 mixpost_update_post or mixpost_schedule_post. The description does not mention preconditions (e.g., post must be pending approval) or exclusions, leaving the agent without contextual decision-making information.
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, the description carries the full burden of disclosing behavioral traits. It only says 'update' implying a mutation, but does not explain effects (e.g., whether it's idempotent, what happens if the tag does not exist, or whether any related resources are affected). This lack of detail is a significant transparency gap for a mutation tool.
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 extremely concise at five words, which is efficient with no wasted words. However, it is under-specified, lacking details that would make it appropriately sized for the tool's purpose. It could benefit from mentioning the updatable fields or conditions, so it sits between minimal and adequate.
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's mutation nature, lack of annotations, and no output schema, the description is too sparse. It does not mention required vs optional parameters, expected behavior, or any prerequisites. A single sentence stating 'Update an existing tag' is insufficient for an agent to fully understand the tool's context and implications.
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% coverage with descriptions for all three parameters (name, tagUuid, hex_color), so the schema already provides the necessary semantics. The description adds no additional parameter information beyond the action itself, keeping it at the baseline for full schema coverage.
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 states a specific action ('Update') and resource ('an existing tag'), clearly distinguishing it from sibling tools like create_tag, delete_tag, and list_tags. However, it does not specify which attributes can be updated, relying on the schema for that detail.
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. It does not mention that it should be used to modify tag names or colors, nor does it exclude scenarios like creating a new tag or deleting one. The description is purely a statement of the action without contextual direction.
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 available, the description carries the full burden of disclosing behavioral traits. It only states the action without revealing potential side effects (e.g., whether duplicate names are rejected), required permissions, or what the tool returns upon success. This is a significant gap for a mutation 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 brief sentence with no unnecessary words. It is front-loaded and efficient, though it may be under-specified. However, for what it attempts to convey, it is 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 low complexity (2 parameters, no nested objects) and full schema coverage, the description is minimal but leaves out important context. It does not explain return values, error conditions, or any behavior beyond the creation action. For a tool with no output schema, the description should provide more guidance on what to expect.
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 provides 100% coverage for both parameters (name and hex_color) with clear descriptions. The tool description adds no parameter-level information beyond what the schema already offers, so the baseline score of 3 applies.
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 uses a specific verb and resource ('Create a new tag'), clearly distinguishing this from sibling tools like mixpost_update_tag, mixpost_delete_tag, and mixpost_list_tags. It is unambiguous and directly reflects the tool's function.
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. There is no mention of exclusions, prerequisites, or scenarios where another tag-related tool might be more appropriate. The agent must infer usage entirely from the name and 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?
No annotations are provided, so the description carries the full burden. It only says 'Get details' without disclosing auth requirements, error behavior, or confirmation that this is read-only; it relies on the verb 'get' to imply safety.
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 filler words. It is appropriately sized for the simple operation it describes.
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?
With no output schema, the description fails to explain what 'details' are returned or what the response structure looks like. It doesn't offer any usage context beyond the operation itself, leaving the agent without guidance on interpreting results.
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 fully documents the only parameter postUuid with a clear description. The tool description adds no additional parameter context, so it earns the baseline score for high schema coverage.
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 'Get details of a specific post' clearly states the action (get) and the resource (specific post). It distinguishes from sibling tools like list_posts by implying a single-object retrieval, though it doesn't explicitly name alternatives.
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 about when to use this tool versus alternatives such as mixpost_list_posts or mixpost_get_media. It simply states what it does without context on prerequisites or exclusions.
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 available, the description carries the full burden, but it only repeats the action implied by the tool name ('Schedule a post') and offers no side effects, prerequisites, reversibility, or post-conditions. The phrase 'for publishing' is largely redundant since a post is inherently for publishing.
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 and front-loaded, consisting of a single sentence with only five words. It could arguably add a bit more context without losing conciseness, but it is appropriately sized for a simple one-parameter tool.
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?
The tool has a single parameter, no output schema, and no annotations, so the description is the only source of context. It does not explain the scheduling workflow, how this relates to add_post_to_queue or approve_post, or what effect scheduling has on the post lifecycle, leaving the tool ambiguous despite its simplicity.
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 schema covers 100% of parameters and the sole parameter postUuid has a clear description. The description adds no additional semantic context beyond the schema, so the baseline of 3 applies.
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 uses a specific verb ('Schedule') and resource ('post'), clearly indicating the core action. However, it does not distinguish scheduling from sibling actions like mixpost_add_post_to_queue or mixpost_approve_post, and doesn't clarify whether a time parameter is expected (no time parameter exists in the schema).
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 the many sibling tools, such as whether it should be used after approval or how it differs from queueing. No prerequisites, scenarios, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only restates the action without disclosing any behavioral traits such as idempotency, error handling, or whether existing fields are overwritten. It provides zero additional context beyond the tool name.
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 waste. However, it is under-specified for other dimensions, which slightly reduces its value; still, it is 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?
For a mutation tool with no annotations and no output schema, the description fails to provide essential context such as what happens on failure, whether updates are partial or full, or any side effects. It is minimally viable but clearly incomplete.
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% for all three parameters, so the baseline applies. The description adds no extra meaning; it does not elaborate on parameter semantics 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?
The description 'Update media file metadata' has a specific verb ('update') and resource ('media file metadata'), clearly distinguishing it from sibling tools like delete or list media. It unambiguously states the tool's action.
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 (e.g., get_media, delete_media). There are no explicit exclusions, prerequisites, or context clues beyond the basic action.
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 must carry the full burden. It only says 'update an existing social media post' without disclosing whether updates are destructive (e.g., replace all fields), whether partial updates are allowed, or any side effects. There is no mention of permissions, validation, or response 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 a single concise sentence with no fluff. It communicates the core action and resource efficiently, earning its place without unnecessary detail.
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?
With 7 parameters, 6 required, no output schema, and no annotations, the description is too sparse. It fails to explain what happens when updating (e.g., does it replace all versions?), any dependencies like accounts must exist, or what the response indicates. The schema covers structure but not behavioral context.
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 baseline is 3. The description itself adds no parameter-level meaning beyond the schema, but the schema already provides descriptions for all fields. The description does not need to compensate for missing schema info.
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 (update) and the resource (existing social media post), which distinguishes it from create, delete, and schedule tools. However, it does not explicitly mention any alternative tools or nuances that set it apart beyond the verb.
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 vs. mixpost_create_post, mixpost_schedule_post, or mixpost_approve_post. It does not mention prerequisites, typical workflow scenarios, or any conditions under which this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the tool's name. With no annotations provided, the description carries the full burden, but it does not disclose irreversibility, permissions, or effects of deleting a tag.
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 filler words. It is concise and 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?
For a destructive operation with one parameter, the description is too sparse. It omits critical context such as irreversibility, required permissions, and what happens if the tag does not exist, and there is no output schema to clarify the response.
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 already provides full coverage (100%) with a clear description of the tagUuid parameter. The tool description does not add parameter meaning, but the schema sufficiently documents it, warranting the baseline score of 3.
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 tag' clearly states the action (delete) and resource (tag), and is specific enough to distinguish from sibling tools like mixpost_create_tag, mixpost_update_tag, and mixpost_list_tags.
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. The description does not mention prerequisites, exclusions, or when a different tag-related operation would be more appropriate.
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, the description must disclose behavioral traits. It indicates a write operation ('Add') but gives no information about side effects, permission requirements, idempotency, or consequences for the post. This is insufficient for a mutation 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?
The description is a single, direct sentence that is free of filler and immediately communicates the 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 fully documented parameter, yet the description lacks context about prerequisites (e.g., post must exist, not already queued) and effects (e.g., status change). The absence of annotations and output schema increases the need for behavioral context, leaving the description marginally adequate.
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 schema already fully documents the single parameter postUuid with its own description (100% coverage). The tool description adds no additional meaning beyond restating the action, so the baseline of 3 applies.
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 uses a specific verb ('Add') and resource ('post to the publishing queue'), clearly stating the tool's function. It does not explicitly differentiate from siblings like mixpost_schedule_post, but the phrase 'publishing queue' implies a distinct destination.
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 such as mixpost_schedule_post or mixpost_approve_post. There is no mention of prerequisites, exclusions, or preferred scenarios.
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 only states 'List posts', which is barely more than the tool name. It does not mention pagination, default limit, or that it is a read-only operation. No side effects or prerequisites are disclosed.
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, concise sentence ('List posts in the workspace') with no superfluous information. It is front-loaded and to the point, using five words to convey the core purpose efficiently.
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 simple list tool with a complete parameter schema, the description combined with the schema provides the minimum viable context to invoke the tool. However, there is no output schema and no mention of return format or how pagination/filtering work, leaving some gaps for the agent.
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 provides 100% coverage with descriptions for all three parameters (page, limit, status). The description adds no additional parameter meaning beyond what the schema already documents, so the baseline score of 3 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 clearly states the action ('list') and the resource ('posts'), which is specific and unambiguous. It does not explicitly distinguish from sibling list tools, but the resource name differentiates them. The addition of 'in the workspace' provides some scope context.
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 about when to use this tool versus alternatives like mixpost_get_post for a single post, or mixpost_create_post for creating. There is no mention of use cases or exclusion criteria, which is especially needed given the large number of sibling tools.
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?
The description only says 'Delete a specific post' and provides no details on destructiveness, irreversibility, permissions, or cascading effects. With no annotations provided, the description carries the full burden but fails to disclose any behavioral traits beyond the explicit action.
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 sentence, concise and front-loaded. It contains no extraneous words and effectively communicates the primary purpose.
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 lack of annotations and output schema, the description is too minimal. It does not explain whether deletion is permanent, what happens to associated media, or any prerequisites. A simple delete operation still benefits from some behavioral context, which is absent here.
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 fully describes the sole parameter (postUuid) with a clear description. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
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 (delete) and the resource (a specific post), distinguishing it from sibling tools like mixpost_delete_multiple_posts by emphasizing 'a specific post'. The verb is specific and the resource is unambiguous.
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 mixpost_delete_multiple_posts. The description simply states the action without any contextual cues about selection criteria or exclusions.
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 simply says 'Delete a media file' without stating that deletion is permanent, whether special permissions are required, or any side effects on related data. This is a significant gap for a destructive operation.
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 extraneous words. It directly states the action and resource, making it an appropriately concise description for a simple deletion tool.
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 (one parameter, no output schema, no annotations), the description provides the core action but lacks contextual details such as irreversibility or impact on referencing entities. The description is adequate for a basic understanding but not fully complete for an agent making an informed invocation decision.
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 fully documents the mediaUuid parameter with a descriptive field. The tool description does not add any additional semantic detail beyond the schema, so the baseline score of 3 applies due to 100% 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 'Delete a media file' clearly identifies the verb ('delete') and resource ('media file'), distinguishing it from sibling tools like mixpost_update_media, mixpost_get_media, and mixpost_list_media. It is specific and unambiguous.
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 the media-related siblings or other delete tools. There is no mention of prerequisites, exclusions, or alternatives, leaving the agent without context for tool selection.
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, the description must disclose behavior itself. It only says 'Get details' without specifying what details are returned, whether the operation is read-only, or how errors (e.g., tag not found) are handled. This is a significant gap for a read operation.
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 concise sentence with no redundancy or filler. It is front-loaded with the key information and earns its place with zero waste.
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 low complexity (one parameter, no annotations, no output schema), the description is adequate but incomplete. It does not mention what the 'details' consist of or any error behavior, which an agent would need to know to use the tool effectively.
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 fully documents tagUuid as 'The UUID of the tag to retrieve', so the description adds no new parameter-specific meaning. Baseline 3 applies because schema coverage is 100%; the description merely reinforces that a specific tag is targeted.
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 'Get details of a specific tag' uses a specific verb ('Get') and resource ('tag'), clearly distinguishing it from list, create, update, and delete siblings. It unambiguously states the tool's action and target.
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 mixpost_list_tags or mixpost_get_account. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage from the parameter and sibling names.
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 full responsibility for disclosing behavioral traits. It only says 'Get details', implying a read operation, but does not state whether it is non-destructive, what fields are returned, how errors or not-found cases are handled, or any permissions required. The brevity leaves the agent without critical context about the operation's effects and output.
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 sentence with no filler, front-loading the key verb and resource. It is appropriately sized for a simple retrieval tool and earns its place without unnecessary detail.
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 simple getter with one parameter and no output schema, the description is minimally viable but has clear gaps: it fails to mention what 'details' includes, any return format, usage guidance vs. sibling tools, or error behavior. The absence of an output schema increases the need for more descriptive context, which is not provided.
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 single parameter mediaUuid is fully described in the input schema ('The UUID of the media file to retrieve'), yielding 100% schema description coverage. The description does not add extra meaning beyond the schema, but the schema alone is sufficient for parameter understanding, so the baseline of 3 is appropriate.
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 a specific verb ('Get') and resource ('details of a specific media file'), clearly distinguishing it from sibling tools like mixpost_update_media, mixpost_delete_media, and mixpost_list_media. It unambiguously conveys this tool retrieves a single media file's details.
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?
Usage context is implied by the name and description: use for a single media file by UUID, versus list operations for multiple files. However, there is no explicit statement of when to use it over alternatives, no exclusion of list/update scenarios, and no mention of prerequisites or typical workflows.
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, the description carries the full burden, but it only repeats the tool's name and does not disclose behavioral details such as pagination behavior, default limits, ordering, or what fields are returned. It adds minimal context beyond the name and schema.
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, concise sentence that immediately conveys the core action and scope. There is no redundant or filler content, making it appropriately sized for a simple list operation.
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 simple list tool with optional parameters and no output schema, the description is minimally sufficient but lacks context about what the returned list contains or how pagination works. Given no annotations, a bit more detail (e.g., 'returns paginated results') would make it 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?
All three parameters (page, type, limit) have descriptions in the schema, giving 100% schema coverage. The description adds no additional parameter semantics, so the baseline of 3 applies as the schema fully documents each parameter's 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 uses a specific verb ('List') and resource ('media files') with a clear scope ('in the workspace'). It distinguishes itself from sibling tools like mixpost_get_media, mixpost_update_media, and mixpost_delete_media by indicating a listing operation.
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 usage for listing media, and the sibling names clarify it is for the collection rather than a single item. However, it does not explicitly state when to use this over mixpost_get_media or mention any prerequisites or exclusions, so guidance is only implied.
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 must carry the full burden of behavioral disclosure. It states the action (deletion) but does not mention whether deletion is permanent, if any authorization is required, or if there are batch size limits or other side effects. This is insufficient for a destructive operation.
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 sentence, extremely concise, and front-loaded. Every word earns its place, conveying the essential purpose without waste.
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 well-documented parameter and no output schema, so the description meets minimal viability. However, it lacks explicit notes on permanence, error behavior, or batch constraints, which would be important for a delete operation without 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 description coverage is 100% for the single parameter postUuids, and the description 'Array of post UUIDs to delete' fully explains it. The tool description adds no additional meaning beyond the schema, so the baseline 3 is appropriate.
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 (delete) and the resource (multiple posts), distinguishing it from the sibling tool mixpost_delete_post. The purpose is unambiguous and specific.
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 implies usage for batch deletion of posts, which provides clear context. However, it does not explicitly mention alternatives or when not to use it, though the context signals and sibling tools make this inferable.
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?
No annotations are provided, so the description carries the full burden for conveying safety and side effects. 'Get details' strongly implies a read-only operation, but the description does not explicitly state that it is non-destructive, nor does it disclose error behavior (e.g., 404 if not found) or whether any cached data is involved. It provides a basic level of transparency.
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, clear sentence with no redundant words. It front-loads the primary action ('Get details') and resource ('specific social media account'), making it highly efficient and easy to parse.
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?
The tool is simple with only one parameter and no output schema or annotations. The description adequately communicates the purpose, but it does not specify what 'details' includes or what the response structure looks like. Given the tool's simplicity, this is acceptable, though additional information on return format would make it fully 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?
Schema description coverage is 100% for the single parameter 'accountUuid', which already fully explains what to pass. The description adds no extra meaning beyond the schema, aligning with the baseline score of 3 for high 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 retrieves details of a specific social media account, with the word 'specific' indicating a single entity by ID. This distinguishes it from sibling tools like mixpost_list_accounts, making the purpose unambiguous.
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 usage for retrieving a single account's details but provides no explicit guidance on when to use this tool versus alternatives (e.g., list_accounts) or any prerequisites/exclusions. The usage context is inferred from the verb and resource, not stated directly.
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 burden of behavioral disclosure. It states 'all tags', which implies a complete read-only operation, but it does not cover potential pagination, ordering, or response format. The description adds minimal context beyond the purpose, but the read-only nature is discernible.
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, concise sentence with no wasted words. It is appropriately short for a parameterless list operation and gets straight to the point.
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 simple, parameter-free list tool, the description sufficiently conveys the core action. It lacks an explicit mention of the response format, but given there is no output schema and the action is straightforward, the description is adequately complete for the task complexity.
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 zero parameters, so the description does not need to explain any. The input schema is empty, and the description covers everything there is to know about inputs. Per the rubric, 0 parameters yields a baseline of 4.
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 the specific verb 'List' with the resource 'tags' and clarifies scope with 'all tags in the workspace', making the tool's action unambiguous. It clearly distinguishes from sibling tools like mixpost_get_tag by indicating a list-all operation rather than retrieving a single tag.
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 such as mixpost_get_tag for a single tag, or any other tag-related tools. There are no explicit context cues 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It indicates a read operation (list) and the scope of results (all connected accounts), but does not mention pagination, return format, authentication requirements, or potential limitations. This is acceptable for a simple list operation but lacks richer context.
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, focused sentence that communicates the tool's purpose and scope without any fluff. Every word contributes meaning, and the structure is immediately understandable.
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 tool with no parameters, no annotations, and no output schema, the description adequately communicates the tool's behavior: it returns all connected accounts in the workspace. It could potentially mention the return type or relationship to mixpost_get_account, but the description is sufficient for a straightforward list operation.
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 zero parameters, and the schema is fully described with 100% coverage. The description adds no conflicting or additional parameter information, which is appropriate given the no-parameter design. The baseline of 4 for zero-parameter tools is met.
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: listing all connected social media accounts in the workspace. The verb 'list' is specific, the resource ('accounts') is explicit, and the scope ('all connected social media accounts in the workspace') distinguishes it from a tool like mixpost_get_account that retrieves a single account.
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 when to use the tool (when you need all connected accounts), but provides no explicit guidance about alternatives or exclusions. For example, it does not mention mixpost_get_account for retrieving a single account, nor does it state when not to use this tool.
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:

[![mixpost-mcp-server MCP server](https://glama.ai/mcp/servers/pfarag/mixpost-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/pfarag/mixpost-mcp-server)

Score Badge

Copy to your README.md:

[![mixpost-mcp-server MCP server](https://glama.ai/mcp/servers/pfarag/mixpost-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/pfarag/mixpost-mcp-server)

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/pfarag/mixpost-mcp-server'

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