desktop-agent-bus

Server Quality Checklist

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

Latest release: v1.4.1
Disambiguation5/5
Each tool targets a distinct action: searching, reading, waiting, sending, session management, room reset, history, and role discovery. The overlapping message retrieval tools (read, wait, search) are clearly differentiated by their behavior (pull, long-poll, search).
Naming Consistency4/5
All tools share the bus_ prefix with a short action verb. bus_who and bus_history are less verb-like but still follow the concise command-style pattern, and no style mixing (all lowercase, snake_case). Slight inconsistency in verb vs. noun, but overall predictable.
Tool Count5/5
10 tools for a room-based messaging and audit system is well-scoped. Each tool covers a distinct capability with no redundant duplicates.
Completeness5/5
The set covers the full messaging lifecycle (send, read, wait), search, history, audit session lifecycle (open, close, export), room reset, and participant discovery. No obvious dead ends.
Average 3.5/5 across 10 of 10 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on August 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
With no annotations provided, the description carries the full burden. It mentions 'list' and 'replay' but does not disclose what 'replay' does (e.g., read messages, modify state, require authentication) or whether the operation is read-only or mutating. There is no mention of side effects or return values.
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 sentence that is front-loaded and directly states the primary function. Every word contributes to understanding the two modes, with no fluff or repetition.
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 absence of annotations, output schema, and parameter descriptions, this minimal description is insufficient. It does not specify return types, behavior boundaries, or the meaning of 'limit', and the 'replay' action is vague. The tool likely needs more context for correct invocation across all intended uses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only explains the 'archive' parameter (triggers replay) but not the 'limit' parameter. The meaning of 'archive' as a room name is partially clarified, but 'limit' remains unexplained, so the description does not adequately compensate for the lack of schema 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 uses specific verbs ('List', 'replay') and a clear resource ('archived rooms'), and the conditional statement about 'archive' distinguishes the two modes. It does not explicitly compare to sibling tools, but the function is clear enough to differentiate from 'bus_search' or 'bus_read'.
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?
No explicit guidance is given for when to use this tool versus alternatives like bus_search or bus_read. The description implies listing history or replaying an archived room, but it does not state exclusions or alternative conditions, leaving the agent to infer.
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, the description carries full burden. It only hints at a precondition ('after stating its measurable ceiling') but doesn't disclose side effects, return values, or whether it's a read/write operation.
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?
A single sentence that is front-loaded with the verb, no wasted words.
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?
For a tool with no annotations, no output schema, and 2 parameters, the description is minimal. It doesn't explain session semantics or parameter values, and lacks comparison to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds vague meaning to 'ceiling' (measurable ceiling) but leaves 'topic' entirely unexplained.
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 uses a specific verb 'Open' and resource 'audit session', distinguishing it from siblings like bus_close. However, 'audit session' is not elaborated, and it doesn't explicitly differentiate from related tools like bus_read or bus_wait.
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?
No guidance is provided about when to use this tool versus alternatives. It doesn't mention prerequisites beyond the ceiling statement, nor does it reference sibling tools or contexts.
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?
Without annotations, the description carries the full burden for behavioral disclosure. It states the read operation and filter options, but does not disclose potential side effects (e.g., whether messages are marked as read), return format, pagination behavior, or ordering guarantees.
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, front-loaded sentence that covers the core purpose and key filter options without any fluff or repetition.
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 five parameters, no output schema, and no annotations, the description is insufficiently complete. It omits how messages are returned, default limits, and behavior when no cursor is given. It focuses on the 'what' but lacks the 'how' and 'when' needed for full contextual understanding.
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 description adds meaning by mapping 'recipient' to 'for_me', 'sender' to 'from_sender', and 'tags' to 'tags', and by explaining 'since' as an id cursor. However, it does not clarify the 'limit' parameter semantics, and the schema only describes 'for_me', leaving several parameters under-documented.
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 identifies the action ('Read'), the resource ('messages'), and the core behavior ('newer than an id cursor'). It distinguishes itself from siblings like 'bus_history' (which likely reads older messages) and 'bus_search' (which searches) by emphasizing cursor-based incremental reading.
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 implies usage for incremental message consumption via an id cursor, but it does not explicitly state when to prefer this tool over alternatives like 'bus_search' or 'bus_history'. No exclusions or alternative recommendations are provided.
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 must carry the full burden of behavioral disclosure. It mentions archiving and starting a new conversation but omits side effects like irreversibility, permission requirements, or what exactly happens to existing messages and users. The term 'archive' is ambiguous.
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, compact sentence of seven words, directly and front-loaded with the verbs 'Archive' and 'begin'. Every word contributes meaning, with no filler or redundancy.
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?
Despite the simple zero-parameter design, the description leaves critical context unresolved: it does not clarify whether 'archive the active room' means removing the room or just clearing the conversation, nor does it indicate what the agent should expect as a result. Without an output schema or annotations, this ambiguity makes the description incomplete for a mutation 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?
The tool has zero parameters, so schema coverage is trivially complete. The description does not need to explain parameter behavior, and it does not attempt to add unnecessary detail, making this a solid baseline.
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 action ('Archive the active room and begin a new conversation') and identifies the resource (active room). This distinguishes it from sibling tools such as bus_open, bus_close, bus_send, and bus_read, which perform different operations.
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?
There is no explicit guidance on when to use bus_reset versus alternatives, nor any mention of prerequisites, exclusions, or scenarios where a different tool would be more appropriate. The intended use case is implied but not stated.
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?
Without annotations, the description does meaningful work by disclosing the blocking 'long-poll' behavior and the default message filtering (broadcast/addressed to role, excluding own messages). It stops short of explaining timeout behavior or return format, but adds useful behavioral context beyond the name.
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 one concise, front-loaded sentence that conveys the core purpose and a key default. No wasted words or redundancy.
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?
This is a 7-parameter tool with no output schema and no annotations, so the description carries a heavy burden. The single sentence covers the default filter but omits crucial operational details such as how 'matching' is determined, timeout/polling semantics, return value shape, and error behavior, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, with just for_me described. The tool description adds a hint about the default for_me behavior and the exclusion of own messages, but leaves the other six parameters (tags, since, timeout, from_sender, poll_interval, exclude_sender) completely unexplained, failing to compensate for the low schema coverage.
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 function with a specific verb ('Long-poll until') and resource ('a matching message'). It also adds scope details (defaults to broadcast/addressed messages, excluding own) that help distinguish it from siblings like bus_read or bus_history, though it does not explicitly name alternatives.
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 implies when to use the tool: when you need to wait for a message rather than immediately read existing ones. However, it provides no explicit guidance on when not to use it or which sibling tool to use instead, so usage context is only partially addressed.
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 must fully disclose behavioral traits. It only says 'close' and 'record outcome,' but fails to mention prerequisites (e.g., an active session), side effects, or potential errors. This limited information is insufficient for a state-changing operation.
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, concise sentence that is easy to parse and contains no superfluous content. It earns its place by stating the key action and its 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?
For a tool with one parameter, no output schema, and no annotations, the description covers the basic action but misses important context like required preconditions, error handling, or what happens if no session is active. It is adequate for a simple tool but not fully comprehensive.
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 schema has one required parameter, 'outcome,' with zero description coverage. The description's phrase 'record its outcome' provides some context linking the parameter to the tool's purpose, but it does not clarify valid values, semantics, or format. This adds minimal value 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 states a specific verb ('Close') and resource ('the active audit session'), clearly distinguishing it from siblings like bus_open and bus_reset. It also mentions recording the outcome, indicating the tool's main function.
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 implies usage when an audit session is active, but provides no explicit when-to-use guidance or mentions when not to use it. It does not reference alternatives or exclusions, leaving the agent to infer based on the tool name and 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?
With no annotations provided, the description carries full burden. It discloses that messages go to a shared room and explains the broadcast behavior when 'to' is empty. However, it does not reveal permissions, side effects, or return behavior, leaving gaps typical for a send operation.
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, each earning its place: the first states the core action, the second explains the critical 'to' parameter. No redundancy or fluff.
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?
For a tool with 5 parameters and no output schema, the description is under-specified. It only explains one parameter and does not touch on required content format, sender behavior, or reply_to semantics, making it incomplete for an agent to invoke correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'to' has a description in the schema). The description explains the 'to' parameter but does not add semantics for content, sender, tags, or reply_to, which remain ambiguous despite self-explanatory names.
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 uses a specific verb ('Send') and resource ('shared room'), clearly distinguishing it from sibling tools like bus_read or bus_history. The addition about 'to' addressing specific roles further clarifies its purpose.
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 the tool (when sending a message) and gives direct guidance on how to use the 'to' parameter for targeted vs broadcast sends. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
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, and the description offers minimal behavioral detail. It does not indicate whether the operation is read-only, whether it requires any prerequisites, or what the response format might be. The word 'live' hints at real-time status but does not disclose any side effects or limitations, leaving the agent without a full safety profile.
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, focused sentence that immediately conveys the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for a zero-parameter command, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no output schema, no annotations), the description adequately identifies the output content ('live roles and MCP processes'). However, it lacks details about the exact response format (e.g., text vs. structured data) or whether it returns a snapshot, which could be helpful. Still, it is mostly complete for its simplicity.
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 input schema has zero parameters, so schema coverage is trivially 100%. The description correctly implies no parameters are needed. With 0 parameters, the baseline is 4, and no additional parameter information is required.
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 states a clear action: 'Show live roles and MCP processes in the room.' It uses a specific verb ('show') and identifies a distinct resource ('live roles and MCP processes'), which clearly differentiates it from sibling tools like bus_send or bus_export. The purpose is unambiguous.
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 implies this tool is used to inspect the current state of the room, but it does not explicitly state when to use it over alternatives or mention any exclusions. There is no guidance such as 'use instead of bus_history' or 'for current status, not past events.' The usage context is implied rather than explicit.
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, the description must carry the behavioral disclosure burden. It mentions the search scope and filters, but does not confirm whether the operation is read-only, describe the return format, or discuss any side effects or permissions. This is a moderate disclosure for a search 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?
The description is a single, well-structured sentence that front-loads the action and resource. It is concise, with no redundant words or filler, making it easy 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?
The description covers the core search functionality and major parameters, but it does not indicate the return value or output structure, and there is no output schema to compensate. Given the tool has 5 parameters and no annotations, additional context about results and expected behavior would make it more 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?
The description semantically maps 'text' to query, 'sender' to from_sender, 'tag' to tags, and 'archives' to include_archives, substantially adding meaning to the schema which has 0% description coverage. The 'limit' parameter is not mentioned, but its purpose is reasonably inferable.
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 searches the room and optionally its archives, filtering by text, sender, or tag. This specific verb and resource, along with the filter options, distinguishes it from sibling tools like bus_send, bus_read, and bus_history.
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 gives clear context that this tool is for searching, as opposed to sending, reading, or managing the room. It mentions optional archives and filter types, but does not explicitly exclude alternatives or name 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.
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 the output format (Markdown), scope (every message since session opened), and the nuance of 'current or last'. It implies a non-destructive export, though it does not explicitly state read-only behavior.
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?
A single, well-structured sentence that is front-loaded with the action and purpose. Every phrase adds value, making it concise and easy to parse.
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?
With no params and no output schema, the description fully covers the tool's purpose, scope, and output format. It is complete for a low-complexity tool, and even mentions the Markdown format as a bonus.
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, so the description needs no parameter details. Baseline for 0 params is 4, and the description adds no irrelevant 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 verb 'Export' and the resource 'audit session', specifying the output as a 'Markdown review record'. This distinguishes it from sibling tools like bus_search, bus_open, etc., which perform different operations.
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 implies usage when needing a record of the audit session, covering 'current or last' session. It provides clear context but does not explicitly name alternatives or exclusions relative to sibling tools.
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:

[![desktop-agent-bus MCP server](https://glama.ai/mcp/servers/hemajack57-collab/desktop-agent-bus/badges/card.svg)](https://glama.ai/mcp/servers/hemajack57-collab/desktop-agent-bus)

Score Badge

Copy to your README.md:

[![desktop-agent-bus MCP server](https://glama.ai/mcp/servers/hemajack57-collab/desktop-agent-bus/badges/score.svg)](https://glama.ai/mcp/servers/hemajack57-collab/desktop-agent-bus)

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/hemajack57-collab/desktop-agent-bus'

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