Skip to main content
Glama

Viral Manager

list_my_account_posts

Read-only

List the posts published by the org's own connected accounts (My Accounts), newest first by default. viral_only returns the breakthrough posts (posts that beat the org's virality threshold). When presenting posts to the user, always include each post's permalink.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNo'recent' = newest first, 'views' = most viewed first, 'viral' = highest relative score firstrecent
tagsNoOnly posts from accounts carrying ANY of these tags (ids or names from list_my_account_tags).
limitNoNumber of posts to return (max 50)
offsetNoPagination offset
accountNoFilter by one account (username, display name or id from list_my_accounts). Empty = all accounts.
categoryNoOnly posts from accounts in this category (id or name from list_my_account_categories). 'none' = accounts with no category. Empty = no filter.
platformNoFilter by platformall
viral_onlyNoOnly return breakthrough (viral) posts

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the readOnlyHint annotation, the description discloses the default sort behavior, defines the virality semantics behind viral_only ('breakthrough posts that beat the org's virality threshold'), and adds a mandatory presentation behavior (include each post's permalink). No contradiction with the annotations; it adds genuinely useful 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with zero waste: the main purpose is front-loaded, followed by a parameter clarification, then a single-sentence presentation requirement. Every sentence earns its place, and the most decision-relevant information appears first.

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 read-only listing tool with a fully documented 8-parameter schema and a readOnlyHint annotation, the description covers default ordering, the special viral filter semantics, and the permalink presentation requirement. The only notable gap is that no output schema exists and the response structure beyond permalinks is unspecified — a minor omission for a list 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 description coverage is 100%, so the baseline of 3 applies — all 8 parameters are already documented in the schema. The description adds marginal value by defining viral_only as 'breakthrough posts' relative to the org's virality threshold, but it does not elaborate on sort, tags, account, category, or platform semantics beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('List the posts') plus a precise scope ('published by the org's own connected accounts (My Accounts)') and anchors the default ordering ('newest first by default'). The 'My Accounts' framing clearly distinguishes this tool from siblings like list_viral_posts and list_analyzed_posts without opening any schema.

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 scope is clearly conveyed: this tool is for the org's own connected accounts, which implicitly separates it from global or analyzed-post listing siblings. It also provides post-call usage guidance ('always include each post's permalink'). It stops short of explicitly naming alternatives or when-not-to-use conditions, so it earns a 4 rather than a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Each tool has a distinct target resource/action, and the descriptions are unusually explicit about differences (e.g., 'Distinct from the watchlist', 'Separate list from list_tags'). A few pairs are still easy to confuse without careful reading: delete_folder vs delete_folders differ only by singular/plural, and the three download-URL tools (get_post_download_url, get_asset_download_url, get_my_account_post_download_url) plus the category/tag families require attention to pick correctly.

Naming Consistency4/5

The snake_case verb_noun pattern is followed consistently throughout (list_*, get_*, create_*, update_*, delete_*, set_*, tag_*). Minor deviations: archive_folder and archive_my_accounts also perform restore despite their names, delete_folder/delete_folders split one operation by cardinality, and tag_posts/tag_my_account use a different verb style than the set_* family for metadata mutations.

Tool Count2/5

At 56 tools, this far exceeds the 25+ threshold for 'too many,' even though the server spans multiple subdomains (watchlist, analysis, assignments, folders, my accounts, assets, Drive, categories/tags). Obvious consolidation candidates exist — delete_folder/delete_folders, the three download-URL getters, and the parallel list_my_account_* listers — and the sheer surface is heavy for an agent to navigate.

Completeness4/5

Core workflows are thoroughly covered with no dead ends: watchlist → analyze → assign → folder → track → approve has full lifecycle support, including reversible archive vs permanent delete choices. Minor gaps exist but are work-aroundable: no create/update for my accounts or models (app-side OAuth/admin only), no way to delete a viral post or a post note, and asset upload only happens in the app.

Resources