StudioSphere Pulse — Audio Intelligence
Server Details
Privacy-first audio intelligence: BPM, key, waveform. Audio never stored. Pay per second.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- notpaulb/studiosphere-pulse-mcp
- GitHub Stars
- 0
- Server Listing
- studiosphere-pulse-mcp
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 8 of 8 tools scored.
Each tool has a clear, distinct purpose: cost estimation, analysis, status polling, token management, payment, and trial. There is minimal overlap, and even the two payment-related tools (purchase_token_pack and request_payment_link) are differentiated by user type and payment flow.
All tool names follow a consistent verb_noun snake_case pattern (e.g., estimate_cost, list_token_packs). The verbs are imperative and the nouns are specific objects, making the pattern predictable and easy to interpret.
With 8 tools, the server covers the core workflow of audio analysis (cost estimate, analysis, status check) along with necessary supporting functions (token management, payment, trial). This is a well-scoped set that neither overwhelms nor underserves the domain.
The tool set covers the essential lifecycle: cost estimation, analysis, status polling, token purchases, per-analysis payment, and trial. Minor gaps exist, such as no tool to list past jobs or view analysis history, but these are not critical for the primary use case.
Available Tools
8 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.
| 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 be expired (30 min TTL). | |
| 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 |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is not read-only and not destructive. The description adds that it requires PULSE_API_KEY, returns a job_id for polling, and requires attestation. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each adding critical information: action, prerequisites, user confirmation, and return value. It is front-loaded and concise, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 required params) and the presence of an output schema (returns job_id), the description sufficiently covers the workflow, prerequisites, and result. It integrates well with sibling tools for a complete process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, so baseline is 3. The description adds value by noting that job_estimate_id has a 30-minute TTL and that attestation_confirmed requires user confirmation. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run audio analysis' and the resource 'on a public audio URL.' It specifies the action and distinguishes from sibling tools like estimate_cost and get_job_status by outlining the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires calling estimate_cost first and obtaining a job_estimate_id, and mandates user confirmation for legal basis. It does not explicitly mention when not to use, but the preconditions are clear. Sibling tools are provided for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_costARead-onlyIdempotentInspect
Get the exact price to analyze an audio file before committing. Always call this first. Returns cost in dollars and a job_estimate_id valid for 30 minutes. Free — never charged.
| 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 |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the agent knows it's safe. The description adds value by stating it's free, never charged, and that the estimate expires in 30 minutes, which is useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded purpose: first sentence states what it does, second gives usage guidance, third describes return value and validity. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 2 parameters and an output schema (implied), the description covers the key aspects: purpose, usage order, return (cost and job_estimate_id), validity period, and cost (free). It is complete for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description mentions 'audio file' and 'analysis tools' but does not add meaningful new semantics beyond the parameter descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Get the exact price' and clearly identifies the resource as 'audio file' price estimation. It distinguishes itself from sibling tools like analyze_track by stating 'Always call this first', making its role as a pre-commit cost check clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Always call this first', which provides strong usage guidance. While it doesn't list alternatives explicitly, the context with sibling tools implies it precedes analyze_track. It could be improved by mentioning when not to use, but it's adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_statusARead-onlyIdempotentInspect
Check the status and results of an analysis job. Poll after analyze_track returns job_id, or after the user pays via request_payment_link. Returns full results when status=completed.
| 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 SVG as MCP image content so the client can display it without fetching a URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, establishing safety and idempotency. The description adds value by explaining the polling behavior and that full results are returned when status=completed, providing context beyond structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences convey the purpose, usage context, and output behavior. Information is front-loaded with the core function. No wasted words, and parameter details are appropriately left to the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but referenced), the description doesn't need to detail return values. It covers the essential polling flow and result retrieval. Minor gap: could mention idempotency, but annotations already cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, baseline is 3. The description adds meaning for include_waveform_data and include_waveform_image by explaining defaults (false, true) and use cases (chat agents, compact summary vs raw samples, SVG image display). This goes beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks the status and results of an analysis job, with specific contexts like polling after analyze_track or request_payment_link. This differentiates it from sibling tools like analyze_track or purchase_token_pack, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: poll after analyze_track returns job_id, or after the user pays via request_payment_link. While it doesn't explicitly state when not to use it, the context is clear enough for an agent to infer appropriate scenarios.
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 |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the API key requirement, which is useful but does not disclose additional behavioral traits such as response format or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the core purpose. Every sentence is essential, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only, idempotent), the description, combined with annotations and the presence of an output schema, provides a complete understanding of the tool's context and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. Per guidelines, the baseline for 0 parameters is 4, and the description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' and identifies the resource 'banked token balance for the authenticated Pulse account', clearly distinguishing it from sibling tools like list_token_packs or purchase_token_pack.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the requirement for 'PULSE_API_KEY', providing clear usage context. It does not, however, elaborate on when not to use this tool or compare directly with alternatives, though the sibling set makes the role clear.
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 |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds the specific fields returned, which is useful but does not disclose additional behavioral traits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no unnecessary words, front-loaded with key action and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description is fully complete: it states what the tool does, when to use it, and what it returns (fields).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description naturally adds no parameter details. Schema coverage is 100% (empty), and the description focuses on the purpose rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'List' and the resource 'available Pulse token packs', specifying the fields returned (tier label, token count, price). It distinguishes from the sibling purchase_token_pack by indicating its use before purchase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use before purchase_token_pack to show options, providing clear context and ordering relative to other tools.
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 |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits: it creates a checkout session (mutation), returns a payment_url, and automatically credits tokens upon payment. This adds value beyond annotations which only indicate non-read-only and non-destructive hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, followed by a critical usage instruction, and then post-payment behavior. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (external payment, automatic credit, auth requirement), the description covers all essential aspects. An output schema exists (not shown), further reducing the need for return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'pack' is fully documented in the schema with enum values and description. The description does not add additional meaning beyond the schema, but schema coverage is 100%, so baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Stripe Checkout session for a Pulse token pack, using a specific verb and resource. It distinguishes itself from siblings like list_token_packs and request_payment_link by focusing on payment session creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns not to submit the payment_url programmatically and instructs to surface it to the user. It also notes the requirement for PULSE_API_KEY, providing clear context for when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_payment_linkAInspect
Generate a one-time Stripe payment page for users without a Pulse account. Before calling, you MUST confirm with the user that they have a lawful basis to submit this audio for analysis; for a user-requested batch/folder/project, one confirmation can cover that scope. Present the payment_url to the user as a link. Analysis begins automatically after payment. Poll get_job_status with the returned job_id.
| Name | Required | Description | Default |
|---|---|---|---|
| job_estimate_id | Yes | The job_estimate_id returned by estimate_cost. | |
| 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 |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which indicate non-readonly and non-destructive), the description adds that analysis begins automatically after payment and to poll with returned job_id, providing valuable post-call behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with zero waste. Front-loaded with purpose, then usage guardrail, then post-call instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers pre-call (confirmation), the action (generate link, present to user), post-call (analysis, polling with job_id). With output schema existing, return values are handled. Complete for a two-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes both parameters. The description reinforces the confirmation condition but adds little new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a one-time Stripe payment page for users without a Pulse account, using a specific verb and resource, and distinguishes from sibling tools like estimate_cost and get_job_status by targeting payment flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the agent must confirm lawful basis with the user before calling, and mentions polling get_job_status after. It provides clear context but does not explicitly list when not to use or alternative tools.
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. Returns a short-lived API key with enough banked tokens for one short URL-based v1 analysis. No Stripe Checkout session is created.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals behaviors beyond annotations: it is temporary, returns a short-lived API key with banked tokens for one analysis. Annotations indicate non-readonly and open world, but the description adds concrete details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every word adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema (presumably describing the API key), the description is complete: it explains the purpose, what is returned, and key constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the description does not need to add meaning. The schema has 100% coverage, so a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a temporary, email-free trial and returns an API key. It distinguishes itself from sibling tools like purchase_token_pack by emphasizing 'email-free' and 'no Stripe Checkout'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool to use for a free trial by noting it is email-free and does not create a payment session, but it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.