sprkly_list_connected_social_accountsEvery ACTIVE social account linked to this sprkly account: platform, handle, follower count, and whether it needs reconnecting. Disconnected/inactive accounts are never listed, so any profileId returned here is a valid posting target. Never returns access tokens.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already specify readOnlyHint=true, which is consistent with the description's non-mutating nature. The description adds valuable behavioral context beyond annotations: it filters out disconnected/inactive accounts (so only valid posting targets are returned) and explicitly states that access tokens are never returned, addressing security expectations. This is more than many read-only tools provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly stating the core function and key constraints. It is front-loaded with the most important information (what accounts are returned) and adds a crucial note about profileId validity. Every word serves a purpose, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description fully covers what an agent needs to know: the exact fields returned, the filtering behavior, the guarantee that returned IDs are valid posting targets, and the absence of access tokens. It is complete for a tool of this complexity, especially with readOnlyHint already declared.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. According to the rubric, a baseline of 4 applies when there are no parameters. The description adds no parameter-specific information because none exist, but it effectively communicates the tool's fixed behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing every ACTIVE social account linked to the sprkly account. It specifies the fields returned (platform, handle, follower count, reconnection status) and distinguishes itself from siblings like sprkly_list_profiles by emphasizing that only active, connected accounts are included and that profileId values are valid posting targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need a list of active, connected social accounts for posting or management. It notes that disconnected/inactive accounts are never listed, which helps prevent misuse, but it does not explicitly name alternative tools or state when not to use it. Still, the context is clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool targets a distinct action and resource: media ingestion, draft creation, scheduling, deleting, updating, validation, approval, analytics, and account/profile listing. The only slight overlap is between sprkly_list_profiles and sprkly_list_scheduled_posts, but they serve clearly different purposes (target selection vs. queue view).
All 16 tools follow the exact sprkly_verb_noun pattern with lowercase snake_case. Verbs are consistent (add, delete, draft, get, list, request, schedule, update, validate) and nouns are clear (media, scheduled_post, account_summary, analytics, profiles, etc.). No style mixing or vague naming.
16 tools is slightly above the typical 3–15 sweet spot but each tool covers a distinct part of the content-scheduling lifecycle. The count feels justified given the breadth of features (media, drafts, scheduling, approvals, analytics), though a few tools could be merged (e.g., get_account_summary could be part of analytics) without much loss.
The surface covers the core workflows well: draft, schedule, update, delete, approve, validate, and analyze. Minor gaps exist—there's no explicit tool to list drafts or edit a draft after submission, and no direct way to unpublish or cancel an approval—but the domain is well-served for typical scheduling needs.