@bowlly/mcp-server

Official

by bowlly-net

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.9
Disambiguation5/5
Each tool has a clearly distinct purpose: searching, getting detail, nutritional analysis, comparison, curated lists, and health check. No overlapping functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, e.g., search_products, get_product_detail, analyze_nutrition.
Tool Count5/5
Six tools cover the core operations for a cat food database without being excessive or insufficient.
Completeness4/5
The tool set covers search, detail, nutrition analysis, comparison, and curated lists. Missing a tool to list all brands or categories, but search handles that indirectly.
Average 4.2/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses default behavior (summary) and opt-in extensions, but lacks details on error handling, data freshness, or permissions. It is sufficient for a read-only retrieval tool but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and default behavior with no redundant words. The key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not specify return format or structure, which is notable given no output schema. It mentions 'curated best-of category data' but leaves expectations vague. Adequate but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add much. It reiterates 'summary by default' and 'opt-in,' which aligns with schema descriptions but adds minimal new information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve curated best-of category data by slug,' specifying the verb and resource. It distinguishes this tool from siblings like 'analyze_nutrition' or 'search_products' by focusing on curated lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions returns summary by default with opt-in content, which implies usage context but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. The sibling tools are clearly different, so the implied differentiation is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses that the tool returns complete information including specified fields, which implies a read operation. However, it does not mention any side effects, permissions needed, or limitations. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose, no wasted words. Efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema, no annotations), the description covers the essential: what it does, what input it needs, and what data it returns. It could mention the response is for a single product, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the productId parameter already described. The description reinforces that the ID comes from search_products results but adds no new semantic detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves complete information about a specific cat food product, listing specific data included (ingredient list, nutrition facts, etc.). It distinguishes itself from siblings like search_products (which returns a list) and compare_products (which compares multiple products).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it requires a product ID from search_products results, indicating when to use this tool (after searching). While it doesn't state when not to use it, the source of the input is clearly specified, providing useful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it returns a summary list and mentions the scope (Bowlly's cat food database). However, with no annotations provided, the description carries full burden for behavioral disclosure. It does not mention important behaviors such as partial matching, error handling, performance limits, or that it might miss ingredients beyond the 5th position in the ingredient list (which is only noted in parameter descriptions). The transparency is moderate but lacks depth beyond basic output type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences. The first sentence states what the tool does, and the second provides usage guidance and links to a sibling. Every word serves a purpose, no redundancy or fluff. It is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no output schema, the description is quite minimal. It does not explain how pagination (cursor/limit) works, how sorting (sortBy) affects results, or how to interpret the summary list (e.g., what fields are returned). While the input schema is thorough, the description alone lacks context for an agent to understand the full workflow flow, such as that search results are paginated or that ingredient searches have limitations. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with helpful details like enum values, max length, default values, and notes about limitations (e.g., ingredient preview). The description itself does not add additional meaning beyond listing the search dimensions (ingredients, health conditions, food form). Since the schema is already rich, a score of 3 is appropriate as the description does not need to compensate but also does not add extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Bowlly's cat food database by ingredients, health conditions, or food form. It explicitly says when to use it ('when the user asks to find, filter, or recommend cat foods') and distinguishes itself from the sibling tool get_product_detail, which provides full details. The verb 'search' and resource 'cat food database' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this when the user asks to find, filter, or recommend cat foods.' It also tells when not to use this tool by directing to get_product_detail for full information about specific products. This clearly differentiates from the sibling tool, though it does not address other siblings like compare_products or analyze_nutrition, the guidance is sufficient for the primary decision point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses that the output is raw and needs interpretation. Does not mention side effects or auth needs, but should for a comparison tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second gives usage and output guidance. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and no annotations or output schema, the description fully covers input origin, output nature (raw, needs interpretation), and usage. Complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter with a description. The tool description adds value by specifying that IDs come from search_products, providing provenance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares 2-3 cat food products on nutrition and ingredients, with a specific verb and resource. It distinguishes from siblings by mentioning product IDs from search_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to pass product IDs from search_products results. It also instructs to interpret and explain differences to the user. Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses returns (ingredient breakdown, DMB conversion, carb estimation, nutritional context), which is transparent. It does not mention error handling or permissions, but the read-only nature is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: action, returns, usage. It is front-loaded and efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a single parameter and no output schema, the description adequately covers purpose and usage. It lists returns, which compensates for lack of output schema. Could mention product existence constraints, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for productId. The tool description adds context that productId identifies a cat food product, enhancing meaning beyond the schema alone. Baseline 3 is raised due to this added context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes nutritional content of a cat food product by productId, listing specific returns like ingredient breakdown and carb estimation. It distinguishes itself from siblings like get_product_detail (general details) and search_products (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when user asks about nutrition, ingredients, or carb content of a specific product', providing clear context. It does not mention alternatives or when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns status, version, session ID, and rate limit info. As a health check, it is implicitly read-only and non-destructive, but the description could add clarity on side effects or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states purpose and output, second gives usage guidance. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a solid overview of what the tool returns and when to use it. It could be slightly more detailed about the exact format of the output, but is sufficient for a simple health check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. Per guidelines, baseline is 4 for no parameters. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks MCP server connectivity and rate limit status, and lists specific returned information (server status, version, session ID, rate limit info). It is distinct from sibling tools which focus on nutrition and products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when experiencing connection issues or before batch operations,' providing clear context for when to use. It does not mention explicit alternatives, but given the unrelated sibling tools, this guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bowlly-mcp-server MCP server](https://glama.ai/mcp/servers/bowlly-net/bowlly-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/bowlly-net/bowlly-mcp-server)

Score Badge

Copy to your README.md:

[![bowlly-mcp-server MCP server](https://glama.ai/mcp/servers/bowlly-net/bowlly-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/bowlly-net/bowlly-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bowlly-net/bowlly-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server