A
licenseA
qualityC
maintenanceAutonomous music intelligence & A&R qualification engine. Extracts acoustic metadata (BPM, key, mood), scores real-time Spotify streaming traction, and detects AI-generated audio (Suno/Udio).
5
79 npm
MIT
StudioSphere Pulse — Audio Intelligence
Server Details
Free licensed loops and authorized audio analysis: BPM, key, waveform. Estimate before paid use.
Ownership verified
- Status
- Healthy
- Uptime
- 100.0% over 82 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- notpaulb/studiosphere-pulse-mcp
- GitHub Stars
- 0
- Server Listing
- studiosphere-pulse-mcp
- ChatGPT
- –
- Claude
- StudioSphere Pulse
TDQS
A3.9/5.0
Scored across 10 tools
Disambiguation3/5
Most tools target distinct resources, but the set has three overlapping entry points into the same 'analyze a URL and pay for it' workflow: analyze_track (key-based), request_payment_link (anonymous one-off Checkout), and start_trial (free trial). Their boundaries are only explained through long billing prose, and get_open_loop vs search_open_loops are also easy to confuse at a glance. The distinctions are real but require careful reading rather than being self-evident.
Naming Consistency5/5
Every name follows a strict snake_case verb_noun pattern (analyze_track, estimate_cost, get_job_status, list_token_packs, purchase_token_pack, search_open_loops, start_trial). Verbs are used consistently by intent: get_/list_/search_ for reads, create/purchase/request_ for writes.
Tool Count5/5
Ten tools is well within a healthy scope for an audio-analysis-plus-billing service. Each tool maps to a real step in the pipeline (search, estimate, pay, analyze, poll, balance, packs) rather than being redundant padding.
Completeness4/5
The core lifecycle is covered end to end: search/retrieve samples, estimate cost, obtain a payment link or trial key, run analysis, and poll job status, plus token balance and pack purchase. Gaps are moderate — no job listing/history, no cancellation, and refund reconciliation is explicitly punted to a result page or external REST receipt URL rather than a tool.
Available Tools
10 toolsanalyze_trackAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tools | Yes | Analysis tools to run. Available in v1.0: bpm, key, waveform. Coming soon: structure, chords. | |
| audio_url | Yes | Public URL of the audio file. | |
| job_estimate_id | Yes | The job_estimate_id returned by estimate_cost. Must not have passed the returned expires_at timestamp. | |
| attestation_confirmed | Yes | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | True when analysis was accepted. |
| error | No | Machine-readable error code. |
| job_id | No | Pulse analysis job id. |
| status | No | Current job status. |
| details | No | Additional structured context from Pulse. |
| message | No | Human-readable recovery guidance. |
| poll_url | No | Relative status polling URL. |
| retryable | No | Whether the caller may retry after changing state or waiting. |
| cache_hits | No | Tools served from cache. |
| stream_url | No | Relative SSE status URL. |
| account_type | No | Account type used for the request. |
| upgrade_path | No | |
| conversion_note | No | |
| tokens_estimated | No | Estimated token charge. |
| cost_usd_estimated | No | Estimated USD value. |
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.
estimate_costARead-onlyIdempotentInspect
Estimate audio analysis cost anonymously and free before committing. Read analysis_options for eligible anonymous one-off Checkout, trial duration fit and key-based banked-token use; these do not verify balance or trial entitlement. Eligible quotes can include checkout.upfront_payment_estimate from the current charge builder; this is not a reserved price or a saved-link charge. Review the hosted amount before payment. Returns estimated dollars, job_estimate_id and expires_at. Review the estimate before spending; final cost depends on measured duration and completed analysis, and Checkout can collect a buffered amount with refund thresholds. If processing or payment returns estimate_pricing_changed, get a fresh free estimate, present the new price, and wait for explicit user approval before processing or payment. Never silently retry analysis or purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| tools | Yes | Analysis tools to price. Available in v1.0: bpm, key, waveform. Coming soon: structure, chords. | |
| audio_url | Yes | Publicly accessible URL of the audio file (MP3, WAV, FLAC, OGG, Opus). |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| error | No | Machine-readable error code. |
| tokens | No | Estimated Pulse tokens. |
| details | No | Additional structured context from Pulse. |
| message | No | Human-readable recovery guidance. |
| cost_usd | No | Estimated analysis cost in USD. |
| breakdown | No | Per-tool token and cost estimate. |
| retryable | No | Whether the caller may retry after changing state or waiting. |
| expires_at | No | ISO timestamp when the estimate expires. |
| content_type | No | |
| cost_display | No | Human-readable USD estimate. |
| duration_source | No | Duration provenance: prior worker measurement, declared WAV or MP3 frame metadata, MP3 bitrate inferred from a bounded prefix, assumed format byte rate, or placeholder. Prefix bitrate cannot establish that the whole file is constant bitrate. All quotes remain estimates; processing measures actual audio. |
| job_estimate_id | No | Estimate identifier valid for the configured TTL. |
| analysis_options | No | Advisory continuation choices for this estimate, not a reserved charge, verified balance, trial grant or host certification. |
| normalize_source | No | |
| duration_inferred | No | |
| audio_url_original | No | |
| audio_url_normalized | No | |
| content_length_bytes | No | |
| duration_estimate_sec | No | Estimated audio duration in seconds. |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and non-destructive, so the safety profile is covered. The description adds real value beyond that: it discloses that quotes are not reserved prices, that eligibility does not verify balance or trial entitlement, that outputs expire, and that Checkout may collect a buffered amount with refund thresholds. That is meaningful behavioral context the annotations do not carry.
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 first sentence is well front-loaded, but the body is a dense run-on mixing URL-format field names, refund semantics, and retry policy without structural breaks. Information is present but not efficiently organized; several clauses could be trimmed or split.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return-value explanation (dollars, job_estimate_id, expires_at) is somewhat redundant. Still, the description covers the pre-spend verification flow, eligibility caveats, and the pricing-change recovery path, giving an agent enough to call and act on this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with only 2 parameters, so the schema fully documents audio_url and the tools enum. The description adds no format, constraint, or semantics beyond the schema, so the baseline of 3 applies.
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 opening sentence names a specific verb ('Estimate') and resource ('audio analysis cost') with clear scope modifiers: anonymous, free, before committing. This distinguishes it from purchase_token_pack and analyze_track, which perform the spend/action. However, the heavy jargon (banked-token, checkout.upfront_payment_estimate) dilutes what should be a crisp statement of purpose.
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?
It implies context ('before committing') and gives a conditional workflow for the estimate_pricing_changed case, plus the instruction not to silently retry. But it never names an alternative sibling (analyze_track, purchase_token_pack) or states explicitly when NOT to use this tool, leaving the agent to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_statusBRead-onlyIdempotentInspect
Resume the original saved job anonymously after interruption. Follow continuation for human payment, bounded polling, result review or support; never create a replacement purchase. Completed/partial results may include studio_notes: preserve provenance, warnings and failed tools; BPM/key are estimates requiring review. Keep job references private. Results, costs and notes are not payment/refund confirmation. refund_status_source=local_ledger is reconciliation at refund_checked_at, not a fresh provider query; unconfirmed/needs_review is not a completed refund. Review terminal Checkout billing separately on the result page or the on-demand REST receipt_api_url; that URL is not another MCP tool.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job_id returned by analyze_track or request_payment_link. | |
| include_waveform_data | No | Optional. Defaults to false so chat agents receive a compact waveform summary plus result_url. Set true only if raw waveform samples are needed. | |
| include_waveform_image | No | Optional. Defaults to true. When the job has waveform data, include a server-rendered PNG as MCP image content so the client can display it without fetching a URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Machine-readable error code. |
| job_id | No | Pulse analysis job id. |
| status | No | Current or terminal job status. |
| billing | No | |
| details | No | Additional structured context from Pulse. |
| message | No | Human-readable recovery guidance. |
| results | No | Analysis results when available. |
| cost_usd | No | |
| metadata | No | Analysis metadata, including asset type, source hints, library metadata, and confidence policy when available. |
| retryable | No | Whether the caller may retry after changing state or waiting. |
| expires_at | No | |
| result_url | No | Public result page URL. |
| completed_at | No | |
| continuation | No | Advisory saved-job recovery. URLs contain a private job reference. No provider read or settlement verification is performed. |
| studio_notes | No | Optional plain-text project notes for completed/partial usable results. Preserve review warnings, provenance and failed tools. Contains no audio/source URL or payment/refund receipt fields; job references are private. |
| waveform_file | No | |
| payment_source | No | |
| tokens_charged | No | |
| waveform_image | No | |
| tokens_estimated | No | |
| waveform_png_url | No | |
| waveform_svg_url | No | |
| result_provenance | No | Per-tool provenance and applicability summary for interpreting detected, audio_candidate (manual review required), filename-sourced, suppressed, or low-confidence results. |
| waveform_markdown | No | |
| result_quality_notes | No | Human-readable quality notes for suppressed, low-confidence, filename-sourced, or review-needed results. |
TDQS
B3.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint, so the safety profile is covered; the description adds meaningful context beyond that: refund_status_source=local_ledger is reconciliation at refund_checked_at and not a fresh provider query, unconfirmed/needs_review is not a completed refund, and results are not payment confirmation. It also warns to preserve provenance and keep job references private. The 'Resume' framing slightly muddies the read-only picture but does not state a mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is a dense run-on of billing, refund-reconciliation and checkpoint caveats, none of which is front-loaded as the primary purpose. Core information (what the tool returns) is buried behind refund_checked_at/local_ledger detail, and several sentences could be shortened or moved to the result documentation.
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?
An output schema exists, so return values need not be explained, and the description does cover the shape of results (studio_notes, BPM/key estimates, warnings, failed tools). What is missing is a clear statement of the tool's core retrieval behavior and job lifecycle, leaving the agent to reconstruct the primary contract from side remarks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with job_id, include_waveform_data and include_waveform_image all documented in the schema, so the baseline is 3. The description adds nothing about any parameter, not even the job_id that analyze_track or request_payment_link produces.
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 opening sentence frames the tool as resuming a saved job rather than plainly stating that it retrieves the status/result of an analysis job by job_id. The follow-on clauses about results, refunds and billing hint at what is returned, but an agent must infer the core verb+resource. It is distinguishable from siblings only indirectly.
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?
It does give usage contexts (follow continuation for payment, bounded polling, result review, support) and a prohibition (never create a replacement purchase), which implicitly routes away from purchase_token_pack/request_payment_link. However, the alternatives are never named and no sibling tool is explicitly contrasted, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_open_loopARead-onlyIdempotentInspect
Get a released sample’s metadata, exact licence, attribution, preview and WAV download URLs. Free; no account or tokens required. Keep attribution when using the sample in a song.
| Name | Required | Description | Default |
|---|---|---|---|
| pol_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| pack | No | |
| error | No | Machine-readable error code. |
| title | No | |
| pol_id | No | |
| details | No | Additional structured context from Pulse. |
| license | No | |
| message | No | Human-readable recovery guidance. |
| retryable | No | Whether the caller may retry after changing state or waiting. |
| attribution | No | |
| license_url | No | |
| download_url | No | |
| review_basis | No | |
| provenance_url | No | |
| metadata_export_url | No |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: no auth/tokens are needed and usage carries a licensing/attribution obligation — both beyond what the annotations convey.
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?
Three short sentences, front-loaded with the core capability, then cost/auth, then the licensing caveat. No filler and nothing repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-item lookup with an output schema (so return shape needn't be explained) and full annotation coverage, this is nearly complete. The one meaningful gap is the provenance of the required pol_id — an agent must infer it comes from search_open_loops.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single required parameter pol_id has no textual explanation of what it identifies or where it comes from. The description only indirectly implies the id refers to a 'released sample', while the format constraint lives in the schema pattern, so it adds marginal semantics.
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?
Specific verb ('Get') plus a precise resource ('a released sample's metadata, exact licence, attribution, preview and WAV download URLs') — an agent immediately knows this is a single-item detail fetch, not a search. It does not name search_open_loops as the sibling it differs from, so sibling differentiation is only implicit.
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?
'Free; no account or tokens required' preempts a real question given the cost/token siblings (estimate_cost, get_token_balance, purchase_token_pack), and the attribution note flags a post-use obligation. However, it never says how to obtain a pol_id or points to search_open_loops as the way to find one, leaving the when-to-use path implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_token_balanceARead-onlyIdempotentInspect
Check the banked token balance for the authenticated Pulse account. Requires PULSE_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Machine-readable error code. |
| details | No | Additional structured context from Pulse. |
| message | No | Human-readable recovery guidance. |
| retryable | No | Whether the caller may retry after changing state or waiting. |
| account_type | No | Pulse account type. |
| trial_policy | No | |
| banked_tokens | No | Current banked-token balance. |
| api_key_prefix | No | Redacted API-key prefix. |
| trial_allowance | No | |
| trial_expires_at | No | Trial expiry timestamp if this is a trial account. |
| account_created_at | No | Account creation timestamp. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds a genuinely useful behavioral detail beyond the annotations: the PULSE_API_KEY authentication requirement, which the rubric explicitly counts as credit-worthy context.
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 short sentences with zero filler; the purpose is front-loaded and the auth constraint follows immediately. Nothing 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?
An output schema exists, so the description need not explain return values, and with no input parameters there is little else to document. Purpose plus auth requirement is sufficient for an agent to call this correctly.
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?
The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond the auth context it already provides.
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 ('Check') and resource ('banked token balance') scoped to the authenticated Pulse account. This is clearly distinguishable from sibling tools like list_token_packs or purchase_token_pack, which deal with packs rather than balance.
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 (query the current balance), but there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The auth prerequisite is stated but that is a precondition, not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_token_packsARead-onlyIdempotentInspect
List the available Pulse token packs (tier label, token count, price). Use before purchase_token_pack to show options to the user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Machine-readable error code. |
| packs | No | Available token-pack tiers. |
| details | No | Additional structured context from Pulse. |
| enabled | No | Whether token-pack purchasing is enabled. |
| message | No | Human-readable recovery guidance. |
| retryable | No | Whether the caller may retry after changing state or waiting. |
TDQS
A4.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds that the list includes tier label, token count, and price, which provides useful context about return content, but this may duplicate the output schema. No additional behavioral disclosures (e.g., auth requirements, rate limits, pagination) are provided, so a moderate score is appropriate.
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 only two sentences. The first sentence states the action and output contents, the second provides usage context. It is succinct, front-loaded, and every word provides value.
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?
The tool is low complexity: no parameters, simple list operation, with output schema present and comprehensive annotations. The description covers the core purpose and the primary usage context (before purchase). There are no significant gaps for the agent to invoke this tool correctly.
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?
The tool has zero parameters and the schema is empty. With no parameters to document, the baseline is 4. The description does not need to add parameter meaning, and it does not. It correctly avoids mentioning parameters that do not exist.
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 action: 'List the available Pulse token packs' with specific return contents (tier label, token count, price). It also distinguishes this tool from sibling purchase_token_pack by referencing it and positioning this as a pre-purchase listing action.
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?
The description gives explicit usage guidance: 'Use before purchase_token_pack to show options to the user.' This tells the agent exactly when to invoke this tool and names the downstream alternative/pair, fulfilling the when-to-use requirement clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_token_packAInspect
Create a Stripe Checkout session for a Pulse token pack. Returns payment_url — DO NOT submit it programmatically; surface it to the user so they can complete payment in their browser. Once paid, banked tokens are credited automatically. Requires PULSE_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | Yes | Token pack tier |
Output Schema
| Name | Required | Description |
|---|---|---|
| pack | No | Token-pack tier label. |
| error | No | Machine-readable error code. |
| tokens | No | Tokens included in the pack. |
| details | No | Additional structured context from Pulse. |
| message | No | Human-readable recovery guidance. |
| currency | No | Checkout currency. |
| retryable | No | Whether the caller may retry after changing state or waiting. |
| amount_usd | No | Pack price in USD. |
| expires_at | No | ISO timestamp when the Checkout link expires. |
| payment_url | No | Stripe Checkout URL to present to the user. |
| purchase_id | No | Pulse token-pack purchase id. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover safety hints (openWorldHint, non-idempotent, non-destructive); the description adds substantive context they cannot convey: the required PULSE_API_KEY, the asynchronous post-condition that tokens are credited after payment, and a hard prohibition on programmatic URL submission. It does not cover retry/idempotency semantics for repeated session creation, which matters for a non-idempotent 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?
Three tight sentences, purpose front-loaded, then the critical output-handling warning, then the auth prerequisite. No filler, and the most failure-prone instruction gets due prominence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return value need not be explained, and the auth requirement plus post-payment crediting are stated, so an agent has enough to invoke it correctly. The one gap is routing versus request_payment_link, which the description never addresses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema description coverage is 100%, so the schema fully documents 'pack' including its enum tiers. The description adds no meaning about tier choice or relative value, so baseline 3 is appropriate.
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?
States a specific verb and resource: 'Create a Stripe Checkout session for a Pulse token pack.' This clearly separates it from readers like get_token_balance and list_token_packs, but it does not distinguish itself from the sibling request_payment_link, which sounds like an overlapping purchasing path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear operational constraint — do not submit the returned URL programmatically, surface it to the user instead — which tells the agent exactly how the tool is meant to be consumed. It does not state when to choose it over list_token_packs or request_payment_link, so an explicit alternative-selection rule is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_payment_linkAInspect
Create anonymous one-off Checkout after an estimate, explicit human link-creation approval and lawful-basis confirmation. Read analysis_options.checkout. The human reviews the hosted upfront amount and pays; it can exceed analysis cost. Save job_id, payment_url and continuation.review_url privately; lost links require support, not a replacement purchase. For minimum_charge_offer, show minimum final cost and upfront estimate, obtain explicit acceptance, then send accept_minimum_charge:true and max_upfront_amount_cents at the approved ceiling. Rights alone do not approve spending. On estimate_pricing_changed, get a fresh free estimate and explicit approval. An exceeded cap needs new review; never raise it or retry automatically. Poll the original job with get_job_status after payment or interruption. Host setup/recovery: https://pulse.studiosphere.space/connect
| Name | Required | Description | Default |
|---|---|---|---|
| job_estimate_id | Yes | The job_estimate_id returned by estimate_cost. | |
| accept_minimum_charge | No | Optional. Set true only after explicit human acceptance of minimum_charge_offer.minimum_final_cost_usd and its estimated upfront payment. Rights confirmation alone is not spending approval. | |
| attestation_confirmed | Yes | 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. | |
| max_upfront_amount_cents | No | Optional approved upfront USD ceiling in whole cents; required for minimum-charge acceptance. The gateway rejects a higher charge before creating a purchase. Do not raise it without renewed human approval. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Machine-readable error code. |
| job_id | No | Pulse job id for polling after payment. |
| deduped | No | True when an existing active Checkout link was reused. |
| details | No | Additional structured context from Pulse. |
| message | No | Human-readable recovery guidance. |
| retryable | No | Whether the caller may retry after changing state or waiting. |
| expires_at | No | ISO timestamp when the Checkout link expires. |
| payment_url | No | Stripe Checkout URL to present to the user. |
| continuation | No | Advisory saved-job recovery. URLs contain a private job reference. No provider read or settlement verification is performed. |
| cost_display | No | Human-readable estimated cost. |
| charged_display | No | Human-readable upfront Checkout charge. |
| amount_charged_cents | No | Stripe Checkout charge in cents. |
| amount_estimate_cents | No | Estimated usage value in cents. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that the hosted upfront amount is reviewed and paid by a human, may exceed the analysis cost, and that lost links require support rather than replacement purchase. It also explains cap enforcement, no automatic retries, and the consequence of exceeded limits.
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 front-loaded with the core action and then branches into required workflow details. It is dense but largely earn-place content; however, its length and high instruction density make it closer to operational policy than a concise tool summary.
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?
An output schema exists, so return values need not be explained. Given the complexity and risk of this payment-link tool, the description covers prerequisites, human approval, edge cases, recovery, and next steps comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 four parameters thoroughly. The description reinforces workflow conditions for accept_minimum_charge and max_upfront_amount_cents, but largely repeats the schema's guidance rather than adding new parameter semantics.
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 states a specific action and resource: creating an anonymous one-off Checkout/payment link. It situates the action after estimate_cost and human approval, clearly distinguishing it from estimation and token-pack purchase siblings.
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?
It gives explicit prerequisites: an estimate must exist, a human must approve link creation, and lawful basis must be confirmed. It also handles branches for minimum_charge_offer, estimate_pricing_changed, exceeded caps, payment/interruption follow-up via get_job_status, and recovery support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_open_loopsARead-onlyIdempotentInspect
Find original synthesis kits and individually auditioned source samples by keyword, pack, BPM, key, role, review_basis and licence. project_bpm with bpm_tolerance (default 5) returns closest-tempo candidates and project_match reasons; do not combine it with bpm_min/max. Project keys need explicit mode. Optional include_unkeyed_percussion includes percussion hints with unspecified key, requiring audition; this is not proof of harmonic fit. Automated checks are not listening review. Free; no account or tokens required. Keywords match any term; read search_match.missing_terms before claiming a full match or genre. Key abbreviations such as Am are accepted; hard filters stay exact. Source tags are creator hints. Preserve attribution when required and follow each sample’s licence.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search sample titles, pack names and source tags. | |
| key | No | ||
| pack | No | ||
| role | No | ||
| limit | No | ||
| offset | No | ||
| bpm_max | No | ||
| bpm_min | No | ||
| license | No | ||
| project_bpm | No | Project tempo; cannot combine with bpm_min/max. | |
| review_basis | No | ||
| bpm_tolerance | No | Project tempo tolerance; default 5 BPM. | |
| include_unkeyed_percussion | No | Project mode only: include percussion tag hints with unspecified key; audition required. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Machine-readable error code. |
| items | No | |
| limit | No | |
| total | No | |
| offset | No | |
| details | No | Additional structured context from Pulse. |
| message | No | Human-readable recovery guidance. |
| retryable | No | Whether the caller may retry after changing state or waiting. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, non-destructive behavior, but the description adds materially new context: 'Free; no account or tokens required', that automated checks are not listening review, that unkeyed percussion implies audition rather than harmonic fit, that keywords match any term and search_match.missing_terms must be read before claiming a full match, plus attribution/licence obligations. Only pagination/result-size behavior goes unmentioned.
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?
Purpose and the main search facets are front-loaded, and nearly every clause carries operational meaning. The middle section stacks several caveats into dense semicolon chains, which slightly hurts scannability, but there is little pure filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter, zero-required search tool with an output schema, the description covers the risky parameters, result-interpretation semantics, cost/auth model, and licence obligations. The missing pieces — pagination via limit/offset and role/pack meaning — are minor since defaults exist and the schema bounds them.
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?
With schema coverage at only 31% across 13 params, the description compensates well: it explains project_bpm vs bpm_min/max exclusivity, the bpm_tolerance default of 5, include_unkeyed_percussion's audition caveat, key abbreviation acceptance (Am) with 'hard filters stay exact', and that source tags are creator hints. It leaves limit, offset, role and pack semantics unaddressed.
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?
Opens with a specific verb and resource — 'Find original synthesis kits and individually auditioned source samples' — and enumerates the facets that define the search space (keyword, pack, BPM, key, role, review_basis, licence). This is clearly a discovery/search tool, readily distinguished from siblings like get_open_loop (fetch by id) and analyze_track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit conditional guidance: project_bpm with bpm_tolerance returns closest-tempo candidates, and 'do not combine it with bpm_min/max'; project keys need an explicit mode; include_unkeyed_percussion is project-mode only. It does not name sibling alternatives (e.g., fetching a specific loop by id), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_trialAInspect
Start a temporary, email-free Pulse trial for one URL analysis. Read trial_policy and trial_allowance for the actual duration cap and remaining attempts; an existing trial key may have a lower cap. One completed/partial analysis consumes the allowance regardless of remaining tokens. A failed analysis may retry only when attempts remain. No Stripe Checkout session is created. Store the returned private API key in the client or a trusted local environment; never repost it in logs, screenshots, shared chats or issues. Confirm rights, permission, lawful access, or another legal basis before analysis. The original CC0 demo is https://pulse.studiosphere.space/assets/pulse-demo.mp3 (180 seconds); use it only if it fits the returned cap.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Machine-readable error code. |
| api_key | No | Temporary Pulse API key for the trial account. Treat as private; do not print it in public logs, screenshots, GitHub issues, shared chats, or directory examples. |
| details | No | Additional structured context from Pulse. |
| message | No | Human-readable recovery guidance. |
| retryable | No | Whether the caller may retry after changing state or waiting. |
| expires_at | No | ISO timestamp when the temporary key expires. |
| usage_note | No | Limits and usage guidance for the trial. |
| account_type | No | The account type created by this tool. |
| analyze_path | No | REST path for authenticated analysis. |
| trial_policy | No | |
| upgrade_path | No | Path for converting to an account. |
| banked_tokens | No | Trial token balance granted. |
| estimate_path | No | REST path for free estimates. |
| trial_allowance | No |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already say readOnly=false, openWorld=true, idempotent=false, destructive=false, but the description adds crucial behavior: existing trial key may lower the cap, consumption semantics for completed/partial vs failed analyses, no Stripe Checkout, and secure handling of the returned private API key. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and key constraints. Dense but every sentence carries operational, security, or legal meaning; could be made more scannable, but no significant waste.
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?
For a zero-parameter tool with an output schema and annotations covering safety, the description supplies all needed calling context: trial policy references, allowance/retry rules, payment distinction, key storage, and legal prerequisites. Return values are covered by the output schema.
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?
There are zero input parameters, so the baseline is 4. The description adds no parameter meaning because none exist, though it mentions a returned private API key and a demo URL.
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?
Specific verb (Start) and resource (temporary, email-free Pulse trial for one URL analysis). It also distinguishes itself from paid siblings by stating 'No Stripe Checkout session is created,' so an agent can tell it apart from purchase_token_pack or request_payment_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear conditions: read trial_policy and trial_allowance, one analysis consumes allowance, failed analysis retries only if attempts remain, no Stripe session, confirm legal basis. It does not name alternative tools or explicitly say when to prefer them, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
get_open_loop2 fields changed- added
Output schema / properties / metadata_export_urlAdded value: +{ + "type": "string" +} - added
Output schema / properties / provenance_urlAdded value: +{ + "type": "string" +}
- Changed
search_open_loops8 fields changed- added
Input schema / properties / bpm_toleranceAdded value: +{ + "description": "Project tempo tolerance; default 5 BPM.", + "maximum": 40, + "minimum": 0, + "type": "number" +} - added
Input schema / properties / include_unkeyed_percussionAdded value: +{ + "description": "Project mode only: include percussion tag hints with unspecified key; audition required.", + "type": "boolean" +} - added
Input schema / properties / project_bpmAdded value: +{ + "description": "Project tempo; cannot combine with bpm_min/max.", + "maximum": 400, + "minimum": 1, + "type": "number" +} - added
Input schema / properties / review_basisAdded value: +{ + "enum": [ + "individually_auditioned", + "original_synthesis" + ], + "type": "string" +} - added
Input schema / properties / roleAdded value: +{ + "enum": [ + "percussion", + "bass", + "chords", + "melody", + "fx", + "vocal", + "mixed", + "unknown" + ], + "type": "string" +} - added
Output schema / properties / items / items / properties / metadata_export_urlAdded value: +{ + "type": "string" +} - added
Output schema / properties / items / items / properties / project_matchAdded value: +{ + "additionalProperties": false, + "properties": { + "key_relation": { + "enum": [ + "exact", + "not_requested", + "unspecified_percussion" + ], + "type": "string" + }, + "reasons": { + "items": { + "type": "string" + }, + "type": "array" + }, + "review_basis": { + "enum": [ + "individually_auditioned", + "original_synthesis" + ], + "type": "string" + }, + "tempo_delta_bpm": { + "type": "number" + } + }, + "required": [ + "tempo_delta_bpm", + "key_relation", + "review_basis", + "reasons" + ], + "type": "object" +} - added
Output schema / properties / items / items / properties / provenance_urlAdded value: +{ + "type": "string" +}
2 tool updates
- Changed
get_job_status1 field changed- changed
Input schema / properties / include_waveform_image / descriptionPrevious value: -"Optional. Defaults to true. When the job has waveform data, include a server-rendered SVG as MCP image content so the client can display it without fetching a URL."New value: +"Optional. Defaults to true. When the job has waveform data, include a server-rendered PNG as MCP image content so the client can display it without fetching a URL."
- Changed
search_open_loops1 field changed- added
Output schema / properties / items / items / propertiesAdded value: +{ + "search_match": { + "additionalProperties": false, + "properties": { + "complete": { + "type": "boolean" + }, + "matched_terms": { + "items": { + "type": "string" + }, + "type": "array" + }, + "missing_terms": { + "items": { + "type": "string" + }, + "type": "array" + }, + "mode": { + "const": "any_term", + "type": "string" + } + }, + "required": [ + "mode", + "matched_terms", + "missing_terms", + "complete" + ], + "type": "object" + } +}
2 tool updates
- Changed
estimate_cost1 field changed- added
Output schema / properties / analysis_options / properties / result_deliveryAdded value: +{ + "additionalProperties": false, + "properties": { + "guidance": { + "type": "string" + }, + "studio_notes_field": { + "const": "studio_notes", + "type": "string" + }, + "tool": { + "const": "get_job_status", + "type": "string" + }, + "when": { + "const": "completed_or_partial_with_usable_results", + "type": "string" + } + }, + "required": [ + "tool", + "studio_notes_field", + "when", + "guidance" + ], + "type": "object" +}
- Changed
get_job_status1 field changed- added
Output schema / properties / studio_notesAdded value: +{ + "description": "Optional plain-text project notes for completed/partial usable results. Preserve review warnings, provenance and failed tools. Contains no audio/source URL or payment/refund receipt fields; job references are private.", + "type": "string" +}
2 tool updates
- Changed
estimate_cost1 field changed- added
Output schema / properties / analysis_options / properties / checkout / properties / minimum_charge_offerAdded value: +{ + "description": "Optional below-admission Checkout choice. Explicitly approve its minimum final cost and upfront estimate; send both acceptance and an approved spending ceiling. It is not a reserved price.", + "properties": { + "acceptance_parameter": { + "const": "accept_minimum_charge", + "type": "string" + }, + "eligible": { + "const": true, + "type": "boolean" + }, + "minimum_final_cost_usd": { + "minimum": 0, + "type": "number" + }, + "requires_explicit_acceptance": { + "const": true, + "type": "boolean" + }, + "spending_limit_parameter": { + "const": "max_upfront_amount_cents", + "type": "string" + }, + "upfront_payment_estimate": { + "properties": { + "amount_cents": { + "minimum": 1, + "type": "integer" + }, + "currency": { + "const": "USD", + "type": "string" + }, + "display": { + "type": "string" + }, + "reserved": { + "const": false, + "type": "boolean" + } + }, + "required": [ + "amount_cents", + "display", + "currency", + "reserved" + ], + "type": "object" + } + }, + "required": [ + "eligible", + "requires_explicit_acceptance", + "minimum_final_cost_usd", + "upfront_payment_estimate", + "acceptance_parameter", + "spending_limit_parameter" + ], + "type": "object" +}
- Changed
request_payment_link2 fields changed- added
Input schema / properties / accept_minimum_chargeAdded value: +{ + "description": "Optional. Set true only after explicit human acceptance of minimum_charge_offer.minimum_final_cost_usd and its estimated upfront payment. Rights confirmation alone is not spending approval.", + "type": "boolean" +} - added
Input schema / properties / max_upfront_amount_centsAdded value: +{ + "description": "Optional approved upfront USD ceiling in whole cents; required for minimum-charge acceptance. The gateway rejects a higher charge before creating a purchase. Do not raise it without renewed human approval.", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" +}
1 tool update
- Changed
estimate_cost2 fields changed- changed
Output schema / properties / duration_source / descriptionPrevious value: -"Duration provenance: prior worker measurement, declared uncompressed WAV sample frames, assumed format byte rate, or placeholder. All quotes remain estimates; processing measures actual audio."New value: +"Duration provenance: prior worker measurement, declared WAV or MP3 frame metadata, MP3 bitrate inferred from a bounded prefix, assumed format byte rate, or placeholder. Prefix bitrate cannot establish that the whole file is constant bitrate. All quotes remain estimates; processing measures actual audio." - changed
Output schema / properties / duration_source / enumPrevious value: -[ - "worker_cache", - "wav_header", - "byte_rate", - "placeholder" -]New value: +[ + "worker_cache", + "wav_header", + "mp3_header", + "mp3_bitrate", + "byte_rate", + "placeholder" +]
2 tool updates
- Changed
get_job_status1 field changed- added
Output schema / properties / continuationAdded value: +{ + "additionalProperties": false, + "description": "Advisory saved-job recovery. URLs contain a private job reference. No provider read or settlement verification is performed.", + "properties": { + "action": { + "enum": [ + "complete_checkout", + "wait", + "review_results", + "contact_support", + "check_saved_job" + ], + "type": "string" + }, + "arguments": { + "additionalProperties": false, + "properties": { + "job_id": { + "type": "string" + } + }, + "required": [ + "job_id" + ], + "type": "object" + }, + "automatic_resubmission_allowed": { + "const": false, + "type": "boolean" + }, + "financial_status_verified": { + "const": false, + "type": "boolean" + }, + "guidance": { + "type": "string" + }, + "max_poll_attempts": { + "minimum": 1, + "type": "integer" + }, + "missing_payment_url_action": { + "const": "contact_support", + "type": "string" + }, + "poll_after_seconds": { + "minimum": 1, + "type": "integer" + }, + "receipt_api_url": { + "type": "string" + }, + "review_url": { + "type": "string" + }, + "status_url": { + "type": "string" + }, + "support_email": { + "type": "string" + }, + "tool": { + "const": "get_job_status", + "type": "string" + } + }, + "required": [ + "action", + "tool", + "arguments", + "status_url", + "review_url", + "automatic_resubmission_allowed", + "financial_status_verified", + "support_email", + "guidance" + ], + "type": "object" +}
- Changed
request_payment_link1 field changed- added
Output schema / properties / continuationAdded value: +{ + "additionalProperties": false, + "description": "Advisory saved-job recovery. URLs contain a private job reference. No provider read or settlement verification is performed.", + "properties": { + "action": { + "enum": [ + "complete_checkout", + "wait", + "review_results", + "contact_support", + "check_saved_job" + ], + "type": "string" + }, + "arguments": { + "additionalProperties": false, + "properties": { + "job_id": { + "type": "string" + } + }, + "required": [ + "job_id" + ], + "type": "object" + }, + "automatic_resubmission_allowed": { + "const": false, + "type": "boolean" + }, + "financial_status_verified": { + "const": false, + "type": "boolean" + }, + "guidance": { + "type": "string" + }, + "max_poll_attempts": { + "minimum": 1, + "type": "integer" + }, + "missing_payment_url_action": { + "const": "contact_support", + "type": "string" + }, + "poll_after_seconds": { + "minimum": 1, + "type": "integer" + }, + "receipt_api_url": { + "type": "string" + }, + "review_url": { + "type": "string" + }, + "status_url": { + "type": "string" + }, + "support_email": { + "type": "string" + }, + "tool": { + "const": "get_job_status", + "type": "string" + } + }, + "required": [ + "action", + "tool", + "arguments", + "status_url", + "review_url", + "automatic_resubmission_allowed", + "financial_status_verified", + "support_email", + "guidance" + ], + "type": "object" +}
2 tool updates
- Changed
estimate_cost1 field changed- added
Output schema / properties / analysis_optionsAdded value: +{ + "description": "Advisory continuation choices for this estimate, not a reserved charge, verified balance, trial grant or host certification.", + "properties": { + "advisory": { + "const": true, + "type": "boolean" + }, + "banked_tokens": { + "properties": { + "balance_tool": { + "type": "string" + }, + "balance_verified": { + "const": false, + "type": "boolean" + }, + "estimated_tokens": { + "type": "integer" + }, + "guidance": { + "type": "string" + }, + "packs_tool": { + "type": "string" + }, + "requires_api_key": { + "const": true, + "type": "boolean" + }, + "token_shop_url": { + "type": "string" + }, + "tool": { + "const": "analyze_track", + "type": "string" + } + }, + "required": [ + "tool", + "requires_api_key", + "balance_verified", + "estimated_tokens", + "balance_tool", + "packs_tool", + "token_shop_url", + "guidance" + ], + "type": "object" + }, + "checkout": { + "properties": { + "billing_terms_url": { + "type": "string" + }, + "eligible": { + "type": "boolean" + }, + "guidance": { + "type": "string" + }, + "human_payment_required": { + "const": true, + "type": "boolean" + }, + "minimum_usd": { + "type": "number" + }, + "reason": { + "enum": [ + "eligible", + "below_minimum_charge" + ], + "type": "string" + }, + "requires_api_key": { + "const": false, + "type": "boolean" + }, + "tool": { + "const": "request_payment_link", + "type": "string" + }, + "upfront_payment_estimate": { + "description": "Advisory current-builder upfront Checkout amount, not a reserved price or a saved-link charge. Review the hosted amount before payment.", + "properties": { + "amount_cents": { + "minimum": 0, + "type": "integer" + }, + "currency": { + "const": "USD", + "type": "string" + }, + "display": { + "type": "string" + }, + "reserved": { + "const": false, + "type": "boolean" + } + }, + "required": [ + "amount_cents", + "display", + "currency", + "reserved" + ], + "type": "object" + } + }, + "required": [ + "eligible", + "reason", + "minimum_usd", + "tool", + "requires_api_key", + "human_payment_required", + "billing_terms_url", + "guidance" + ], + "type": "object" + }, + "guidance": { + "type": "string" + }, + "trial": { + "properties": { + "allowance_tool": { + "type": "string" + }, + "allowance_verified": { + "const": false, + "type": "boolean" + }, + "analysis_tool": { + "type": "string" + }, + "credential_creation_requires_approval": { + "const": true, + "type": "boolean" + }, + "duration_within_public_policy": { + "type": "boolean" + }, + "enabled": { + "type": "boolean" + }, + "guidance": { + "type": "string" + }, + "max_duration_sec": { + "type": "number" + }, + "requires_reconnection": { + "const": true, + "type": "boolean" + } + }, + "required": [ + "enabled", + "duration_within_public_policy", + "max_duration_sec", + "allowance_verified", + "credential_creation_requires_approval", + "requires_reconnection", + "allowance_tool", + "analysis_tool", + "guidance" + ], + "type": "object" + } + }, + "required": [ + "advisory", + "guidance", + "checkout", + "trial", + "banked_tokens" + ], + "type": "object" +}
- Changed
request_payment_link1 field changed- changed
Output schema / anyOfPrevious value: -[ - { - "required": [ - "payment_url", - "job_id", - "cost_display", - "charged_display", - "amount_charged_cents", - "amount_estimate_cents", - "expires_at" - ] - }, - { - "required": [ - "error", - "message" - ] - } -]New value: +[ + { + "required": [ + "payment_url", + "job_id", + "cost_display", + "charged_display", + "amount_charged_cents", + "amount_estimate_cents", + "expires_at" + ] + }, + { + "required": [ + "error", + "message" + ] + }, + { + "properties": { + "deduped": { + "const": true + } + }, + "required": [ + "payment_url", + "job_id", + "cost_display", + "expires_at", + "deduped" + ] + } +]
1 tool update
- Changed
estimate_cost1 field changed- added
Output schema / properties / duration_sourceAdded value: +{ + "description": "Duration provenance: prior worker measurement, declared uncompressed WAV sample frames, assumed format byte rate, or placeholder. All quotes remain estimates; processing measures actual audio.", + "enum": [ + "worker_cache", + "wav_header", + "byte_rate", + "placeholder" + ], + "type": "string" +}
1 tool update
- Changed
analyze_track1 field changed- changed
Input schema / properties / job_estimate_id / descriptionPrevious 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."
4 tool updates
- Changed
get_job_status1 field changed- changed
Output schema / properties / result_provenance / descriptionPrevious value: -"Per-tool provenance and applicability summary for interpreting detected, filename-sourced, suppressed, or low-confidence results."New value: +"Per-tool provenance and applicability summary for interpreting detected, audio_candidate (manual review required), filename-sourced, suppressed, or low-confidence results."
- Changed
get_token_balance2 fields changed- added
Output schema / properties / trial_allowanceAdded value: +{ + "additionalProperties": false, + "properties": { + "analyses_remaining": { + "type": "integer" + }, + "attempts_remaining": { + "type": "integer" + }, + "max_duration_sec": { + "type": "integer" + }, + "state": { + "enum": [ + "available", + "in_progress", + "used", + "exhausted" + ], + "type": "string" + } + }, + "required": [ + "state", + "analyses_remaining", + "attempts_remaining", + "max_duration_sec" + ], + "type": "object" +} - added
Output schema / properties / trial_policyAdded value: +{ + "additionalProperties": false, + "properties": { + "enabled": { + "type": "boolean" + }, + "expires_in_hours": { + "type": "integer" + }, + "max_duration_sec": { + "type": "integer" + }, + "max_queued_attempts": { + "type": "integer" + }, + "tokens": { + "type": "integer" + } + }, + "required": [ + "enabled", + "tokens", + "max_duration_sec", + "max_queued_attempts", + "expires_in_hours" + ], + "type": "object" +}
- Changed
purchase_token_pack1 field changed- changed
Input schema / properties / pack / enumPrevious value: -[ - "10K", - "50K", - "200K" -]New value: +[ + "1K", + "10K", + "50K", + "200K" +]
- Changed
start_trial3 fields changed- changed
Output schema / anyOfPrevious value: -[ - { - "required": [ - "api_key", - "account_type", - "banked_tokens", - "expires_at", - "usage_note" - ] - }, - { - "required": [ - "error", - "message" - ] - } -]New value: +[ + { + "required": [ + "api_key", + "account_type", + "banked_tokens", + "expires_at", + "usage_note", + "trial_policy", + "trial_allowance" + ] + }, + { + "required": [ + "error", + "message" + ] + } +] - added
Output schema / properties / trial_allowanceAdded value: +{ + "additionalProperties": false, + "properties": { + "analyses_remaining": { + "type": "integer" + }, + "attempts_remaining": { + "type": "integer" + }, + "max_duration_sec": { + "type": "integer" + }, + "state": { + "enum": [ + "available", + "in_progress", + "used", + "exhausted" + ], + "type": "string" + } + }, + "required": [ + "state", + "analyses_remaining", + "attempts_remaining", + "max_duration_sec" + ], + "type": "object" +} - added
Output schema / properties / trial_policyAdded value: +{ + "additionalProperties": false, + "properties": { + "enabled": { + "type": "boolean" + }, + "expires_in_hours": { + "type": "integer" + }, + "max_duration_sec": { + "type": "integer" + }, + "max_queued_attempts": { + "type": "integer" + }, + "tokens": { + "type": "integer" + } + }, + "required": [ + "enabled", + "tokens", + "max_duration_sec", + "max_queued_attempts", + "expires_in_hours" + ], + "type": "object" +}
2 tool updates
- Changed
get_open_loop2 fields changed- added
Output schema / properties / packAdded value: +{ + "maxLength": 200, + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / review_basisAdded value: +{ + "enum": [ + "original_synthesis", + "individually_auditioned" + ], + "type": "string" +}
- Changed
search_open_loops2 fields changed- added
Input schema / properties / packAdded value: +{ + "maxLength": 200, + "type": "string" +} - changed
Input schema / properties / q / descriptionPrevious value: -"Search sample titles and source tags."New value: +"Search sample titles, pack names and source tags."
2 tool updates
- Added
get_open_loop - Added
search_open_loops
1 tool update
- Changed
get_job_status3 fields changed- added
Output schema / properties / metadataAdded value: +{ + "additionalProperties": true, + "description": "Analysis metadata, including asset type, source hints, library metadata, and confidence policy when available.", + "type": "object" +} - added
Output schema / properties / result_provenanceAdded value: +{ + "additionalProperties": true, + "description": "Per-tool provenance and applicability summary for interpreting detected, filename-sourced, suppressed, or low-confidence results.", + "type": "object" +} - added
Output schema / properties / result_quality_notesAdded value: +{ + "description": "Human-readable quality notes for suppressed, low-confidence, filename-sourced, or review-needed results.", + "items": { + "type": "string" + }, + "type": "array" +}
1 tool update
- Changed
start_trial1 field changed- changed
Output schema / properties / api_key / descriptionPrevious value: -"Temporary Pulse API key for the trial account."New value: +"Temporary Pulse API key for the trial account. Treat as private; do not print it in public logs, screenshots, GitHub issues, shared chats, or directory examples."
8 tool updates
- Changed
analyze_track3 fields changed- added
Output schema / anyOfAdded value: +[ + { + "required": [ + "ok", + "job_id", + "status", + "cache_hits", + "tokens_estimated", + "cost_usd_estimated", + "poll_url", + "stream_url" + ] + }, + { + "required": [ + "error", + "message" + ] + } +] - added
Output schema / propertiesAdded 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" + } +} - added
Output schema / requiredAdded value: +[]
- Changed
estimate_cost3 fields changed- added
Output schema / anyOfAdded value: +[ + { + "required": [ + "cost_usd", + "cost_display", + "tokens", + "breakdown", + "duration_estimate_sec", + "job_estimate_id", + "expires_at" + ] + }, + { + "required": [ + "error", + "message" + ] + } +] - added
Output schema / propertiesAdded value: +{ + "audio_url_normalized": { + "type": "string" + }, + "audio_url_original": { + "type": "string" + }, + "breakdown": { + "additionalProperties": { + "additionalProperties": true, + "properties": { + "cost_usd": { + "type": "number" + }, + "tokens": { + "type": "number" + } + }, + "required": [ + "tokens", + "cost_usd" + ], + "type": "object" + }, + "description": "Per-tool token and cost estimate.", + "type": "object" + }, + "content_length_bytes": { + "type": "number" + }, + "content_type": { + "type": "string" + }, + "cost_display": { + "description": "Human-readable USD estimate.", + "type": "string" + }, + "cost_usd": { + "description": "Estimated analysis cost in USD.", + "type": "number" + }, + "details": { + "additionalProperties": true, + "description": "Additional structured context from Pulse.", + "type": "object" + }, + "duration_estimate_sec": { + "description": "Estimated audio duration in seconds.", + "type": "number" + }, + "duration_inferred": { + "type": "boolean" + }, + "error": { + "description": "Machine-readable error code.", + "type": "string" + }, + "expires_at": { + "description": "ISO timestamp when the estimate expires.", + "type": "string" + }, + "job_estimate_id": { + "description": "Estimate identifier valid for the configured TTL.", + "type": "string" + }, + "message": { + "description": "Human-readable recovery guidance.", + "type": "string" + }, + "normalize_source": { + "type": "string" + }, + "note": { + "type": "string" + }, + "retryable": { + "description": "Whether the caller may retry after changing state or waiting.", + "type": "boolean" + }, + "tokens": { + "description": "Estimated Pulse tokens.", + "type": "number" + } +} - added
Output schema / requiredAdded value: +[]
- Changed
get_job_status3 fields changed- added
Output schema / anyOfAdded value: +[ + { + "required": [ + "job_id", + "status" + ] + }, + { + "required": [ + "error", + "message" + ] + } +] - added
Output schema / propertiesAdded value: +{ + "billing": { + "additionalProperties": true, + "type": "object" + }, + "completed_at": { + "type": "string" + }, + "cost_usd": { + "type": "number" + }, + "details": { + "additionalProperties": true, + "description": "Additional structured context from Pulse.", + "type": "object" + }, + "error": { + "description": "Machine-readable error code.", + "type": "string" + }, + "expires_at": { + "type": "string" + }, + "job_id": { + "description": "Pulse analysis job id.", + "type": "string" + }, + "message": { + "description": "Human-readable recovery guidance.", + "type": "string" + }, + "payment_source": { + "type": "string" + }, + "result_url": { + "description": "Public result page URL.", + "type": "string" + }, + "results": { + "additionalProperties": true, + "description": "Analysis results when available.", + "type": "object" + }, + "retryable": { + "description": "Whether the caller may retry after changing state or waiting.", + "type": "boolean" + }, + "status": { + "description": "Current or terminal job status.", + "type": "string" + }, + "tokens_charged": { + "type": "number" + }, + "tokens_estimated": { + "type": "number" + }, + "waveform_file": { + "additionalProperties": true, + "type": "object" + }, + "waveform_image": { + "additionalProperties": true, + "type": "object" + }, + "waveform_markdown": { + "type": "string" + }, + "waveform_png_url": { + "type": "string" + }, + "waveform_svg_url": { + "type": "string" + } +} - added
Output schema / requiredAdded value: +[]
- Changed
get_token_balance3 fields changed- added
Output schema / anyOfAdded value: +[ + { + "required": [ + "banked_tokens", + "api_key_prefix", + "account_type", + "trial_expires_at", + "account_created_at" + ] + }, + { + "required": [ + "error", + "message" + ] + } +] - added
Output schema / propertiesAdded value: +{ + "account_created_at": { + "description": "Account creation timestamp.", + "type": "string" + }, + "account_type": { + "description": "Pulse account type.", + "type": "string" + }, + "api_key_prefix": { + "description": "Redacted API-key prefix.", + "type": "string" + }, + "banked_tokens": { + "description": "Current banked-token balance.", + "type": "number" + }, + "details": { + "additionalProperties": true, + "description": "Additional structured context from Pulse.", + "type": "object" + }, + "error": { + "description": "Machine-readable error code.", + "type": "string" + }, + "message": { + "description": "Human-readable recovery guidance.", + "type": "string" + }, + "retryable": { + "description": "Whether the caller may retry after changing state or waiting.", + "type": "boolean" + }, + "trial_expires_at": { + "description": "Trial expiry timestamp if this is a trial account.", + "type": [ + "string", + "null" + ] + } +} - added
Output schema / requiredAdded value: +[]
- Changed
list_token_packs3 fields changed- added
Output schema / anyOfAdded value: +[ + { + "required": [ + "enabled", + "packs" + ] + }, + { + "required": [ + "error", + "message" + ] + } +] - added
Output schema / propertiesAdded value: +{ + "details": { + "additionalProperties": true, + "description": "Additional structured context from Pulse.", + "type": "object" + }, + "enabled": { + "description": "Whether token-pack purchasing is enabled.", + "type": "boolean" + }, + "error": { + "description": "Machine-readable error code.", + "type": "string" + }, + "message": { + "description": "Human-readable recovery guidance.", + "type": "string" + }, + "packs": { + "description": "Available token-pack tiers.", + "items": { + "additionalProperties": true, + "properties": { + "amount_cents": { + "type": "number" + }, + "amount_usd": { + "type": "number" + }, + "currency": { + "type": "string" + }, + "pack": { + "type": "string" + }, + "tokens": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + }, + "retryable": { + "description": "Whether the caller may retry after changing state or waiting.", + "type": "boolean" + } +} - added
Output schema / requiredAdded value: +[]
- Changed
purchase_token_pack3 fields changed- added
Output schema / anyOfAdded value: +[ + { + "required": [ + "purchase_id", + "pack", + "tokens", + "amount_usd", + "currency", + "payment_url", + "expires_at" + ] + }, + { + "required": [ + "error", + "message" + ] + } +] - added
Output schema / propertiesAdded value: +{ + "amount_usd": { + "description": "Pack price in USD.", + "type": "number" + }, + "currency": { + "description": "Checkout currency.", + "type": "string" + }, + "details": { + "additionalProperties": true, + "description": "Additional structured context from Pulse.", + "type": "object" + }, + "error": { + "description": "Machine-readable error code.", + "type": "string" + }, + "expires_at": { + "description": "ISO timestamp when the Checkout link expires.", + "type": "string" + }, + "message": { + "description": "Human-readable recovery guidance.", + "type": "string" + }, + "pack": { + "description": "Token-pack tier label.", + "type": "string" + }, + "payment_url": { + "description": "Stripe Checkout URL to present to the user.", + "type": "string" + }, + "purchase_id": { + "description": "Pulse token-pack purchase id.", + "type": "string" + }, + "retryable": { + "description": "Whether the caller may retry after changing state or waiting.", + "type": "boolean" + }, + "tokens": { + "description": "Tokens included in the pack.", + "type": "number" + } +} - added
Output schema / requiredAdded value: +[]
- Changed
request_payment_link3 fields changed- added
Output schema / anyOfAdded value: +[ + { + "required": [ + "payment_url", + "job_id", + "cost_display", + "charged_display", + "amount_charged_cents", + "amount_estimate_cents", + "expires_at" + ] + }, + { + "required": [ + "error", + "message" + ] + } +] - added
Output schema / propertiesAdded value: +{ + "amount_charged_cents": { + "description": "Stripe Checkout charge in cents.", + "type": "number" + }, + "amount_estimate_cents": { + "description": "Estimated usage value in cents.", + "type": "number" + }, + "charged_display": { + "description": "Human-readable upfront Checkout charge.", + "type": "string" + }, + "cost_display": { + "description": "Human-readable estimated cost.", + "type": "string" + }, + "deduped": { + "description": "True when an existing active Checkout link was reused.", + "type": "boolean" + }, + "details": { + "additionalProperties": true, + "description": "Additional structured context from Pulse.", + "type": "object" + }, + "error": { + "description": "Machine-readable error code.", + "type": "string" + }, + "expires_at": { + "description": "ISO timestamp when the Checkout link expires.", + "type": "string" + }, + "job_id": { + "description": "Pulse job id for polling after payment.", + "type": "string" + }, + "message": { + "description": "Human-readable recovery guidance.", + "type": "string" + }, + "payment_url": { + "description": "Stripe Checkout URL to present to the user.", + "type": "string" + }, + "retryable": { + "description": "Whether the caller may retry after changing state or waiting.", + "type": "boolean" + } +} - added
Output schema / requiredAdded value: +[]
- Changed
start_trial3 fields changed- added
Output schema / anyOfAdded value: +[ + { + "required": [ + "api_key", + "account_type", + "banked_tokens", + "expires_at", + "usage_note" + ] + }, + { + "required": [ + "error", + "message" + ] + } +] - added
Output schema / propertiesAdded value: +{ + "account_type": { + "description": "The account type created by this tool.", + "enum": [ + "trial" + ], + "type": "string" + }, + "analyze_path": { + "description": "REST path for authenticated analysis.", + "type": "string" + }, + "api_key": { + "description": "Temporary Pulse API key for the trial account.", + "type": "string" + }, + "banked_tokens": { + "description": "Trial token balance granted.", + "type": "number" + }, + "details": { + "additionalProperties": true, + "description": "Additional structured context from Pulse.", + "type": "object" + }, + "error": { + "description": "Machine-readable error code.", + "type": "string" + }, + "estimate_path": { + "description": "REST path for free estimates.", + "type": "string" + }, + "expires_at": { + "description": "ISO timestamp when the temporary key expires.", + "type": "string" + }, + "message": { + "description": "Human-readable recovery guidance.", + "type": "string" + }, + "retryable": { + "description": "Whether the caller may retry after changing state or waiting.", + "type": "boolean" + }, + "upgrade_path": { + "description": "Path for converting to an account.", + "type": "string" + }, + "usage_note": { + "description": "Limits and usage guidance for the trial.", + "type": "string" + } +} - added
Output schema / requiredAdded value: +[]
1 tool update
- Added
start_trial
7 tool updates
- Changed
analyze_track1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "type": "object" +}
- Changed
estimate_cost1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "type": "object" +}
- Changed
get_job_status1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "type": "object" +}
- Changed
get_token_balance1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "type": "object" +}
- Changed
list_token_packs1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "type": "object" +}
- Changed
purchase_token_pack1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "type": "object" +}
- Changed
request_payment_link1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "type": "object" +}
Related MCP Connectors
Search 2M+ licensed production-music tracks, find similar ones by track or audio, share pick lists.
Royalty-free music fitted to your length: find, generate, adjust and download tracks and stems.
Generate, edit and stream royalty-free music, or search a licensed catalogue.
Search 18,594 production-music cues by mood, sound and exact runtime. Instant preview links.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAnalyzes audio files to extract exact, reproducible measurements like loudness, tempo, key, spectral balance, and clipping for LLM-based DAW control.-
- FlicenseNot gradedqualityAmaintenanceWatches uploaded footage or public URLs to return license-printed, license-safe BGM shortlists along with a 12–20s hook window, beat-snapped cut suggestions, and ffmpeg ducking/mix specs. Enables agents and editors to analyze clips, rank royalty-free or user-owned tracks, and export ready-to-render mix recipes without handling raw video bytes.-
- AlicenseNot gradedqualityBmaintenanceEnables local, evidence-led analysis of a master recording into inspectable stems, timing, beats, harmony, lyrics, MIDI and sonic evidence, then finds complete-bar loopable sections for Shorts and other short-form video. Results stay traceable through source hashes, manifests, JSON/TSV/NPZ artifacts and portable Sonic Visualiser sessions, and it can run as a CLI, Python library, web service, container or MCP plugin.304 PyPIMIT
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.