Get audio URL
get_audio_urlRead-onlyIdempotent
Resolve the playable audio URL for an article. Returns a stitched-with-ad URL on free tier or the bare audio for plus/pro.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
storyflo
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it discloses that the returned URL differs based on user tier (free: stitched-with-ad; plus/pro: bare audio). However, it does not mention error conditions or edge cases (e.g., missing audio), but given the annotations already declare readOnlyHint and idempotentHint, the description improves transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and no extraneous information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers the key differentiator (tier-based output). It could mention the function's idempotency or error handling, but annotations cover idempotency. The description is nearly complete for a straightforward 'get URL' tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate for the undocumented 'slug' parameter. The description only says 'for an article,' leaving the user to infer that slug likely identifies the article. This provides minimal semantic help and does not specify format or source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: resolving a playable audio URL for an article. It further distinguishes the output based on user tier (free vs plus/pro), making it specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning tier-dependent behavior, but it does not explicitly state when to use this tool versus alternatives (e.g., get_article) or if there are prerequisites (e.g., article must have audio). No direct when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A3.6/5.0
Disambiguation4/5
Most tools have distinct purposes, but there is overlap between `get_my_private_feed`, `subscribe_topic`, and `list_subscriptions`—all return or manage feed URLs, which could confuse an agent. Otherwise, categories like publisher, fund manager, and search tools are clearly separated.
Naming Consistency5/5
All tools use consistent snake_case with a verb_noun pattern (e.g., `get_article`, `search_articles`, `publisher_upload_audio`). Exceptions like `digest` are single-word verbs but still fit the pattern. No mixed conventions are present.
Tool Count2/5
With 37 tools, the server exceeds the 25-tool threshold considered 'too many' by the rubric. While the broad scope (news, podcasting, publishing, fund management, embedding) justifies a large surface, the count still adds cognitive load and would benefit from splitting into separate servers.
Completeness4/5
The tool set covers the major domains: search, retrieval, subscriptions, publishing, fund manager operations, and embedder network. Minor gaps exist, such as the absence of an unsubscribe or delete-episode tool, but the core workflows are well-supported and agents can accomplish most tasks.