Skip to main content
Glama

DropTrack

by io.github.droptrack

DropTrack Analyze Audio

droptrack_analyze_audio

Analyze a WAV, MP3, AIF, AIFF, SoundCloud URL, or Spotify track URL directly through MCP and return structured analysis. No browser analyzer visit is required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
s3UrlNoS3 URL for an uploaded audio file, such as s3://bucket/key
titleNoOptional track title used when creating a new DropTrack track
artistNoOptional artist name used when creating a new DropTrack track
trackIdNoExisting DropTrack track ID. When provided, uploaded audio is saved as a new active track version instead of a new track
audioUrlNoDirect HTTPS audio URL. S3 URLs are preferred for private uploads
fileNameNoFilename used to infer audio type when needed
uploadKeyNoupload_key returned by droptrack_create_audio_analysis_upload after the client PUTs the file
audioBase64NoInline base64 audio for small files only
contentTypeNoOptional audio MIME type used when the source does not provide one
providerUrlNoSpotify track URL/URI or SoundCloud URL
accountTypesNoSubmission opportunity categories to return with the analysis
versionLabelNoOptional label when trackId is provided and a new version is created
analysisTimeoutMsNoOptional maximum milliseconds to wait for synchronous analysis before returning the saved track and polling instructions
includeOpportunitiesNoReturn personalized submission opportunities derived from the analysis genres
opportunitiesPerTypeNoMaximum submission opportunities to return per account type

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultNoStructured DropTrack result returned by this tool

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

B3.1/5.0
Behavior2/5

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

Annotations declare readOnlyHint=false, yet the description frames this as a pure analysis call ('Analyze... and return structured analysis'). The schema reveals significant undisclosed side effects: creating new DropTrack tracks when title/artist are provided, saving a new active track version when trackId is set, and potentially returning asynchronously with polling instructions per analysisTimeoutMs. This is not a direct annotation contradiction, but a material under-disclosure for a mutating tool.

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?

Two tight sentences with zero waste. The verb and supported inputs are front-loaded, and the second sentence earns its place by establishing the workflow benefit (no browser analyzer visit). Appropriate length for the tool's scope.

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?

For a tool with 15 optional parameters, multiple input pathways, async timeout behavior, and track-creation side effects, the description is too thin. It doesn't surface key decision points an agent needs: new track vs new version (trackId/title/artist), sync vs async behavior and polling, or the prerequisite upload flow via droptrack_create_audio_analysis_upload. An output schema exists, so return values need no explanation, but the central behavioral choices are left entirely to schema spelunking.

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

Parameters4/5

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 genuine value by enumerating accepted input formats (WAV, MP3, AIF, AIFF, SoundCloud, Spotify), which guides selection among the five input-source parameters (s3Url, audioUrl, providerUrl, uploadKey, audioBase64). It avoids duplicating the schema's already-detailed parameter descriptions.

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 uses a specific verb ('Analyze') with explicit resource types (WAV, MP3, AIF, AIFF, SoundCloud URL, Spotify track URL) and states the outcome: structured analysis returned through MCP. It also distinguishes from the browser-based analyzer workflow. However, it doesn't differentiate from the sibling droptrack_get_track_analysis, which could be confused for retrieving analysis of an existing track.

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 vs alternatives. The schema hints at an upload workflow (upload_key returned by droptrack_create_audio_analysis_upload) and versioning behavior via trackId, but the description never tells the agent whether to prefer this tool over droptrack_get_track_analysis for existing tracks or how the upload flow relates. 'No browser analyzer visit is required' excludes a non-MCP alternative only.

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

All DropTrack toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0
Disambiguation3/5

Most tools target distinct resources and actions, but several clusters are easy to confuse: get_track_analysis vs get_track_analytics vs get_track_tags, plus analyze_audio/request_track_tagging/auto_tag_tracks overlap in the audio-analysis/tagging space. The descriptions do help separate them, so careful agents can disambiguate, but the naming alone creates real misselection risk.

Naming Consistency4/5

All tools share the droptrack_ prefix, use snake_case, and follow a verb-first noun pattern, with list for collections and get for single items. Minor inconsistencies exist—add_contact vs create_contact_list, browse vs list, auto_tag_tracks—but the overall convention is predictable and readable.

Tool Count2/5

At 55 tools this is far beyond the recommended 3-15 range and well over the 25+ threshold. Many tools are near variants of each other, especially company-level vs label-level ads, analytics, and wallet tools, inflating the surface area and making selection harder.

Completeness3/5

The set covers many domains and some workflows are complete, such as album art generation/polling/acceptance/deletion and track tagging request/poll/apply. However, core lifecycle gaps remain: no update or delete for campaigns, contacts, or contact lists, no playlist mutation tools, and AI press-release/bio workflows end at polling without a save or publish step.

Resources