AI-manageable audio CDN: upload, transcode, normalize, stream & deliver audio, plus grounded docs.
Scored across 6 tools
Each tool targets a distinct documentation purpose: server info, guides, operation details, operation listing, variant types listing, and documentation search. No overlaps or ambiguous boundaries.
All tools follow the 'adn_' prefix with a descriptive verb_noun pattern (e.g., get_guide, list_operations), though 'adn_about' is a slight deviation as a bare noun rather than verb_noun.
Six tools is a well-scoped set for a documentation discovery server, covering information retrieval and exploration without being excessive or insufficient.
The tool surface fully covers the domain of API documentation: version info, operations listing and detail, guides, variant types, and search. No obvious gaps for its intended purpose.
Report the MCP server version, the bundled OpenAPI version, the docs source (bundled snapshot vs live), and the canonical API base URL. Use this to confirm how fresh the grounded documentation is.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, indicating a safe, read-only operation. The description adds value by specifying exactly what information is reported (version, OpenAPI version, docs source, base URL), which is beyond the 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 two sentences: the first lists the reported items, the second gives the use case. Every word is informative, and there is no extraneous 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?
With no output schema, the description sufficiently explains what the tool returns (version, OpenAPI version, docs source, base URL). For a simple metadata tool with no parameters, this is complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter semantics, and the baseline for zero parameters is 4. The description does not attempt to describe parameters, which 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 reports server version, OpenAPI version, docs source, and canonical API base URL. This is distinct from sibling tools like adn_get_guide or adn_search_docs, which focus on specific content rather than server metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the use case: 'Use this to confirm how fresh the grounded documentation is.' This provides clear context, though it does not explicitly state when not to use or mention alternatives, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a concise, canonical guide for a core AudioDN concept. Topics: authentication, upload, processing, playback, webhooks, variant-types, security, compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds that the guide is 'concise' and 'canonical', giving agents a clear expectation of output scope and quality beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence states the purpose with verb and resource, second sentence enumerates valid topics. No wasted words, well front-loaded.
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 single-parameter tool with no output schema, the description adequately explains input (topic enumeration) and output (concise canonical guide). Slight gap: could mention the guide structure (e.g., text, code snippets) but context is sufficient.
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 0%, so description must compensate. It explicitly lists all enum values ('Topics: authentication, upload, ...'), providing essential parameter semantics that the schema alone does not convey.
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 'Get a concise, canonical guide for a core AudioDN concept', specifying the action and resource. The listed topics distinguish it from sibling tools like adn_get_operation or adn_list_variant_types.
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 lists specific topics but does not explicitly compare to siblings or mention when not to use it. However, the topics and sibling names provide implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full OpenAPI definition for a single operation by operationId (method, path, parameters, request body, responses). Use adn_list_operations to find operationIds.
| Name | Required | Description | Default |
|---|---|---|---|
| operationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds value by specifying exactly what information the returned definition contains (method, path, parameters, request body, responses), which is beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. The first sentence defines the action and output scope; the second provides usage guidance. No filler or redundancy. Every word 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's simplicity (1 parameter, no output schema, clear annotations), the description fully covers what an agent needs: what it does, how to use it, and how to find the required parameter. No gaps.
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 only parameter (operationId) has no description in the schema (0% coverage). The description explains that it is an 'operationId' used to identify a single operation and directs the agent to adn_list_operations to find valid values. This adds essential meaning beyond the raw schema type, though it could specify expected format (e.g., string pattern).
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 full OpenAPI definition for a single operation by operationId.' It lists what the definition includes (method, path, parameters, request body, responses) and mentions how to find operationIds via a sibling tool, distinguishing it from related tools like adn_list_operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use adn_list_operations to find operationIds, providing a clear prerequisite. It doesn't explicitly state when not to use this tool, but the context implies it is for retrieving details after listing. This is good guidance, though it could be more explicit about usage order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every AudioDN REST API operation from the bundled OpenAPI spec (operationId, method, path, summary). Use this to discover the exact, canonical endpoints instead of guessing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by stating the data source ('bundled OpenAPI spec') and the fields returned (operationId, method, path, summary), which go beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: two sentences total. The first sentence states the action and result, and the second provides usage guidance. No extraneous 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?
Given no output schema, the description explains the return fields (operationId, method, path, summary). It is sufficient for an agent to understand the tool's output and decide to invoke it. Minor missing details like data format but overall adequate.
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 tool has zero parameters, and the schema coverage is 100%. The description adds value by explaining that it lists 'every...from the bundled OpenAPI spec,' providing context beyond the empty 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 uses a specific verb ('List') and resource ('AudioDN REST API operations from the bundled OpenAPI spec'). It clearly distinguishes from sibling tools like adn_get_operation (single operation retrieval) and adn_search_docs (documentation search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to discover exact endpoints instead of guessing, providing clear context. It does not explicitly mention when not to use it or list alternatives, but sibling tools imply different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the AudioDN variant types (transcode, preview, levels, waveform_video, waveform_image, original, cover) with descriptions and whether each can be created via the REST API. Use this to distinguish variant types from org delivery "index" values (see adn_list_variants).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds that it returns descriptions and creatability, which is useful but not deep 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?
Two sentences with no fluff, each sentence adds essential information: what it lists and when to use it.
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?
Complete for a parameterless listing tool. Description covers what it returns and references sibling tool. No output schema needed given simple output.
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%. Description does not need to add parameter info, and baseline for zero params is 4.
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 lists AudioDN variant types with descriptions and creation status, distinguishing it from the sibling tool adn_list_variants which deals with index values.
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 tells when to use it: to distinguish variant types from org delivery index values, referencing the alternative tool adn_list_variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the bundled AudioDN documentation (llms-full.txt, OpenAPI operation summaries, and guides) for a keyword or phrase. Returns ranked snippets. Use this before writing integration code to ground answers in canonical docs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by specifying the return format as 'ranked snippets', indicating ordering behavior. This is enough context beyond annotations to warrant a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The first sentence conveys the core purpose and resource, the second provides the usage context. Every word 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 lack of parameter descriptions in the schema and no output schema, the description falls short. It doesn't explain the limit parameter's effect or how results are ranked. For a tool with only two params, the description should cover them to be 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 0% schema description coverage, the description must explain the two parameters (query and limit). It does not mention either parameter, their roles, or constraints. This is a significant failure to add semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search', the specific resource 'bundled AudioDN documentation', and the outcome 'Returns ranked snippets'. It distinguishes from sibling retrieval tools like adn_get_guide by focusing on search across multiple doc sources.
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 states 'Use this before writing integration code to ground answers in canonical docs', giving clear when-to-use guidance. It implies the tool is for initial exploration but lacks explicit exclusions or comparisons to alternatives, which would push it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
adn_aboutadn_get_guideadn_get_operationadn_list_operationsadn_list_variant_typesadn_search_docsAI transcription from URLs or files. 119 languages, diarization, SRT/VTT/text export.
AI-native digital asset management: semantic search, generative image edits, and CDN delivery.
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
Transcribe audio & video to text for AI agents: 100+ languages, speaker labels, webhooks.
Add one secure layer between your agents and this server.
