BasicDeploy MCP Server

Overview Schema Source Related Servers Score Discussions Admin

get_kafka

Read-only

Retrieve Kafka connection details: internal and external bootstraps, SASL credentials, consumer-group prefix, current topics, and usage limits. Provisions tenancy on first call.

Instructions

Get the user's Kafka connection details and topics. BasicDeploy gives every account a Kafka broker (SASL/SCRAM, SCRAM-SHA-256) shared by all their containers. Returns the internal bootstrap (preset as KAFKA_BOOTSTRAP inside containers), the external bootstrap (for outside clients), the SASL username/password, the mandatory consumer-group id prefix (group ids MUST start with it), the current topics, usage and the plan limits. Provisions the tenancy on first call.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`limits`	No
`topics`	No
`enabled`	Yes	Whether Kafka is available on this deployment.
`password`	No	SASL/SCRAM password.
`username`	No	SASL/SCRAM username.
`bootstrap`	No	In-container bootstrap (preset as KAFKA_BOOTSTRAP).
`usedBytes`	No	Reserved storage used across topics.
`groupPrefix`	No	Required prefix for topic and consumer-group ids.
`saslMechanism`	No
`securityProtocol`	No
`externalBootstrap`	No	Public bootstrap for outside clients.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.3Sep 8, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond the readOnlyHint and destructiveHint annotations: it discloses the first-call provisioning side effect, the shared-broker model, SASL/SCRAM authentication, and the mandatory consumer-group prefix. This is strong transparency, and while the provisioning note creates mild tension with readOnlyHint, it is framed as a one-time setup rather than a mutation of user data.

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 compact and front-loaded: the purpose appears in the opening phrase, followed by the critical return fields and the provisioning caveat. Every clause adds information an agent needs, with no filler or repetition.

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?

For a parameterless, read-oriented getter with an output schema present, the description covers what is returned, the authentication model, the consumer-group constraint, usage limits, and the only side effect. Nothing an agent needs to understand before invoking is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so there is nothing for the description to explain. The baseline for a parameterless tool is 4; the description appropriately focuses on what the call returns and the constraints on using the returned values.

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 a specific verb and resource: retrieves the user's Kafka connection details and topics. It enumerates the exact return contents and is immediately distinguishable from sibling tools such as get_account or the topic-management tools.

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?

It is clear from context that this tool is for fetching Kafka broker/auth/topic information, so an agent can infer when to use it. However, it does not explicitly state when not to use it or name a sibling alternative for different Kafka needs, leaving usage guidance implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server