connect your ai agent to sprkly-mcp and let the agent handle your social media content calendar!
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 16 of 16 tools scored. Lowest: 3.6/5.
Most tools are clearly distinct, such as get_analytics vs get_post_status, but list_profiles and list_connected_social_accounts both list accounts and could cause misselection without reading descriptions closely. The optional helper tools (add_media_from_url, get_tiktok_posting_options) are well-justified and don't overlap with schedule_post.
Every tool follows the same sprkly_ + verb_noun pattern (e.g., get_account_summary, list_scheduled_posts, schedule_post). No mixing of cases or verb styles, making the API predictable.
16 tools is at the high end but each earns its place given the server's broad scope covering scheduling, drafting, approvals, analytics, billing, and account management. The count is slightly above the typical well-scoped range but not excessive.
Core lifecycle (schedule, update, delete, status, approval) is well covered, and analytics/billing add depth. However, there's no way to list or manage drafts beyond creation, and media management is limited to upload—no list or delete media. These are minor gaps agents can work around.
sprkly_add_media_from_urlAdd media from a URLADownload an image or video from a public link into sprkly and get a media_id back, for reuse across several posts. You usually do NOT need this: sprkly_schedule_post accepts a link directly in media_urls and pulls it into storage itself whenever the target platform requires that. Reach for this tool only when the user wants one media_id to attach to more than one post. Google Drive and Dropbox share links are converted automatically; the file must be shared publicly. Limit 50 MB.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Direct https link to the image or video file. Must be publicly reachable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read/write/idempotent/non-destructive hints, and the description adds useful behavioral context: the file must be publicly shared, Drive/Dropbox links are auto-converted, and there is a 50 MB limit. It does not describe failure behavior or response shape, but for a one-parameter tool with strong annotations this is adequate.
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?
Four sentences, each earning its place: purpose, when to skip, when to use, and prerequisites. The guidance is front-loaded and reads naturally; the mild repetition of the media_id reuse idea is not enough to count as waste.
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?
For a simple, one-parameter tool with no output schema, the description is complete: it names the returned object (media_id), explains the common alternative path, and gives the operational constraints (public sharing, automatic Drive/Dropbox conversion, 50 MB limit). No important decision or invocation detail is missing.
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 schema already documents the single url parameter as a direct, publicly reachable https link, so the baseline is 3. The description adds meaning beyond the schema by noting that Google Drive and Dropbox share links are accepted/converted and by specifying the 50 MB file limit.
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 uses a specific verb plus resource ('Download an image or video from a public link into sprkly and get a media_id back') and immediately differentiates from the sibling sprkly_schedule_post by clarifying when the tool is NOT needed. This makes the tool's purpose unmistakable.
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?
It explicitly tells the agent when not to use it ('You usually do NOT need this'), names the alternative (sprkly_schedule_post with media_urls), and states the specific condition for using this tool ('only when the user wants one media_id to attach to more than one post'). It also adds sharing and size prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_delete_scheduled_postDelete a scheduled postARemove a post from the queue. This is a soft delete. The user can restore it from the Deleted tab for 30 days. Posts that have already published cannot be deleted this way. Always confirm with the user before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | The scheduled post id to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveHint=true, but the description goes further by explaining this is a soft delete, that the user can restore it from the Deleted tab for 30 days, and that published posts are excluded. It also discloses the confirmation requirement, adding meaningful behavior not contained in annotations.
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?
Four short sentences, each earning its place: the action, the soft-delete nature, the recovery window, the published-post limitation, and the confirmation requirement. 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?
For a single-parameter destructive tool with no output schema and robust annotations, this description is complete. It covers what happens to the post, how it can be recovered, what cannot be deleted, and an important user-confirmation step.
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 input schema already fully documents the only parameter, post_id, as 'The scheduled post id to delete.' The description does not add extra detail about the parameter, but none is needed for a single obvious identifier, so the baseline 3 applies.
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 uses a clear verb and resource: 'Remove a post from the queue,' and the title specifies 'Delete a scheduled post.' This distinguishes it from siblings like update_scheduled_post, draft_post, and schedule_post, and the soft-delete nuance adds necessary precision.
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 gives clear context: use it to remove queued posts, and explicitly states a limitation—'Posts that have already published cannot be deleted this way.' It also adds a mandatory workflow instruction: 'Always confirm with the user before calling.' It does not name an explicit alternative tool, but the intended use is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_draft_postDraft a postAInspectCompose a caption from a content hint and save it as a draft in sprkly, shaped to the tightest caption limit among the target platforms. Returns a draft id; the draft appears under /drafts for the user to review.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional label for the draft. | |
| tone | No | Voice for the draft. | casual |
| platforms | No | Intended platforms, used to pick the caption length ceiling. | |
| profile_ids | No | Optional accounts to pre-select on the draft. From sprkly_list_profiles. | |
| content_hint | Yes | What the post should be about: a topic, phrase, or key message. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are all false (mutating, non-idempotent), so the description carries the burden of explaining behavior. It does so well: describes the caption-length-shaping logic ('tightest caption limit among the target platforms'), the return value (draft id), and the user-visible side effect (/drafts). No contradiction with annotations.
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?
Two lean, information-dense sentences. Front-loaded verb, clear flow from action → behavior → return value → next step. Zero wasted words.
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?
With no output schema, the description correctly discloses the return value ('Returns a draft id') and the user-facing effect ('appears under /drafts for the user to review'). Combined with perfect schema coverage and simple flat params, this is complete 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a 3 is the baseline for params alone. The description meaningfully connects the 'platforms' param to the caption-length-ceiling behavior and 'content_hint' to the generation input, adding semantic richness the enum/schema fields don't express.
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?
Uses specific verbs tied to a resource ('Compose a caption'... 'save it as a draft in sprkly') and adds meaningful detail about content-hint-driven generation and caption-limit shaping. The '/drafts' location distinguishes it from sibling scheduling tools like sprkly_schedule_post.
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?
Clearly frames a drafting workflow (compose → save → user reviews under /drafts) that differentiates it from schedule/delete siblings. However, it doesn't explicitly state when NOT to use it or name alternatives, leaving the exclusion implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_get_account_summaryGet account summaryAPlan tier, trial state, connected account count, scheduled post counts by status, and the next three upcoming posts. Never returns tokens or secrets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the read-only safety profile. The description adds a valuable behavioral guarantee ('Never returns tokens or secrets') and specifies the exact return items, giving useful context beyond the annotations.
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 extremely concise: one sentence lists the returned components, and the second sentence provides a security guarantee. Every word earns its place, with no redundancy or filler.
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?
For a read-only, parameterless tool, the description fully covers the output content and the security guarantee. It does not detail the structure of 'next three upcoming posts' or error behavior, but these are likely minor given the tool's simplicity and the presence of annotations.
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 takes zero parameters, so the description need not explain input semantics. The schema is empty, and the description's focus on output content is appropriate; a score of 4 is the baseline for no-parameter tools.
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?
Description explicitly enumerates the exact fields returned (plan tier, trial state, connected account count, scheduled post counts, next three upcoming posts), making the tool's purpose unambiguous. The name 'get_account_summary' directly aligns with the description, and the content distinguishes it from siblings like billing or analytics.
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 does not explicitly state when to use this tool versus alternatives such as get_billing_summary or get_analytics. Usage is implied by the listed summary contents, but no alternative guidance or exclusion scenarios are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_get_analyticsGet post performanceAHow the user's published posts actually performed: total views and engagement, week-on-week / month-on-month / year-on-year change, their best posting hour, weekday and content category, and the top posts behind those numbers. Every recommendation carries a samples count — say how thin the evidence is rather than presenting a one-post pattern as a finding. Every period-on-period percentage carries the post counts and raw totals it came from: quote those, because a big percentage off a tiny base is not a big change. topPosts is grouped by platform and ranked only inside each group; relativeToPlatformBest compares a post with others on its OWN platform and never across platforms, so use the absolute value and its metric label to weigh one platform against another. Instagram contributes likes and comments only, and Threads and Facebook produce no metrics at all, so read coverage before comparing platforms.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days back to analyse. Default 30. | |
| profile_ids | No | Limit to these accounts. Omit for every account this connection can see. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits beyond the annotations: it explains that recommendations include sample counts, period-over-period percentages are based on raw totals, topPosts are grouped by platform, relativeToPlatformBest compares within the same platform only, and platform-specific metric limitations. This is substantial context not present in the annotations.
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 a single dense paragraph but efficiently packs in essential usage details without redundancy. It is front-loaded with the core purpose, then elaborates on data interpretation caveats, making it concise enough while maintaining completeness. Minor lack of formatting (e.g., bullet points) prevents a 5.
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 absence of an output schema, the description thoroughly explains the output contents, including metrics, comparisons, grouping, and platform-specific coverage. It even advises on interpreting statistics correctly, making it fully self-sufficient for an agent to understand what the tool returns and how to use it responsibly.
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?
Schema coverage is 100%, with both parameters having clear descriptions. The tool description adds no new parameter semantics beyond restating defaults and the profile_ids scope, which is already in the schema. Baseline of 3 is appropriate.
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 what the tool does: it returns how published posts performed, including views, engagement, changes, best posting times, and top posts. It differentiates from siblings like account summary and billing summary by focusing specifically on post performance.
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 the tool by detailing the data it provides, but does not explicitly contrast with alternative tools or state when not to use it. However, the context from the title and description makes the use case clear, and it advises on how to interpret the results, which is a form of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_get_billing_summaryGet billing summaryASubscription status, current plan, period end, purchased handles and the last few billing events. No payment method details; the Stripe customer id is truncated.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true and openWorldHint: false, so the description doesn't need to restate that it's a read operation. The description adds context by specifying what it includes (purchased handles, billing events) and what it excludes (payment method details, Stripe ID truncated). This adds some behavioral context beyond the annotations, but it doesn't mention any other behaviors like rate limits or response format, which are less critical since it's a simple read with no parameters.
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 extremely concise: two sentences with zero waste. The first sentence lists the key output components, and the second clarifies exclusions. It is front-loaded with the most important information and every word earns its place.
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 that this is a simple read-only tool with no parameters and no output schema, the description is fairly complete. It explains the contents of the summary and notes what's excluded. However, it doesn't mention any edge cases like what happens if the subscription is inactive or if there are no billing events, and it doesn't state the return format (e.g., JSON structure). Since it's a simple tool, this is acceptable, but there is a slight gap in completeness.
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 0 parameters and the schema coverage is 100%. With no parameters, the baseline is 4 as per the rubric. The description adds value by explaining what the tool returns, which is especially important given the absence of parameters. It clarifies the output scope, which compensates for the lack of an output schema.
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 what the tool does: it retrieves billing summary information. The description lists specific components (Subscription status, current plan, period end, purchased handles, last few billing events), which distinguishes it from sibling tools like sprkly_get_account_summary or sprkly_get_analytics, though it doesn't explicitly name them. The purpose is clear and specific.
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 usage context: when a user wants to see billing information. However, it doesn't explicitly state when NOT to use this tool or compare it to alternatives like sprkly_get_account_summary. The mention of what's excluded (no payment method details) gives some guidance about its scope, but it lacks explicit guidance on when to choose this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_get_post_approval_statusGet approval statusAWhether a post is awaiting human review, approved or rejected, including reviewer notes and timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | The scheduled post id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's a safe read. The description adds value by specifying the exact output content (reviewer notes and timestamps) and the possible states, which are behavioral details beyond the annotation. No contradictions.
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 a single sentence that directly conveys the essential information without fluff. It is front-loaded with the core question ('Whether a post is...') and includes all relevant details. Every word earns its place.
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?
For a simple read-only tool with one parameter and no output schema, the description is sufficiently complete. It explains what the tool returns (status, notes, timestamps) and does not require additional context. The presence of annotations and a simple schema covers the remaining needs.
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 schema covers 100% of the parameter with a minimal description ('The scheduled post id.'). The tool description does not add any additional meaning about the parameter, such as format or scope. Since coverage is high, the baseline of 3 is appropriate.
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: to return the approval status of a post (awaiting review, approved, rejected) along with reviewer notes and timestamps. This is specific and distinguishes it from the sibling 'get_post_status' which likely covers a different aspect of post status.
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 usage for checking approval status but provides no explicit guidance on when to use this tool versus alternatives like 'sprkly_get_post_status'. There is no when-not-to-use or mention of alternative tools, but the purpose is clear enough that an agent can infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_get_post_statusGet post statusAFull detail for one post: status, targets, scheduled and published times, permalink, and the failure reason if it did not publish. Media comes back as mediaIds in slide order, not as links. Ids and profile ids are plumbing: talk to the user about accounts by handle and about posts by their caption, and do not read ids out unless they ask for one.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | The scheduled post id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only behavior, so the description appropriately focuses on additional behavioral details: media is returned as mediaIds in slide order rather than links, failure reasons are included when relevant, and IDs are presented as plumbing to avoid exposing them to users. This adds value beyond the annotations without contradicting them.
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 three sentences long and front-loaded with the core purpose. Every sentence contributes essential information: what is returned, the media format quirk, and the user-facing communication guideline. No filler is present.
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 simple one-parameter read-only tool and no output schema, the description covers the important return values (status, targets, times, permalink, failure reason) and flags the mediaIds behavior and ID-handling convention. It is sufficiently complete for an agent to invoke the tool and interpret the result correctly.
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 input schema fully documents the single post_id parameter with 100% coverage, so the baseline is 3. The description adds a note about not reading IDs aloud, which is useful interaction guidance, but it does not add significant semantic detail about the parameter itself.
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 names a specific verb and resource ('Full detail for one post') and enumerates what is returned, distinguishing it from sibling tools like list_scheduled_posts or get_post_approval_status. The phrase 'one post' and the detailed result fields make the tool's purpose unmistakable.
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 establishes a clear use case: retrieving full detail for a single post. It does not explicitly name alternative tools or exclusion criteria, but the 'one post' scoping contrasts with list-oriented siblings, giving clear context for when it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_get_tiktok_posting_optionsGet TikTok posting optionsAThis creator's allowed TikTok privacy levels and interaction settings, fetched live from TikTok. You usually do NOT need this before scheduling: sprkly_schedule_post checks privacyLevel against this same list itself and, when it is wrong, returns the levels that would work. Call this only when the user asks what their options are, or you want to offer them a choice.
| Name | Required | Description | Default |
|---|---|---|---|
| profile_id | Yes | The TikTok profile id to query, from sprkly_list_profiles. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description need not restate this. The description adds useful context: the data is fetched live from TikTok (implying potential latency or external dependency), and it notes that schedule_post already handles validation internally, which clarifies the tool's role. It does not disclose error behavior or return format, but given the read-only annotation and simple scope, the description adds sufficient behavioral insight without contradiction.
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 exactly two sentences without any filler. The first sentence states the purpose and data source; the second provides actionable usage guidance. It is front-loaded and every word earns its place, making it highly concise and well-structured.
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?
For a simple read-only tool with one parameter and no output schema, the description is complete enough. It explains what data is returned (privacy levels and interaction settings), when to use it, and its relationship to schedule_post. The absence of output schema means the description could specify the exact return shape, but the given information is sufficient for an agent to correctly invoke the tool and understand its purpose.
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 input schema has 100% coverage: the only parameter, profile_id, has a description explaining its source ('from sprkly_list_profiles'). The tool description does not add further semantics beyond that. With the schema already providing clear meaning, a baseline of 3 is appropriate.
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 purpose: it fetches the creator's allowed TikTok privacy levels and interaction settings. It uses a specific verb ('fetched') and resource ('privacy levels and interaction settings'), and it distinguishes itself from siblings by focusing on posting options for a specific TikTok profile. The mention of 'live from TikTok' adds clarity about data freshness.
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 explicitly states when NOT to use it ('usually do NOT need this before scheduling') and provides the alternative (sprkly_schedule_post validates the same list itself and returns valid levels on error). It then gives precise conditions for when to call: when the user asks for options or you want to offer a choice. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_list_connected_social_accountsList connected accountsAEvery 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 parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only safety, and the description adds valuable behavioral context: inactive/disconnected accounts are never returned, and access tokens are never exposed. It also explains the practical implication that returned profileIds are safe posting targets.
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?
Three concise, information-dense sentences. Every sentence contributes useful details: scope of results, exclusion behavior, and security guarantee, 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 has no parameters and no output schema, the description fully covers what an agent needs: what is returned, what is excluded, and a security caveat. It is complete for this simple read-only listing tool.
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 the schema carries no parameter burden. The description appropriately focuses on what the result contains rather than parameter details, which is sufficient for a no-argument tool.
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 a specific verb+resource: lists every ACTIVE social account linked to the sprkly account, with concrete fields (platform, handle, follower count, reconnect status). It distinguishes from sibling tools by emphasizing active-only accounts and 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 gives clear context for when to use this tool: to retrieve active connected accounts and valid profileId posting targets. It excludes disconnected/inactive accounts, but it does not explicitly name alternatives such as sprkly_list_profiles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_list_profilesList posting targetsAThe profile ids needed to target a post, with each one's platform and handle. Call this before sprkly_schedule_post.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the description does not need to emphasize that. The description adds context about what the output contains (profile IDs, platform, handle) and its prerequisite role. It does not disclose potential nuances like whether it includes all accounts or only those eligible for posting, but with readOnlyHint, the bar is lower and this is adequate.
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, front-loaded with the core purpose and ending with explicit guidance to call it before scheduling. Every sentence earns its place, zero waste.
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?
The tool is simple with no parameters and a readOnlyHint annotation. The description tells the agent what it returns and when to use it. Without an output schema, it could benefit from explaining what 'posting targets' are exactly (e.g., social media profiles) but the description does this. It is complete enough for its purpose.
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?
There are 0 parameters, so the schema provides no parameter information. The baseline for 0 parameters is 4, and the description does not need to add parameter semantics. It does explain the output (profile IDs, platform, handle), which is useful.
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 what the tool does: it lists posting targets (profile IDs) with platform and handle, needed for targeting a post. It explicitly names the resource (posting targets) and the purpose (provide profile IDs for targeting), distinguishing it from sibling tools like sprkly_list_connected_social_accounts.
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 clearly states when to use this tool: 'Call this before sprkly_schedule_post.' However, it does not explicitly say when not to use it or mention alternatives (like sprkly_list_connected_social_accounts), though its specific purpose implies it for scheduling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_list_scheduled_postsList scheduled postsAThe post queue, newest first, with a caption preview, targets, status and failure reason. Supports a status filter and cursor pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum posts to return. | |
| cursor | No | Pagination cursor. Pass the nextCursor value from a previous response. | |
| status | No | Filter by status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals no side effects. The description adds behavioral details: ordering (newest first), response fields (targets, status, failure reason), and pagination via cursor. It does not mention permissions or rate limits, but for a read-only list operation, the provided info is sufficient.
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 one sentence but packs relevant details: ordering, output fields, filtering, and pagination. It is front-loaded with the core purpose ('post queue') and avoids redundancy with the schema. No fluff.
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?
For a read-only list tool with 3 well-documented parametersable response shape, the description captures the essence: newest first, included fields, and pagination. Since there is no output schema, the description adequately hints at what the user will receive. No significant gaps.
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?
Schema coverage is 100% with descriptions for limit, cursor, and status. The description only reiterates 'status filter and cursor pagination' without adding new meaning. It does not clarify the limit parameter's default or max, but those are in the schema. Thus it meets the baseline but adds little.
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 uses a specific verb ('list'), names the resource ('scheduled posts'), and provides concrete details: 'post queue, newest first, with a caption preview, targets, status and failure reason.' This clearly distinguishes it from sibling tools like get_post_status or get_post_approval, which are single-post lookups.
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 usage for viewing the post queue, and the mention of 'status filter' and 'cursor pagination' gives context for when to use this tool. However, it does not explicitly state when to avoid it (e.g., when you need a single post's details), but the 'post queue' phrasing makes the list purpose obvious enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_request_post_approvalRequest human approvalAInspectSubmit a draft post for human review. Moves the post to pending_approval and returns an approval id to poll with sprkly_get_post_approval_status. Use this when the user wants a person to sign off before anything publishes.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional context for the reviewer. | |
| post_id | Yes | The draft post id to submit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false indicates a mutation), the description adds meaningful behavioral detail: the post is moved to pending_approval and an approval id is returned. This helps the agent understand state changes and follow-up behavior without contradicting the annotations.
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?
Three sentences, each earning its place: the action, the state/return behavior, and the usage context. Information is front-loaded and there is no redundant phrasing or filler.
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?
For a simple two-parameter tool with no output schema, the description adequately covers the purpose, the state change, the return value, and the appropriate usage scenario. It also directs the agent to the sibling polling tool, making the surrounding workflow clear.
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?
Schema description coverage is 100%, so the schema already fully documents both parameters ('post_id' and 'note'). The description does not add extra parameter-level detail, but it does clarify the workflow role of the approval id, so the baseline of 3 is appropriate.
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 states a specific action ('Submit a draft post for human review') and identifies the exact resource and state transition ('Moves the post to pending_approval'). It clearly distinguishes the tool from the sibling status-polling tool by mentioning the returned approval id and the dedicated poll tool.
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 gives an explicit when-to-use condition: 'Use this when the user wants a person to sign off before anything publishes.' It does not explicitly name alternatives or when-not-to-use cases, but the polling sibling is referenced, providing clear workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_schedule_postSchedule a postAInspectQueue a post for publishing, in ONE call. Attach media by passing the user's link straight to media_urls: sprkly downloads it into storage itself for the platforms that need that, so no upload tool has to run first. Runs the same quota, duplicate-content and platform pre-flight checks as the sprkly app. Instagram and TikTok require media at submission time; YouTube and TikTok require a title, and TikTok also requires platform_meta.tiktok.privacyLevel — just send the level the user asked for and this tool names the allowed values if it is not one of them. It reads the real bytes of the media and the response says what will actually publish on each platform (a Reel, a 3-slide carousel, a photo set, a Page feed video) plus anything worth passing on: relay that to the user. Confirm the date, time and target accounts with the user first. If a target platform has more than one connected account and profile_ids is not given, the tool returns needsAccountChoice with the options instead of scheduling — put that choice to the user, then re-call.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Post title. Required for YouTube (max 100 characters) and TikTok (max 150 characters). | |
| caption | No | Post caption, max 2200 characters. | |
| category | No | Optional content category, e.g. "fitness". | |
| media_id | No | Id of a single media file already uploaded to sprkly. Shorthand for a one-item media_ids. | |
| media_ids | No | Ids of media files already uploaded to sprkly, in slide order. Array order is the published order. Use these when the user already has media in sprkly, or when one file is going on several posts; for a link the user just gave you, media_urls is fewer steps. Every photo in a set must be the SAME shape or the call is refused: export them all at 1080x1920 (9:16), 1080x1440 (3:4), 1080x1350 (4:5) or 1080x1080 (1:1). Instagram takes at most 10 slides; TikTok photo sets take up to 35. | |
| platforms | No | Platforms to publish to. A platform with exactly one connected account is targeted directly; one with several makes the tool answer needsAccountChoice so the user can pick. | |
| media_urls | No | Publicly reachable image or video URLs to attach, in slide order. Pass links through for ANY platform. Instagram and Threads fetch them directly; for TikTok, YouTube and Facebook sprkly downloads the file into its own storage while scheduling, so a link works there too and any problem with it is reported now, in this call. Google Drive and Dropbox share links are converted automatically. JPEG, PNG, WebP, GIF, MP4, MOV and WebM only: AVIF and HEIC (the iPhone camera default) are refused with re-export instructions, because sprkly cannot convert them. Each file must be publicly reachable and under 50 MB. | |
| profile_ids | No | Specific accounts to publish to, from sprkly_list_profiles. When given, this list IS the target set — platforms are not fanned out. | |
| all_accounts | No | Explicitly post to EVERY connected account on every listed platform, skipping the needsAccountChoice question. Only pass true when the user has said they want all accounts. | |
| platform_meta | No | Platform-specific publishing options, keyed by platform. | |
| scheduled_time | No | ISO 8601 timestamp to publish at. Must be in the future. If omitted the post goes out on the next publisher run, about a minute from now — there is no smart slot-picking, so pass an explicit time unless the user wants it published immediately. sprkly_get_analytics can suggest one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations providing only readOnlyHint=false and openWorldHint=true, the description carries the full burden and does so excellently. It discloses that it runs pre-flight checks (quota, duplicate-content, platform-specific), downloads media on behalf of the user, may refuse calls (e.g., for AVIF/HEIC), returns needsAccountChoice when ambiguous, and reads real bytes to report actual publish format. It also instructs the user to confirm details first, which is critical behavioral context not derivable from annotations.
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 long but packed with essential information for an 11-parameter tool with complex platform-specific behavior. It is well-structured: main purpose first, then media handling, platform requirements, user confirmation, and the needsAccountChoice flow. Each sentence adds value, but it could be tightened without losing critical detail; for instance, some redundancy exists around platform-specific requirements. Still, it is far from wasteful and earns its length.
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 complexity (11 params, nested objects, no output schema), the description is remarkably complete. It covers the full workflow, media constraints, platform-specific requirements, pacing behavior (no smart slot picking), error handling (needsAccountChoice), and how to proceed after that response. It also explains the return content ('the response says what will actually publish') and actions to take, which compensates for the lack of an output schema.
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 input schema has 100% coverage, so the baseline is 3. The description adds significant value beyond the schema: it explains the trade-off between media_urls and media_ids (download vs pre-uploaded), clarifies that platform_meta.tiktok.privacyLevel is required and how to get allowed values, and describes the behavior of media_urls for different platforms. It also clarifies the scheduled_time default and suggests using sprkly_get_analytics. This extra context elevates it above baseline, but since the schema already contains detailed parameter descriptions, it does not need to repeat everything, so 4 is appropriate.
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 opens with a specific verb and resource: 'Queue a post for publishing, in ONE call.' It clearly distinguishes itself from siblings by explaining the media_urls shorthand ('no upload tool has to run first') and contrasts with draft tools implicitly. The scope is explicit: it schedules a post to one or more platforms, with clear platform-specific requirements.
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 gives explicit when-to-use guidance: it explains when to use media_urls vs media_ids, when to confirm with the user (date, time, target accounts), and what happens when profile_ids is omitted (needsAccountChoice). It also says when not to use it (e.g., if the user wants immediate publishing, it mentions scheduling time behavior). It references alternative tools (sprkly_get_analytics for suggested time, sprkly_list_profiles for profile_ids) and clarifies the workflow around needsAccountChoice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_update_scheduled_postReschedule or edit a postAChange the caption, publish time, target accounts or attached media on a post that has not published yet. Only posts with status "scheduled" can be edited.
| Name | Required | Description | Default |
|---|---|---|---|
| caption | No | Replacement caption, max 2200 characters. | |
| post_id | Yes | The scheduled post id. | |
| media_id | No | Replacement sprkly media file id. Shorthand for a one-item media_ids. | |
| media_ids | No | Replacement media, in slide order. Replaces the whole set, it does not append — pass every slide you want the post to keep. | |
| profile_ids | No | Replacement target accounts. Platforms are re-derived from them. | |
| scheduled_time | No | New ISO 8601 publish time. Must be in the future. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds that only scheduled posts can be edited, which is a key behavioral constraint. It also implies the tool modifies existing posts (not creating new ones). No contradiction with annotations; the description adds context beyond the annotations.
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, front-loaded with the main action, and includes a critical constraint. Every word earns its place; no fluff or repetition.
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 complexity (6 parameters, mutation, no output schema), the description covers the essential behavioral constraint (only scheduled posts) and the main editable fields. It doesn't explain return values, but since there's no output schema, that's not required. The description is sufficient for an agent to understand when and how to use it, though it could mention that all fields are optional replacements.
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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by clarifying that media_ids 'Replaces the whole set, it does not append — pass every slide you want the post to keep.' This is crucial semantic information beyond the schema's basic description. Also, the description mentions 'target accounts' which maps to profile_ids, and 'attached media' to media_id/media_ids, providing a high-level summary.
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: 'Change the caption, publish time, target accounts or attached media on a post that has not published yet.' It specifies the resource (scheduled post) and the actions (change caption, time, accounts, media), distinguishing it from siblings like sprkly_schedule_post (creating) and sprkly_delete_scheduled_post (deleting).
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 provides a clear condition for use: 'Only posts with status "scheduled" can be edited.' This implies when to use the tool (for scheduled posts) and implicitly when not to (for published or draft posts). It doesn't explicitly name alternatives, but the sibling list includes related tools like sprkly_schedule_post and sprkly_draft_post, which are distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sprkly_validate_post_policyValidate against platform rulesACheck a caption against each target platform's posting rules before scheduling: caption length, media requirements, hashtag ceilings, whether links are clickable, required YouTube titles, and PII or prohibited-content warnings. Pure analysis. Writes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Post title. Required for YouTube, max 100 characters. | |
| caption | Yes | The caption to check. | |
| hashtags | No | Hashtags posted alongside the caption, if they are not already in it. | |
| platforms | Yes | Target platforms to check against. | |
| platformMeta | No | Platform-specific publishing options, keyed by platform. | |
| mediaUrlsCount | No | How many images or videos will be attached. Instagram and TikTok require at least one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description reinforces this with 'Pure analysis. Writes nothing.' It adds behavioral context about what the validation covers (e.g., PII/prohibited-content warnings), going beyond the annotation. However, it does not describe the exact return format or behavior on violations.
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, front-loaded with the core purpose and follow-through with 'Pure analysis. Writes nothing.' Every clause adds value; no fluff or repetition of schema field names.
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?
For a validation tool with 6 parameters and no output schema, the description covers the main inputs and behavior. It lacks explicit mention of what the function returns (e.g., a list of violations vs. a pass/fail flag), but the mention of 'warnings' and the overall scope is sufficient for an agent to invoke it correctly.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning by tying parameters to validation rules (caption length, media requirements, hashtag ceilings, YouTube titles), which helps select and populate the correct parameters. It does not detail platformMeta, but the schema already describes it.
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 uses a specific verb ('Check a caption') and a clear resource ('against each target platform's posting rules'), enumerating concrete checks (caption length, media requirements, hashtag ceilings, clickable links, YouTube titles, PII/prohibited-content warnings). This clearly distinguishes it from sibling scheduling, drafting, and deletion tools.
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?
'before scheduling' gives a clear when-to-use context, and 'Pure analysis. Writes nothing' implies it should be used for validation before mutation tools like sprkly_schedule_post. It does not explicitly name alternatives when not to use it, but the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
