agentic-commerce-catalog
Server Details
AI music, video, image, and voice tools callable by agents with USDC payments via x402 on Base.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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 1.7/5 across 17 of 17 tools scored.
Many tools have distinct purposes but some overlap, e.g., 'agent_music' and 'create_music' both relate to music generation; 'cover', 'extend', 'continue_track' could be confused. Overall, an agent might struggle to differentiate between a few tools.
Naming patterns are inconsistent: some use verb_noun (create_music, prompt_analyze), others are single nouns (lyrics, midi, vox), and prefixes like 'agent_' and 'rig_' vary. No unified convention.
With 17 tools, the set is slightly above the ideal 3-15 range but still manageable for a creative media domain. The count is not excessive given the breadth of features.
The tool set covers music creation, video, analysis, lyrics, style coaching, and chat. Minor gaps like explicit video editing or track management are present, but overall it's fairly comprehensive.
Available Tools
17 toolsagent_musicDInspect
agent_music — $0.20 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional comma-separated tags stored with the generated asset. | |
| style | No | Optional style or genre preset (for example, 'ambient', 'synthwave'). | |
| lyrics | No | Custom lyrics to sing when custom_mode is true. | |
| prompt | Yes | Creative prompt describing mood, genre, instrumentation, or lyrics guidance. | |
| custom_mode | No | Enable advanced lyric control (requires lyrics). | |
| vocal_gender | No | Preferred vocal gender ('m' or 'f') if vocals are enabled. | |
| durationSeconds | No | Desired duration of the track in seconds (defaults to a full-length song). | |
| make_instrumental | No | Generate an instrumental version without vocals. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions payment details. It fails to disclose that this tool generates a music track, what side effects exist, or any behavioral traits.
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 a single line that omits essential information about the tool's function. It is not 'appropriately sized' because it fails to convey core purpose, making it ineffective despite brevity.
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 8 parameters and no output schema, the description must clarify what the tool produces and how to use it. It only mentions cost, leaving the agent completely uninformed about the tool's capabilities.
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 baseline is 3. The description adds no additional meaning to parameters beyond what the schema provides, but it does not contradict or worsen understanding.
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 only states pricing and payment method ('$0.20 USDC via x402 on Base'). It does not specify that this tool generates music, which is its core function. This is misleading and provides no actionable purpose.
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?
No guidance on when to use this tool vs siblings (e.g., 'create_music', 'cover', 'continue_track'). The description does not distinguish this tool from others or provide any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
agent_videoCInspect
agent_video — $1.50 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Optional random seed for reproducible renders. | |
| model | No | Optional model preset variant. Leave unset for the default. | |
| prompt | Yes | Narrative or visual prompt to drive the music video concept. | |
| asyncMode | No | If true, return immediately while the video renders asynchronously. | |
| resolution | No | Target rendering resolution. | |
| aspectRatio | No | Desired frame aspect ratio. | |
| durationSeconds | No | Clip length in seconds (default 8). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses the cost and chain, but with no annotations, it leaves out important behavioral traits like idempotency, rate limits, or the behavior of asyncMode. The brief description adds minimal behavioral info.
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 but at the expense of clarity. It is not structured to highlight key information beyond pricing.
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?
With 7 parameters, no output schema, and no annotations, the description is extremely lacking. It only provides pricing, leaving out behavior, return values, and usage 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 covers all 7 parameters with descriptions, so baseline is 3. The description adds no extra 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 only mentions a cost and payment method, not the actual function. From the input schema, it appears to generate a music video, but the description fails to state this explicitly.
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?
No guidance on when to use this tool versus sibling tools like agent_music or cover. The description does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
audio_analyzeDInspect
audio_analyze — $0.00 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| audioUrl | Yes | HTTPS URL to an audio file (mp3, wav, flac, m4a, ogg). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only mentions payment details. No information on read/write nature, return values, or side effects is provided.
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 brief but under-specified, omitting essential purpose information. Conciseness is not a virtue when it sacrifices content.
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?
Despite having only one parameter and no output schema, the description fails to explain what the tool returns or how the analysis works. It is incomplete for an agent to use correctly.
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% for the single parameter (audioUrl), so the baseline is 3. The description adds no extra meaning beyond what the schema already provides.
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 only repeats the tool name and adds a payment note, failing to state what the tool actually does. It is a tautology with no verb or resource indicating functionality.
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?
No guidance is provided on when to use this tool versus its many sibling tools (e.g., cover, create_music, agent_music). The description gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chain_chatDInspect
chain_chat — $0.02 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Question for the on-chain provenance oracle. | |
| assetHash | No | Optional Suede Registry asset hash for context. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions cost and blockchain. It does not disclose behavioral traits such as latency, authentication requirements, rate limits, or what happens after submitting a question (e.g., response format, processing time).
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 short (one sentence), but it is under-specified. It does not provide enough information to be useful, so it is not appropriately 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 the complexity (on-chain oracle, payment, optional asset hash) and lack of output schema or annotations, the description is completely inadequate. It fails to explain return values, error cases, or any behavioral context beyond cost.
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 with descriptions. The tool description adds no additional meaning beyond the schema, which itself is adequate. Baseline score of 3 applies.
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 only mentions the cost and blockchain, but does not clearly state the tool's function. The name 'chain_chat' implies a chat, but the description is too vague to distinguish it from sibling tools. The schema's 'question' parameter hints at querying an oracle, but the description fails to explicitly state what the tool does.
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?
No guidance on when to use this tool versus alternatives like 'rig_oracle' or other siblings. The description does not mention any context or prerequisites for using the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
continue_trackDInspect
continue_track — $0.40 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | Optional creative direction for the continuation. | |
| audioUrl | Yes | Public URL to the source audio file. | |
| durationSeconds | No | Desired additional duration (seconds). | |
| continueAtSeconds | No | Timestamp within the source to continue from. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It omits whether the tool is read-only or destructive, what the output is, or any side effects. The cost/blockchain info is insufficient for understanding tool behavior.
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 short but misses essential information. It is not a model of conciseness because it sacrifices clarity for brevity.
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 4 parameters, no output schema, and no annotations, the description is severely incomplete. It provides zero context about what the tool does, how it works, or what the return value is.
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% with descriptions for each parameter, so baseline is 3. The description adds no extra meaning beyond the schema, but does not mislead.
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 only states the tool name and payment info ($0.40 USDC via x402 on Base) without any indication that it continues a track. It fails to define the primary action or resource, making it uninformative for tool selection.
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?
No guidance on when to use this tool versus siblings like 'extend' or 'cover'. The description provides no context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
coverDInspect
cover — $0.40 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional style tags. | |
| style | No | Target style (e.g. 'orchestral', 'lofi'). | |
| title | No | Optional title for the cover. | |
| prompt | No | Optional creative direction for the cover. | |
| audioUrl | No | Alternative: public URL of source audio. | |
| sourceClipId | Yes | Suede clip id of the source track to cover. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses cost and payment method, which is a behavioral trait, but fails to explain core behavior (e.g., that it creates a cover, whether it modifies existing content, or response details). This is insufficient.
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 but at the expense of clarity and completeness. It does not earn its place because it omits essential purpose and usage information. Conciseness without substance is under-specification.
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 6 parameters, no output schema, and no annotations, the description is severely incomplete. It only provides cost and chain info, leaving the agent uninformed about what the tool does, how to use parameters effectively, or expected results.
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. The description adds no additional meaning beyond the schema—only pricing info. The parameters are already fully described in the schema, so no penalty but no enhancement.
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 'cover — $0.40 USDC via x402 on Base (chain 8453).' does not state what the tool does. It only provides pricing and payment method, making it a tautology of the name with cost info. It does not distinguish from sibling tools like 'create_music' or 'continue_track'.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions. The name hints at creating a cover, but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_musicDInspect
create_music — $0.20 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Comma-separated keywords to tag the generated file. | |
| style | No | Specific musical style or genre tag (e.g., 'Hip Hop', 'Ambient', 'Rock'). Helping the AI focus on a specific sound. | |
| lyrics | No | Your custom lyrics. Required if custom_mode is true. | |
| prompt | Yes | Describe the song you want to create. Include genre, mood, instruments, and any specific vibe. Example: 'Upbeat 80s synthwave with driving bass and neon atmosphere' or 'A melancholic acoustic guitar ballad about rain'. | |
| custom_mode | No | Set to true to use your own lyrics provided in the 'lyrics' field. | |
| vocal_gender | No | Preferred gender for the vocalist ('m' for male, 'f' for female). | |
| durationSeconds | No | Duration of the track in seconds. Defaults to a full-length song. | |
| make_instrumental | No | If true, generates a track without vocals. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose any behavioral traits such as side effects, resource usage, or limitations. Only payment info is mentioned, which is insufficient.
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 short (one sentence) but under-specified. It does not effectively communicate the tool's functionality, reducing its utility.
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?
With 8 parameters, no output schema, and no annotations, the description is grossly incomplete. It provides no context about return values, side effects, or usage examples.
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 all parameters adequately. The description adds no additional parameter meaning, earning the baseline score 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 focuses only on payment details ('$0.20 USDC via x402 on Base') and does not explicitly state that the tool creates music. The purpose is implied by the name 'create_music' but the description lacks a clear verb+resource statement.
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?
No guidance on when to use this tool versus siblings like 'agent_music', 'cover', or 'extend'. There is no indication of context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extendDInspect
extend — $0.40 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional comma-separated style tags. | |
| title | No | Optional title for the extended track. | |
| prompt | No | Optional creative direction for the extension. | |
| audioUrl | No | Alternative: public URL of source audio to register and extend. | |
| sourceClipId | Yes | Suede clip id of the source track to extend. | |
| continueAtSeconds | No | Timestamp within the source (seconds) to continue from. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits but only mentions payment method. No disclosure of side effects, permissions, or that this is a write operation.
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 overly brief but sacrifices informativeness. It fails to earn its place by not explaining the tool's purpose.
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?
With 6 parameters, no output schema, and many siblings, the description is extremely incomplete. It does not even state the primary functionality, leaving the agent clueless.
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. The description adds no extra parameter 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 only provides pricing and chain info, failing to state what the tool does. It is essentially a tautology, repeating the name without clarifying the 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?
No guidance on when to use this tool versus siblings like continue_track or cover. The name implies audio extension but no explicit usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lyricsDInspect
lyrics — $0.04 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Optional style hint (e.g. 'country ballad'). | |
| prompt | Yes | Description of the song or scene to write lyrics for. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only covers pricing. It does not disclose what the tool produces, whether it's blocking, or any side effects.
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 very short but focuses on pricing rather than tool functionality, making it under-specified rather than 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 no output schema, no annotations, and only two parameters, the description fails to explain return value, usage, or prerequisites, leaving the agent with insufficient information.
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 baseline is 3. The description adds no extra meaning beyond the schema, which already describes the 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?
The description only mentions payment and cost, not what the tool does. The name 'lyrics' and the schema prompt field imply lyric generation, but the description itself is vague.
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?
No guidance on when to use this tool instead of siblings like 'create_music' or 'cover'. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lyric_syncCInspect
lyric_sync — $0.10 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| lyrics | No | Optional plain-text lyrics to align (if known). | |
| audioUrl | Yes | Public URL to the source audio file. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as whether this is a read or write operation, auth requirements, or rate limits. The cost implication is mentioned but does not clarify tool behavior.
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?
Extremely concise (one sentence) but under-specified. Every word has low value; cost and payment info is present but does not aid tool selection or invocation. Lacks structure.
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?
Despite only 2 parameters and no output schema, the description fails to provide essential context: what the tool returns, how to invoke it besides payment, or prerequisites. Sibling tools are numerous and diverse, making this gap critical.
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% with descriptions for both parameters. The description adds no additional meaning beyond the schema, but also does not detract. Baseline score 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 only states the cost and payment method, not the tool's function. 'lyric_sync' suggests synchronizing lyrics, but the description fails to confirm this or provide any verb-resource combination.
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?
No guidance on when to use this tool versus siblings like 'lyrics' or 'audio_analyze'. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
midiDInspect
midi — $0.10 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| audioUrl | Yes | Public URL to the source audio file. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states a payment requirement. It does not disclose whether the tool is destructive, requires authentication, or any side effects. The behavioral profile is almost entirely absent.
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 but lacks structure. It fails to front-load the tool's purpose, and the single sentence does not earn its place as it omits the main function.
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?
With a single parameter and no output schema, the description should at least clarify the tool's output or result. It is completely incomplete for an agent to understand what happens when invoking the 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 description coverage is 100% for the single parameter. The description adds no meaning beyond the schema's 'Public URL to the source audio file.', so 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 only mentions payment method and cost but does not state what the tool does. 'midi' suggests a relation to MIDI, but the core function (e.g., converting audio to MIDI) is not described, leaving the purpose unclear.
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?
No guidance on when to use this tool vs. siblings like 'create_music' or 'cover'. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prompt_analyzeDInspect
prompt_analyze — $0.00 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Music generation prompt to analyze. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions cost and chain, ignoring what the tool does, side effects, or constraints. This is severely insufficient.
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 but wastes the single sentence on cost information instead of functional purpose. It is not informative for agent use.
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 output schema and no annotations, the description should explain what analysis is performed and what the output looks like. It fails entirely, leaving the agent uninformed.
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 the single parameter with description 'Music generation prompt to analyze.' The description adds no extra meaning, so 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 only mentions cost and chain ('$0.00 USDC via x402 on Base (chain 8453)') but fails to state what the tool does. The purpose is vaguely inferred from the parameter description 'Music generation prompt to analyze,' but the main description is misleadingly focused on technical details.
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?
No guidance is provided on when to use this tool versus alternatives like 'audio_analyze' or 'rig_analyze'. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rig_analyzeDInspect
rig_analyze — $0.10 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| pedals | No | Optional declared pedal list. | |
| audioUrl | Yes | HTTPS URL to a rig audio clip. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits (e.g., what happens upon analysis, side effects, authorization needs). Only payment info is given, which is not behavioral context.
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?
Description is very short but under-specifies functionality. It is not front-loaded with purpose; the only information is pricing, which is not the tool's primary role.
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 2-parameter tool with no output schema and no annotations, the description should explain what the tool does. It fails to provide essential functional context, making it incomplete.
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% (both 'audioUrl' and 'pedals' have descriptions). Baseline 3 applies since description adds no additional parameter meaning beyond schema, but does not detract.
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 only states pricing and payment method ($0.10 USDC via x402 on Base), not the tool's function. The name 'rig_analyze' suggests analyzing a rig, but the description fails to confirm this or state any verb+resource. Sibling tools like 'audio_analyze' similarly lack differentiation.
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?
No guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rig_oracleDInspect
rig_oracle — $0.10 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | Tone goal (e.g. 'warm 80s lead'). | |
| genre | No | Optional genre constraint. | |
| budgetUsd | No | Optional budget in USD. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing the full burden on the description. The description only mentions cost and chain, failing to disclose behavioral traits such as what the tool does, whether it reads or writes, any side effects, authentication requirements, or rate limits. This is insufficient for a tool that presumably interacts with an external service.
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 short (one line), but it sacrifices essential information for brevity. It does not fulfill the basic requirement of stating what the tool does. This is under-specification, not conciseness.
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 lack of output schema and annotations, and the presence of 3 parameters with only basic schema descriptions, the description is critically incomplete. It provides no high-level context, no return value information, and no behavioral details. A tool with this complexity requires a much richer description to guide an agent.
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 has 100% coverage with descriptions for each parameter (e.g., 'Tone goal (e.g. warm 80s lead).'). The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate. However, the parameter descriptions themselves are minimal, but the tool description does not contribute to clarifying them.
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 only provides the tool name and cost details ($0.10 USDC via x402 on Base chain), but does not state what the tool actually does. It fails to distinguish from sibling tools like agent_music, cover, or create_music, which are music-related. The verb and resource are missing, making the purpose unclear.
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?
No guidance is given about when to use this tool versus its siblings. There are no conditions, prerequisites, or alternatives mentioned. The description is completely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rig_roastDInspect
rig_roast — $0.05 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| amp | No | Amp model. | |
| guitar | No | Guitar model. | |
| pedals | No | Pedalboard contents. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It mentions a cost and payment method (x402), which is useful, but does not state whether the tool creates, modifies, or retrieves data, leaving core behavior ambiguous.
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 short, which could be considered concise, but it under-specifies the tool's purpose. It could be more informative without losing conciseness.
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 3 parameters, no output schema, and no annotations, the description fails to explain the tool's primary action, return value, or side effects, making it insufficient for an agent to decide to invoke 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 description coverage is 100%, so each parameter has a description. The tool description adds no additional meaning, meeting the baseline expectation for high coverage.
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 only provides a cost and chain identifier but lacks any verb or resource indicating what the tool actually does. It does not distinguish from sibling tools like rig_analyze, making it impossible to infer the tool's intended operation.
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?
No guidance is given on when to use this tool versus alternatives (e.g., rig_analyze). The description provides no context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
style_coachDInspect
style_coach — $0.02 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | Short seed tag list (e.g. 'lofi, rainy, late night'). | |
| targetCount | No | How many expanded tags to return (default ~12). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits. It fails to explain what the tool does, its side effects, or authentication needs.
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 one line, but it is not concise in a useful way—it omits the core functionality and instead focuses on pricing. Overly sparse and not front-loaded with purpose.
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 annotations, no output schema, and sibling tools that are likely alternatives, the description is severely incomplete. It does not explain what the tool returns or how it integrates.
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 describes both parameters. The description adds no additional meaning beyond the price, which is irrelevant to parameter semantics.
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 only states a price and chain, without any verb or resource to indicate what the tool does. The name 'style_coach' hints at style suggestions, but the description provides no functional purpose.
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?
No guidance on when to use this tool vs siblings like prompt_analyze or rig_analyze. The description lacks any context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
voxDInspect
vox — $0.40 USDC via x402 on Base (chain 8453).
| Name | Required | Description | Default |
|---|---|---|---|
| audioUrl | Yes | Public URL to the source audio file. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only gives pricing and payment details, not behavioral traits such as whether it reads or writes data, side effects, or requirements. The agent cannot infer how the tool behaves beyond a monetary transaction.
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 very short but fails to be concise because it omits essential purpose. It front-loads pricing instead of the action, which is not useful for an agent selecting a tool.
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 one parameter and no output schema, the description is severely incomplete. It does not explain what 'vox' does with the audio URL (e.g., transcribe, analyze, transform), leaving the agent unable to understand the tool's value.
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% for the single parameter 'audioUrl' with a description 'Public URL to the source audio file.' The tool description adds no additional meaning beyond the schema, so 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 'vox — $0.40 USDC via x402 on Base (chain 8453)' does not specify what the tool does; it only mentions pricing and payment method, which is misleading for understanding the tool's functionality. The name 'vox' suggests audio but the description fails to clarify the action (e.g., transcribe, generate, modify).
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?
No guidance is provided on when to use this tool versus its siblings (e.g., agent_music, audio_analyze). The description does not mention any context or alternative tools, leaving the agent without criteria for selection.
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!