Skip to main content
Glama

generate_topology

Determine required firewall rules by providing server names, their services, and product name. Returns port mappings between all specified servers.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
product_nameYes
servers_jsonYes
include_loopbackNo
exclude_subsectionsNo
exclude_portsNo
formatNojson

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/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 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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/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 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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Install Server

Other Tools

Latest Blog Posts

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/shapedthought/veeam-ports-mcp'

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