Solnk MCP

Official

by solnk-dev

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.0.3
Disambiguation5/5
Each tool has a distinct purpose: media upload methods are clearly separated by source (URL vs local file), publishing operations are split into create, confirm, and cancel, and analytics, status, usage, accounts, and lists all address different needs without overlap.
Naming Consistency5/5
All tools follow the 'solnk_' prefix and consistent snake_case with verb_noun patterns (e.g., confirm_publish, get_usage, list_accounts). The two media creation tools are clearly distinguished by suffix (_from_url vs _upload).
Tool Count5/5
11 tools is appropriate for a publishing platform, covering media upload, publishing lifecycle, analytics, accounts, and usage. Each tool serves a clear role without being excessive or insufficient.
Completeness4/5
The tool set covers the main workflow: list accounts, check usage, upload media, create/confirm/cancel publish, get status and analytics. Minor gap: no direct edit/update for a draft publish, though cancel and re-create may suffice.
Average 3.9/5 across 11 of 11 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behaviors such as pagination (page, page_size params), default ordering, or what 'recent' means. No mention of read-only property or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It could be expanded to include key filtering or pagination details 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?
With 6 parameters and no output schema, the description is too minimal. It does not cover return value format, pagination details, or how filters interact. Sibling tools are contextually related but not addressed.
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 17% (only created_after has a description). The description adds 'optional filters' but does not explain individual parameter meanings (e.g., status values, platform enumeration, account_id usage).
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 recent publishes with optional filters' clearly states it retrieves a list of publishes and mentions filtering. It is distinct from sibling tools which handle publishing actions (cancel, confirm, publish) and analytics.
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 on when to use this tool versus alternatives like solnk_get_publish_status (which retrieves a single publish status) or solnk_list_accounts. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It states the primary action but lacks details on side effects, prerequisites, error handling, or idempotency, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words; the purpose is front-loaded and the usage clause is clear. Every word earns its place.
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 2 parameters, no output schema, and the tool's simplicity, the description covers the essential behavior but omits output format and error scenarios, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds slight value for scheduled_at by rephrasing the schema's description, but does not explain publish_id. With 50% schema coverage, the description does not fully compensate.
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 confirms a draft publish to make it go out. It distinguishes from siblings like solnk_cancel_publish and solnk_publish by implying a two-step process, but does not explicitly contrast.
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 explains when to omit or pass scheduled_at but does not specify when to use this tool over solnk_publish or other siblings. Usage context is implied but not explicit.
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, description must disclose behavior fully. It states the constraint on state but does not explain side effects, error conditions, or return value for this mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy, front-loading the purpose and key limitation efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core purpose and constraint but lacks parameter documentation and return behavior, making it incomplete for a simple cancel operation with no output schema.
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 coverage is 0% and description fails to explain the publish_id parameter, leaving the agent without guidance on what value to provide.
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 'Cancel' and the resource 'draft or not-yet-sent scheduled publish', distinguishing it from siblings like solnk_publish and solnk_confirm_publish.
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?
Explicitly specifies when to cancel (draft or scheduled not yet sent) and when not to (already processing or published), providing clear usage context. Lacks mention of alternatives but sufficient given sibling list.
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 explains the different outputs for each mode, including engagement and URLs, but does not disclose side effects, read-only nature, rate limits, or pagination behavior beyond schema details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no fluff, and front-loads the primary action. Every word serves a purpose.
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?
Given the complexity of two modes and no output schema, the description provides useful detail on return types (rolled-up metrics, per-platform breakdown with URLs and engagement). However, it omits mention of pagination parameters present in the schema, so completeness is slightly lacking.
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 low (25%). The description adds meaning for post_id by explaining its effect on output, but does not explain page or page_size parameters, which are left to the schema. It partially compensates but not fully.
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 'Get post performance' and distinguishes two modes based on whether post_id is provided. This specificity and differentiation from sibling tools (e.g., get_publish_status) makes the purpose very clear.
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 guidance on when to use each mode (without/with post_id) but does not mention when not to use the tool or suggest alternatives among the many sibling tools, which would improve decision-making.
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 must fully cover behavioral traits. It discloses the returned fields and implies a read-only operation. However, it does not mention auth requirements, rate limits, or whether the list is paginated. This is adequate but not thorough.
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 two sentences: the first states what the tool does and the fields returned, the second gives a clear usage directive. Every sentence is meaningful, no redundancy.
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?
Given the tool's simplicity (list operation, two optional filters) and no output schema, the description sufficiently covers the core functionality. It does not explain filtering behavior or sorting, but the context signals (2 enum parameters, no required params) make the tool straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 optional parameters (platform, status) with enums. Schema description coverage is 50% (status has a description). The tool description adds no parameter details beyond the schema, so it meets the baseline but provides no extra value for parameter semantics.
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 (user's connected social accounts), and the specific fields returned (id, platform, username, status, capabilities). It distinguishes from sibling tools like solnk_publish or solnk_list_publishes by focusing on account listing rather than 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 explicitly advises 'Call this first to get account_id values for publishing.' This gives clear context for when to use the tool. However, it lacks explicit exclusions or alternatives, so it doesn't fully meet the criteria for a 5.
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 provided, so description is the sole source. Describes a simple read operation but lacks details on authentication, rate limits, or return format.
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?
Two concise sentences, each serving a purpose. No unnecessary words.
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?
Tool has no output schema; description does not mention return fields (e.g., can_publish, limits). For a parameterless tool, it is adequate but not fully informative.
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?
No parameters exist, so the description is not required to add parameter information. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets plan limits and usage, with a specific verb and resource. Distinguishes from sibling publish-related tools.
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?
Explicitly advises to check `can_publish` before publishing, providing a clear use case. However, does not mention when not to use or alternatives.
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?
Describes core behavior: verifies file and marks media ready. No annotations provided, so description carries burden; lacks details on error handling or idempotency but is adequate for a finalization step.
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?
Two sentences, front-loaded with action, no unnecessary words, and clear logical flow: prerequisite, action, output usage.
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?
Given the single parameter and no output schema, the description provides sufficient workflow context (prerequisite and next step). Could mention failure scenarios, but overall complete for its simplicity.
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?
Schema covers 100% of parameters with description; the description adds contextual meaning by linking media_id to solnk_create_media_upload and solnk_publish, enhancing understanding beyond schema.
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?
State specifically 'Finalize a presigned upload' referring to the upload process from solnk_create_media_upload, and distinguishes from siblings by mentioning prerequisite and next-step tools.
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?
Explicitly instructs when to use: after PUT to upload_url from solnk_create_media_upload, and that output media_id is for solnk_publish. No explicit exclusions or alternatives, but context is clear.
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?
Without annotations, the description bears full burden. It discloses that Solnk fetches and stores server-side and returns a media_id. However, it does not mention failure modes (e.g., invalid URL), idempotency, or side effects, which is a gap for a creation 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?
Three sentences, front-loaded with main function, no wasted words. Every sentence adds value.
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?
Given no output schema and no annotations, the description covers input, process, output (media_id), constraints, and sibling relationship. It lacks details on error handling or storage duration but is adequate for a simple fetch-and-store tool.
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 coverage is 50%. The description repeats the url parameter description from the schema and lists allowed types for content_type in a friendlier format, adding some value but not fully compensating for the missing parameter description in the schema.
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 attaches an image or video by public URL, explicitly distinguishing it from the sibling solnk_create_media_upload which handles local files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for URLs) and when not (for local files, use the sibling), along with file size and type constraints.
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 explains that the tool returns a presigned upload_url and media_id, outlines the subsequent steps (PUT with Content-Type header), notes the URL expiration (15 min), and mentions file limits. It does not cover error cases or authorization, but provides substantial behavioral detail.
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 concise (single paragraph), front-loaded with the main action, and every sentence adds value. It efficiently conveys steps, alternatives, and limits without unnecessary words.
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?
Given the multi-step upload process and no output schema, the description effectively explains the entire workflow and ties to sibling tools. It lacks description of the output format or error handling, but covers essential contextual information for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so the baseline is 3. The description does not add parameter-level information beyond the schema's own descriptions (e.g., filename, size_bytes have schema descriptions). It contextualizes parameters in the workflow but does not elaborate on each parameter's semantics. Adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: uploading a local image/video file via a 3-step process. It distinguishes itself from the sibling solnk_create_media_from_url by specifying local file vs public URL. Limits (500 MB, allowed types) are provided.
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 explicitly states when to use this tool (local file) and when to use the alternative (solnk_create_media_from_url for public URLs). It outlines the required steps after calling this tool. It does not give explicit 'do not use' conditions but provides sufficient guidance.
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?
No annotations provided, so description carries full burden. It discloses the return values (aggregate status with enumerated possibilities). Although it doesn't explicitly state non-destructiveness, the 'get' verb implies it. Would benefit from mentioning it's read-only.
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?
Two sentences: first describes the tool's function and possible statuses, second provides a usage alternative. No redundant words, highly efficient.
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 simple get-status tool with one parameter and no output schema, the description covers purpose, possible return values, and provides a sibling alternative. No major gaps given the tool's simplicity.
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%, and the description does not add any information about the parameter 'publish_id' beyond its name in the schema. The parameter is simple but the description fails to explain its purpose or format.
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 states the specific verb 'Get' and resource 'aggregate status of a publish', and distinguishes from siblings by listing possible statuses and mentioning an alternative for per-platform details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'For per-platform post URLs and engagement, use solnk_get_post_analytics', providing clear when-not-to-use and an alternative. It also lists possible statuses, aiding in decision-making.
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. It discloses the three publish modes and mentions that per-target overrides are possible, but it does not cover authentication requirements, rate limits, or what happens on success (e.g., returns a publish ID). The behavioral description is functional but not exhaustive.
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 two sentences, front-loads the primary verb and scope, and every phrase adds value (modes, next steps, constraints). Zero wasted words.
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?
Given the tool's complexity (6 parameters, nested `targets` object, enum), the description covers the essential workflow and mode distinctions. It names the follow-up tool for drafts. It does not describe the return format (e.g., a publish ID), but with no output schema, this is acceptable. A brief return note would make it a 5.
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?
Schema coverage is high (83%), so the baseline is 3. The description adds value by explaining the role of `publish_mode` in the workflow, the override relationship between top-level and per-target `content`/`media_ids`, and provides a reference link for `platform_settings`. This goes beyond simple schema repetition.
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 starts with a clear action verb ('Publish') and resource ('content'), specifies scope ('one or more platforms'), and distinguishes from sibling tools like `solnk_confirm_publish` and `solnk_cancel_publish` by naming them explicitly in the usage guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use each `publish_mode` ('draft' to stage, 'scheduled' with `scheduled_at`, 'immediate') and names the sibling `solnk_confirm_publish` as the tool to follow after drafting, providing clear alternative context.
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:

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

Score Badge

Copy to your README.md:

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

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