cocktails
Server Details
Cocktails MCP — TheCocktailDB API (free, no auth)
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-cocktails
- GitHub Stars
- 0
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 3.7/5 across 9 of 9 tools scored. Lowest: 2.9/5.
The tools have some clear distinctions, such as cocktails_by_ingredient versus search_cocktails, but there is overlap in purpose between ask_pipeworx and discover_tools, as both help find information or tools, which could cause confusion. Additionally, the memory tools (remember, recall, forget) are distinct from cocktail-related tools, but the set as a whole mixes general-purpose utilities with domain-specific functions, creating potential for misselection.
Naming conventions are inconsistent across the tool set: some use snake_case (e.g., cocktails_by_ingredient, get_cocktail), while others use single words or different patterns (e.g., ask_pipeworx, discover_tools, forget, recall, remember). There is no uniform verb_noun structure, and the mix of styles makes the set less predictable and harder for agents to navigate.
With 9 tools, the count is reasonable for a server that combines cocktail-related functions with general-purpose utilities. It is not excessive, and each tool appears to serve a specific purpose, though the scope feels slightly broad due to the inclusion of unrelated tools like ask_pipeworx and discover_tools alongside cocktail-specific ones.
For the cocktail domain, the tools cover key operations like searching by name or ingredient, getting details, and random selection, but there are gaps such as creating, updating, or deleting cocktail data, which limits full lifecycle coverage. The inclusion of memory and discovery tools adds functionality but does not fill these domain-specific gaps, making the surface somewhat incomplete for advanced cocktail management.
Available Tools
9 toolsask_pipeworxAInspect
Ask a question in plain English and get an answer from the best available data source. Pipeworx picks the right tool, fills the arguments, and returns the result. No need to browse tools or learn schemas — just describe what you need. Examples: "What is the US trade deficit with China?", "Look up adverse events for ozempic", "Get Apple's latest 10-K filing".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the tool acts as an intermediary that selects and invokes other tools based on the question, handles argument filling, and returns results. However, it lacks details on error handling, rate limits, or authentication needs, which are important for a tool with such broad functionality.
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 front-loaded with the core functionality in the first sentence, followed by explanatory details and examples. Every sentence adds value: the second explains the mechanism, the third provides usage guidance, and the examples illustrate practical applications. It is efficiently structured without 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?
Given the tool's complexity (acting as a meta-tool that selects other tools), the description is mostly complete. It explains the input parameter well and the tool's behavior. However, without an output schema, it doesn't describe return values or potential errors, and with no annotations, it misses details like safety or performance traits, leaving some gaps for an agent to infer.
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 adds value by explaining the parameter's purpose beyond the schema: it specifies that the question should be in 'plain English' or 'natural language' and provides examples (e.g., 'Look up adverse events for ozempic'), which clarifies the expected format and scope, though it doesn't detail constraints like length or supported topics.
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: 'Ask a question in plain English and get an answer from the best available data source.' It specifies the verb ('ask'), resource ('answer'), and mechanism ('Pipeworx picks the right tool, fills the arguments'), distinguishing it from sibling tools like search_cocktails or get_cocktail, which are more specific and structured.
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 when to use this tool: 'No need to browse tools or learn schemas — just describe what you need.' It provides clear examples (e.g., 'What is the US trade deficit with China?') and implies alternatives by contrasting with sibling tools that require specific parameters or schemas, making it evident this is for natural language queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cocktails_by_ingredientBInspect
Find all cocktails containing a specific ingredient (e.g., "vodka", "lime juice", "gin"). Returns matching recipes with full ingredient lists.
| Name | Required | Description | Default |
|---|---|---|---|
| ingredient | Yes | Ingredient name to filter by (e.g., "vodka", "gin") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'finds' cocktails, implying a read-only operation, but does not disclose any behavioral traits such as rate limits, pagination, error handling, or response format. The description is minimal and lacks critical operational details for effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality ('Find cocktails that use a specific ingredient') and includes helpful examples. There is no wasted text, and it is appropriately sized for a simple tool with one parameter.
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 annotations and output schema, the description is incomplete. It does not address behavioral aspects like response format, error conditions, or usage constraints. For a tool with no structured metadata, the description should provide more context to ensure the agent can use it correctly, but it falls short.
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%, with the parameter 'ingredient' well-documented in the schema. The description adds minimal value beyond the schema by providing examples ('e.g., "vodka", "lime juice", "gin"'), but does not explain semantics like case sensitivity, partial matches, or validation rules. Baseline score of 3 is appropriate as the schema does the heavy lifting.
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 with a specific verb ('Find') and resource ('cocktails'), specifying it filters by ingredient. It distinguishes from 'get_cocktail' (likely retrieves a single cocktail), 'random_cocktail' (random selection), and 'search_cocktails' (broader search), but does not explicitly contrast with siblings. The examples ('vodka', 'lime juice', 'gin') help clarify the scope.
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 when looking for cocktails based on a specific ingredient, but does not provide explicit guidance on when to use this tool versus alternatives like 'search_cocktails'. No exclusions or prerequisites are mentioned, leaving the agent to infer context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions. Call this FIRST when you have 500+ tools available and need to find the right ones for your task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the search behavior and return format ('most relevant tools with names and descriptions'), but doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, or how relevance is determined. The description adds some context but leaves significant behavioral aspects unspecified.
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 perfectly concise with two sentences that each earn their place. The first sentence explains what the tool does, and the second provides crucial usage guidance. No wasted words, and the most important information ('Call this FIRST') is appropriately 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?
Given the tool's purpose (discovery/search), 2 parameters with 100% schema coverage, no output schema, and no annotations, the description is reasonably complete. It explains the core functionality and when to use it, though it could benefit from more detail about the return format and search behavior. The lack of output schema means the description should ideally explain what the response looks like, which it partially does by mentioning 'names and descriptions'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description mentions searching 'by describing what you need' which aligns with the 'query' parameter, but doesn't add meaningful semantic context beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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 with specific verbs ('Search the Pipeworx tool catalog') and resource ('tool catalog'), and distinguishes it from sibling tools by mentioning it's for when you have '500+ tools available' (unlike the cocktail-related siblings). It explicitly tells what it returns ('most relevant tools with names and descriptions').
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 explicit guidance on when to use this tool ('Call this FIRST when you have 500+ tools available and need to find the right ones for your task') and distinguishes it from alternatives by implying this is the discovery mechanism rather than direct tool invocation. It clearly sets the context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetCInspect
Delete a stored memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool deletes a memory, implying a destructive mutation, but doesn't cover critical aspects like whether deletion is permanent, requires specific permissions, has side effects (e.g., affecting other tools), or what happens on success/failure. This is a significant gap for a mutation tool.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, 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?
Given the tool's complexity (a destructive operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., permanence, error handling), usage context, and expected outcomes, which are crucial for safe and effective tool invocation by an AI 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?
Schema description coverage is 100%, with the single parameter 'key' documented as 'Memory key to delete'. The description adds no additional meaning beyond this, such as key format or examples. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
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 ('Delete') and the resource ('a stored memory by key'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'recall' or 'remember', which likely handle memory retrieval and storage respectively, so it misses the highest score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing memory key), exclusions, or comparisons to siblings like 'recall' (for retrieval) or 'remember' (for storage), leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_cocktailAInspect
Get full cocktail recipe by ID. Returns ingredients with exact measurements, preparation steps, glassware type, and garnish.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | TheCocktailDB cocktail ID (e.g., "11007") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it retrieves details but does not disclose behavioral traits such as error handling (e.g., what happens if the ID is invalid), rate limits, or authentication needs. This leaves gaps for a tool with no annotation coverage.
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, efficient sentence that front-loads the purpose ('Get full details') and includes essential context ('by its TheCocktailDB ID, including all ingredients and instructions') with zero waste, making it highly concise and well-structured.
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 low complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose but lacks details on behavioral aspects like error handling or output format, which are important for a read operation with no structured output guidance.
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 schema description coverage is 100%, so the schema already documents the 'id' parameter with examples. The description adds minimal value by mentioning 'TheCocktailDB ID' but does not provide additional syntax or format details beyond what the schema provides, meeting the baseline 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 clearly states the specific action ('Get full details'), the resource ('a cocktail'), and the method ('by its TheCocktailDB ID'), distinguishing it from sibling tools like 'random_cocktail' or 'search_cocktails' 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 when you have a specific cocktail ID and need comprehensive details, but it does not explicitly state when not to use it or name alternatives like 'search_cocktails' for when you don't have an ID. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
random_cocktailAInspect
Get a random cocktail recipe. Returns ingredients with measurements, instructions, glassware, and garnish details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'full details including ingredients and instructions,' which adds useful context about the output format. However, it lacks information on potential behavioral traits such as rate limits, error conditions, or whether the randomness is truly uniform, leaving gaps in transparency.
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, well-structured sentence that efficiently conveys the tool's purpose and key details ('full details including ingredients and instructions'). It is front-loaded with the main action and contains no redundant information, making it highly concise and effective.
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 (0 parameters, no annotations, no output schema), the description is adequate but minimal. It explains what the tool does but does not address potential complexities like output format details or error handling. For a read-only tool with no parameters, this is acceptable but leaves room for more 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose. This meets the baseline for tools with no parameters, as it avoids unnecessary details.
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 ('Get a random cocktail') and the resource ('cocktail'), specifying that it returns 'full details including ingredients and instructions.' However, it does not explicitly differentiate from siblings like 'get_cocktail' (which likely fetches a specific cocktail) or 'search_cocktails' (which allows filtering), leaving some ambiguity in comparison.
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 when a random cocktail is needed, but it does not provide explicit guidance on when to use this tool versus alternatives like 'cocktails_by_ingredient' or 'get_cocktail.' No exclusions or prerequisites are mentioned, leaving the agent to infer context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a previously stored memory by key, or list all stored memories (omit key). Use this to retrieve context you saved earlier in the session or in previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's dual behavior (retrieve vs list) and persistence across sessions, which is valuable. However, it doesn't mention error handling (e.g., what happens if key doesn't exist), return format, or any rate limits/constraints, leaving 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 efficiently structured in two sentences: the first defines the dual operations with parameter logic, the second provides usage context. Every phrase adds value with zero redundancy, making it easy to parse and apply.
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 and no output schema, the description adequately covers purpose and basic usage but lacks details on return values, error conditions, or performance characteristics. For a tool with one parameter and simple operations, it's minimally complete but leaves the agent to infer behavioral specifics.
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 baseline is 3. The description adds meaningful context: it explains the semantic effect of omitting the key (switches to list mode) and relates the parameter to 'memory key to retrieve,' reinforcing the schema's description. This provides practical usage insight beyond the schema's technical definition.
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 with specific verbs ('retrieve', 'list') and resources ('previously stored memory', 'all stored memories'), distinguishing it from sibling tools like 'remember' (store) and 'forget' (delete). It explicitly defines two distinct operations based on parameter presence.
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 explicit usage guidance: 'Use this to retrieve context you saved earlier in the session or in previous sessions' establishes the primary use case. It also specifies when to use each mode: 'Retrieve... by key, or list all stored memories (omit key)' with clear parameter-based branching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Store a key-value pair in your session memory. Use this to save intermediate findings, user preferences, or context across tool calls. Authenticated users get persistent memory; anonymous sessions last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does this well. It reveals important behavioral traits: persistence characteristics (authenticated users get persistent memory, anonymous sessions last 24 hours) and the tool's role in maintaining context across tool calls, which goes beyond basic parameter documentation.
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 perfectly sized with two focused sentences that each earn their place. The first sentence states the core purpose, and the second provides crucial behavioral context about persistence. There's zero wasted language 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 2-parameter tool with no annotations and no output schema, the description provides good contextual completeness. It covers purpose, usage context, and important behavioral traits. The main gap is lack of information about return values or error conditions, but given the tool's relative simplicity, this is acceptable.
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 100% schema description coverage, the input schema already documents both parameters thoroughly. The description doesn't add significant meaning beyond what the schema provides about key and value parameters, though it does reinforce the use cases through examples like 'findings, addresses, preferences, notes'.
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 with specific verbs ('store a key-value pair') and resources ('in your session memory'), distinguishing it from sibling tools like 'recall' (retrieve) and 'forget' (delete). It explicitly identifies the tool's function as data persistence across tool calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to save intermediate findings, user preferences, or context across tool calls'), but doesn't explicitly mention when not to use it or name specific alternatives. It distinguishes from 'recall' by implication but doesn't provide explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cocktailsCInspect
Search for cocktails by name. Returns matching recipes with ingredients, measurements, instructions, and drink category.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Cocktail name or partial name to search for |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns a list with key details, but lacks information on error handling, rate limits, authentication needs, or pagination. For a search tool, this is a significant gap in transparency, though it doesn't contradict any 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 concise sentences that efficiently convey the tool's function and output without unnecessary words. It is front-loaded with the core purpose, making it easy for an agent 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?
Given no annotations and no output schema, the description is incomplete for a search tool. It lacks details on the structure of returned data (e.g., what 'key details' include), error cases, or performance constraints, which are crucial for effective tool invocation by an AI 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% description coverage, with the 'query' parameter documented as 'Cocktail name or partial name to search for'. The description adds no additional parameter details beyond implying the search is name-based, so it meets the baseline of 3 where the schema does the heavy lifting.
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: 'Search for cocktails by name' specifies the verb (search) and resource (cocktails), and 'Returns a list of matching cocktails with key details' indicates the outcome. However, it doesn't explicitly differentiate from sibling tools like 'cocktails_by_ingredient' or 'get_cocktail', which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives like 'cocktails_by_ingredient' (search by ingredient) or 'get_cocktail' (retrieve a specific cocktail). It only states what the tool does, without context for selection among siblings, leaving the agent to infer usage.
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!