QPost MCP
Server Quality Checklist
Latest release: v0.2.0
- Disambiguation5/5
Each tool has a clearly distinct purpose: account listing, post CRUD, and retry. No two tools could be confused, as create/list/get/update/delete/retry operate on different actions and list_connected_accounts is separate.
Naming Consistency5/5All tool names follow the same snake_case verb_noun pattern (list_, create_, get_, update_, delete_, retry_). This is highly predictable and consistent.
Tool Count5/5Seven tools is well-scoped for a social media posting server. Each tool earns its place, covering the essential operations without unnecessary bloat.
Completeness5/5The set covers the full lifecycle of posts: create, list, get, update, delete, plus retry for failures and account listing for platform awareness. No obvious gaps for the stated purpose.
Average 3.9/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 18 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.
This server has been verified by its author.
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, the description carries full burden for side effects. It only says 'retry' without disclosing what that entails (e.g., whether it creates a new publishing attempt, updates status, or is idempotent). This leaves the agent uncertain about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is concise and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple with one parameter and no output schema, the lack of behavioral details and the vague parameter meaning mean the description is not fully complete for an agent to safely invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'id' parameter with no documentation. The description implies 'id' refers to the post that previously failed, adding some meaning, but it does not clarify if this is the post ID or an attempt ID, nor does it provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (retry) applied to a specific resource (publishing a post) with a precondition (previously failed). This distinguishes it from sibling tools like create_post or update_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously failed' gives a clear condition for when to use the tool. However, it does not explicitly name alternatives or state when not to use it, so it lacks 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, the description is the sole source of behavioral disclosure. It mentions the ownership constraint but fails to explain consequences of failing ownership checks, side effects of status changes, or whether updates are reversible. This is minimal transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the updatable fields and includes an ownership caveat. Every word contributes meaning with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with five parameters, no annotations, and no output schema, the description is far too sparse. It omits critical details like validation rules, state transition behaviors (e.g., posting side effects), error handling for unauthorized use, and expected outcomes, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It maps 'caption, schedule, timezone, or status' to parameters but does not clarify formats, optionality beyond the schema's enum, or the relationship between 'schedule' and 'scheduledFor'. It adds some value but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a post's caption, schedule, timezone, or status, which is a specific verb+resource combination. It distinguishes itself from sibling tools like create_post and delete_post by focusing on modifying an existing post's fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by noting the tool only works on posts the user owns, implying a prerequisite for use. However, it does not explicitly list alternatives or exclusion scenarios, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses two key traits: deletion is permanent and ownership is required. However, it does not mention potential consequences like cascading effects or error responses, which are relevant for a destructive tool. The core behaviors are covered, though not exhaustively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. 'Permanently' and 'you own' are essential qualifiers that add value, and the structure is front-loaded with the action verb. It is a model of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 essential action but leaves out important context such as the meaning of the 'id' parameter and success/failure behavior. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines only an 'id' parameter with no description, and the description does not mention it. Since schema coverage is 0%, the description should clarify that 'id' refers to the post being deleted, but it remains implicit. This creates a gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: 'Permanently delete a post you own.' The verb 'delete' and resource 'post' make the action explicit, and the qualifier 'you own' distinguishes it from sibling tools like list_posts or update_post. This fully captures the tool's unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context—use when you own a post and want to permanently remove it—but does not explicitly mention alternatives or exclusions. There is no guidance such as 'use update_post to modify instead' or 'do not use for posts you don't own,' leaving the decision-making to inference.
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, the description carries the full burden. It adds context about the response including publish status, but doesn't disclose permissions, error cases, or other operational behaviors. It's not contradictory, but it's minimal for a full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, front-loaded sentence with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool with no output schema, the description covers the core purpose and key return detail (publish status). It's not exhaustive but sufficient for the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that 'id' is the post identifier, but beyond restating the parameter name, it adds little detail about format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'single post by ID', clearly distinguishing it from sibling tools like list_posts. It also adds useful scope by mentioning per-platform publish status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use when you need a single post by ID. It doesn't explicitly contrast with list_posts or other tools, nor does it state when not to use it, so it's not fully explicit.
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 burden. The verb 'List' implies a read-only operation, but the description does not explicitly state non-mutating behavior, pagination, return format, or other caveats. It adds little beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no unnecessary words. It is front-loaded and directly states the core action and filtering options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional parameters, no output schema), the description covers the essential usage. It mentions the account scope and filter dimensions. Minor gaps like pagination or return format are not critical for a simple list tool, but without annotations there is room for more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by saying 'optionally filtered by status or platform,' indicating the parameters are filters. However, it does not explain enum semantics or default behavior; the schema provides the allowed values. This adds some meaning but is not extensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction: 'List posts on this QPost account, optionally filtered by status or platform.' It clearly distinguishes from siblings like list_connected_accounts (which lists accounts) and get_post (which retrieves a single post).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to list posts, with optional filters. It does not explicitly mention alternatives or when not to use this tool, relying on the name and resource reference to differentiate it from siblings like update_post or get_post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: media is fetched from remote URLs or read from disk, exactly one media source per call, and omitting scheduledFor publishes immediately. This goes beyond schema information, though it does not cover error handling, authentication, or side effects like partial failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences) and front-loaded with the tool's primary action. It avoids redundancy with the schema and earns every word by explaining media constraints and scheduling behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main creation flow and scheduling, but with no output schema, it omits what the caller should expect in return (e.g., post IDs, confirmation of scheduling). It also doesn't mention timezone or carousel options, though those are in the schema. The lack of return/error information leaves a gap for a tool with 10 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful clarification: mediaUrl is server-fetched while mediaPath is read from disk, exactly one media source is required, and scheduledFor omitted means immediate publish. This enriches the parameter meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Create and publish') and resource ('post') along with target platforms (YouTube, TikTok, Instagram). It distinguishes this tool from siblings like update_post and delete_post by focusing on creation and immediate/scheduled publishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 (creating new posts) and even explains scheduling vs. immediate publishing. It does not explicitly name alternatives or exclusions, but the intended use is unambiguous given the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description is the sole source of behavioral information. It discloses that the output includes 'connection status,' adding useful context beyond the verb 'List.' While it does not explicitly state that this is a read-only operation, the nature of 'List' makes that clear, and no side effects are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first states the tool's purpose and scope, the second provides usage context. Every clause earns its place with no wasted words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description fully covers the needed context: what is listed (specific platforms), the scope (QPost account), and a key attribute of the output (connection status). The sibling tools are all about posts, so there is no ambiguity about when this tool is relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description correctly does not spend space on parameters, as there is nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource ('the social media accounts... currently connected to this QPost account') and mentions the key detail of including connection status. It is clearly distinct from the sibling tools, which all operate on posts rather than account connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Call this before creating a post to know which platforms are actually available.' This tells the agent exactly when to use the tool and why, which is sufficient for a tool with no relevant siblings.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/arslan2012/qpost-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server