Send a shoot's worth of scripts to the Daily Studio teleprompter on iPhone, in one link.
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.5/5 across 12 of 12 tools scored.
Each tool targets a distinct resource-action pair: planning (add, edit, archive, list, get, reorder), teleprompter delivery (send), and scheduled posts (list, cancel, retry). Even closely named tools like get_planned_scripts vs list_planned_scripts are clearly separated by metadata vs full-text purpose. No two tools overlap in function.
Names are uniformly snake_case and follow a verb_noun pattern, but there is slight inconsistency: 'add_scripts_to_plan' uses a prepositional phrase while similar operations use past-participle adjectives ('edit_planned_scripts', 'archive_planned_scripts'). Verb choices like list vs get are consistent with their functions. Minor deviations prevent a perfect score but the pattern is highly predictable.
12 tools is well within the ideal 3-15 range for a focused domain. Each tool covers a clear need for content planning and teleprompter delivery without bloat or missing essentials. The count feels appropriately scoped for the server's purpose.
The toolset offers full lifecycle coverage for content plans (create, read, update, delete via archive, reorder) and scheduled posts (list, cancel, retry), with connected account listing for context. The only seemingly absent operation—permanent deletion—is intentionally excluded for safety. Read and write paths are complete, and the design prevents dead ends.
add_scripts_to_planAdd scripts to the content planAInspectPut finished scripts into the user's Daily Studio content plan, each with the day it should go out. Use this when the user asks you to PLAN — a week, a month, a series — rather than to hand them something to record right now. The plan lives on their account: it shows up in the app, on dailystudio.app/plan, and stays there. Calling this twice with the same scripts is safe; duplicates are skipped. Requires a connected Daily Studio account with the plan turned on. To record something immediately, use send_script_to_teleprompter instead — that is a delivery, this is a plan.
| Name | Required | Description | Default |
|---|---|---|---|
| scripts | Yes | The scripts to add, in the order they should sit in the plan. | |
| collection | No | Optional name for this batch as a group — a topic ('Customer questions'), a series ('Framing, part 1-5'), or what the week is about. The scripts show up grouped under it in the app and on the web, which is how somebody finds them again later. Use one when the scripts belong together; leave it out for a handful of unrelated ones. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the burden. It discloses that the action is non-destructive and idempotent: 'Calling this twice with the same scripts is safe; duplicates are skipped.' It also mentions the persistence: 'it shows up in the app, on dailystudio.app/plan, and stays there.' It does not mention any failure modes or side effects, but given the annotations provide no hints, this is still strong coverage. A minor deduction for not explicitly stating that it modifies the plan but that is implied.
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 that open with the action, then provide usage context, a warning about idempotency, and a comparison to an alternative. Every sentence contributes meaning. It is front-loaded with the purpose and scannable. 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 output schema and the annotations are all false, the description must explain what happens. It covers the outcome (scripts appear in the plan), the idempotency (duplicates skipped), the prerequisite (connected account), and the alternative (teleprompter). It does not describe what a successful response looks like, but since there is no output schema, that is acceptable. The complexity is moderate (2 params, nested array), and the description is thorough. A slight deduction for not specifying error cases (e.g., what if account not connected?) but that is optional.
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 contextual meaning to the parameters: 'collection' is explained as 'Optional name for this batch as a group — a topic, a series, or what the week is about. The scripts show up grouped under it... which is how somebody finds them again later.' It also clarifies the broader purpose of 'scripts' as ordered and dated. This adds value beyond the schema's field-level descriptions, justifying a slight above-baseline score.
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: 'Put finished scripts into the user's Daily Studio content plan, each with the day it should go out.' It uses a specific verb ('Put'), specifies the resource ('Daily Studio content plan'), and explicitly distinguishes itself from the sibling tool: 'To record something immediately, use send_script_to_teleprompter instead — that is a delivery, this is a plan.' The contrast between planning and delivery is clear.
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 guidance on when to use this tool: 'Use this when the user asks you to PLAN — a week, a month, a series — rather than to hand them something to record right now.' It also states the when-not: 'To record something immediately, use send_script_to_teleprompter instead.' It mentions prerequisites: 'Requires a connected Daily Studio account with the plan turned on.' 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.
archive_planned_scriptsArchive planned scriptsAArchive scripts out of the user's working plan, by id — or restore archived ones with restore: true. Archiving is reversible and keeps the script and any recorded video; it is the right way to clear finished or shelved work. Permanent deletion is deliberately not available to assistants — the user does that themselves.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | The scripts to archive (or restore). Ids come from list_planned_scripts. | |
| restore | No | true brings archived scripts back into the plan instead. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations present, the description adds valuable behavior: the operation is reversible, the script and recorded video are kept, and permanent deletion is deliberately outside the assistant's scope. This aligns with `idempotentHint: true` and `destructiveHint: false`, and there is no 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?
Three purposeful sentences front-load the primary action, add the restoration behavior, then state the important boundary around permanent deletion. There is no filler or repeated information from the schema.
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 small parameter count, strong schema coverage, and useful annotations, the description is effectively complete for selecting and invoking the tool. It could add a note about how restored archived scripts appear in lists, but that is not critical for correct use.
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 covers both parameters and includes helpful field descriptions, including that ids come from list_planned_scripts and that restore defaults to false. The description reinforces `restore: true` behavior but does not need to fill a schema gap.
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 the exact action and resource: it archives planned scripts out of the working plan, plus the same tool can restore via `restore: true`. That makes its purpose distinct among sibling tools like edit_planned_scripts, list_planned_scripts, and reorder_planned_scripts.
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 describes the intended use case ('the right way to clear finished or shelved work') and states the assistant cannot permanently delete. It does not explicitly name sibling tools as alternatives, but the context is accurate and a strong enough boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_scheduled_postCancel a scheduled postACancel one post that is waiting to go out, by id from list_scheduled_posts. Only works while the post is still waiting; the take becomes approvable again. Confirm with the user before calling this — it withdraws something they approved.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The post's id, from list_scheduled_posts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds important context: the post withdraws something the user approved, becomes approvable again, and requires user confirmation before calling. This goes beyond the annotation and explains the consequence of the destructive action.
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, with every sentence adding value: the action, an operational constraint, and a user-consent requirement. There is no redundant wording 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 tool with a single parameter and no output schema, the description covers all essential operational aspects: when it is valid, the effect on the post, and the required user confirmation. It is complete for its simplicity.
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 only parameter 'id' is fully described in the schema with 'The post's id, from list_scheduled_posts.' The description repeats this same source instruction without adding new semantics beyond the schema, so the baseline of 3 for 100% schema coverage 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 'Cancel one post that is waiting to go out' with a specific verb and resource. It also names the source of the id, list_scheduled_posts, which distinguishes it from siblings like retry_scheduled_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?
The description explicitly states a key usage condition: 'Only works while the post is still waiting.' It also implies when to use by saying the take becomes approvable again. It does not explicitly name alternatives, but the constraint is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edit_planned_scriptsEdit planned scriptsAChange scripts already in the user's Daily Studio content plan, by id and in bulk: move them to other days, group them into collections, retitle or rewrite them. This is the tool for 'these contents go on these days, grouped like this' when the content already exists — read the plan first with list_planned_scripts, then send one call with all the changes. Only the fields you send change; one bad entry never drops the batch.
| Name | Required | Description | Default |
|---|---|---|---|
| edits | Yes | The changes, one entry per script. Only the fields you send change; everything else stays. Get ids from list_planned_scripts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutation), idempotentHint=true, destructiveHint=false. The description adds important context: partial updates ('Only the fields you send change'), null semantics (clearing fields), and batch atomicity ('one bad entry never drops the batch' – implies partial success or error isolation). While idempotency is annotated, the description doesn't explicitly state it, but the partial-update semantics and error handling are useful beyond 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 sentences that pack a lot of information with efficient phrasing. The first sentence states everything the tool does; the second explains workflow and batch behavior. No redundancy, front-loaded with the most critical info, and each clause adds value.
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 bulk update tool with one parameter array and full schema coverage, the description provides complete context: when to use (after reading plan), what can be changed, how updates behave (partial), and failure handling. No output schema, but return value isn't critical here. The description is sufficient for correct tool invocation.
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 has 100% description coverage with rich details (explains 'null makes it undated', 'null clears it', 'get ids from list_planned_scripts'). The description repeats the essence but adds little beyond schema. Baseline 3 is appropriate because the schema covers parameter semantics thoroughly.
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 scripts already in the user's Daily Studio content plan, by id and in bulk' with specific actions (move to other days, group into collections, retitle or rewrite). It distinguishes from siblings by specifying 'when the content already exists' and naming 'read the plan first with list_planned_scripts'. This is specific verb+resource+scope.
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 provides usage guidance: 'read the plan first with list_planned_scripts, then send one call with all the changes' and contrasts with alternative tools (list_planned_scripts for reading). It also states the batch behavior: 'Only the fields you send change; one bad entry never drops the batch' – clear when-to-use and operational notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_planned_scriptsRead scripts in fullARead the full text of specific scripts in the user's content plan, by id — the words themselves, not just titles. Use it before rewriting or reviewing a script, or when the user asks about one ('check the hook on Tuesday's'). Up to 20 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | The scripts to read in full, at most 20 per call. Ids come from list_planned_scripts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only/idempotent safety. The description adds useful behavioral context: it returns full text, not just titles, and imposes a per-call limit of 20, though the limit is also in the schema. It doesn't describe return format or pagination, but for this simple read tool the added clarity 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?
Three short sentences front-load the core purpose, provide usage context, and state the limit. Every sentence earns its place with no redundancy or 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 simple read-only tool with a single param, full schema coverage, and strong annotations, the description covers what the tool does, when to use it, and its constraints. No critical information 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?
Schema description coverage is 100% (the single 'ids' parameter is fully described, including the source 'Ids come from list_planned_scripts' and limit). The description only repeats 'by id' and 'Up to 20 per call,' adding minimal value beyond the 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 uses a specific verb ('Read') and clearly identifies the resource ('specific scripts in the user's content plan'), and distinguishes itself from siblings by emphasizing 'the words themselves, not just titles.' This is a clear, distinct purpose.
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 says when to use the tool ('Use it before rewriting or reviewing a script, or when the user asks about one') and contrasts with listing tools via 'not just titles,' giving context on when to prefer this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_collectionsList the plan's collectionsAList the collections (piles) the user already groups their scripts into, with counts. Call it before grouping anything so you reuse their existing names instead of inventing near-duplicates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it returns collections 'with counts' and emphasizes the existing groupings, which helps the agent understand what data to expect 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, with the primary action stated first and a concise usage directive second. Every word adds value, and there is 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?
With zero parameters, rich annotations, and a clear description that mentions return value (counts) and purpose, the tool is fully contextualized. The sibling list provides further differentiation, but the description alone 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?
The input schema has zero parameters and 100% coverage, so there are no parameter semantics to explain. The baseline for 0-param tools is 4, and the description does not need to add parameter details. It appropriately focuses on purpose and usage.
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 lists collections (piles) with counts, specifying both the resource (collections) and the scope (user's existing script groups). This distinguishes it from sibling tools like list_planned_scripts, which focus on scripts themselves rather than their groupings.
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 instructs to call this tool 'before grouping anything' to reuse existing names, providing a clear when-to-use directive and rationale. This prevents duplicate collection names and is a strong usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_connected_accountsList connected social accountsAList the social accounts the user has connected to Daily Studio, so you know where a video could be published and under which handle. Requires a connected Daily Studio account — the first time you call this, the user is asked to connect one, and the call is retried automatically afterwards. Nothing is published by this tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds valuable behavioral context beyond these: the first call triggers a user connection prompt and the call is retried automatically. It also reinforces that nothing is published, complementing the read-only annotation.
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 concise sentences, each with a distinct purpose: listing the accounts, explaining the use case, and clarifying the connection requirement and non-destructive nature. No unnecessary words 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?
This is a simple list tool with an empty input schema and no output schema. The description covers the tool's purpose, use case, side effect (first-time auth), and safety, making it complete for an agent to select and 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?
The tool has zero parameters, so the schema covers everything. The baseline for zero-parameter tools is 4, and the description appropriately adds no parameter-specific information, which is sufficient.
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 lists connected social accounts for a specific purpose ('so you know where a video could be published and under which handle'). It uses a specific verb 'List' and resource 'social accounts', and differentiates itself from the sibling send_script_to_teleprompter by emphasizing it publishes nothing.
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 clear context for when to use this tool: before publishing a video to know target platforms and handles. It also notes the first-time connection requirement and auto-retry, but does not explicitly state exclusions or alternatives, though the sibling tool is unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_planned_scriptsRead the content planARead what is already in the user's Daily Studio content plan — each script's id, title, collection, the day it goes out, its place in the shoot order, and how far it has got (written, recorded, uploaded, scheduled, published, or failed). Call this before adding to a plan so you do not repeat what is there, before editing so you hold real ids, and whenever the user asks what they have coming up. Nothing is changed by this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Only scripts dated on or before this day. | |
| from | No | Only scripts dated on or after this day. | |
| collection | No | Only scripts in this collection. Omit to read the whole plan. | |
| includeUndated | No | Include scripts with no date at all (the backlog). Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation set already declares readOnly, idempotent, and non-destructive; the description adds 'Nothing is changed by this tool' and lists the data returned. This is consistent with the annotations and provides useful behavioral clarity, but it doesn't add deeper context such as auth or pagination.
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, front-loaded with the action, then result scope, then when to use it, then a side-effect guarantee. No 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?
For a simple read-only list tool with full parameter schema, good annotations, and no output schema, the description covers purpose, trigger situations, returned fields, and non-mutating behavior. This is sufficient for selection and invocation.
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 description need not explain parameters; it doesn't add semantic detail beyond the schema. The phrase 'whole plan' echoes the collection parameter's schema description. Baseline 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 'Read what is already in the user's Daily Studio content plan' and enumerates returned fields, making the verb and resource specific. It does not explicitly differentiate from the sibling get_planned_scripts, though it contrasts with add/edit actions.
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 gives explicit usage triggers: 'Call this before adding to a plan so you do not repeat what is there, before editing so you hold real ids, and whenever the user asks what they have coming up.' It lacks explicit when-not-to-use guidance or named alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_scheduled_postsRead the publishing queueARead what the user has approved for publishing and what happened to it: waiting, going up now, published (with the link), failed (with the reason in plain words), or cancelled. Call it when the user asks 'did my post go out?' or 'why not?'. Nothing is changed by this tool, and new posts cannot be scheduled from here.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Only posts in this state. Omit for the whole queue, newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about what is read (approved posts and their statuses) and explicitly states 'Nothing is changed by this tool', reinforcing the read-only nature. It also discloses that it includes published links and failure reasons, adding value beyond 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 what it does, followed by when to use it. Every word adds value; no repetition of schema or annotations, and 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?
Given the simple tool with one optional parameter and no output schema, the description provides necessary context: it lists possible states, explains that published includes link and failed includes reason, and clarifies it's read-only. It does not mention pagination beyond 'newest first' which is already in schema, but this is sufficient for its complexity.
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 description covers the only parameter 'state' fully with an enum and explanation including 'Omit for the whole queue, newest first'. The tool description does not add additional parameter semantics, so it stays at the baseline given 100% schema coverage.
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 reads the publishing queue with specific states (waiting, going up, published, failed, cancelled) and includes details like links and failure reasons. It uses a specific verb 'Read' and resource 'publishing queue', distinguishing it from sibling tools like retry_scheduled_post or cancel_scheduled_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?
It explicitly says to call it when the user asks 'did my post go out?' or 'why not?', providing clear when-to-use guidance. It also notes that nothing is changed and new posts cannot be scheduled here, which differentiates it from other tools. However, it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reorder_planned_scriptsSet the shoot orderASet the order the user's camera walks through their scripts — pass ids first-to-record first. Scripts you leave out keep their current order after the ones you name. Use it when the user says what to shoot first, or after planning a batch that should be recorded in sequence.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Script ids in the order they should be recorded, first first. Scripts you leave out keep their current order, after the ones you name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, but the description adds important behavioral context: 'Scripts you leave out keep their current order after the ones you name.' This clarifies the exact effect of the operation beyond what the annotations state, making the behavior predictable.
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 long, front-loaded with the core action, and uses a dash to explain the ordering logic. The second sentence provides practical usage guidance without excessive detail. Every word contributes to understanding.
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 tool with one parameter, a clear description, and annotations covering idempotency and destructiveness, the description fully explains what happens to named and unnamed scripts and when to use it. No output schema is needed, and the tool's behavior is completely specified.
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 covers 100% of parameter semantics, including the exact order semantics and the behavior of omitted scripts. The tool description repeats this information but does not add meaning beyond the schema, so a baseline score 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 with a specific verb and resource: 'Set the order the user's camera walks through their scripts.' It also distinguishes itself from siblings by focusing on first-to-record ordering, which is not mentioned in other tool names like add_scripts_to_plan or edit_planned_scripts.
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 usage context: 'Use it when the user says what to shoot first, or after planning a batch that should be recorded in sequence.' It does not explicitly list exclusions or mention alternatives, but the intended use case is clear enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
retry_scheduled_postRetry a failed postAPut one failed post back in the queue, due now — by id from list_scheduled_posts. Use it after the cause in the failure sentence is fixed (say, a reconnected account). The post goes out within about five minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The post's id, from list_scheduled_posts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, and the description adds that the post goes out within about five minutes. It also mentions it's a single post (one failed post), complementing the annotations. No contradiction; the description adds temporal behavior beyond 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 three sentences, all with purpose: states the action, specifies the condition, and notes the timing. No filler, front-loaded with the verb and object.
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 a single parameter, high schema coverage, idempotent annotation, and no output schema, the description is sufficient. It covers the trigger condition and expected behavior, though it doesn't detail what happens on failure or idempotency implications, but that's not required given context.
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 covers 100% of the parameter with a detailed description ('The post's id, from list_scheduled_posts.') and maxLength. The tool description repeats the source ('by id from list_scheduled_posts') but doesn't add new semantics beyond the schema, so baseline 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 put a failed post back in the queue, with the specific condition of being due now and referenced by id. It distinguishes itself from siblings by specifying it operates on a failed post from list_scheduled_posts.
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 states when to use it: after the cause in the failure sentence is fixed (e.g., reconnected account). It also implies not to use it before fixing the cause, and provides context on the timing (about five minutes). This gives clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_script_to_teleprompterSend script to teleprompterAInspectTurn one or more finished video scripts into a single one-tap link that opens the user's Daily Studio app with the script(s) loaded into the teleprompter and the right platform safe-zones selected, ready to record. For one script use text; for a batch the user will record back-to-back (a day's 3-4 videos, or a whole content plan — up to 100), use scripts — they land as an in-app shoot queue in order, and ONE link carries them all. Call this only once the scripts are final. Returns a link the user taps on their iPhone; on a desktop it opens a page with a QR code to scan.
| Name | Required | Description | Default |
|---|---|---|---|
| wpm | No | Optional scroll speed in words per minute. Sets the app's teleprompter speed. Omit to leave the user's setting alone. With `scripts`, applies to items that don't set their own. | |
| text | No | A single finished teleprompter script, plain UTF-8. Newlines allowed. Provide either this or `scripts`, not both. | |
| title | No | Optional short label for `text`, e.g. 'Cold plunge hook'. | |
| scripts | No | A batch of scripts (in recording order) delivered as a single link — up to 100 of them, 400000 characters of script in total. The app queues them; after each recording it offers the next. Provide either this or `text`, not both. | |
| platform | No | Where the video will be published. Selects that platform's safe-zone overlay so on-screen UI never covers the creator. Omit to leave the user's choice alone. With `scripts`, applies to items that don't set their own. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations being false, the description carries the transparency burden. It discloses key behaviors: it generates a link, batch scripts form an in-app shoot queue in order, desktop displays a QR code, and iPhone opens a one-tap link. It does not mention link expiration or authentication requirements, but the core behavior is well covered.
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 concise and well-structured, with each sentence adding essential information: the core purpose, the text vs. scripts modes, the batch queue ordering, the finalization prerequisite, and the return format. No sentences are wasted, and it is front-loaded with the primary action.
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 output schema and no annotation hints, the description competently explains the return value (link/QR code) and covers both single and batch scenarios, including ordering, platform safe-zones, and device behavior. It also implies that at least one of `text` or `scripts` must be provided, satisfying the core usage context.
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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by explaining the relationship between `text` and `scripts`, the 100-item/400k-character limits, and that `wpm`/`platform` defaults apply to items that don't set their own. This goes beyond the schema's individual property descriptions.
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 specifies the tool's function: 'Turn one or more finished video scripts into a single one-tap link that opens the user's Daily Studio app with the script(s) loaded into the teleprompter and the right platform safe-zones selected.' It uses a specific verb and resource, and is distinct from the sibling tool 'list_connected_accounts' which handles account listing.
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 explicit guidance: 'For one script use `text`; for a batch ... use `scripts`' and explains the batch use case ('a day's 3-4 videos, or a whole content plan — up to 100'). It also states a clear prerequisite: 'Call this only once the scripts are final.' This gives the agent clear when-to-use and how-to-choose information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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!
