Skip to main content
Glama
Sign In

StudioSphere Pulse — Audio Intelligence

by space.studiosphere
OverviewDiscussionsAdmin

analyze_track

Run audio analysis on a public audio URL. Requires estimate_cost to be called first (job_estimate_id). Requires PULSE_API_KEY. Before calling, you MUST confirm with the user that they have a lawful basis to submit this audio for analysis. For a user-requested folder, project, playlist, or batch, one confirmation can cover every track in that scope. Returns job_id — poll get_job_status for results. If processing or payment returns estimate_pricing_changed, get a fresh free estimate with estimate_cost, present the new price, and wait for explicit user approval before processing or payment. Never silently retry analysis or purchase.

Input Schema

NameRequiredDescriptionDefault
toolsYesAnalysis tools to run. Available in v1.0: bpm, key, waveform. Coming soon: structure, chords.
audio_urlYesPublic URL of the audio file.
job_estimate_idYesThe job_estimate_id returned by estimate_cost. Must not have passed the returned expires_at timestamp.
attestation_confirmedYesSet to true ONLY after the user has confirmed they have rights, permission, lawful access, or another legal basis to submit this audio, or the current user-requested batch/folder/project containing it, for analysis.

Output Schema

NameRequiredDescriptionDefault
okNoTrue when analysis was accepted.
errorNoMachine-readable error code.
job_idNoPulse analysis job id.
statusNoCurrent job status.
detailsNoAdditional structured context from Pulse.
messageNoHuman-readable recovery guidance.
poll_urlNoRelative status polling URL.
retryableNoWhether the caller may retry after changing state or waiting.
cache_hitsNoTools served from cache.
stream_urlNoRelative SSE status URL.
account_typeNoAccount type used for the request.
upgrade_pathNo
conversion_noteNo
tokens_estimatedNoEstimated token charge.
cost_usd_estimatedNoEstimated USD value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / job_estimate_id / description
      Previous value: -"The job_estimate_id returned by estimate_cost. Must not be expired (30 min TTL)."New value: +"The job_estimate_id returned by estimate_cost. Must not have passed the returned expires_at timestamp."
  2. Changed3 schema fields changed
    • addedOutput schema / anyOf
      Added value: +[
+  {
+    "required": [
+      "ok",
+      "job_id",
+      "status",
+      "cache_hits",
+      "tokens_estimated",
+      "cost_usd_estimated",
+      "poll_url",
+      "stream_url"
+    ]
+  },
+  {
+    "required": [
+      "error",
+      "message"
+    ]
+  }
+]
    • addedOutput schema / properties
      Added value: +{
+  "account_type": {
+    "description": "Account type used for the request.",
+    "type": "string"
+  },
+  "cache_hits": {
+    "description": "Tools served from cache.",
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  "conversion_note": {
+    "type": "string"
+  },
+  "cost_usd_estimated": {
+    "description": "Estimated USD value.",
+    "type": "number"
+  },
+  "details": {
+    "additionalProperties": true,
+    "description": "Additional structured context from Pulse.",
+    "type": "object"
+  },
+  "error": {
+    "description": "Machine-readable error code.",
+    "type": "string"
+  },
+  "job_id": {
+    "description": "Pulse analysis job id.",
+    "type": "string"
+  },
+  "message": {
+    "description": "Human-readable recovery guidance.",
+    "type": "string"
+  },
+  "ok": {
+    "description": "True when analysis was accepted.",
+    "type": "boolean"
+  },
+  "poll_url": {
+    "description": "Relative status polling URL.",
+    "type": "string"
+  },
+  "retryable": {
+    "description": "Whether the caller may retry after changing state or waiting.",
+    "type": "boolean"
+  },
+  "status": {
+    "description": "Current job status.",
+    "type": "string"
+  },
+  "stream_url": {
+    "description": "Relative SSE status URL.",
+    "type": "string"
+  },
+  "tokens_estimated": {
+    "description": "Estimated token charge.",
+    "type": "number"
+  },
+  "upgrade_path": {
+    "type": "string"
+  }
+}
    • addedOutput schema / required
      Added value: +[]
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
  4. Changed1 schema field changed
    • changedInput schema / properties / attestation_confirmed / description
      Previous value: -"Set to true ONLY after the user has confirmed they have rights, permission, lawful access, or another legal basis to submit this audio for analysis."New value: +"Set to true ONLY after the user has confirmed they have rights, permission, lawful access, or another legal basis to submit this audio, or the current user-requested batch/folder/project containing it, for analysis."
  5. Changed1 schema field changed
    • changedInput schema / properties / attestation_confirmed / description
      Previous value: -"Set to true ONLY after the user has confirmed they have the right to submit this audio."New value: +"Set to true ONLY after the user has confirmed they have rights, permission, lawful access, or another legal basis to submit this audio for analysis."
  6. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false) by disclosing auth requirements (PULSE_API_KEY), a mandatory user-attestation gate, the return value (job_id), the polling workflow, and explicit no-silent-retry behavior on pricing changes. This is exactly the behavioral context an agent needs to avoid unauthorized or unintended submissions.

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?

Front-loaded with the core action and preconditions, then the return/polling flow, then the edge-case pricing handling. It is somewhat long, but nearly every sentence carries actionable constraint information, so little is wasted.

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 a mutation tool with an output schema, the description still covers the full lifecycle: prerequisites, auth, legal attestation, return value, polling, and the pricing-change/retry policy. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description adds real value by explaining the estimate-to-analysis flow (job_estimate_id must come from estimate_cost) and the scope semantics of attestation_confirmed (one confirmation can cover an entire folder/project/playlist batch). This clarifies parameter intent beyond the schema text.

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?

States a specific verb+resource (run audio analysis on a public audio URL) and clearly distinguishes itself from siblings by naming estimate_cost as a prerequisite and get_job_status as the polling follow-up. An agent can immediately tell this is the actual analysis-execution step versus the estimate step.

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

Usage Guidelines5/5

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

Explicitly states when to use it and the required preconditions: estimate_cost must be called first to obtain job_estimate_id, PULSE_API_KEY is required, and user confirmation of lawful basis is mandatory before calling. It also names the alternative for retrieving results (get_job_status) and covers the pricing-changed re-estimate path.

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

All StudioSphere Pulse — Audio Intelligence toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources