Provides tools for managing Apache Pulsar topics, publishing and consuming messages, and managing connectors.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Pulsar MCP Server Publish 'Hello' to topic 'greetings'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for Apache Pulsar that provides tools to interact with Pulsar clusters through MCP-compatible clients.
Publish Messages: Send messages to Pulsar topics with optional properties
Consume Messages: Receive messages from topics with configurable subscription settings
Topic Management: Create, delete, and list topics
Topic Statistics: Get detailed statistics and metadata about topics
Connector Management: List, get status, and configuration of Pulsar IO connectors
Flexible Configuration: Environment-based configuration with sensible defaults
Related MCP server: Kafka MCP Server
Clone the repository:
git clone <repository-url>
cd pulsar-mcp-serverInstall dependencies:
pip install -r requirements.txtInstall the package in development mode:
pip install -e .pip install pulsar-mcp-serverAfter installation, you can run the server using:
pulsar-mcp-serverThe server will start and listen for MCP requests via stdio.
from pulsar_mcp_server import main
# Run the server
main()In your ~/.cursor/mcp.json file, add the following:
"pulsar": {
"command": "pulsar-mcp-server",
"env": {
"PULSAR_SERVICE_URL": "pulsar://localhost:6650",
"PULSAR_WEB_SERVICE_URL": "http://localhost:8080"
}
}The server can be configured using environment variables or a .env file:
# Pulsar connection settings
PULSAR_SERVICE_URL=pulsar://localhost:6650
PULSAR_WEB_SERVICE_URL=http://localhost:8080
# Topic and subscription settings
TOPIC_NAME=my-topic
SUBSCRIPTION_NAME=pulsar-mcp-subscription
SUBSCRIPTION_TYPE=Shared
IS_TOPIC_READ_FROM_BEGINNING=false
# Authentication (optional)
PULSAR_TOKEN=your-jwt-token
PULSAR_TLS_TRUST_CERTS_FILE_PATH=/path/to/certs
PULSAR_TLS_ALLOW_INSECURE_CONNECTION=falsePublish a message to a Pulsar topic.
Parameters:
topic (string, required): The Pulsar topic to publish to
message (string, required): The message content to publish
properties (object, optional): Message properties as key-value pairs
Consume messages from a Pulsar topic.
Parameters:
topic (string, required): The Pulsar topic to consume from
subscription_name (string, required): The subscription name
max_messages (integer, optional): Maximum number of messages to consume (default: 10)
Create a new Pulsar topic.
Parameters:
topic (string, required): Name of the topic to create
partitions (integer, optional): Number of partitions (default: 1)
Delete an existing Pulsar topic.
Parameters:
topic (string, required): Name of the topic to delete
List all topics in the Pulsar cluster.
Parameters: None
Get statistics and metadata about a topic.
Parameters:
topic (string, required): Name of the topic to get stats for
List all connectors of a specified type (source or sink).
Parameters:
connector_type (string, optional): Type of connectors to list ("source" or "sink", default: "source")
Get the status of a specific connector.
Parameters:
connector_name (string, required): Name of the connector to get status for
Get the configuration of a specific connector.
Parameters:
connector_name (string, required): Name of the connector to get configuration for
Get all connectors organized by type (source and sink).
Parameters: None
pulsar-mcp-server/
├── src/
│ └── pulsar_mcp_server/
│ ├── __init__.py # Package entry point
│ ├── server.py # MCP server implementation
│ ├── pulsar_connector.py # Pulsar client wrapper
│ └── settings.py # Configuration settings
├── pyproject.toml # Project configuration
├── requirements.txt # Dependencies
├── test_server.py # Test script
└── README.md # This fileRun the test script to verify the server functionality:
python test_server.pyYou can also run Pulsar locally using Docker for testing:
# Start Pulsar standalone
docker run -it -p 6650:6650 -p 8080:8080 apachepulsar/pulsar:latest bin/pulsar standalonePython 3.12+
Apache Pulsar cluster (local or remote)
MCP-compatible client
mcp>=1.1.0,<2.0: Model Context Protocol library
pulsar-client>=3.4.0: Apache Pulsar Python client
pydantic>=2.10.3: Data validation and settings management
pydantic-settings>=2.6.1: Settings management for Pydantic
MIT License
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
For issues and questions, please open an issue on the GitHub repository.
Get all connectors organized by type (source and sink)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 fails to disclose authentication needs, rate limits, or what 'all' includes (e.g., system connectors). The description adds minimal value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Every word is necessary and clear. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could detail the return structure (e.g., how connectors are organized). It mentions organization by type but omits specifics like fields or pagination. Adequate for a simple list but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description inherently covers parameter semantics. With zero parameters, a baseline of 4 is appropriate; the description could mention that no input is needed, but it's not required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), the resource (all connectors), and the organization by type (source and sink). It distinguishes from the sibling 'pulsar_list_connectors' by implying a grouped output, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'pulsar_list_connectors'. The description implies a use case (getting connectors organized by type) but does not provide conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the configuration of a specific connector
| Name | Required | Description | Default |
|---|---|---|---|
| connector_name | Yes | Name of the connector to get configuration for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states 'Get' implying read-only, but offers no detail on authentication, rate limits, error handling, or behavior when the connector does not exist. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant words. Every word serves to define the tool's action and resource, achieving maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and no annotations, the description is too brief. It omits details about what the configuration includes, return format, and error cases. This leaves agents with incomplete information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (connector_name) described. The description adds no additional meaning beyond the schema; it simply echoes the schema's purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'configuration of a specific connector', clearly indicating the tool's purpose. It distinguishes from siblings like pulsar_connector_status (status) and pulsar_list_connectors (list all connectors).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving connector configuration but provides no explicit guidance on when to use this tool versus alternatives like pulsar_connector_status or pulsar_list_connectors. No exclusion criteria or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of a specific connector
| Name | Required | Description | Default |
|---|---|---|---|
| connector_name | Yes | Name of the connector to get status for |
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 only states 'Get the status' implying a read operation, but does not disclose any behavioral traits such as side effects, caching behavior, or required permissions. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status check tool with one parameter and no output schema, the description is adequate but not complete. It does not describe the output format or what 'status' contains, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter already documented. The description adds no extra meaning beyond what the schema provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'status of a specific connector', clearly distinguishing it from sibling tools like pulsar_connector_config (gets config) and pulsar_list_connectors (lists connectors). It avoids tautology by not merely repeating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it specify prerequisites or exclusions. It simply states what it does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consume messages from a Pulsar topic
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The Pulsar topic to consume from | |
| max_messages | No | Maximum number of messages to consume | |
| subscription_name | Yes | The subscription name for consuming messages |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose important behavioral traits such as whether messages are acknowledged, if consumption is blocking/non-blocking, or any side effects on the subscription. For a consume operation, these details are critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no waste. However, it could be improved by front-loading key details such as blocking behavior or subscription durability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the high schema coverage, the description lacks completeness for a consumption tool. There is no output schema, and the description does not explain return values (e.g., message contents), termination conditions, or error scenarios. It is insufficient for an agent to fully understand tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already explains each parameter. The tool description 'Consume messages from a Pulsar topic' adds no additional meaning beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Consume messages from a Pulsar topic' clearly states the verb 'consume' and the resource 'messages from a Pulsar topic'. It effectively distinguishes from sibling tools like pulsar_publish and pulsar_create_topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when to use pulsar_publish instead). It lacks context about prerequisites or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Pulsar topic
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Name of the topic to create | |
| partitions | No | Number of partitions to allocate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it fails to mention idempotency, error behavior, or permissions. It only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at 4 words, front-loaded with the key purpose. While it could include more detail, it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, the description lacks crucial context such as idempotency and error handling, making it incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (Pulsar topic), distinguishing it from sibling tools like pulsar_delete_topic and pulsar_list_topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions for creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing Pulsar topic
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Name of the topic to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behaviors. Only states it deletes; lacks details on irreversibility, permission requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Efficient but could be front-loaded with more context. Still good for length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple destruction tool, but lacks context on consequences. Given no output schema and one parameter, it meets minimum viability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description adds no extra meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete an existing Pulsar topic', with specific verb and resource. It distinguishes from siblings like pulsar_create_topic and pulsar_list_topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or when not to use. Does not mention prerequisites, such as ensuring the topic exists, or alternatives like checking topic stats first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all connectors of specified type (source or sink)
| Name | Required | Description | Default |
|---|---|---|---|
| connector_type | No | Type of connectors to list | source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The verb 'list' implies a read-only, non-destructive operation, which is appropriate for a listing tool. No behavioral traits beyond the stated action are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence of 8 words that is front-loaded and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 param, no output schema), the description adequately covers what the tool does. It could optionally hint at the return format, but the agent can infer from the context and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter intent is fully captured. The description adds no extra meaning beyond what the schema already provides ('Type of connectors to list' with enum values).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all connectors of specified type (source or sink)' clearly states the action (list), resource (connectors), and filter (type). It distinguishes from the sibling tool pulsar_all_connectors, which lists all connectors without type filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to list connectors of a specific type, but it does not explicitly mention when to use the alternative pulsar_all_connectors or provide any when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all topics in the Pulsar cluster
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as read-only nature, pagination, rate limits, or response format. The description is minimal and does not add value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function with no extraneous words. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally adequate for a simple tool with no parameters, but it lacks details about what information is returned (e.g., full topic names, URI format) and whether it lists topics globally or within a specific namespace. More context would aid an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage, the description does not need to explain parameters. Baseline score of 4 is appropriate, though the description could mention that no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and resource 'topics', clearly distinguishing from sibling tools like pulsar_create_topic and pulsar_delete_topic. However, it essentially restates the tool's name without additional scope or clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or context such as namespace or cluster specifics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a message to a Pulsar topic
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The Pulsar topic to publish to | |
| message | Yes | The message content to publish | |
| properties | No | Optional message properties as key-value pairs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states the basic function without revealing idempotency, error handling, or side effects. Does not mention required permissions or message delivery guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but lacks structure. It is not overly verbose, yet sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 parameters including a nested object, the description fails to explain return values, error conditions, or usage nuances. For a publish tool, critical information like whether a message ID is returned is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds no additional meaning beyond the schema, achieving the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('publish a message') and the resource ('Pulsar topic'), effectively distinguishing from siblings like pulsar_consume. The verb-noun combination is 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., pulsar_consume), no prerequisites mentioned, and no conditions for appropriate use. The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics and metadata about a topic
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Name of the topic to get stats for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get statistics and metadata' without indicating read-only nature, error behavior (e.g., if topic does not exist), or any side effects. For a tool with zero annotations, this level of detail is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action. It is efficient with no wasted words, but could incorporate brief usage notes without losing conciseness. Still, it earns a 4 for being appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description should provide a richer picture of what 'statistics and metadata' means (e.g., throughput, partitions) and any prerequisites. The current description leaves an agent with incomplete information to decide correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single parameter 'topic' is fully described in the schema). The description adds no additional meaning beyond what the schema provides ('Name of the topic to get stats for'). Baseline 3 is appropriate as the schema already documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('statistics and metadata about a topic'), clearly distinguishing it from sibling tools like pulsar_list_topics (list topics) or pulsar_consume (consume messages). No ambiguity remains about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for inspecting topic stats, but does not mention exclusion cases (e.g., when to use pulsar_list_topics instead). Usage context is implied by the tool name and description, but not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0pulsar_all_connectorspulsar_connector_configpulsar_connector_statuspulsar_consumepulsar_create_topicpulsar_delete_topicpulsar_list_connectorspulsar_list_topicspulsar_publishpulsar_topic_statsScored across 10 tools
All tools have clearly distinct purposes. The slight overlap between 'pulsar_all_connectors' and 'pulsar_list_connectors' is resolved by descriptions: one returns all connectors organized by type, the other lists connectors of a specified type.
All tool names follow the consistent pattern 'pulsar_<verb>_<noun>' (e.g., create_topic, list_connectors). The naming is uniform and predictable, aiding agent selection.
With 10 tools, the server is well-scoped for a Pulsar cluster management interface. Each tool serves a necessary function without redundancy.
The tool set covers core topic operations (CRUD, publish, consume, stats) and connector inspection. However, it lacks connector creation/deletion, which may be needed for full lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Connect MCP clients to 2,000+ AI models without managing provider API keys.
One MCP URL for all your connectors — scoped writes, enforced constraints, and a full audit trail.
Authenticated MCP server for ClearPolicy policy and compliance workflows.
