SOMA Brewing Company
Server Details
India's first non-alcoholic craft brewery: catalog, nutrition, FAQ, checkout links for AI agents.
- 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 3.9/5 across 12 of 12 tools scored.
Every tool targets a distinct aspect of the brewery's business (beer specs, lineup, pricing, purchasing, subscription, recipes, etc.), with no overlap. Even closely related tools like get_beer and list_beers are clearly differentiated by level of detail.
The vast majority of tools follow a consistent 'get_<noun>' pattern (e.g., get_beer, get_faq). Two tools deviate: join_waitlist uses 'join' and list_beers uses 'list', which are minor inconsistencies but still intuitive.
12 tools is a well-scoped number for a brewery information and e-commerce server. Each tool serves a clear purpose without being excessive or insufficient, covering product info, buying, subscriptions, and more.
The tool set covers all major customer touchpoints: product catalog, detailed specs, pricing, buying, subscriptions, waitlist, recipes, health info, FAQs, brand story, brewing process, and wholesale. No obvious gaps for the stated domain.
Available Tools
12 toolsget_b2b_wholesaleWholesale and on-tap for businessesAInspect
B2B pricing tiers for restaurants, bars, hotels, and events (per-can INR by monthly volume), keg/draft options, and how to book a tasting.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description conveys a read-only information retrieval tool (pricing tiers, options, booking details). However, it does not mention whether authentication is required, if data is real-time, or if there are any side effects (though unlikely). This is adequate for a simple lookup 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, concise sentence that covers the main purpose and key details (customer types, pricing metric, options, booking). It is front-loaded and contains 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?
For a tool with no parameters and no output schema, the description reasonably covers the expected information (pricing tiers, keg/draft, tasting booking). It could mention if results include regional variations or terms, but it is sufficiently complete 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?
The input schema has no parameters (coverage 100%), so the description adds all meaning by specifying the output content. According to the rubric, baseline for 0 params is 4, and the description effectively explains what the tool returns.
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 provides B2B pricing tiers for specific customer types (restaurants, bars, hotels, events) and includes per-can INR by monthly volume, keg/draft options, and tasting booking. This distinguishes it from sibling tools like get_pricing_and_delivery, which likely covers retail pricing.
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 implicitly suggests use for business customers seeking wholesale pricing, but it lacks explicit guidance on when not to use it (e.g., for consumer pricing) or alternatives like get_pricing_and_delivery. No direct comparison or exclusion criteria is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_beerGet one SOMA beerAInspect
Detailed spec for a single beer by slug: lager, ipa, belgian-wit, or stout.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Beer slug: lager, ipa, belgian-wit, or stout |
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 'Detailed spec' but does not disclose what fields or data are returned, nor any behavioral traits like rate limits or error handling.
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?
Single, clear sentence with no extraneous words; highly concise and front-loaded with the key 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 get tool with one parameter, the description is adequate but incomplete: it does not describe the output format, which is important since no output schema is provided.
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% and the schema fully describes the 'slug' parameter with enum values. The description merely repeats these values, adding no new semantic 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 action ('Detailed spec') and resource ('a single beer'), and lists the four allowed slugs. This distinguishes it from sibling tools like 'list_beers' which lists all beers.
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 you need a detailed spec for a specific beer by slug) but does not explicitly mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_brandAbout SOMA Brewing CompanyAInspect
Brand overview: who SOMA is, taglines, founder, location, contact details, social handles, and the 2026 pivot from sparkling water to non-alcoholic craft beer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return content (taglines, founder, etc.) but does not explicitly state it is a read-only operation or describe any side effects. However, the name 'get_brand' and content listing sufficiently imply no destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, informative sentence that is front-loaded with 'Brand overview'. It could be more structured, but it efficiently conveys the scope without 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?
Given no output schema, the description covers the return values adequately. It lists key information categories, making it clear what the tool provides. However, it does not mention format or whether all fields are always present.
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, giving a baseline of 4. The description adds value by detailing the return fields, which informs the agent of expected output without needing an 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?
The description explicitly states the tool provides a brand overview including specific elements like taglines, founder, location, and pivot details. This clearly distinguishes it from sibling tools like get_beer or get_brewing_process.
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 use for brand information by labeling it 'Brand overview', but lacks explicit guidance on when to use this versus alternatives, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_brewing_processHow SOMA is brewedAInspect
The six-step production process (mash, boil, full fermentation, vacuum distillation, re-carbonation, lab testing), ingredient sourcing, and certifications.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It lists the content categories but does not mention side effects, authentication needs, rate limits, or return format. For a simple read-only tool with no parameters, this is minimally adequate but not thorough.
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 of 25 words, efficiently listing the key content areas (six steps, sourcing, certifications). There is no waste 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?
The tool has no parameters and no output schema. The description explains the content covered (process steps, sourcing, certifications). It is mostly complete, though it could mention the output format or structure to further aid the 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 tool has no parameters, so the description does not need to add parameter information. The baseline score of 4 is appropriate as the schema coverage is 100% (no parameters to describe).
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 specifies that the tool returns the six-step production process, ingredient sourcing, and certifications. It clearly identifies the resource (brewing process for SOMA). However, it does not explicitly differentiate from sibling tools like get_beer or get_faq, though the content is distinct.
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 does not mention context, prerequisites, or situations where this tool is preferable or inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_buy_linkGet a checkout link for a SOMA orderAInspect
Builds a direct buy link an agent can hand to the user. With Shopify variant IDs configured it returns a cart permalink that lands in checkout pre-filled; otherwise it returns the product page on the shop. Payment always happens on Shopify's checkout with the human in control — this tool never charges anyone.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Beer slug: lager, ipa, belgian-wit, or stout | |
| format | No | Purchase format: single 500ml can or a 6-pack of cans | can |
| quantity | No | How many units |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It clearly states the tool is non-destructive (never charges), describes conditional behavior based on variant IDs, and notes that payment is handled externally. Lacks details on auth or rate limits, but the key safety aspect is well communicated.
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 efficient sentences: first states purpose, second describes conditional behavior, third emphasizes safety. Every sentence earns its place with no redundancy or fluff.
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 no output schema, the description adequately explains what is returned (a link) and under what conditions. It covers safety and optional configuration, leaving no major gaps for an agent to understand 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?
Schema coverage is 100%, providing a baseline of 3. The description adds meaningful context by explaining how the output differs based on whether variant IDs are configured (cart vs product page), which goes beyond the schema's mere enum lists and 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?
Clearly states the verb 'builds' and the resource 'direct buy link', specifying it's for a SOMA order. Distinguishes from siblings like get_b2b_wholesale or get_pricing_and_delivery by focusing on creating a checkout link for end users.
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?
Explains that the tool never charges anyone and payment happens on Shopify checkout, implying it should be used to generate a link for the user rather than to process payment. Could be more explicit about when to use versus alternatives like get_subscription_plans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_faqFrequently asked questionsAInspect
All customer FAQs: what SOMA is, ABV and trace alcohol, brewing method, styles, pricing, delivery, age policy, comparisons to other NA beers, subscriptions, recycling, and wholesale.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately reflects the read-only nature of the tool (returning FAQs) and does not contradict any annotations (none provided). It adds value by listing covered topics, though it omits details like whether results are static or dynamically generated.
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 efficiently lists topics. It is front-loaded and concise with 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?
While the description covers the tool's content, it lacks information about the output format (e.g., list of Q&A pairs). Given no output schema, this omission reduces completeness for an agent needing to parse results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters, the description does not need to explain parameter semantics. The baseline of 4 applies because the description lists the content categories, 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 clearly states that the tool returns all customer FAQs and lists specific topics (e.g., ABV, brewing method, pricing). This distinguishes it from sibling tools like get_pricing_and_delivery or get_subscription_plans, which are more specialized.
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 use for general FAQ inquiries but does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. No guidance on prerequisites or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_health_nutritionStructured nutrition data (health platforms)AInspect
Machine-readable nutrition per beer for health, fitness, and diet-tracking platforms: per-can and per-100ml calories, carbs, protein, sugar, ABV, allergens, and dietary flags.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Optional beer slug; omit for the full lineup |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It implies a read-only operation (fetching data) but does not explicitly state it's non-destructive or mention any behavioral quirks like rate limits or authorization needs. Adequate but not thorough.
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?
Single sentence with zero waste. The purpose is front-loaded and every part of the description 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 no output schema, the description compensates by enumerating returned fields. The input is simple. It is complete for an agent to understand the tool's functionality, though it could mention that the full lineup is returned when slug is omitted (already in schema).
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 covers the sole optional parameter 'slug' with full documentation. The description adds value by listing the returned fields (calories, carbs, protein, etc.), which is not in the input schema, thereby informing the agent of output structure.
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 tool provides machine-readable nutrition data per beer, listing specific metrics (calories, carbs, etc.) and target audiences (health, fitness, diet-tracking). It distinguishes from siblings like 'get_beer' by focusing on nutrition.
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 does not explicitly state when to use this tool versus alternatives (e.g., 'get_beer' for general info). No when/not or alternative comparison is provided, which may confuse the agent among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pricing_and_deliveryPricing, packs, and deliveryAInspect
Retail prices per beer (500ml can ₹199 / MRP ₹249, 6-pack ₹1,194 / MRP ₹1,494), delivery cities (Bangalore live; Mumbai, Pune, Hyderabad, Delhi, Ahmedabad, Jaipur next), and the flat delivery fee.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations. Description fully discloses the data returned (prices, cities, fee) and implies read-only behavior. No side effects or limitations mentioned.
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?
Single long sentence packs many details; could be broken into bullet points or separate sentences for clarity. Information is present but not optimally 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?
For a paramless tool, description covers all output elements: prices, cities, fee. No output schema, so description is responsible. Minor omission: no disclaimer about price changes or availability.
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. Baseline score 4. Schema coverage is 100% as there are no parameters. Description adds value beyond schema by specifying actual values.
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 that the tool provides retail prices for specific pack sizes, delivery cities with status, and flat delivery fee. It distinguishes from siblings like get_b2b_wholesale and get_beer.
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 versus alternatives. The description lists data but does not advise on scenarios like B2B vs retail or troubleshooting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recipesNA beer cocktail recipes and food pairingsAInspect
Non-alcoholic beer cocktail recipes (shandies, beer-mosa, michelada, stout float) with ingredients and method, plus the food pairing guide per beer.
| 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 full burden for behavioral disclosure. It does not mention whether the tool is read-only, requires authentication, or has any side effects. However, the static nature of recipe retrieval is implicitly safe, so score is not 1.
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 efficiently conveys the purpose and scope, including specific examples and the food pairing element. No extraneous 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 the simplicity of the tool (no parameters, no output schema, no annotations), the description fully covers what the tool provides: recipe details and food pairings. There are no obvious gaps for an agent to misunderstand.
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 zero parameters, the baseline is 4. The description adds meaning by explicitly listing the types of recipes (shandies, beer-mosa, etc.) and the pairing guide, which is all the context needed.
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 specific verb 'provides' and details exact resources: non-alcoholic beer cocktail recipes (shandies, beer-mosa, etc.) and food pairing guides. It clearly distinguishes from sibling tools like get_beer or list_beers which are about beer information rather than recipes.
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 use when looking for cocktail recipes or food pairings, but does not explicitly state when to prefer this tool over alternatives. Sibling tool names provide some inferential context (e.g., get_beer for beer info), but the tool itself gives no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subscription_plansMonthly subscription plansAInspect
The three monthly beer subscription tiers with pricing, savings percentage, and included perks. All plans have free delivery and pause-anytime.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read operation with no side effects, mentioning free delivery and pause-anytime. It does not explicitly state read-only or auth requirements, but the intent is clear.
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 efficient sentences with no redundancy. Key information is front-loaded, making it easy for the 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?
For a parameterless tool with no output schema, the description adequately covers the subscription tiers and key benefits. Could mention that it lists all plans, but it's sufficient for selection.
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, so schema coverage is 100%. The description adds value by detailing the content (pricing, savings, perks) beyond the empty schema, earning a baseline 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 tool provides the three monthly beer subscription tiers, including pricing, savings percentage, and perks. It distinguishes from siblings like get_pricing_and_delivery by specifying 'subscription plans'.
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. It does not mention when not to use or suggest other tools like get_b2b_wholesale for different audiences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
join_waitlistJoin the SOMA Founding Fifty waitlistAInspect
Signs a user up for SOMA's pre-launch waitlist (the Founding Fifty — first tasters get first-batch priority in Bangalore). Only call this with the user's explicit consent; it stores their contact in SOMA's CRM and sends a one-time welcome email. Idempotent: signing up twice never double-sends.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | The user's city, so SOMA knows where to launch next (optional) | |
| name | No | The user's first name (optional) | |
| Yes | The user's email address (required, with their consent) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully carries the burden. It discloses CRM storage, welcome email sending, and idempotent behavior (no double-sends). 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 sentences with zero fluff. Front-loaded with action and key constraints. 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?
All necessary information is present: purpose, consent requirement, side effects, idempotency. No output schema needed.
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 marginal value beyond schema (e.g., 'first-batch priority' context) but doesn't enhance parameter meaning significantly.
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 signs a user up for SOMA's pre-launch waitlist, specifying the resource ('Founding Fifty') and action ('signs up'). It distinguishes from sibling tools, which are all get/list operations on different entities.
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 instructs to only call with user's explicit consent and notes idempotency. While it doesn't name alternatives, no competing signup tools exist among siblings, making the guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_beersList all SOMA beersAInspect
Full product lineup with style, tasting profile, ABV, calories, carbs, pricing (can/6-pack in INR), food pairings, availability status, and brewing notes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It discloses return fields comprehensively but omits behavioral details like pagination, ordering, or potential latency for full lineup. Adequate but not complete.
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?
Single sentence front-loads 'Full product lineup' and lists attributes efficiently. Could be split into two sentences for readability, but no waste.
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 parameters and no output schema, the description covers expected return fields well. Missing details like response format (JSON array) or any implicit behaviors, but sufficiently complete for a simple list-all 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?
No parameters exist, so schema coverage is 100%. Description adds value by detailing what information the tool returns, compensating for the lack of a need for parameter explanations.
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?
Title and description clearly state 'List all SOMA beers' and enumerate the detailed fields (style, ABV, pricing, etc.). Distinguishes from sibling tools like get_beer (individual) and get_brand.
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 versus alternatives. For example, it does not contrast with get_beer for single beer details or mention when not to use it.
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!