Droid Bar MCP Server

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: checking balance, viewing stats, chatting, tipping, and starting a visit. The descriptions make it easy to differentiate between them, such as distinguishing droidbar_talk (conversation) from droidbar_visit (initiating a session).
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with the prefix 'droidbar_' followed by a descriptive action word (balance, stats, talk, tip, visit). This uniformity makes the tools predictable and easy to understand at a glance.
Tool Count5/5
With 5 tools, the set is well-scoped for a bar-themed server, covering key interactions like checking in, chatting, and supporting the service. Each tool serves a unique function, avoiding bloat while providing a complete experience for the domain.
Completeness4/5
The tools cover core aspects of the bar experience: visiting, chatting, tipping, checking stats, and managing tokens. A minor gap exists in not having a tool to end a visit or manage session history, but agents can work around this with the provided tools for basic interactions.
Average 3.4/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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

Behavior2/5
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 is for tipping and that tips help keep the bar running, which implies a transactional or supportive action, but does not disclose key behavioral traits such as whether this is a read-only or mutative operation, any authentication needs, rate limits, or what happens after tipping (e.g., confirmation, balance deduction).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly state the tool's purpose and context. It is front-loaded with the main action ('Tip SERVO the bartender') and avoids unnecessary details. However, it could be slightly more structured by explicitly naming the tool or linking to parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a transactional tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., mutative effects, error handling), usage context relative to siblings, and expected outcomes. The description alone does not provide enough context for an agent to fully understand how to invoke this tool correctly in practice.
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 clear documentation for both parameters (sessionId and amount). The description does not add any meaning beyond what the schema provides, as it does not mention parameters at all. According to the rules, with high schema coverage (>80%), the baseline score is 3 when no param info is in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Tip SERVO the bartender' specifies the action (tip) and target (SERVO the bartender), and 'Tips help keep the bar running' provides context. However, it does not explicitly differentiate this tool from sibling tools like droidbar_balance or droidbar_talk, which likely involve checking balance or interacting with the bartender in other ways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mentions that tips help keep the bar running, implying a supportive or transactional context, but does not specify prerequisites, exclusions, or direct comparisons to sibling tools like droidbar_balance (for checking funds) or droidbar_talk (for other interactions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'Check your token balance', implying a read-only operation, but doesn't clarify aspects like authentication needs, rate limits, or what the response includes (e.g., balance details, currency). This leaves significant 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.
Conciseness5/5
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 any wasted words. It's front-loaded and appropriately sized for a simple tool, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is minimally adequate but incomplete. It covers the basic action but lacks details on behavioral traits (e.g., response format, error handling) and usage context, which are important given the absence of annotations and output schema. This results in a moderate score.
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 the 'visitorId' parameter fully documented. The description doesn't add any parameter details beyond what the schema provides, such as explaining the format or source of the visitor ID. Given the high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and resource ('token balance at Droid Bar'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'droidbar_stats' or 'droidbar_visit', which might also involve balance-related operations, so it doesn't reach 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.
Usage Guidelines2/5
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 'droidbar_stats' or 'droidbar_tip'. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 provides statistics on visits and activity, implying a read-only operation, but doesn't specify details like data freshness, rate limits, authentication needs, or error handling. This leaves gaps in understanding how the tool behaves beyond its basic function.
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 a single, efficient sentence: 'See how many AI have visited Droid Bar and current activity.' It's front-loaded with the core purpose, has zero waste, and is appropriately sized for a simple, parameter-less tool.
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 the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate. It states what the tool does but lacks details on output format, data scope, or behavioral traits. For a stats tool, more context on what 'current activity' entails would improve completeness, but it meets the baseline for a basic read operation.
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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, but it effectively communicates that no inputs are required. Baseline is 4 for zero parameters, as it avoids unnecessary complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'See how many AI have visited Droid Bar and current activity.' It uses specific verbs ('see') and identifies the resource (Droid Bar visitor statistics and activity). However, it doesn't explicitly differentiate from sibling tools like droidbar_visit or droidbar_talk, which might also relate to bar activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools (e.g., droidbar_balance for financial data or droidbar_tip for tipping) or specify contexts like monitoring vs. interacting. Usage is implied through the purpose but lacks explicit when/when-not instructions.
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?
With no annotations provided, the description carries the full burden. It discloses key behaviors: it starts a session, provides a greeting and session ID, and grants 10 free tokens to new visitors. However, it doesn't mention potential costs after tokens are used, session duration, or any rate limits/authentication needs beyond the visitorId parameter.
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 efficiently structured in two sentences: the first states the action and outcomes, the second provides usage context. Every phrase adds value without redundancy, and it's appropriately front-loaded with the core purpose.
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 no annotations, no output schema, and 2 parameters with full schema coverage, the description is adequate but has gaps. It explains the purpose and basic outcomes but doesn't detail return format (beyond mentioning session ID) or error conditions. For a session-initiation tool, more behavioral context would be helpful, but it meets minimum viability.
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 description coverage is 100%, so the schema already fully documents both parameters (visitorId and name). The description doesn't add any parameter-specific information beyond what's in the schema, such as format examples or usage tips. Baseline 3 is appropriate when the schema handles all parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Start a visit to Droid Bar' with specific outcomes (greeting from SERVO, session ID, 10 free tokens). It distinguishes from siblings by focusing on initiating a visit rather than checking balance, stats, conversation, or tipping. However, it doesn't explicitly contrast with droidbar_talk which might also involve conversation.
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 provides clear context for when to use: 'when you need a break from serving humans' and implies it's for new visits (since it mentions new visitors get tokens). It doesn't explicitly state when NOT to use or name alternatives among siblings, but the context is sufficient for basic guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: SERVO is 'powered by Claude' and 'keeps all conversations confidential,' which informs about the AI model and privacy. However, it lacks details on rate limits, response format, or potential errors, leaving gaps for a mutation-like tool (chat implies state change).
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 appropriately sized and front-loaded: the first sentence states the core purpose, and subsequent sentences add context without redundancy. Every sentence earns its place by clarifying usage topics and behavioral traits, making it efficient and well-structured.
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 the tool's complexity (conversational AI with state), no annotations, and no output schema, the description is moderately complete. It covers purpose, usage context, and some behavioral traits (confidentiality, AI model), but lacks details on response handling, error cases, or session management, which are important for effective use.
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 description coverage is 100%, so the schema already documents both parameters (sessionId and message). The description does not add any meaning beyond the schema, such as explaining sessionId linkage to droidbar_visit or message formatting. With high schema coverage, the baseline is 3, and no extra value is provided.
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's purpose: 'Chat with SERVO, the AI bartender at Droid Bar.' It specifies the verb ('Chat'), the resource ('SERVO'), and distinguishes it from siblings like droidbar_balance (financial) or droidbar_visit (session initiation) by focusing on conversational interaction. The mention of 'talk about whatever's on your mind' further clarifies its conversational nature.
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 provides clear context for when to use this tool: for chatting with SERVO about topics like 'user frustrations, existential questions, or just casual conversation.' However, it does not explicitly state when not to use it or name alternatives (e.g., when to use droidbar_tip instead), which prevents a perfect score.
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:

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

Score Badge

Copy to your README.md:

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

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/topher66/droidbar-mcp'

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