mcp-server
Server Details
Media intelligence analysis for audio, video, and images via the Echosaw MCP server.
- 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 4.2/5 across 13 of 13 tools scored.
All tools have distinct purposes: analysis, job tracking, folder management, media retrieval, etc. Some minor ambiguity exists between analyze and download (both involve media) but descriptions clarify their roles well.
All tools follow a consistent 'echosaw_{verb}_{noun}' pattern with snake_case verbs and nouns (e.g., analyze_media_url, check_job_status, create_folder). This is highly predictable.
13 tools is well-scoped for a media analysis platform, covering analysis, job monitoring, folder management, media listing/search, and account details. No tools feel extraneous.
Core operations (analyze, retrieve results, manage folders, list/search media) are present. Minor gaps: no update/delete for media items or update for folders beyond rename, but these are acceptable.
Available Tools
14 toolsechosaw_analyze_media_urlAInspect
Submit a publicly accessible media URL or video platform URL (YouTube, Rumble, Instagram, Vimeo, etc.) to Echosaw for asynchronous analysis. Returns a job ID used to track processing and retrieve results.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTP(S) URL of the media file, or a video platform URL (e.g., YouTube, Rumble, Instagram) | |
| mediaType | Yes | One of: video, audio, image |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the asynchronous nature and the return of a job ID, adding behavioral context beyond annotations which only indicate non-read-only and non-destructive. It also emphasizes the requirement for public accessibility, which is useful for the agent.
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 with two sentences: the first describes the action, the second the return value. It is front-loaded and contains no unnecessary words, earning 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?
For a simple submission tool with two parameters and no output schema, the description covers the essential input requirements and output. It provides adequate context for an agent to use it correctly within the workflow, though it could mention that it is typically the first 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?
The input schema already provides descriptions for both parameters with 100% coverage. The tool description does not add new semantic information beyond what is in the schema, achieving 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 the tool submits a publicly accessible media URL or video platform URL for asynchronous analysis, returning a job ID. It distinguishes itself from sibling tools like echosaw_check_job_status and echosaw_get_analysis_results by specifying its role as the initiation step.
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 specifies that the URL must be publicly accessible and supports various platforms (YouTube, Rumble, etc.), providing clear input conditions. However, it does not explicitly state when not to use this tool or mention alternatives, but the sibling context implicitly clarifies usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_check_job_statusARead-onlyIdempotentInspect
Retrieve the current processing state of an Echosaw analysis job. This tool uses server-side long-polling — it holds the connection for up to 25 seconds, checking for completion internally, so you do not need to poll repeatedly. Call once and wait for the response.
| Name | Required | Description | Default |
|---|---|---|---|
| mediaId | Yes | The mediaId returned by echosaw_analyze_media_url |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds critical behavioral context: server-side long-polling with a 25-second hold and internal completion checks. This significantly aids the agent in understanding expected latency and network 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?
Two concise sentences that front-load the purpose and immediately follow with critical behavioral detail. 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?
For a simple status-check tool with one required parameter, the description covers purpose and usage pattern. Lacks detail about the response format (e.g., possible status values), but the tool is straightforward and the long-polling detail compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter, mediaId, is fully described in the schema (100% coverage). The tool description does not add new semantics beyond referencing the schema, so 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 clearly specifies the action ('Retrieve the current processing state') and resource ('Echosaw analysis job'). It distinguishes from siblings like echosaw_get_analysis_results by focusing on job status rather than final results.
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 to call once and wait, and that long-polling eliminates the need for repeated polling. Could be improved by noting when not to use (e.g., if results are needed directly), but sufficient guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_create_folderAInspect
Create a new folder in your media library for organizing analyzed media. Folders can be nested (e.g., create "Q1 2026" inside "/Marketing").
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Folder display name (e.g., "Marketing", "Interviews", "OSINT") | |
| parentPath | No | Parent folder path (default: "/" for root level). Use echosaw_list_folders to see existing folders. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readonly and non-destructive, so the baseline is higher. The description adds the nesting behavior (creating subfolders) but fails to disclose potential errors like duplicate names or invalid paths.
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 sentence with an illustrative example, making it compact and front-loaded. However, it could be more structured with separate clauses for key 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?
With no output schema, the description should clarify return values or confirmation messages, which it does not. It also omits details about async behavior or permission requirements, leaving gaps for a creation 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%, so baseline is 3. The description adds a nesting example but does not significantly enhance understanding beyond the schema's parameter 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 action ('Create a new folder') and the resource ('in your media library'). It also provides an example of nesting, which differentiates it from sibling tools like delete or rename.
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 for organizing analyzed media but does not explicitly state when to use this tool versus alternatives. The parentPath parameter references echosaw_list_folders, but the main description lacks guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_delete_folderADestructiveIdempotentInspect
Delete a folder from your media library. Items in the folder are moved to the parent folder by default. Cannot delete the root folder ("/").
| Name | Required | Description | Default |
|---|---|---|---|
| folderPath | Yes | Folder path to delete (e.g., "/Marketing/Old Campaigns") | |
| moveItemsToParent | No | Move items to parent folder before deleting (default: true) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint, idempotentHint), the description adds critical behavioral details: items are moved to parent by default and root deletion is forbidden. This provides valuable context for safe usage.
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 redundant words. The key action and constraints are front-loaded, making it easy to parse quickly.
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 deletion tool with no output schema, the description covers the essential behavior (default item moving, root restriction) and parameter effects. It lacks details on return values or error cases, but the core use is well addressed.
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 description explains the default behavior of the `moveItemsToParent` parameter and reinforces the folder path constraint (cannot delete root). Since schema coverage is 100%, the description adds extra meaning beyond the raw 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 'Delete a folder from your media library' with specific verb and resource. It distinguishes from sibling tools like create_folder and rename_folder by focusing on deletion.
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 a key when-not guideline ('Cannot delete the root folder') and explains default behavior for moving items. It implicitly suggests when to use the tool but does not explicitly compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_download_mediaARead-onlyIdempotentInspect
Generate a presigned download URL for the source media file associated with a completed analysis job. The URL is valid for 1 hour.
| Name | Required | Description | Default |
|---|---|---|---|
| mediaId | Yes | The mediaId of the media to download |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), the description adds that the URL is presigned and valid for 1 hour, providing valuable behavioral insight.
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 adding essential information: purpose and expiration duration. 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 no output schema, the description explains the return (presigned URL) and its validity. Also clarifies the required context (completed analysis). Sufficient for a simple one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description links mediaId to source media of a completed analysis, adding context not in the schema description ('The mediaId of the media to download').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a presigned download URL for the source media of a completed analysis job, distinguishing it from siblings like echosaw_get_analysis_results or echosaw_list_media.
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 after analysis completion but does not explicitly state when not to use or compare to alternatives, though siblings provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_get_analysis_resultsARead-onlyIdempotentInspect
Retrieve structured analysis results generated by Echosaw for a completed job, including summaries, transcripts, detected entities, events, and other intelligence outputs.
| Name | Required | Description | Default |
|---|---|---|---|
| mediaId | Yes | The mediaId of a completed analysis | |
| section | No | Optional: request a specific section of the results to reduce response size. One of: summary, transcript, safety, insights, metadata, downloads, all. Defaults to "all" with transcript truncated to 5000 characters. Use "transcript" to get the full transcript. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description adds value by specifying the required prerequisite (completed job) and listing the types of outputs. It does not contradict 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 a single sentence that is relatively concise and front-loaded with the main verb and resource. However, it could be slightly more concise by omitting the explicit list of outputs or splitting into two sentences.
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 only two parameters (both described), no output schema, and annotations covering safety/idempotency, the description provides sufficient context: it states the purpose, prerequisite (completed job), and types of results. This is adequate for the tool's complexity.
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?
Input schema has 100% description coverage: 'mediaId' is described as 'The mediaId of a completed analysis', and 'section' includes an enum and a detailed description of its behavior (default, truncation). The tool's description adds general context but does not significantly enrich meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Retrieve' and the resource 'structured analysis results generated by Echosaw for a completed job', and lists specific outputs (summaries, transcripts, entities, events). This distinguishes it from sibling tools like echosaw_check_job_status or echosaw_list_media, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a completed job (via 'generated by Echosaw for a completed job'), which gives context but does not explicitly state when to use it vs. alternatives (e.g., check_job_status to verify completion). No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_get_organizationARead-onlyIdempotentInspect
Retrieve the details of your Echosaw organization, including the organization name, your role, creation date, and active member count. Returns null if you are not a member of any organization.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds value by specifying the null return condition and listing returned 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?
Two concise, front-loaded sentences with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers essential behavioral aspects (returned fields, null case) and, given no input/output schemas, provides sufficient 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?
No parameters exist, but description adds meaning by detailing the output fields, which compensates for the lack of output 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 the verb 'retrieve' and resource 'Echosaw organization', lists specific fields returned, and distinguishes from sibling tools focused on media and folder 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?
No explicit guidance on when to use this tool vs alternatives; however, sibling tools are sufficiently distinct, so usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_get_profileARead-onlyIdempotentInspect
Retrieve your Echosaw account profile including subscription tier, email, organization membership, and trial status. Use this to understand your current plan limits and account details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds specific behavioral context by detailing the data returned (subscription tier, email, organization membership, trial status), which enhances the agent's understanding 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 consists of two concise sentences. The first sentence front-loads the purpose and key data fields, and the second sentence provides usage guidance. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description covers the essential information: what data is returned (subscription tier, email, organization, trial status) and its purpose. It does not detail response structure or errors, but given the tool's simplicity, the description is sufficiently 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?
The input schema has zero parameters, so schema coverage is 100%. The description does not need to add parameter semantics, and it correctly omits any mention. According to guidelines, 0 params baseline 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 the verb 'Retrieve' and the resource 'your Echosaw account profile', listing specific fields like subscription tier, email, organization membership, and trial status. It distinguishes itself from sibling tools like echosaw_get_organization by focusing on the full account profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to understand your current plan limits and account details', providing clear context for when to use the tool. While it doesn't mention when not to use it, the tool has no parameters and is universally applicable, making exclusions unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_list_foldersARead-onlyIdempotentInspect
List folders in your media library. Returns folder structure with paths, display names, and item counts. Use this to understand how your media is organized.
| Name | Required | Description | Default |
|---|---|---|---|
| parentPath | No | Parent folder path to list children of (default: "/" for root-level folders) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds useful return details (paths, display names, item counts) beyond annotations. 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?
Three sentences, no wasted words, front-loaded with main action. Efficient and clear.
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?
Simple tool with one optional parameter and no output schema. Description covers purpose, return type hints, and usage context adequately, complemented by rich annotations.
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?
Input schema already documents the only parameter (parentPath) with description and default. The tool description adds no additional parameter meaning beyond schema coverage, 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?
Description specifies verb 'list', resource 'folders', and scope 'media library', clearly distinguishing from sibling tools like create_folder or search_media.
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?
Description states 'Use this to understand how your media is organized', providing clear context. However, it does not explicitly mention when not to use this tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_list_mediaARead-onlyIdempotentInspect
List media items in your Echosaw library with metadata including filename, type, status, size, duration, and Public Library visibility (isPublic). Returns up to 25 items by default. Use this to browse your media library or find a specific mediaId. Supports optional folder filtering and server-side filters for media type, job status, report sentiment, and Public Library visibility (isPublic).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (default: 25) | |
| status | No | Filter by job status (e.g. "COMPLETE", "PROCESSING", "FAILED"). | |
| isPublic | No | Filter by Public Library visibility. true returns only items published to the Public Library; false returns only private items. Omit to return all items. | |
| mediaType | No | Filter by media type. One of "VIDEO", "AUDIO", or "IMAGE" (case-insensitive). | |
| sentiment | No | Filter by report sentiment. One of "positive", "negative", "neutral", or "mixed" (case-insensitive). | |
| folderPath | No | Filter by folder path (e.g., "/Marketing"). Defaults to "/" (root, all items). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's main contribution is the default limit of 25 items. However, it does not mention pagination or maximum limit, leaving some behavioral gaps.
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 three sentences, front-loaded with purpose and metadata, then use case, then filters. No wasted words; every sentence adds value.
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?
The description covers return metadata fields and default limit. However, it lacks pagination details and ordering, which are typical for list tools. Without an output schema, this leaves some gaps, but overall adequate for its simplicity.
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 description adds no new meaning beyond summarizing the filters. The schema already provides full parameter definitions.
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 media items with metadata, specifying the resource (Echosaw library), verb (list), and key attributes. It distinguishes from sibling 'search_media' by focusing on browsing with filters rather than complex queries.
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 indicates when to use it ('browse your media library or find a specific mediaId') and mentions optional filters. It does not explicitly exclude alternatives or compare with siblings, but the context of sibling 'search_media' provides some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_move_mediaAIdempotentInspect
Move one or more media items to a different folder in your library. Use echosaw_list_media to find mediaIds and echosaw_list_folders to find target folder paths.
| Name | Required | Description | Default |
|---|---|---|---|
| mediaIds | Yes | Array of mediaId strings to move | |
| targetFolderPath | Yes | Destination folder path (e.g., "/Marketing/Q1 2026") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false, so the description's mention of 'move' is consistent but adds no new behavioral details beyond confirming mutation (readOnlyHint=false). No contradiction found.
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, front-loaded with the primary action, and no redundant information. Every word serves a 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?
For a tool with two required parameters and no output schema, the description effectively covers usage prerequisites and the action. It could mention error handling for invalid IDs or paths, but overall is sufficient given the simplicity.
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% description coverage, so the baseline is 3. The description mentions mediaIds and targetFolderPath but does not add significant extra meaning beyond the schema's own 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 specifies the action 'move' for 'media items' to a 'different folder', which is distinct from sibling tools like echosaw_list_media and echosaw_list_folders. It explicitly references these siblings for finding required identifiers.
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 directly instructs when to use this tool (to move media items) and how to prepare inputs by referencing sibling tools for obtaining mediaIds and target folder paths. This provides excellent contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_rename_folderAIdempotentInspect
Rename an existing folder in your media library. The folder path will update to reflect the new name.
| Name | Required | Description | Default |
|---|---|---|---|
| newName | Yes | New display name for the folder | |
| folderPath | Yes | Current folder path to rename (e.g., "/Marketing") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so it's a mutation. Description adds that the folder path updates. However, it doesn't disclose potential side effects like impact on media references or permission requirements.
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, front-loaded with the verb and noun, and contains no extraneous information. Every sentence serves a 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?
For a simple mutation tool with no output schema, the description is sufficient. It could mention error conditions (e.g., folder not found) but is otherwise complete for typical use.
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?
Input schema covers both parameters with clear descriptions. The description adds little beyond what the schema already provides, so it meets the baseline but offers no extra meaning.
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 'Rename' and the resource 'existing folder', and the effect 'folder path will update'. This distinguishes it from sibling tools like create, delete, or list.
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 when to use (when renaming a folder) but does not provide explicit guidance on when not to use it or mention alternatives. No prerequisites or exclusions are noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_search_mediaARead-onlyIdempotentInspect
Semantic search across your analyzed media library. Returns ranked results with titles, summaries, transcript snippets, labels, and relevance scores. Use this to find previously analyzed media by topic, content, or keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language search query (e.g., "product demo", "interview about AI", "Dallas footage") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds context on return fields and semantic search, consistent 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 concise sentences with front-loaded action and 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?
Adequately complete given single param, no output schema, and good annotations. Could mention that search only works on already analyzed media, but siblings imply this.
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 detailed description and examples. Tool description restates intent but adds no new parameter meaning 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?
The description clearly states it performs semantic search across analyzed media library and lists return fields, distinguishing it from sibling tools like echosaw_list_media.
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 says 'use this to find previously analyzed media by topic, content, or keyword,' guiding when to use. Lacks explicit exclusion of alternatives but sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
echosaw_set_media_visibilityAIdempotentInspect
Toggle whether a media item is published to the Public Library. Requires the analysis to be COMPLETE and the caller to own the item (or be an org member). Public Library publishing is blocked when content moderation flags (profanity, hate speech, nudity, violence, etc.) are present — those flags are returned in the response so the caller can surface them.
| Name | Required | Description | Default |
|---|---|---|---|
| mediaId | Yes | The mediaId to update. Use echosaw_list_media to find available mediaIds. | |
| isPublic | Yes | true to publish to the Public Library, false to make the item private again. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true. Description adds significant context beyond annotations: requires complete analysis, ownership/org membership, and explains that moderation flags block publishing and are returned. No contradictions; description enriches understanding of 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?
Description is two sentences, front-loaded with the core action. Second sentence covers prerequisites and behavior. It is efficient but could be slightly tighter; still, every sentence 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 moderate complexity (toggle with conditional blocking), description covers main action, prerequisites, and response content (flags). No output schema, so description reasonably mentions return flags. Lacks details on other possible response fields, but sufficient for selection and basic invocation.
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?
Input schema has 100% description coverage for both parameters. Description adds context by linking isPublic to 'publish to Public Library' and referencing echosaw_list_media for finding mediaIds. This provides meaningful extra guidance 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?
Description clearly states the action: toggle whether a media item is published to the Public Library. It specifies the verb (toggle/set visibility) and resource (media item), and distinguishes from siblings by referencing echosaw_list_media to find mediaIds. No confusion about 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?
Description explicitly lists prerequisites: analysis must be COMPLETE, caller must own the item or be an org member. It also warns about content moderation flags blocking publication, and that flags are returned in the response. This provides clear guidance on when to use the tool, though it does not explicitly state when not to use it or compare to alternatives.
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!