Publer MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes. Some slight overlap exists between schedule_post and schedule_posts_bulk (single vs bulk), and publish_with_media is a convenience wrapper that could be confused with upload+schedule workflows, but descriptions generally clarify these boundaries.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., get_post, list_media, upload_media_from_url). The naming is predictable and makes the action and target resource clear across the entire set.
Tool Count4/5
At 24 tools, this is slightly above the 'typically 3-15' sweet spot but still reasonable for a comprehensive social media management server covering posts, media, accounts, presets, analytics, and utilities. No tool feels entirely redundant.
Completeness5/5
The tool surface covers the full post lifecycle (create/schedule/publish, read, update, delete), media management (upload, list, delete), account and workspace management, plus supporting analytics and validation features. No critical gaps are apparent.
Average 2.9/5 across 24 of 24 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention whether the tool immediately publishes, how splitting works (e.g., character limits, paragraph handling), or what the output/return value is. This is a significant gap for a tool that likely has side effects.
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. Brevity does not offset the lack of substantive information; this is not conciseness but emptiness.
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?
With three parameters, no output schema, and zero annotations, the description fails to provide necessary context. It does not explain the splitting behavior, platform requirements, numbering option, or expected result. For a tool with this complexity, the description is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions no parameters. It does not clarify the meaning of 'text', 'platform', or 'includeNumbering' beyond the parameter names, which are ambiguous (e.g., which platforms are supported?). The description adds no value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Split long text into a thread' clearly identifies the verb 'split' and the resource 'content into a thread', giving a basic sense of the operation. However, 'thread' is ambiguous and it does not differentiate this tool from siblings like schedule_post or publish_post_now.
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 versus alternatives. The description implies a use case (splitting long text) but provides no context, prerequisites, or exclusions.
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 of behavioral disclosure. 'Upload a local file' provides no information about side effects, required permissions, return values, or how parameters like in_library and direct_upload affect behavior. This is a severe gap for a mutation-type 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 short, but it is under-specified rather than appropriately concise. It restates the tool's name without adding value, and no structure exists to convey necessary context.
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 has 3 parameters, no output schema, and no annotations, the description is woefully incomplete. It fails to explain what the tool does with the file, what the parameters control, or what the outcome will be, making it unsafe for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters with 0% description coverage, and the description does not compensate by explaining any of them. It does not mention file_path, in_library, or direct_upload, leaving the agent with no semantic understanding beyond raw names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Upload' and specifies 'a local file', which conveys the basic action and somewhat differentiates from the sibling upload_media_from_url. However, it is extremely terse and does not clarify the upload target or that it pertains to media, relying on the tool name for 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 given about when to use this tool versus alternatives like upload_media_from_url or publish_with_media. The description simply states the action without any contextual or exclusionary information.
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 full responsibility for behavioral disclosure, but it only states 'Manage reusable groups' without revealing any side effects, permissions, or return behavior. No mention of create/delete implications or whether actions are persistent.
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 a single concise sentence with no fluff, but it adds little value over the tool name itself. It's under-specified rather than efficiently informative.
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 complexity (3 parameters, an enum, no annotations/output schema), the description is far too sparse. It doesn't describe how actions work, what account_ids refer to, or what a successful operation returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. None of the parameters (name, action, account_ids) are explained, and with 0% schema description coverage, the agent receives no help understanding what these fields represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (reusable groups of social accounts) but uses the vague verb 'manage', which doesn't specify the actual operations. It distinguishes from sibling tools like list_accounts by focusing on groups, but could be more explicit about the actions (list, create, delete).
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 any prerequisites, exclusions, or context where this tool is preferred over list_accounts or other account-related tools.
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 disclosing behavioral traits. It only states 'List media assets' without mentioning pagination, filtering, permissions, return format, or any side effects, offering virtually no 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than conciseness. It lacks structural elements like parameter details or usage context, making the single phrase insufficient for an agent to invoke the tool correctly.
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 has 6 parameters, no annotations, and no output schema, the description is severely incomplete. It fails to explain filters, pagination, or what the response will contain, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the six parameters. It does not mention any of them (ids, page, used, types, search, source), leaving the agent to guess their meaning from names alone.
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 'List media assets' clearly indicates a listing operation for media resources. It is specific in verb and resource but lacks any scope or differentiation from sibling tools such as list_posts, so it does not fully distinguish itself.
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 any use cases, restrictions, or alternative tools that might be more appropriate for specific 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?
The description discloses only that it supports auto_adapt threading. With no annotations, there is no information about side effects, permission requirements, or what happens upon creation, so the agent is left unaware of critical behavioral traits.
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 brief, which is concise in word count but severely under-specified for a tool with 8 parameters and nested objects. It lacks the structure needed to convey essential information, making it an underspecification rather than true conciseness.
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 has no annotations, no output schema, and 8 parameters, the one-sentence description is grossly incomplete. It does not explain return values, usage context, or parameter relationships, so the agent cannot reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no explanation for parameters such as account_ids, text, scheduled_at, or state. The only hint is for auto_adapt, but even that is vague, leaving most parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a scheduled post, which is a specific action. However, it does not explicitly distinguish itself from sibling tools like schedule_posts_bulk or publish_post_now, relying mostly on the tool name for differentiation.
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 implies scheduling but does not mention scenarios like bulk scheduling or immediate publishing, leaving the agent without decision criteria.
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 must carry full behavioral disclosure. 'Update an existing post' reveals no operational traits such as whether it performs a partial or full update, which fields are affected, whether it requires authorization, or what happens on invalid input. This 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four words, which is under-specification rather than effective conciseness. It front-loads the main action but fails to provide any accompanying context or detail that would justify such brevity. Every sentence should earn its place, but here valuable information is omitted entirely.
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?
For a tool with 6 parameters, no annotations, and no output schema, the description is severely underwhelming. It does not explain the semantics of the parameters, the expected side effects, return format, or error conditions. The description is far too sparse to support safe and correct invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter roles. It does not mention text, label_ids, media_ids, account_ids, or scheduled_at, leaving the meaning of the six schema parameters entirely to the developer. The description adds no value beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing post' clearly states the specific action (update) and the target resource (existing post), which distinguishes it from sibling tools like get_post, delete_post, schedule_post, and publish_post_now. It is concise and unambiguous in identifying the tool's core 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used for editing existing posts rather than creating new ones, nor does it reference any excluded scenarios or preferred sibling tools. The only hint is the name itself.
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 present, so the description carries the full burden of behavioral disclosure. It only indicates an upload (a write operation) but does not mention authentication requirements, side effects, rate limits, or the difference between in_library and direct_upload. The description adds minimal behavioral context beyond what the name and schema already imply.
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 short sentence, which is concise but severely under-specified for a tool with three parameters. It is front-loaded and lacks wasteful text, but the extreme brevity leaves out essential information, making the conciseness counterproductive.
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?
For a tool with no output schema and no annotations, the description should clarify inputs, behavior, and return value. It explains none of these. The three parameters remain vague, and the tool's role in the media management workflow is not established. The description is inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the parameters. It only mentions 'URLs', which maps to the 'url' property, but fails to explain the required media array structure (url+name), or the boolean parameters in_library and direct_upload. The description adds virtually no semantic value beyond the schema field names.
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 ('Upload') and resource ('media') with a source qualifier ('from URLs'), which distinguishes it from the sibling tool upload_media_file (which handles file uploads). However, it does not clarify whether the upload targets a library or direct publication, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like upload_media_file or publish_with_media. It simply states the action without any contextual triggers, 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?
No annotations are provided, and the description does not disclose whether this is a read-only operation, whether permissions are needed, how date ranges are handled, or what the response format is. The word 'Get' implies read-only, but it is not explicitly stated, and no other behavioral context is given.
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 brief, which is concise, but it sacrifices necessary substance. For a tool with no annotations and an uninformative schema, this brevity is under-specification rather than good conciseness.
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, no annotations, and a vague description, the agent is left without enough context to select and invoke the tool correctly. It does not specify what metrics are returned, whether historical data is included, or how errors are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for the parameters 'from', 'to', or 'account_id'. It is unclear if 'from'/'to' are date ranges, what format they expect, or how 'account_id' selects the account. The parameter names are mildly self-explanatory but the description does not confirm or explain them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get detailed performance metrics' – it identifies a verb and a general resource (metrics) but does not specify the entity (post, account) or the kind of metrics. The tool name suggests post insights, but the description alone is ambiguous and does not distinguish it from other analytics-related siblings like get_best_times.
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 about when to use this tool versus alternatives such as get_post, get_best_times, or list_posts. It does not mention use cases, 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 provided, the description must carry the full burden of behavioral disclosure. It only says 'list posts', which implies a read-only operation but does not disclose pagination behavior, default ordering, how filters behave, or any rate limits. The absence of any safety or side-effect information is a notable gap for a tool with nine parameters.
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 a single, concise sentence that is easy to read and front-loads the primary action. However, it is under-specified given the tool's complexity, and the brevity comes at the cost of necessary detail. It is not overly verbose, but the minimalism limits its usefulness.
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?
The tool has 9 optional parameters, no output schema, and no annotations, yet the description provides no information about filters, pagination, return format, or any constraints. This is highly inadequate for a tool with such a rich input schema. The description fails to provide comprehensive context for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It only says 'optional filters' without elaborating on any of the nine parameters (to, from, page, query, state, states, postType, member_id, account_ids). This provides no additional meaning beyond the bare schema, leaving users to guess parameter formats and semantics.
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 posts') and a key feature ('with optional filters'). It is distinguishable from sibling tools like get_post, which retrieves a single post, and update_post, which modifies a post. However, it does not explicitly mention the scope of posts (e.g., across workspaces or accounts), which could be ambiguous.
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 get_post or schedule_post. It vaguely mentions 'optional filters' but does not explain what filters are available or when they would be used. There is no mention of exclusions or preferred use cases.
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 'Bulk delete media assets' without disclosing behavioral traits such as irreversibility, impact on existing posts that may reference the media, permission requirements, or whether the deletion is permanent. With no annotations provided, the description carries the full burden but fails to convey critical safety information 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at six words and is front-loaded with the action. However, its brevity omits essential usage and safety details, making it under-specified rather than optimally concise. A slightly longer description could include necessary context without losing efficiency.
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 bulk delete operation with no annotations, no output schema, and minimal parameter detail, the description is incomplete. It does not address effects, prerequisites, or error behavior. The presence of sibling tools like list_media and delete_post suggests that more context about scope (e.g., which workspace or account) and relationship to posts is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single 'media_ids' array, but the description does not explain that these are the IDs of media to delete, nor any constraints (e.g., format, count, or association with a specific workspace/account). With schema description coverage at 0%, the description should compensate for this gap but does not.
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 ('delete') and the target resource ('media assets'), with 'bulk' indicating multiple items. This distinguishes it from sibling tools like delete_post (for posts) and upload_media_file (for uploads), though it lacks detail on what exactly qualifies as a media asset.
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 usage guidance is provided. There is no mention of when to use this tool, prerequisites, or alternatives. It does not compare to cleanup of posts or uploads, and the context of bulk deletion is left entirely to the user's interpretation.
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 behavioral disclosure. It mentions 'immediately' and 'auto_adapt threading' but fails to explain side effects, permissions, rate limits, return values, or what auto_adapt threading actually does. The mutation nature is implicit but vague.
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?
A single, tightly worded sentence with no filler. The parenthetical adds a useful feature note. Every word 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 tool with 6 parameters, a nested networks object, and no output schema, the description is severely under-specified. It does not explain required fields, return values, or the structure of nested objects, leaving the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meanings. It only hints at auto_adapt threading, which likely maps to the auto_adapt parameter, but leaves the other five parameters (text, networks, media_ids, account_ids, follow_up_text) without any semantic explanation.
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 'Publish a post immediately' – a specific verb and resource. It clearly distinguishes from scheduling tools like schedule_post by emphasizing 'immediately'. However, it does not explicitly distinguish from publish_with_media or other immediate publishing variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like schedule_post or publish_with_media. There are no exclusions, prerequisites, or contextual hints for 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?
There are no annotations, so the description must disclose behavioral traits. It only states a 'heatmap' is returned without explaining whether the operation is read-only, how 'optimal' is determined, what time range is covered, or if any special permissions are needed. This is minimal behavioral context.
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, front-loaded sentence with no fluff. It is appropriately concise for a simple tool, though it could be slightly more detailed without becoming verbose.
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, this description is the only spec. It fails to explain what the heatmap contains, how to interpret it, or what account_id is used for, making the tool incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, account_id, with 0% description coverage. The description does not mention this parameter or explain its role, so the agent must infer its meaning from the parameter name alone. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'heatmap of optimal posting times', which is a specific resource and action. It distinguishes itself from siblings like get_post_insights by focusing on optimal times rather than post performance.
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 any prerequisites, use cases, or exclusions, leaving the agent to infer when this is 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 provided, the description carries full responsibility for behavioral disclosure. It does not mention whether the operation is read-only, what happens if the job_id is invalid, or what the response structure looks like. The description is too minimal to convey the tool's behavior beyond the basic action.
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, front-loaded sentence with no redundant words. It earns its place by stating the core purpose efficiently. However, it may be too terse, missing valuable context that could be added without harming conciseness. Still, for a simple tool, the length is appropriate.
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 is simple (1 parameter, no output schema, no annotations), but the description is still incomplete. It does not explain what the returned status values are, error conditions, or the context in which this job-status check is used (e.g., after scheduling). The absence of an output schema increases the need for description to cover return values, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate by explaining the parameter. The description does not mention 'job_id' at all, relying solely on the schema. While the parameter name is self-explanatory, the description adds no meaning about where to obtain the job_id or accepted formats, leaving a gap in understanding.
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 function with a specific verb ('Check') and resource ('status of an asynchronous Publer job'). It distinguishes itself from sibling tools, none of which are related to job status checking. The wording is unambiguous and direct.
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, nor does it mention prerequisites or exclusions. It simply says what the tool does, leaving the agent to infer that it should be used when a job_id is available. No alternative tools or contexts are referenced.
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?
There are no annotations, so the description must disclose behavior. 'Sanity check' implies a non-mutating read operation, but it doesn't state whether it returns a boolean, list of errors, or any details about side effects. No information about output or what constraints are checked.
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, tightly-worded sentence that front-loads the core purpose without any filler. It wastes zero words and follows the pattern of minimal, focused descriptions.
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?
Despite the apparent simplicity of a validation tool, the description lacks essential contextual information: no return format, no mention of how media_count/media_types are validated, and no usage prerequisites. Combined with no annotations and no output schema, the tool is under-specified for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the four parameters (text, platform, media_count, media_types). The schema only provides types with no semantic context, and the description adds no meaning. The agent cannot infer what values are expected or how they interact.
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 'Sanity check' with a clear resource 'post' and context 'platform constraints', immediately distinguishing it from sibling tools like get_post, update_post, or publish_post_now. No ambiguity about what action this tool performs.
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 vs alternatives. It doesn't mention that it should be used before publishing, nor does it reference any sibling tools. The agent is left to infer the use case 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It notes a destructive action ('delete') but fails to mention irreversibility, required permissions, or side effects on related data, which is significant for a delete 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 filler words. It front-loads the action and object, making it easy to parse quickly.
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 single-parameter delete, the description covers the core function adequately. However, it lacks any warning about permanent consequences or expected return behavior, and with no annotations or output schema, a slightly richer description would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, post_id, is a required string. The description says 'by ID' which clarifies the parameter's role, but adds no extra format constraints or handling details. Given the schema has zero coverage, the description provides minimal but sufficient context for a single straightforward parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete' and the resource 'post' identified by ID, effectively distinguishing it from sibling tools like get_post, update_post, and publish_post_now. The phrasing 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?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or restrictions. The description only states what it does, not when it should be chosen over other post-related 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?
No annotations are provided, so the description bears the full burden of disclosing behavior. It only states the action without mentioning authentication requirements, potential errors, return format, or side effects. For a read operation, it does not explicitly confirm 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, concise sentence with no unnecessary words. Every word contributes to the core meaning, and it is front-loaded with the action.
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 no output schema and no annotations, the description should provide more context, such as return value or differentiation from get_post_insights. It is too minimal to fully guide an agent in selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate for parameter meaning. It only repeats 'by ID' which adds little to the schema's post_id property. No additional details like format, requiredness, or where to obtain the ID are given.
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 'Retrieve a specific post by ID' clearly states the action (retrieve), the resource (post), and the scope (by ID), distinguishing it from list_posts which would retrieve multiple posts. It is specific and non-tautological.
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 versus alternatives like list_posts or get_post_insights. The phrase 'by ID' implies a use case but does not explicitly state exclusions or alternatives.
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 does not disclose what the returned instructions include, the format, whether it's static or generated, or any side effects. For a read-only informational tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, direct sentence with no filler. It front-loads the verb and resource, making it easy to parse quickly.
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 no parameters and no output schema, the description is the only source of information. It states what the tool does at a high level but fails to explain what the instructions actually contain or how the agent should use them. This is adequate but minimal, leaving ambiguity about the return value's scope.
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 empty, so there is nothing to explain. Per the baseline rules, a description of a no-parameter tool gets a default of 4; it adequately states the tool's basic action.
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 clear verb ('Get') and identifies the resource ('high-level instructions and best practices'), and the tool name confirms it's about social manager instructions. It distinguishes itself from sibling tools by not performing a social media operation, though it could be more specific about which domain the instructions cover.
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 gives no indication of when to use this tool versus alternatives. There is no mention of prerequisites, expected context, or whether this should be called before other social media operations. It relies solely on the name to imply usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only states the action without disclosing side effects, failure behavior, prerequisites, or what happens after publishing. It also does not mention whether scheduled_at allows scheduling instead of immediate publishing.
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?
Single sentence, concise, and front-loaded with the main action. No redundant information.
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 5 parameters and no output schema, yet the description only gives a brief summary. It lacks guidance on parameter semantics, expected results, or error handling, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter details beyond the concept of media URLs. With a schema description coverage of 0%, the description fails to explain account_ids, text, scheduled_at, or auto_adapt, leaving the agent without essential parameter meaning.
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 combined action: uploading media from URLs and publishing in one step. This distinguishes it from sibling tools like upload_media_from_url and publish_post_now, which perform only one step. The verb phrase 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for combining media upload and publishing, but does not explicitly state when to use this tool versus alternatives like upload_media_from_url followed by publish_post_now. No exclusions or conditions are provided.
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 'schedule multiple posts' and does not disclose potential side effects, validation behavior, error handling, authentication requirements, or what the response looks like. It lacks any detail about whether scheduling is atomic, asynchronous, or reversible.
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, short sentence that clearly communicates the core action with no unnecessary detail. It is front-loaded and efficient.
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?
The tool has a nested array parameter and no output schema, yet the description provides no information about return values, error scenarios, limits, or prerequisites. It is far too minimal for an agent to use effectively beyond the basic intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description merely says 'multiple posts', which maps to the 'posts' array parameter but does not explain the required fields (account_ids, text) or their meaning. The schema shows the structure but no descriptions, so the agent gets little guidance on what a post object must contain.
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 ('Schedule') and resource ('posts') with clear scope ('multiple at once'). It effectively distinguishes this tool from sibling 'schedule_post' by indicating it is for bulk operations.
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 the tool is for scheduling multiple posts in a single operation, which provides clear context for when to use it. However, it does not explicitly mention alternatives like 'schedule_post' for single posts or state when not to use it.
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, and the description adds no behavioral context beyond the operation itself. It does not mention return format, authentication requirements, error behavior, or what fields the profile contains, leaving the agent to infer everything from the name.
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 wasted words. It is concise and immediately understandable.
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 zero parameters and no output schema, the description is minimal. It tells what the tool does but does not specify what 'profile' includes or any response shape, leaving some ambiguity for the agent to resolve.
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 schema has zero parameters with 100% coverage, so there is nothing for the description to compensate for. A baseline of 4 is appropriate for parameterless tools.
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 operation ('Get') and the resource ('profile of the currently authenticated user'), making it distinct from sibling tools that operate on posts, media, or workspaces.
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 alternatives or any exclusions. It simply states the purpose without context on prerequisites, so the agent gets no direct usage direction.
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 burden of disclosure. It adds useful context by specifying 'connected' and 'current workspace', but it does not mention read-only behavior, pagination, or that results can be filtered by provider/capability. This is a moderate level of transparency for a simple list 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, well-structured sentence that immediately conveys the tool's purpose. It contains no redundant words and is appropriately front-loaded with the action verb.
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 straightforward list tool with two optional filters, the description is largely complete. It specifies the resource and scope, and the schema covers the filters. However, the absence of an output schema and annotations means the agent lacks details on return format or safety, but this is not critical for a simple read operation.
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 both parameters, so the baseline is 3. The description adds no extra parameter context, but the schema already provides clear descriptions for provider and capability filters. No compensation is needed.
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 ('list'), the resource ('connected social media accounts'), and the scope ('current workspace'). This distinguishes it from sibling tools like list_posts and list_workspaces, which target different resources.
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 usage is implied by the resource name: use this to retrieve connected accounts. However, there is no explicit guidance on when to choose this over alternatives, nor any exclusion criteria. The description provides context but no direct comparison with sibling tools.
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 full responsibility for behavioral disclosure. It states that the token's access scope determines the results, which clarifies authorization requirements, and 'List' implies a read-only operation. However, it does not discuss potential rate limits, pagination, or response size.
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 directly states the tool's function without any extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does not detail the return format or fields. While the tool is simple with no parameters, the lack of output information is a gap for agents that need to know what data will be returned. It does adequately convey the tool's purpose for selection.
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 input schema has zero parameters, so the schema coverage is complete. The baseline for 0 params is 4, and the description appropriately avoids adding parameter details since there are none.
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 verb 'List' and the resource 'Publer workspaces', and specifies the scope 'the API token has access to'. This distinguishes it from sibling tools like list_accounts which target a different resource type.
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 usage guidance is provided. The description does not indicate when to choose this tool over similar listing tools such as list_accounts or list_posts, nor does it mention any prerequisites or alternative 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-style operation via 'Get' but does not explicitly state it is read-only or safe, nor does it describe any edge cases (e.g., behavior when no platforms are connected) or what 'limits' includes. This leaves room for ambiguity.
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 states the tool's purpose. It is front-loaded with the verb and object, with no unnecessary words or repetition.
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 zero-parameter tool with no output schema, the description covers the core functionality adequately. However, it could be more complete by specifying what kinds of limits (e.g., rate limits, character limits) and whether connected platform details include account names or IDs. Still, given the tool's simplicity, the description is mostly sufficient.
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 parameter meanings. The baseline for zero-parameter tools is 4, and the description adds value by naming the output scope (platforms and limits) which helps set expectations.
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 function: fetching combined platform information and limits. It uses a specific verb ('Get') and resource ('all connected platforms'), distinguishing it from sibling tools focused on posts, accounts, or publishing actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (when needing platform information and limits), though it does not explicitly name alternatives or exclusions. Given the tool takes zero parameters and has no close siblings, this is sufficient guidance.
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, which is good, but it does not disclose details like return format, pagination, ordering, or authorization requirements. Adds only minimal behavioral context beyond the operation itself.
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 that fully states the tool's purpose without any filler. It is appropriately concise for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, simple listing tool, the description is complete. It specifies what is listed (labels) and the scope (in the workspace). No output schema exists, but the outcome is self-evident: a list of labels. No additional context is necessary given the low 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?
There are zero parameters, so the schema is empty. The description does not need to add parameter details, and the baseline of 4 applies. No information is missing about inputs.
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 a clear resource 'labels defined in the workspace', which distinguishes it from sibling tools like list_workspaces, list_accounts, or list_posts. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is provided, but the scope 'in the workspace' implies it is for the current workspace's labels. There are no alternatives mentioned, so usage is only implied by the description.
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:

[![publer-mcp MCP server](https://glama.ai/mcp/servers/pawel-tkaczyk/publer-mcp/badges/card.svg)](https://glama.ai/mcp/servers/pawel-tkaczyk/publer-mcp)

Score Badge

Copy to your README.md:

[![publer-mcp MCP server](https://glama.ai/mcp/servers/pawel-tkaczyk/publer-mcp/badges/score.svg)](https://glama.ai/mcp/servers/pawel-tkaczyk/publer-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pawel-tkaczyk/publer-mcp'

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