Skip to main content
Glama

Zernio

by com.zernio

Check upload status and get file URLs

media_check_upload_status
Read-only

Check the status of an upload token and get uploaded file URLs.

Use this after the user has uploaded files through the browser upload page. Returns: pending (waiting for upload), completed (files ready), or expired (token expired).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesThe upload token from media_generate_upload_link (required)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the operation as read-only and non-destructive. The description adds meaningful behavioral context by enumerating the possible statuses (pending, completed, expired) and indicating that file URLs are returned once complete.

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 only a few sentences long, front-loads the core purpose, and then provides actionable usage and return-value context without unnecessary detail. Every sentence contributes.

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?

The tool is simple, has only one required parameter, benefits from an output schema, and carries read-only annotations. The description adds the missing workflow context and status semantics, making it complete for an agent to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The token parameter is already fully described in the schema, including its source. The description restates that a token is involved but adds no new structural or format details, so the schema carries the parameter documentation weight.

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 a specific verb and resource: checking the status of an upload token and retrieving file URLs. It clearly describes the tool's outcome and differentiates it from the related generation flow by mentioning the browser upload stage.

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 tells when to use the tool: after the user has uploaded files through the browser upload page. It does not name alternatives or state when not to use it, but the usage context is clear enough for an agent to select it appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Zernio toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.7/5.0
Disambiguation3/5

Many tools are clearly separated by domain prefix, but several overlap: posts_publish_now duplicates posts_create's publish_now mode, posts_edit_post vs posts_update is confusing without reading both descriptions, and analytics_get_analytics broadly overlaps the more specific analytics metrics tools. The descriptions do help disambiguate, but the large number of similar post/analytics helpers still creates selection risk.

Naming Consistency3/5

Most tools follow a readable lower_snake resource_verb format, with domains like accounts_, posts_, profiles_, and queue_. However, there is notable drift: redundant suffixes (queue_create_queue_slot, tracking_tags_get_tracking_tag_stats), singular/plural mismatch (account_groups_ vs accounts_), non-prefixed helpers (call_tool, search_tools, docs_search), and paired verbs that seem arbitrary (posts_edit_post vs posts_update). It is readable but not cleanly consistent.

Tool Count2/5

51 tools is far above the range where an agent can quickly select the right one, and many entries are wrappers or variants: publish_now, edit_post, retry_all_failed, and multiple analytics/queue helpers could be consolidated. The broad domain justifies more tools than a tiny server, but this count is excessive and will add navigation overhead.

Completeness4/5

The server covers the core social media management lifecycle well: profiles, accounts, posts, scheduling, queueing, analytics, comments, mentions, media uploads, tracking tags, and usage billing are all represented. There are minor gaps—tracking tags are read-only, there is no direct account connection/disconnection flow, and published-post deletion is unsupported—but agents can complete the main workflows with these tools.

Resources