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.6/5 across 8 of 8 tools scored.
Each tool has a clearly distinct purpose: cost estimation, analysis, status polling, token balance, pack listing, purchase, payment link, and trial. No overlapping functionality.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., estimate_cost, get_job_status, purchase_token_pack). No mixed conventions.
8 tools appropriately cover the core workflow of audio analysis (cost, analyze, poll) and payment management (balance, packs, purchase, link, trial). Not excessive or insufficient.
The tool set covers the essential lifecycle: estimate -> analyze -> poll, plus payment options. Minor gaps like history of analyses are missing but not critical for the primary purpose.
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 |
|---|---|---|
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses beyond annotations: requires API key, estimate, user confirmation, and that results require polling. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).
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?
Single paragraph, 4 sentences, no fluff. Front-loaded with main purpose, each sentence contributes essential information.
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?
Completes the picture: prerequisites, workflow, user confirmation, return value, and polling. Output schema exists but description adequately describes the job_id and next step.
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%, but description adds extra context: job_estimate_id TTL, tools availability, attestation_confirmed usage condition. Adds value beyond 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?
Description clearly states 'Run audio analysis on a public audio URL' – a specific verb and resource. 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?
Explicitly requires estimate_cost to be called first, mentions PULSE_API_KEY, and mandates user confirmation for lawful basis. Provides batch confirmation guidance, leaving no ambiguity about prerequisites or usage order.
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 |
|---|---|---|
| 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. |
| job_estimate_id | No | Estimate identifier valid for the configured TTL. |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds critical details: 'Free — never charged' and that it returns a job_estimate_id valid for 30 minutes. This provides valuable behavioral context not captured in structured fields.
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 with only two sentences that front-load the purpose and include key instructions. Every sentence adds value 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 low complexity (2 fully described parameters, output schema exists), the description covers all needed context: what the tool does, when to use it, cost implications, and the validity of the returned estimate.
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 description coverage is 100%, so the schema already documents both parameters (audio_url and tools) adequately. The description adds no extra meaning beyond the schema definitions, meeting the baseline of 3.
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's purpose: 'Get the exact price to analyze an audio file before committing.' It uses a specific verb and resource, distinguishing it from siblings like analyze_track which actually performs the analysis.
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 instruction 'Always call this first' explicitly tells when to use this tool before committing to analysis. It does not mention alternatives or when not to use, but the context strongly implies it should precede analyze_track.
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 |
|---|---|---|
| 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 | |
| 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 | |
| waveform_file | No | |
| payment_source | No | |
| tokens_charged | No | |
| waveform_image | No | |
| tokens_estimated | No | |
| waveform_png_url | No | |
| waveform_svg_url | No | |
| waveform_markdown | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds behavioral context: it's a polling tool, details default parameter values (include_waveform_data defaults false, include_waveform_image defaults true), and explains the response format for chat agents ('compact waveform summary plus result_url'). 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 concise and front-loaded with the primary purpose. Every sentence serves a clear function: stating the purpose, specifying when to use, and clarifying parameter defaults. 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 three parameters and existence of an output schema, the description covers all necessary aspects: when to poll, what to expect on completion, and default behaviors for optional parameters. It also contextualizes the tool within the workflow (after analyze_track or request_payment_link), making it self-contained.
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 baseline is 3. However, the description adds significant meaning: for job_id, it specifies the source (analyze_track or request_payment_link); for include_waveform_data, it explains the default behavior and chat agent implications; for include_waveform_image, it describes the 'server-rendered SVG as MCP image content.' This goes well beyond the schema 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 the purpose: 'Check the status and results of an analysis job.' It specifies when to use (after analyze_track or request_payment_link) and describes the result condition ('Returns full results when status=completed'). This distinguishes it effectively from sibling tools.
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?
Explicit guidance is provided: 'Poll after analyze_track returns job_id, or after the user pays via request_payment_link.' This tells the agent exactly when to invoke the tool. The description also clarifies that the return value includes full results on completion, aiding decision-making.
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. |
| banked_tokens | No | Current banked-token balance. |
| api_key_prefix | No | Redacted API-key prefix. |
| trial_expires_at | No | Trial expiry timestamp if this is a trial account. |
| account_created_at | No | Account creation timestamp. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds the authentication requirement (PULSE_API_KEY) and specifies the scope ('authenticated Pulse account'). This provides useful behavioral context without contradiction.
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 long, providing all essential information with no extraneous words. It is efficiently front-loaded and earns its place.
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 has no parameters and an output schema exists (so return values are covered), the description is complete. It explains what the tool does and what is required, meeting all informational needs.
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 zero parameters, the input schema is fully covered and the description need not add parameter details. The baseline of 4 applies because no parameter explanation is necessary, and the description focuses on the tool's purpose.
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 action ('Check') and the resource ('banked token balance for the authenticated Pulse account'), making the purpose specific and distinct from sibling tools which focus on listing token packs or purchasing.
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 usage by stating the requirement of the PULSE_API_KEY, but it doesn't provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds no further behavioral context beyond listing, which is consistent but not additional.
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 sentences, each earning its place: first defines action and output, second gives usage context. Front-loaded and concise.
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 output schema exists, description adequately covers purpose and usage. No missing details for a read-only listing 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?
No parameters; schema coverage is 100% (empty). Description adds no parameter info, but baseline for 0 params is 4, and it correctly implies no inputs needed.
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?
Clearly states it lists available Pulse token packs with details (tier label, token count, price). Distinguished from sibling purchase_token_pack by explicitly mentioning 'use before 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?
Explicitly instructs 'Use before purchase_token_pack to show options to the user,' providing clear when-to-use guidance.
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: the session is user-interaction-dependent, tokens are credited automatically after payment, and requires PULSE_API_KEY. Annotations indicate mutability and non-destructiveness, which are consistent. Could mention session expiration or error handling, but overall good.
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, front-loaded with the main action, followed by critical usage instructions and post-payment behavior. 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?
Covers the core flow, user action requirement, and automatic crediting. The output schema handles return values. Could include details on session timeouts or error scenarios, but sufficient for a payment 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 enum values are already documented. The description adds minimal new meaning beyond 'token pack tier', keeping it at the baseline score.
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 creates a Stripe Checkout session for a Pulse token pack, with a specific verb and resource. It distinguishes from siblings like list_token_packs and get_token_balance by focusing on the purchasing action.
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?
Provides explicit instructions: not to submit the payment URL programmatically but to surface it to the user, and mentions automatic crediting after payment. However, it does not explicitly state when not to use this tool versus alternatives like request_payment_link.
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 |
|---|---|---|
| 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. |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) but no contradiction. Description adds behavioral context: one-time use, automatic analysis start, and polling requirement. Could further mention link expiration or idempotency, but sufficient for typical use.
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?
Four sentences: purpose, prerequisite, post-call action, follow-up. No redundancy, all information is essential and front-loaded. Excellent structure for AI consumption.
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 role in a payment flow and availability of output schema, description covers all critical steps: user confirmation, link presentation, automatic analysis, status polling. Mentions sibling get_job_status, completing the workflow context.
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%, but description adds value by explaining job_estimate_id's origin (from estimate_cost) and clarifying attestation_confirmed's scope per user-requested batch. Reinforces schema descriptions effectively.
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 'Generate a one-time Stripe payment page for users without a Pulse account', specifying verb, resource, and target audience. Distinguishes from sibling tools like estimate_cost (pricing) and purchase_token_pack (for users with accounts).
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 mandates user confirmation for lawful basis and scope, instructs to present payment_url as a link, notes automatic analysis after payment, and directs to poll get_job_status. Provides complete workflow guidance with no ambiguity.
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 private API key with enough banked tokens for one short URL-based v1 analysis. No Stripe Checkout session is created. Store the key in the client or a trusted local environment; do not repost it in public logs, screenshots, GitHub issues, shared chats, or directory examples.
| 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. |
| upgrade_path | No | Path for converting to an account. |
| banked_tokens | No | Trial token balance granted. |
| estimate_path | No | REST path for free estimates. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=false and other annotations, the description discloses that the API key is short-lived, limited to one URL-based v1 analysis, and should not be exposed. 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 sentences, each earning its place: action, return value and scope, security advice. No fluff.
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?
For a simple no-param tool with an output schema, the description covers everything needed: purpose, output details, and caveats. Complete.
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 zero parameters, schema coverage is 100%, so the description does not need to add param information. Baseline 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 Pulse trial and returns a short-lived API key. It distinguishes from sibling tools like purchase_token_pack or request_payment_link by specifying that no Stripe session is created and it's for free trial use.
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 provides clear guidance on storing the key securely and warns against public exposure. It implicitly suggests use for free trials, but does not explicitly contrast with sibling tools like purchase_token_pack for paid purchases.
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.