Azure Service Bus MCP Server

Server Quality Checklist

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

Latest release: v0.2.6
Disambiguation5/5
Every tool has a clearly distinct purpose, indicated by the combination of verb (list, peek, purge, requeue, send) and object (namespace, queue, topic, dlq, subscription). Even the file variants are explicitly differentiated for handling large payloads.
Naming Consistency5/5
All tools follow a consistent 'servicebus_<verb>_<object>' pattern using snake_case. The verbs and objects are uniform, making the tool set predictable and easy to navigate.
Tool Count5/5
With 19 tools, the server covers the essential operations for monitoring, debugging, and message remediation in Azure Service Bus. The count is well-scoped for its purpose without being excessive or overly sparse.
Completeness3/5
While the tool set is strong for message-level operations (peek, purge, requeue, send), it lacks management capabilities such as creating, deleting, or updating queues, topics, and subscriptions. This leaves a significant gap for full lifecycle management of Service Bus entities.
Average 4.1/5 across 19 of 19 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and warns of destructive, unrecoverable behavior and the max_messages cutoff. It adds value by stating the stop condition, though it omits permissions or rate limits.
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 concise with three sentences, each providing essential information: action, destructive warning, and stop behavior. No unnecessary words.
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?
While it covers core behavior and destructiveness, it lacks usage guidelines, parameter details, and return value information. For a destructive tool with no annotations, more completeness is expected.
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 explain parameters. It only indirectly explains max_messages via the stop condition; namespace and queue remain undefined. The output schema exists but is not referenced.
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 deletes all messages from a dead letter queue, matching the name and distinguishing it from sibling tools like servicebus_purge_queue. The resource (DLQ) and action (delete) are specific.
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 on when to use this tool versus alternatives like requeue_dlq or peek_dlq. The description only implies its use for permanent deletion but doesn't mention context or exclusions.
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?
Discloses auth requirements and scheduling behavior, but does not mention error scenarios (e.g., queue not found), message size limits, or return value. No annotations provided, so description carries full burden but is incomplete.
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?
Four sentences with clear front-loading. No redundant information, but could be slightly more concise.
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 7 parameters and no annotations, the description is incomplete. It lacks details on most parameters, error handling, and success/failure behavior. Output schema exists but its contents are not used to supplement description.
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?
Only 2 of 7 parameters are described in the text (namespace and scheduled_enqueue_time). Critical parameters like body, session_id, correlation_id, and application_properties are not explained. With 0% schema coverage, the description should cover more.
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 sends a single message to an Azure Service Bus queue or topic, distinguishing it from sibling tools like servicebus_send_batch and the peek/purge/requeue tools.
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?
Provides guidance on namespace format (short name vs FQDN), scheduled_enqueue_time format (ISO 8601), and authentication (DefaultAzureCredential, need 'az login'). Could be improved by explicitly stating when to use versus servicebus_send_batch.
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?
With no annotations provided, the description carries the full burden. It clearly states the destructive nature, irreversibility, and the behavior of stopping when max_messages is exceeded, disclosing key behavioral traits beyond the basic operation.
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 short with two sentences and a bold warning line, front-loading the critical destructive aspect. It is concise but could include brief parameter explanations without adding fluff.
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, 4 parameters with zero schema descriptions, the description partially completes the picture by explaining destructiveness and max_messages behavior. However, it omits explanations for three required parameters, leaving gaps in context.
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 0%, so the description must compensate. It explains the role of max_messages ('stops... if running total exceeds max_messages'), but fails to describe namespace, topic, and subscription, which are required and lack schema descriptions.
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 explicitly states 'Delete all messages from the dead letter queue for a topic subscription,' providing a specific verb and resource, clearly distinguishing it from sibling tools like servicebus_purge_subscription (purges main queue) and servicebus_peek_subscription_dlq (peeks).
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 warns of destructiveness and mentions the max_messages limit, providing context for when it might be used, but does not explicitly guide when to use versus alternatives like servicebus_peek_subscription_dlq or servicebus_requeue_subscription_dlq.
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 carries the full burden. It clearly states the destructive action and the partial purging behavior. However, it does not disclose other important behaviors like required permissions, rate limits, or whether the queue metadata is affected. The disclosure is adequate but not comprehensive.
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: three lines. It front-loads the purpose, then a warning, then the behavior detail. No redundant information; every sentence earns its place.
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 lack of annotations and the tool's destructive nature, the description should cover prerequisites, permissions, and response format. It mentions the partial purge behavior but omits what the tool returns (e.g., count of deleted messages) and any preconditions. It is somewhat incomplete for an AI agent to confidently select and invoke the tool.
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 0%, meaning no parameter descriptions in the schema. The description only explains `max_messages` behavior. The required parameters `namespace` and `queue` are not described beyond their names, which are somewhat self-explanatory but could benefit from more context (e.g., format, restrictions). The output is not explained despite an output schema being present.
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 'Delete all messages from an Azure Service Bus queue.' It uses a specific verb (delete) and resource (messages on a queue), distinguishing it from sibling tools like `servicebus_purge_dlq` (dead-letter queue) and `servicebus_purge_subscription` (subscription).
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 warns about the destructive nature and mentions the max_messages behavior: 'Stops and leaves remaining messages untouched if the running total exceeds max_messages.' This guides the agent on when to use the tool (full purge) and the effect of the max_messages parameter. However, it does not mention when not to use it or suggest alternative tools like fetching messages first.
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?
With no annotations, the description provides useful behavioral info: 'non-destructively', saving bodies to file as JSON, and returning only metadata. However, it does not mention file overwrite behavior, rate limits, or authentication needs. Overall, sufficiently transparent.
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 concise sentences: first defines purpose and non-destructive nature, second explains file format and returned metadata. No redundant information, perfectly front-loaded.
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 4 parameters and an output schema, the description covers the core functionality and return values. It lacks details on max_count and output_file format (JSON keyed by sequence number is mentioned). Output schema likely covers return values, so overall adequate but leaves some parameter specifics unaddressed.
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 has 0% description coverage, so description must compensate. It explains output_file's role and mentions max_count implicitly via default, but namespace and queue are not described beyond the tool name. Partial compensation, but insufficient for full parameter understanding.
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 peeks at dead letter queue messages non-destructively and saves bodies to a file, distinguishing it from siblings like servicebus_peek_dlq (no file) and servicebus_peek_messages_to_file (regular queue).
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 examining DLQ messages and saving bodies, but does not explicitly state when to use this tool versus alternatives like servicebus_peek_dlq (no file) or servicebus_peek_messages_to_file (regular queue). No direct when-not or alternative guidance.
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?
The description details that messages are re-sent preserving body, session_id, correlation_id, and application_properties, then completed from the DLQ. It also notes the stopping condition for max_messages. With no annotations, this provides good behavioral insight, though it lacks error handling or idempotency details.
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 long, each adding essential information: purpose, preserved fields, and stopping condition. No redundant or extraneous content.
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 complexity of requeueing from DLQ and the presence of an output schema, the description covers the main behavior. However, it misses notes on error handling or idempotency. Still, it is fairly complete for this type of tool.
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 0%, but the description only explains 'max_messages' (stopping condition). 'namespace' and 'queue' are not described individually, leaving ambiguity. The description does not compensate for the low coverage.
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: 'Move messages from a queue's dead letter queue back to the main queue.' It uses a specific verb ('Move') and distinct resource ('dead letter queue'), and distinguishes from siblings like 'purge_dlq' or 'peek_dlq'.
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 requeueing DLQ messages but does not explicitly state when to use this tool versus alternatives like 'purge_dlq' or 'peek_dlq'. No exclusions or when-not-to-use guidance 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 fully disclose behavioral traits. It mentions batch delivery in a single operation and details message structure, but omits critical information like atomicity (whether the entire batch succeeds or fails), error handling, idempotency, or rate limits. This gap leaves the agent uncertain about important behavioral aspects.
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 very concise, leading with the main purpose and then listing message fields in a clear bullet-like format. No extraneous information, every sentence adds value.
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 presence of an output schema (not shown), the description need not detail return values. It covers the required parameters partially but misses behavioral aspects like atomicity. For a batch send tool, the description 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description adds significant value by detailing the structure of the 'messages' parameter, including required 'body' and optional fields. However, it does not explain 'namespace' or 'queue', relying on context from sibling tools. Overall, strong for the key parameter.
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 sends multiple messages in a single batch to an Azure Service Bus queue or topic. It uses a specific verb (send) and resource (multiple messages) and distinguishes itself from the sibling tool servicebus_send_message, which sends a single message.
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 indicates the tool is for sending multiple messages in a single operation and is useful for seeding test data. It implicitly differentiates from sending individual messages, but lacks explicit when-not-to-use or alternative guidance.
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, but description discloses non-destructive read, file output format (JSON keyed by sequence number), and that only metadata is returned. Could mention file overwrite behavior or permissions, but covers main traits.
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, front-loaded with purpose and key details, no extraneous 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?
Covers purpose, action, and output. With output schema present, return values not needed. Missing file overwrite and error handling details, but sufficient for a peek tool.
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?
0% schema coverage, but description adds meaning for output_file (write as JSON) and implies max_count limits peek count. Other parameter names are self-explanatory, but no further details 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?
Description clearly states the tool peeks non-destructively at subscription dead letter queue messages and saves bodies to a file, distinguishing it from siblings like servicebus_peek_subscription_dlq (no file) and servicebus_peek_dlq_to_file (queue DLQ).
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?
Implied usage for inspecting subscription DLQ and saving bodies, but no explicit guidance on when not to use or alternatives beyond what sibling names suggest.
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 carries the full burden. It discloses non-destructive nature, file writing, and session behavior. However, it omits details like file overwrite policy, error handling, and any rate limits, leaving some behavioral aspects unclear.
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 concise, with two short paragraphs that front-load the core purpose. Every sentence adds value without redundancy or fluff.
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 moderate complexity and presence of an output schema, the description covers the essential aspects: non-destructive peek, file saving, and session handling. It could mention that the output file is JSON, but overall it is sufficiently complete 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 coverage is 0%, so the description must compensate. It explains output_file (saves bodies as JSON), max_count (peek count default 10), and session_id (optional, with session-release behavior). However, it does not describe namespace, topic, or subscription beyond their names, which are needed for full clarity.
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 peeks at messages non-destructively from an Azure Service Bus topic subscription and saves bodies to a file. It distinguishes itself from sibling tools like servicebus_peek_subscription_messages by highlighting the file-saving behavior, making the purpose 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this variant (when message bodies may be large to avoid filling context window) and covers session handling. It lacks explicit when-not-to-use guidance but provides sufficient context for appropriate selection among siblings.
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 provided, so description carries full burden. It discloses that messages preserve body, session_id, correlation_id, and application_properties, are completed (removed) after requeue, and stops if max_messages is exceeded. This covers key behavioral traits.
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: the first states the core action, the second provides behavioral details. No filler, efficiently front-loaded.
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 an output schema exists (not shown), the description covers the tool's function and safety behavior (max_messages guard, message preservation). It omits return value details but that is handled by the output schema. No prerequisites mentioned, but that may be assumed.
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 0%, so description must compensate. It explains max_messages as the stop condition and implies namespace, topic, subscription are identifiers via 'topic subscription's dead letter queue'. However, it does not describe valid values or format for the required parameters.
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: 'Move messages from a topic subscription's dead letter queue back to the topic.' It specifies the resource (topic subscription DLQ) and the verb (requeue). This distinguishes it from siblings like servicebus_requeue_dlq (for queue DLQ) and others.
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?
No explicit guidance on when to use this tool versus alternatives like servicebus_peek_subscription_dlq or servicebus_purge_subscription_dlq. The description implies usage for reprocessing dead-lettered messages but does not provide exclusions or context for choosing 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?
With no annotations provided, the description carries full burden. It discloses the read-only nature, what is returned (message bodies, dead letter reason, metadata), and the max_count cap of 100. This is sufficient for a peek operation, though it does not cover rate limits or empty queue 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?
The description is concise with four sentences, each adding distinct value: operation type, read-only nature, return data, cap, and alternative tool. 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 presence of an output schema (though not shown) and clear description of return data, the description is adequately complete for a peek tool. It covers the key behavioral aspects and constraints without needing to detail the output schema.
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?
Input schema has 0% description coverage. The description only adds context for max_count ('capped at 100') but does not elaborate on namespace, topic, subscription, or the default value. Without schema descriptions, the description should provide more parameter guidance.
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 'Non-destructively peek at messages in the dead letter queue for a topic subscription' with specific verb (peek) and resource (DLQ for subscription). It distinguishes from sibling 'servicebus_peek_subscription_dlq_to_file' by suggesting that alternative for large message bodies.
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?
It explicitly says 'non-destructively' and 'read-only' to indicate when to use, and suggests using 'servicebus_peek_subscription_dlq_to_file' for large bodies as an exclusion criterion. However, it does not contrast with other siblings like purge or requeue, leaving some ambiguity.
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?
With no annotations provided, the description must convey behavioral traits. It clearly labels the operation as destructive and explains that purging stops if max_messages is exceeded. It does not cover authorization or rate limits, but the core behavioral info is present.
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: purpose, destructive warning, and behavior limit. No extraneous words, and critical information is front-loaded.
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 complexity (destructive, 4 parameters) and lack of annotations, the description covers the essential aspects: what it does, that it's destructive, and the safety limit. It omits potential error conditions or prerequisites, but an output schema exists to clarify return values.
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?
The input schema has 0% coverage (no parameter descriptions). The description only adds meaning for `max_messages` via the stop condition. For `namespace`, `topic`, and `subscription`, no extra guidance is given, so the agent must infer their roles from the tool name alone.
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 'Delete all messages from an Azure Service Bus topic subscription.' This is a specific verb ('delete') and resource ('messages from a topic subscription'), and it distinguishes itself from sibling purge tools like `servicebus_purge_queue` and `servicebus_purge_dlq` by targeting a subscription.
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 a strong warning about destructiveness ('messages cannot be recovered') and explains the stop behavior when max_messages is exceeded. However, it does not explicitly compare with sibling purge tools (e.g., when to use purge_dlq instead), leaving some ambiguity for the agent.
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?
With no annotations, the description provides valuable behavioral details: returns a sorted JSON array or map with subscriptions, and explains namespace handling (short name vs. FQDN, auto-appending suffix). This goes beyond the bare minimum.
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?
Concise and well-structured: the main action is front-loaded, followed by return format details and a parameter note. No wasted words. Appropriate length for the tool's complexity.
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 the output schema exists, the description covers both parameters adequately and explains return behavior. The agent has all necessary information to invoke the tool correctly.
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 0%, but the description explains both parameters: namespace format (short name or FQDN) and include_subscriptions effect (returns mapping of topic to subscriptions). This compensates for missing schema descriptions.
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?
Clearly states 'List all topics in an Azure Service Bus namespace.' The verb 'list' and resource 'topics' are specific, distinguishing it from siblings like servicebus_list_queues and servicebus_list_namespaces.
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?
Implies what the tool does, but does not explicitly guide when to use it versus siblings like servicebus_list_queues or servicebus_list_namespaces. The description focuses on functionality rather than usage context.
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 provided, so the description carries full burden. It accurately describes the read-only, non-locking nature and lists return values (message bodies, dead letter reason, metadata). However, it does not mention permissions or error conditions.
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 4 sentences, each adding essential information: purpose, non-destructive nature, return values, cap, and sibling alternative. 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 presence of an output schema and the simplicity of the tool, the description covers return values and key constraints. It also points to an alternative for large bodies. Minor gaps like authentication or error handling exist but are acceptable.
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 0%, but the description adds value by noting the max_count cap. Namespace and queue are self-explanatory for the domain, so no further elaboration is critical.
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 (peek), resource (dead letter queue), and scope (for a Service Bus queue), distinguishing it from siblings like servicebus_peek_messages and servicebus_peek_subscription_dlq.
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?
Explicitly declares the operation as read-only and non-destructive, and provides a clear alternative (servicebus_peek_dlq_to_file) for large message bodies. Also mentions the max_count cap of 100.
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 provided, so description covers read-only nature, max_count cap, session behavior, and return of bodies/metadata. Could mention rate limits or pricing implications, but sufficient.
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?
Five concise sentences front-load the purpose, with no redundant information. Every sentence adds value.
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 complexity, description covers key aspects: read-only operation, parameter constraints, session handling, and alternative tool. Output schema exists but specifics of return values are briefly mentioned.
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 0%, but description compensates for max_count (capped at 100) and session_id (optional, explained). Namespace and queue are required but not further described beyond 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 it peeks at messages non-destructively, and distinguishes from siblings like servicebus_peek_messages_to_file by noting when to use the alternative.
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?
Explicitly states it is read-only, non-destructive, and advises using servicebus_peek_messages_to_file for large messages. Session handling behavior is also explained.
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 provided, so the description carries full burden. It discloses listing behavior, subscription resolution, and error conditions. Adequate for a simple read-only tool with output schema.
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, front-loaded with purpose, then essential context. No wasted words.
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 parameters and an output schema present, the description covers everything needed: purpose, subscription resolution, error handling. Complete for its complexity.
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?
No parameters exist, so baseline is 4. The description correctly implies no additional inputs are needed.
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 tool name and description clearly state it lists all Service Bus namespaces. The verb 'List' and resource 'namespaces' are specific and distinct from sibling tools that list queues, topics, etc.
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 on subscription resolution (env var then az login) and error handling, but no explicit when-not or alternatives are given. Siblings exist but not mentioned.
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?
With no annotations, the description discloses the return format (sorted JSON array) and namespace flexibility. It does not cover error conditions or limitations, but for a simple list operation, this is sufficient.
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 focused sentences, front-loaded with the main action, no redundancy. Every word adds value.
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 has an output schema, the description covers parameter usage and return format well. It lacks mention of prerequisites or permissions, but these are common for such operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the namespace parameter. The description adds critical context: acceptable formats and auto-suffix behavior, greatly aiding correct invocation.
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 lists all queues in a namespace and returns a sorted JSON array. It distinguishes itself from siblings like servicebus_list_topics.
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 guidance on how to specify the namespace (short name or FQDN) and mentions auto-appending suffix. While it doesn't explicitly state when not to use or compare to siblings, the 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?
Describes key behaviors: non-destructive peek, writing bodies to file, returning only metadata in context, session handling (accept and release). No annotations provided, so description carries full burden. Missing details like error handling or file overwrite behavior, but covers primary traits well.
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?
Description is 6 sentences, front-loaded with the primary action and key differentiator. No redundant or unnecessary information. Each sentence adds value.
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 5 parameters, no annotations, and presence of an output schema (though not detailed), the description covers the tool's purpose, usage context, and key behaviors. Could mention output file format in more detail or potential file size implications, but sufficient for effective use.
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 0%, so description adds meaning. Explains output_file usage (writes bodies as JSON keyed by sequence number) and session_id behavior. However, namespace and queue parameters are not elaborated beyond their names, but their purpose is self-explanatory given tool 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?
Description clearly states the tool peeks non-destructively at messages and saves bodies to a file, distinguishing it from the sibling servicebus_peek_messages which does not save to file. It specifies the action, resource, and key differentiator (large message bodies).
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?
Explicitly states when to use this variant (when message bodies may be large to avoid filling context window). Provides guidance for session-enabled queues: either provide session_id for a specific session or omit to accept the next available session, which is then released.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: it's read-only, non-destructive, returns message bodies and metadata, caps max_count at 100, and details session handling (peeking a specific session or automatically accepting the next available one). No behavioral gaps remain.
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 concise, with front-loaded purpose and structured bullet points for behavioral details. Every sentence adds value without redundancy.
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 the tool's complexity (sessions, capping, alternative tool), the description covers all needed context: read-only nature, return information, limits, session behavior, and when to use a sibling. Output schema exists, so return values are not required.
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 0%, so description must add meaning. It explains max_count (default 10, capped 100) and session_id (sessions, optional, auto-accept if omitted). However, it does not elaborate on namespace, topic, or subscription beyond their names, leaving some parameters minimally described.
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 peeks non-destructively at messages in a subscription, using specific verbs ('peek', 'non-destructively'). It distinguishes from siblings like servicebus_peek_subscription_messages_to_file by noting when to use the alternative for large bodies.
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?
It explicitly guides when to use this tool (for peeking) and when to use an alternative (servicebus_peek_subscription_messages_to_file for large messages). Session behavior is clearly explained, providing comprehensive usage context.
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:

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

Score Badge

Copy to your README.md:

[![servicebus-mcp MCP server](https://glama.ai/mcp/servers/BrianDeacon/servicebus-mcp/badges/score.svg)](https://glama.ai/mcp/servers/BrianDeacon/servicebus-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/BrianDeacon/servicebus-mcp'

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