Skip to main content
Glama
davidmosiah

YouTube Shorts Agent

Server Quality Checklist

75%
Profile completionA complete profile improves this server's visibility in search results.
  • Latest release: v0.1.6

  • Disambiguation5/5

    Each tool serves a clear, distinct purpose: manifest info, connection status, listing videos, OAuth URL generation, privacy audit, and upload. No functional overlap.

    Naming Consistency5/5

    All tools follow the consistent pattern 'youtube_verb_noun', making it easy to predict tool behavior from names alone.

    Tool Count5/5

    With 6 tools covering auth, status, listing, upload, and audit, the count is well-scoped for a YouTube Shorts agent without unnecessary bloat.

    Completeness4/5

    Core workflows (upload, list, OAuth, status check) are covered. Minor gaps like deletion or metadata editing are acceptable for a focused shorts agent.

  • Average 3.3/5 across 6 of 6 tools scored. Lowest: 2.4/5.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 9 commits in the last 12 weeks
    • Last stable release on
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI is passing
  • This repository is licensed under MIT License.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • This repository includes a glama.json configuration file.

  • This server has been verified by its author.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

  • Behavior3/5

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

    Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool provides 'install, client, runtime and safety guidance', which gives some behavioral context beyond annotations but does not detail return behavior or side effects. 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.

    Conciseness3/5

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

    The description is a single sentence, which is concise, but it lacks a clear structure and does not front-load the most critical information about what the tool does. It could be more informative without increasing length.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the simple tool (2 optional params, no output schema, presence of annotations), the description is incomplete. It does not explain what the manifest contains, what the tool returns, or how the output should be used. This leaves ambiguity for an AI agent.

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

    Parameters1/5

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

    The input schema has 0% description coverage for its two parameters ('client' and 'response_format'). The description does not mention or explain these parameters, leaving the agent to infer their meaning from names alone. This is a significant gap.

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

    Purpose3/5

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

    The description 'Machine-readable install, client, runtime and safety guidance for agents' is somewhat vague and does not use a strong action verb. It conveys the tool provides configuration guidance but lacks specificity about its exact function, such as retrieving a manifest document. It partially distinguishes from sibling tools which perform actions like listing videos or uploading.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description provides no guidance on when or why to use this tool versus alternatives like youtube_connection_status or youtube_privacy_audit. It does not mention any prerequisites, context, or exclusions.

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

  • Behavior4/5

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

    The description discloses that the PKCE verifier is persisted locally and not returned, which is a significant behavioral trait not covered by annotations. However, it does not mention that a user interaction is required to complete OAuth.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness3/5

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

    The description is a single sentence that is concise and front-loaded with the main action, but at the cost of omitting parameter details and usage context.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the complexity of OAuth and no output schema, the description fails to explain what the agent should do with the returned URL, nor does it mention security considerations or integration with sibling tools like youtube_connection_status.

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

    Parameters1/5

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

    Schema description coverage is 0%, and the description adds no meaning to any of the 4 parameters (state, scopes, redirect_uri, response_format). The agent lacks context for required and optional fields.

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

    Purpose5/5

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

    The description clearly states the tool creates a Google OAuth authorization URL and persists the PKCE verifier locally, distinguishing it from sibling tools that handle other YouTube operations.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance on when to use this tool versus alternatives or prerequisites. The description does not mention that this should be called before other YouTube tools or explain the OAuth flow context.

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

  • Behavior3/5

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

    Annotations already declare readOnlyHint, idempotentHint, etc. The description adds only that it accesses a configured channel, which is basic context. Lacks details on rate limits or result ordering.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness4/5

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

    Single sentence is concise with no unnecessary words, but could benefit from a slightly more structured breakdown.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    The description is too sparse for a tool without output schema; it does not explain what 'recent' means, how results are ordered, or pagination behavior, leaving gaps for an agent.

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

    Parameters1/5

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

    Schema coverage is 0% (no parameter descriptions), and the tool description does not mention or explain any parameters (max_results, response_format), leaving the agent without guidance beyond the schema structure.

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

    Purpose5/5

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

    Description clearly states verb 'list' and resource 'recent videos from the configured YouTube channel', distinguishing it from siblings like youtube_upload_short or privacy_audit.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines3/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    Usage is implied by the simple purpose, but no explicit guidance on when to use vs. other tools (e.g., for searching) or when not to use.

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

  • Behavior4/5

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

    Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying the exact data returned (OAuth scope, safety boundaries), which is beyond the generic read-only indication. It does not contradict annotations, and the added context helps the agent understand the output nature, though it could mention any special requirements like authentication status.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness4/5

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

    The description is a single sentence that conveys the core function without any unnecessary words. It is appropriately concise for a simple tool, though the brevity sacrifices detail on parameters and usage.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the low complexity (one optional parameter, no output schema), the description adequately lists the three return components. However, it does not describe the structure or format of the response, leaving some ambiguity about what exactly is returned under each category. A more complete description would include example values or a note about the response format.

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

    Parameters2/5

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

    The single parameter 'response_format' has enum values (json, markdown) and a default of 'json', but the description does not mention this parameter or explain its effect. With 0% schema description coverage, the description fails to compensate by clarifying how the parameter controls output format, which is essential for agent decision-making.

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

    Purpose4/5

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

    The description clearly states the verb 'Return' and the resource 'privacy audit info', listing three specific components (OAuth scope, synthetic media, live-upload safety boundaries). It distinguishes this tool from siblings like youtube_upload_short or youtube_list_recent_videos by focusing on privacy audit rather than operations. However, the description could be more explicit about what each component entails.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description provides no guidance on when to use this tool versus alternatives like youtube_oauth_authorize_url or youtube_connection_status. It does not specify prerequisites, use cases, or situations where this tool is preferred, leaving the agent to infer usage context.

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

  • Behavior4/5

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

    The description adds the dry-run behavior beyond what annotations provide (which only indicate mutability). Annotations show readOnlyHint=false and destructiveHint=false, consistent with upload. The vertical video constraint is noted, but missing details like auth requirements or rate limits.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

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

    The description is two sentences, front-loaded with the core purpose, and contains no filler. Every word is necessary.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    With 7 parameters including required fields and enums, and no output schema, the description is too minimal. It does not explain how to specify the video path, title requirements, or effects of optional parameters like privacy_status. The agent lacks sufficient guidance for correct invocation.

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

    Parameters2/5

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

    Schema description coverage is 0%, and the description offers no explanation for any of the 7 parameters (e.g., video_path, title, tags, privacy_status). The description only covers the tool's primary purpose but leaves parameter meaning entirely to the schema with no additional guidance.

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

    Purpose5/5

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

    The description clearly states the tool uploads one vertical video as a YouTube Short. This verb-resource combination is distinct from sibling tools like youtube_list_recent_videos or youtube_oauth_authorize_url.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines3/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description mentions dry-run default and live mode requirement, providing some context but no explicit when-not-to-use or comparison to alternatives. Siblings are different enough to not require detailed exclusion.

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

  • Behavior5/5

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

    Annotations already indicate read-only and idempotent. The description adds value by specifying the exact readiness aspects checked (dry-run, OAuth, live upload) and explicitly states tokens are not exposed, providing useful behavioral context 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.

    Conciseness5/5

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

    The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose and key safety detail.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness5/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the simplicity of the tool (one optional parameter, no output schema, clear annotations), the description provides all necessary context: what is checked, that tokens are not exposed, and the read-only nature is reinforced.

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

    Parameters2/5

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

    Schema coverage is 0% and the description does not mention the 'response_format' parameter or its enum values. Since the parameter is simple, the oversight is minor but still fails to add meaning beyond the schema.

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

    Purpose5/5

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

    The description clearly states the tool checks dry-run mode, OAuth readiness, and live upload readiness, which is a specific verb and resource. It distinguishes from siblings like youtube_oauth_authorize_url and youtube_upload_short by focusing on status checks.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines3/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description implies usage when needing readiness status, but lacks explicit guidance on when to use vs alternatives or exclusions. It does not mention when not to use this tool.

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

GitHub Badge

Glama performs regular codebase and documentation scans to:

  • Confirm that the MCP server is working as expected.
  • Confirm that there are no obvious security issues.
  • Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

youtube-shorts-agent MCP server

Copy to your README.md:

Score Badge

youtube-shorts-agent MCP server

Copy to your README.md:

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidmosiah/youtube-shorts-agent'

If you have feedback or need assistance with the MCP directory API, please join our Discord server