Provides structured access to Veeam product network port requirements via the Magic Ports API, enabling queries for ports, generation of topology diagrams, and creation of firewall rule import files for 25+ Veeam products.
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., "@veeam-ports-mcp What ports does VBR v13 need?"
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.
An MCP (Model Context Protocol) server that gives Claude structured access to Veeam product network port requirements. Query ports, generate topology diagrams, and produce firewall rule import files — all from natural language.
Backed by the Magic Ports API, covering 25+ Veeam products.
Add to your Claude Desktop config:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"veeam-ports": {
"command": "uvx",
"args": ["veeam-ports-mcp"]
}
}
}Requires uv — a single binary install. uvx downloads and runs the package automatically with no repo clone needed.
claude mcp add veeam-ports -- uvx veeam-ports-mcpgit clone https://github.com/shapedthought/veeam-ports-mcp.git
cd veeam-ports-mcp
uv syncClaude Desktop config for a local dev install:
{
"mcpServers": {
"veeam-ports": {
"command": "uv",
"args": [
"run",
"--directory", "/path/to/veeam-ports-mcp",
"veeam-ports-mcp"
]
}
}
}Related MCP server: Veeam Intelligence MCP Server
Tool | Description |
| List all Veeam products with port data |
| List available service roles for a product — call this before |
| Get all port requirements for a product |
| Get section headings for a product — use to find valid |
| Free-text keyword search across all products |
| Find which products and services use a specific port |
| Source services with their section groupings |
| Port data with LLM-parsed service metadata |
| Resolve firewall rules between named servers in your environment |
| Generate a JSON import file for the Magic Ports frontend app |
Call list_services to see available service roles for the product
Ask the user which servers they have and what roles each one serves
Call generate_topology or generate_app_import with the server definitions
Optionally exclude subsections (e.g. CDP Components) or specific ports with exclude_subsections / exclude_ports
User: "Generate firewall rules for my VBR v13 environment.
I have a VBR server, two Linux proxies, a repo, and ESXi hosts behind vCenter."
Claude: [calls list_services → generate_app_import]
"Import file saved: ~/Documents/veeam-ports-exports/magic-ports-vbr-v13-import.json"Generated files are saved to ~/Documents/veeam-ports-exports/ by default.
"What ports does VBR v13 need?"
"Which products use port 902 and why?"
"Show me all ports the backup server uses to talk to ESXi hosts"
"Generate firewall rules for my VBR environment — I have a VBR server, a Linux proxy, a repo server, and ESXi hosts managed by vCenter"
"Create a Magic Ports import file for my VB365 deployment, excluding the proxy ports"
"What ports does the Veeam ONE server need open?"
Environment Variable | Default | Description |
|
| API base URL |
|
| Directory for generated import files |
Use the MCP Inspector to test tools interactively:
npx @modelcontextprotocol/inspector uvx veeam-ports-mcpMIT
Generate a JSON file for importing into the Magic Ports frontend app.
Resolves the port mapping topology between user-defined servers using the enriched knowledge graph on the API server. The full JSON is written to a file on disk and a compact summary is returned.
Workflow:
Call list_services to see available service roles for the product.
Ask the user which servers they have and what roles they serve.
Call this tool with the server definitions.
Present the generated file to the user for download/import.
Args: product_name: Exact product name (e.g. 'VBR v13', 'VB365') servers_json: JSON array of server definitions. Each object must have 'name' (server label) and 'services' (list of service names this server provides). Example: [ {"name": "VBR", "services": ["Backup server"]}, {"name": "Proxy", "services": ["Backup proxy"]}, {"name": "Repo", "services": ["Backup repository"]}, {"name": "ESXi", "services": ["ESXi host", "vCenter Server"]} ] output_dir: Optional directory to write the file to. Defaults to ~/Documents/veeam-ports-exports or VEEAM_PORTS_OUTPUT_DIR env var. exclude_subsections: Subsection names to exclude from results (e.g. ["CDP Components"]). Accepts a list or JSON string. exclude_ports: Port numbers to exclude from results (e.g. ["33035"]). Accepts a list or JSON string. format: Output format — 'json' (default), 'csv', or 'markdown'. csv and markdown return the raw content as text (no file written).
| Name | Required | Description | Default |
|---|---|---|---|
| product_name | Yes | ||
| servers_json | Yes | ||
| output_dir | No | ||
| exclude_subsections | No | ||
| exclude_ports | No | ||
| format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses key behaviors: resolves topology using the knowledge graph, writes a file to disk, returns a compact summary, and for csv/markdown formats no file is written. It does not mention overwrite behavior or error handling, but overall provides sufficient 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 well-structured into a workflow and parameter list. Every sentence adds value: the opening states the tool's purpose, the workflow gives step-by-step guidance, and parameter descriptions are clear and actionable. No redundancy or filler.
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 tool's complexity (6 parameters, 2 required, no enums) and the presence of an output schema (indicated by context), the description adequately covers the generation process and parameter usage. It could mention the output schema or return value format slightly more, but the presence of an output schema means that information is already structured elsewhere.
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 0% description coverage, so the description must explain all parameters. It does so thoroughly: defines product_name, servers_json with a complete example, output_dir with default and env var fallback, exclude_subsections and exclude_ports with acceptable formats, and format with behavior differences. This fully compensates for the schema gap.
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 tool generates a JSON file for importing into the Magic Ports frontend app. It specifies the verb 'generate' and the resource 'app import file', and distinguishes it from sibling tools like get_enriched_ports or get_product_ports which focus on querying ports rather than producing an importable artifact.
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 a clear multi-step workflow (list services, ask user, call this tool, present file) that guides when to use this tool. While it does not explicitly state when not to use it, the context implies it is for generation after server definitions are collected, and the sibling tools provide clear alternatives for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve server topology — given named servers and their services, returns all port mappings between them as human-readable text.
Use this when the user describes their server layout and wants to know what firewall rules are needed between servers.
Args: product_name: Exact product name (e.g. 'VBR v13', 'VB365') servers_json: JSON array of server definitions. Each object must have 'name' (server label) and 'services' (list of service names this server provides). Example: [ {"name": "VBR", "services": ["Backup server"]}, {"name": "Proxy", "services": ["Backup proxy"]}, {"name": "ESXi", "services": ["ESXi host"]} ] include_loopback: Include ports where source and target are the same server (default: false) exclude_subsections: Subsection names to exclude from results (e.g. ["CDP Components"]). Accepts a list or JSON string. exclude_ports: Port numbers to exclude from results (e.g. ["33035"]). Accepts a list or JSON string. format: Output format — 'json' (default), 'csv', or 'markdown'. csv and markdown return the raw content as text.
| Name | Required | Description | Default |
|---|---|---|---|
| product_name | Yes | ||
| servers_json | Yes | ||
| include_loopback | No | ||
| exclude_subsections | No | ||
| exclude_ports | No | ||
| format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 explains the output is human-readable text, details all parameters, and mentions format options. It does not disclose side effects or authentication, but given the tool's nature (computation), this is adequate.
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 well-structured with a clear purpose statement, usage guidance, and a detailed Args section. It is concise yet comprehensive, with every sentence adding value.
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 fully covers the tool's purpose, parameters, and behavior. Since an output schema exists, it correctly avoids detailing return values. It is complete for the tool's complexity.
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 0%, so the description must compensate. It does so excellently by providing detailed explanations, examples, defaults, and accepted types for all 6 parameters, adding significant value beyond the input schema.
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 tool resolves server topology and returns port mappings. It distinguishes itself from sibling tools like get_product_ports (which retrieve existing data) by generating new mappings based on user-provided server definitions.
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 explicitly says 'Use this when the user describes their server layout and wants to know what firewall rules are needed between servers.' It provides clear context but does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get port data with LLM-parsed service metadata for a product.
Returns the same port entries as get_product_ports, plus enriched metadata for each source and target service (canonical name, roles, OS, hypervisor, storage type). Useful for understanding service relationships and filtering by role.
Returns 404 if enrichment hasn't been run for this product.
Args: product_name: Exact product name (e.g. 'VBR v13', 'VB365')
| Name | Required | Description | Default |
|---|---|---|---|
| product_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description discloses enrichment addition and 404 error. Does not cover potential rate limits or auth, but core behavior is clear.
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 paragraph with front-loaded purpose, no filler. Each sentence earns its place.
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?
Low complexity (1 param, output schema exists). Covers return vs sibling, error case, and argument format. Minor gap: no mention of synchronization or prerequisites.
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 0%, but description documents parameter with name and examples (e.g. 'VBR v13'), adding meaning beyond schema type.
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?
Clear verb and resource: 'Get port data with LLM-parsed service metadata'. Distinguishes from sibling get_product_ports by mentioning enriched metadata.
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?
Explicitly states similarity to get_product_ports, when to use (for enriched metadata), and provides error case (404). Includes argument format examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all network port requirements for a specific Veeam product.
Returns every port entry including source service, target service, port number, protocol, and description. Use list_products first to find valid product names.
Args: product_name: Exact product name (e.g. 'VBR v13', 'VB365', 'VONE')
| Name | Required | Description | Default |
|---|---|---|---|
| product_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states that the tool returns port entries with specific fields, but does not disclose any behavioral traits such as side effects, idempotency, authentication needs, or potential errors.
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 with two sentences for the main purpose followed by an Args section. It is front-loaded and contains no unnecessary words, making it efficient and easy to parse.
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 tool's simplicity (one parameter, no nested objects) and the presence of an output schema, the description provides sufficient information: it explains the return format and usage prerequisite. It is complete for an agent to correctly select and invoke this tool.
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 0% descriptive coverage, but the description adds significant meaning to the single parameter 'product_name' by specifying it requires an exact product name and providing examples like 'VBR v13', 'VB365'. This compensates well for the schema's lack of description.
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 verb 'Get all network port requirements' and the specific resource 'for a specific Veeam product'. It distinguishes itself from sibling tools like search_by_port_number and list_products by focusing on port requirements per product.
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 explicitly advises to 'Use list_products first to find valid product names', providing clear context for usage. However, it does not mention when not to use this tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the section headings that organise a product's port requirements.
Each subheading represents a component or role within the product (e.g. 'Backup Server', 'Proxy Server'). Useful for understanding the product architecture before diving into specific ports.
Args: product_name: Exact product name (e.g. 'VBR v13', 'VB365')
| Name | Required | Description | Default |
|---|---|---|---|
| product_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 describes the return value and does not mention side effects, error behavior, authentication needs, or rate limits. For a simple query tool, minimal disclosure 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 two sentences plus an argument description, front-loaded with the core purpose. Every word adds value; no unnecessary content.
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 tool has an output schema (not shown) and a single parameter, so the description need not detail return values. However, it does not mention what happens if the product_name is invalid or missing, leaving a gap for error handling. It is otherwise sufficient for a simple lookup.
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 schema has 0% description coverage for the 'product_name' parameter. The description adds explicit guidance: 'Exact product name (e.g. 'VBR v13', 'VB365')', which clarifies the expected format and provides examples, adding significant value beyond the schema.
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 it gets section headings that organize a product's port requirements, with examples. It distinguishes from siblings like 'get_product_ports' and 'list_products' by specifying the output is structural headings, not port details or product names.
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 indicates the tool is useful before diving into specific ports, implying a sequence. It provides context but does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the source services for a product, grouped by section.
Shows which components/roles (source services) exist within each section of a product's port requirements. Useful for understanding the network topology before querying specific port details.
Args: product_name: Exact product name (e.g. 'VBR v13', 'VB365')
| Name | Required | Description | Default |
|---|---|---|---|
| product_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains basic behavior (returns grouped source services) but does not disclose read-only status, authentication needs, 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?
The description is concise: three sentences plus an args listing. It is front-loaded with the main action and contains no redundant 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 tool has one parameter and an output schema, the description adequately covers purpose, usage, and parameter semantics. No major gaps.
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 schema has 0% description coverage, so the description compensates by specifying that product_name must be exact and providing examples. This adds meaning beyond the schema's bare string type.
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 it retrieves source services for a product grouped by section, relating to port requirements and network topology. This distinguishes it from sibling tools that deal with ports directly.
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 mentions it is useful before querying port details, implying when to use it. However, it does not explicitly exclude other scenarios or compare with alternatives like get_product_ports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Veeam products that have port requirement data available.
Call this first to discover valid product names before using other tools. Returns product names like 'VBR v13', 'VB365', etc.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the output (product names) but does not disclose any behavioral traits like side effects, rate limits, or data freshness. However, as a read-only list operation, the description is minimally adequate.
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?
Two focused sentences plus an example, front-loaded with purpose. Every word earns its place with no redundancy.
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 parameters and an existing output schema, the description provides enough context: it explains what the tool returns, why to use it, and gives concrete examples. Complete for effective use.
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?
No parameters exist, so baseline is 4. The description adds no parameter info, which is appropriate since there are none.
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 it lists Veeam products with port requirement data, gives examples of returned product names, and explains its role as a discovery tool before using other tools. It distinguishes from siblings by its specific purpose.
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?
Explicitly says 'Call this first to discover valid product names before using other tools,' providing clear guidance on when to use and its prerequisite role. No exclusions or alternatives listed, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all known service roles for a product from the knowledge graph.
Returns canonical service names with their original name variants and any OS/hypervisor/storage qualifiers. Useful for discovering valid service names before calling generate_topology or generate_app_import.
Args: product_name: Exact product name (e.g. 'VBR v13', 'VB365')
| Name | Required | Description | Default |
|---|---|---|---|
| product_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior fully. It states it returns canonical names, variants, and qualifiers, implying a read-only list operation. However, it does not explicitly confirm lack of side effects or mention any permissions needed, which would be helpful for a tool with no annotations.
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 with 4 sentences including the Args section, no fluff, and the most important information is 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?
Given there is an output schema, the description appropriately does not detail return values. It covers purpose, usage, and parameters. Missing elements like error handling or rate limits are minor for a simple list tool, so it is largely 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?
Schema description coverage is 0%, so the description compensates by documenting the only parameter: product_name. The Args section provides the exact product name requirement and examples, adding meaning beyond the bare schema property.
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 verb 'List', the resource 'all known service roles', and the source 'from the knowledge graph'. It distinguishes from siblings like generate_topology and generate_app_import by specifying it lists service names used as input for those tools.
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 explicitly says 'Useful for discovering valid service names before calling generate_topology or generate_app_import', providing clear when-to-use guidance. It does not explicitly mention when not to use, but the context makes it a precursor tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all Veeam product entries that use a specific port number.
Searches the port field across all products. Useful for firewall audits or checking which Veeam services need a particular port opened.
Args: port: Port number to search for (e.g. '443', '9392', '6180')
| Name | Required | Description | Default |
|---|---|---|---|
| port | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only indicates it is a search operation on the port field, lacking details about safety, rate limits, or side effects. 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 concise, with a clear first sentence and a brief usage note. The 'Args:' section is slightly redundant with the schema but adds example values, making it still helpful.
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 tool has a simple interface (1 parameter) and an output schema exists, the description adequately explains the search scope and usage context. Missing details like return format are covered by output schema.
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 0%, but the description adds examples ('e.g. '443', '9392', '6180'), which is valuable. It explains the parameter purpose ('Port number to search for'), going beyond the bare schema.
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 ('Find all Veeam product entries') and the target resource ('that use a specific port number'). It distinguishes from siblings like 'search_ports' by specifying it searches the port field across all products, though not explicit differentiation.
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 mentions use cases ('firewall audits or checking which Veeam services need a particular port opened'), providing context for when to use, but does not explicitly state when not to use or compare to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across all Veeam products for port requirements matching a query.
Searches product names, source/target services, port numbers, protocols, descriptions, and section headings. Useful for questions like 'which products use SMTP' or 'what needs port 443'.
Args: query: Search text (e.g. 'SMTP', 'backup server', 'cloud gateway')
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It lists searched fields (product names, services, ports, protocols, descriptions, headings) but omits details like return format, pagination, or case sensitivity. Adequate but not fully transparent.
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?
Concise and well-structured with a clear purpose statement followed by field list and parameter description. No wasted words, but could be slightly more compact.
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 single-parameter search tool, the description covers scope, examples, and searched fields. The existence of an output schema mitigates the need to describe return values. Minor gaps like query limitations are absent but not critical.
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?
Despite 0% schema description coverage, the description adds meaning by naming the parameter 'query' with examples ('SMTP', 'backup server', 'cloud gateway'). This provides context beyond the schema type definition.
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 tool searches across all Veeam products for port requirements with a specific verb ('search') and resource ('port requirements'). It distinguishes itself from sibling tools like 'search_by_port_number' by indicating a broader multi-field search.
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?
Provides explicit usage examples like 'which products use SMTP' or 'what needs port 443', clearly indicating the type of queries it handles. However, it lacks direct comparison to siblings to specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search port requirements using natural language (vector similarity).
Understands synonyms and related concepts — e.g. 'firewall rules for backup to NAS' matches NFS/SMB repository entries even if those exact words don't appear in the data.
Falls back to keyword search if vector embeddings are unavailable.
Args: query: Natural language search query (e.g. 'what ports does the proxy need for VMware', 'cloud connectivity', 'database ports') product_name: Optional product to filter results (e.g. 'VBR v13'). If omitted, searches across all products. limit: Max results to return (1-100, default 20)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| product_name | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses vector similarity usage and keyword fallback, but does not mention performance, rate limits, or auth requirements. For a search tool, this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear paragraphs and bullet-like argument list. It is concise, informative, and front-loads the primary functionality. No superfluous content.
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 tool has an output schema (not shown) and 3 parameters. Description covers inputs and core behavior. It does not explain output format, but the output schema likely handles that. Complexity is moderate, and the description is largely 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?
Schema description coverage is 0%, and the description effectively explains each parameter: query as natural language, product_name as optional filter, limit as max results. This adds significant value beyond the schema.
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 tool performs semantic search for port requirements using natural language. It distinguishes itself from sibling tools like search_ports and search_by_port_number by highlighting vector similarity and synonym understanding.
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 example queries and optional filters (product_name, limit). It mentions fallback behavior but lacks explicit guidance on when to use this tool vs alternatives like keyword search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: listing products, querying ports, searching, and generating topologies. No two tools overlap, and descriptions clearly differentiate them.
Names follow a consistent action_noun pattern using snake_case (list_, get_, search_, generate_). 'semantic_search' deviates slightly but remains descriptive and intuitive.
With 11 tools, the server is well-scoped for its domain: discovery (list_products, list_services), detailed querying (get_product_ports, etc.), search (multiple methods), and generation (topology, app import). No bloat or insufficiency.
The tool set covers the full lifecycle for a read-only knowledge base: discovery, metadata browsing, precise querying, search across dimensions, and generation of outputs. No obvious gaps—users can explore and export effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate cloud architecture diagrams, flowcharts, and sequence diagrams.
Query Allen-Bradley and Siemens PLC projects, live tag values, and analyses in plain English.
Generate, edit, and export data-architecture diagrams from your AI. Column lineage, PNG in chat.
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shapedthought/veeam-ports-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
