Click on "Deploy 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., "@peering-manager-mcp-server Which BGP sessions are not established?"
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 read-only Model Context Protocol server for Peering Manager. Exposes peering infrastructure data as conversational tools for use with Claude Code, claude.ai, or any MCP-compatible client.
Tool | Description |
| Unified view of BGP sessions across direct peering and IXP sessions |
| Full detail for a single session with type-specific fields |
| Search/filter autonomous systems |
| AS detail with shared IXPs and facilities |
| Routers with status and platform info |
| Internet exchange points |
| IXP detail with available peers |
| IXP connections with IP/VLAN/router mapping |
| Import/export routing policies |
| BGP communities |
| Rendered Jinja2 configuration for a router |
| Query cached PeeringDB data (networks, IXPs, facilities, network-ixlans) |
| Audit log of recent object changes |
All tools are read-only. No write operations are exposed.
Related MCP server: flowspec-mcp
Node.js 18+
A running Peering Manager instance with API access
An API token with read permissions
npm install -g git+https://github.com/yourorg/peering-manager-mcp-server.gitThis installs the peering-manager-mcp-server command globally.
The server reads two required environment variables:
Variable | Description |
| Base URL of your Peering Manager instance (e.g. |
| API token for authentication |
| Optional. Timeout in seconds for config rendering (default: |
Add to your global MCP settings (~/.claude/settings.json):
{
"mcpServers": {
"peering-manager": {
"command": "peering-manager-mcp-server",
"env": {
"PM_URL": "https://pm.example.com",
"PM_API_TOKEN": "your-api-token"
}
}
}
}PM_URL=https://pm.example.com PM_API_TOKEN=your-token npx @modelcontextprotocol/inspector peering-manager-mcp-servergit clone https://github.com/yourorg/peering-manager-mcp-server.git
cd peering-manager-mcp-server
npm install
npm run build
PM_URL=https://pm.example.com PM_API_TOKEN=your-token npm startOnce connected, you can ask Claude things like:
"Which BGP sessions are not established?"
"Show me all peers at AMS-IX"
"What IXPs do we share with AS13335?"
"Show me the config for router core-1"
"What routing policies are applied to our transit peers?"
"What changed in the last week?"
All list tools accept limit (default 100, max 1000) and offset for pagination. Responses include total_count so you know when there are more results.
Session-specific filters:
list_bgp_sessions: asn, router, ixp, status, bgp_state, address_family, is_route_server
list_autonomous_systems: asn, name, affiliated, search
list_routers: status, platform_id, local_autonomous_system_id
list_internet_exchanges: status, local_autonomous_system_id, local_autonomous_system_asn
list_connections: status, internet_exchange_point_id, router_id
list_routing_policies: type, address_family
list_communities: type
search_peeringdb: resource_type (required), search, asn, name
list_changes: action, changed_object_type, user, time_after, time_before
Peering Manager stores direct peering sessions and IXP peering sessions as separate models. This server unifies them:
list_bgp_sessions merges both types into a single list with common fields and a session_type field ("direct" or "ixp")
get_bgp_session_detail returns the full type-specific response — direct sessions include relationship, bgp_group, local_ip_address; IXP sessions include ixp_connection, is_route_server, exists_in_peeringdb
Most API calls use a 30-second timeout. get_router_configuration uses 120 seconds by default (configurable via PM_CONFIG_TIMEOUT) because config rendering may involve Jinja2 template processing and IRR/AS-SET lookups.
MIT
Get full detail for an autonomous system including shared IXPs and shared facilities.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Autonomous system ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only describes the output content but does not mention side effects, permissions, rate limits, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose without extraneous 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's simplicity (one parameter, no output schema), the description adequately covers purpose and output content. Minor gains could be made by noting absence of side effects 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 description coverage is 100% for the single parameter 'id'. The description adds context about the output but does not enhance parameter semantics beyond the schema's own 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 action 'Get full detail' for a specific resource 'autonomous system' and specifies what is included (shared IXPs and facilities). It effectively distinguishes from sibling tools like list_autonomous_systems.
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 use for retrieving details of a specific AS but does not provide explicit guidance on when to use vs. alternatives like list_autonomous_systems or what prerequisites are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full detail for a single BGP session. Returns type-specific fields based on session type.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Session ID | |
| session_type | Yes | Session type: 'direct' for direct peering, 'ixp' for internet exchange |
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 discloses that returns vary by session type, which is helpful. However, it does not mention whether the operation is safe, read-only, or any side effects (likely read-only). More behavioral detail would improve 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 sentence that conveys the core functionality and a key behavior. Every word earns its place; 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?
For a simple two-parameter tool with no output schema, the description provides sufficient context: it explains the basic action and hints at the output structure via 'type-specific fields'. A more detailed description of what 'full detail' includes would improve completeness, but it is adequate.
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 descriptions for both parameters. The description does not add additional meaning beyond what is already in the schema. Baseline of 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 clearly states the verb 'Get' and the resource 'full detail for a single BGP session', distinguishing it from sibling tools like list_bgp_sessions (which lists). The mention of type-specific fields adds specificity.
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 tool's purpose is clear from the name and description, but no explicit guidance is given on when to use this tool versus alternatives like list_bgp_sessions or search_peeringdb. Implicit context is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full detail for an internet exchange point including available peers.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Internet exchange ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the response includes 'available peers,' which adds some behavioral context. However, it does not describe other return fields, any side effects, or whether the tool requires authentication. The mention of peers is a modest but non-trivial addition.
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, efficient sentence that conveys the core purpose without any wasted words or repetition.
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 adequate for a simple retrieval tool with one parameter and no output schema. However, it could be more specific about what 'full detail' includes (beyond peers) or mention pagination or availability. Given the lack of output schema, additional hints about return structure would improve completeness.
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 covers the only parameter 'id' with a description. The tool description adds no additional semantic meaning beyond the schema, which already states 'Internet exchange ID.' With 100% schema coverage, a score of 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 clearly specifies the action ('Get full detail') and the resource ('internet exchange point'), and includes the notable output component ('including available peers'). It effectively distinguishes from sibling tools like list_internet_exchanges, which likely return summaries, and search_peeringdb, which is broader.
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., list_internet_exchanges for a list, or other detail tools). No prerequisites, exclusions, or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the rendered configuration for a specific router. Uses extended timeout due to Jinja2 rendering and possible IRR lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Router ID |
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 discloses that the tool uses extended timeout due to rendering and lookups, which is useful behavioral context. However, it does not confirm read-only nature or describe any 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, with two short sentences that front-load the purpose and add a key behavioral note. Every sentence adds value without unnecessary words.
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 is simple with one parameter and no output schema, the description is adequate but could be improved by mentioning the return format or any prerequisites. It does not explain what the configuration looks like.
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 for its single required parameter 'id' (Router ID). The description adds no extra meaning beyond what the schema provides, leading to a baseline score.
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 retrieves the rendered configuration for a specific router, using a specific verb and resource. It distinguishes itself from sibling tools that deal with other entities like autonomous systems or BGP sessions.
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 an extended timeout due to Jinja2 rendering and IRR lookups, implying it is a heavier operation. However, it does not explicitly state when to use this tool over alternatives or provide any usage exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List autonomous systems configured in Peering Manager.
| Name | Required | Description | Default |
|---|---|---|---|
| asn | No | Filter by AS number | |
| name | No | Filter by name | |
| limit | No | Max results to return (default 100, max 1000) | |
| offset | No | Offset for pagination | |
| search | No | Free-text search across AS fields | |
| affiliated | No | Filter by affiliated status (true = local/own ASes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description should disclose behavioral traits. It only says 'list', but does not mention that it is read-only, supports pagination (limit/offset), or any default behavior. The schema implies filtering but description adds no context beyond the verb.
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, well-formed sentence with no wasted words. It is front-loaded with the action and resource, 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?
Despite having 6 parameters and no output schema, the description lacks essential context about return format, pagination behavior, or how filters affect results. The tool is minimally documented, leaving gaps for the 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?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning to parameters beyond what the schema already provides; it does not explain or contextualize the filter parameters.
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 'List autonomous systems configured in Peering Manager,' using specific verb+resource. It distinguishes from siblings like get_autonomous_system (singular) and list_bgp_sessions (different resource), making purpose 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 such as get_autonomous_system for a single AS or list_bgp_sessions for sessions. No exclusions, prerequisites, or context on typical use cases are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List BGP sessions across both direct peering and IXP sessions. Returns unified view with common fields.
| Name | Required | Description | Default |
|---|---|---|---|
| asn | No | Filter by remote AS number | |
| ixp | No | Filter by internet exchange ID | |
| limit | No | Max results to return (default 100, max 1000) | |
| offset | No | Offset for pagination | |
| router | No | Filter by router name | |
| status | No | Filter by status (e.g. enabled, disabled, maintenance) | |
| bgp_state | No | Filter by BGP state (e.g. established, active, idle) | |
| address_family | No | Filter by address family (4 or 6) | |
| is_route_server | No | Filter IXP sessions by route server status (IXP sessions only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the unified view but does not detail pagination, authentication requirements, or what happens with no results. The description is adequate but lacks depth.
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, front-loaded with the main action, and contains no redundant or extraneous information. Every word serves a purpose.
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?
With no output schema and 9 parameters, the description is minimal. It covers the purpose but lacks details on return fields, edge cases, or performance considerations. Adequate but incomplete given 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 coverage is 100% with adequate descriptions for all 9 parameters. The tool description does not add additional parameter-specific meaning beyond the schema, so baseline score of 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 clearly states the tool lists BGP sessions across both direct peering and IXP sessions, specifying the resource (BGP sessions) and the action (list). It distinguishes from siblings like get_bgp_session_detail and list_autonomous_systems by focusing on a unified view covering both session types.
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 listing BGP sessions but does not provide explicit guidance on when to use this tool over alternatives like search_peeringdb or list_connections. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent object changes from the Peering Manager audit log.
| Name | Required | Description | Default |
|---|---|---|---|
| user | No | Filter by username | |
| limit | No | Max results to return (default 100, max 1000) | |
| action | No | Filter by action: create, update, delete | |
| offset | No | Offset for pagination | |
| time_after | No | Filter changes after this date (ISO format, e.g. 2026-07-01) | |
| time_before | No | Filter changes before this date (ISO format) | |
| changed_object_type | No | Filter by object type (e.g. peering.directpeeringsession) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It does not mention side effects, read-only nature, default behavior, or any constraints beyond parameter hints. A read tool but not explicitly stated.
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, readable sentence with no wasted words. However, it could be expanded slightly for more utility without becoming 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?
Given the tool has 7 parameters and no output schema, the description lacks important context about return format, pagination defaults, and how it fits into broader workflows. It is insufficient for an agent to fully understand the 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond that, meeting the baseline expectation.
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 lists recent object changes from the Peering Manager audit log, using a specific verb and resource. It is well-differentiated from sibling list tools like list_autonomous_systems or list_bgp_sessions.
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 exclusions or prerequisites. The description simply states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List BGP communities configured in Peering Manager.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by type: egress, ingress | |
| limit | No | Max results to return (default 100, max 1000) | |
| offset | No | Offset for pagination |
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 does not disclose any behavioral traits like read-only nature, authentication requirements, or pagination behavior, leaving the agent with minimal context.
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 is concise and front-loaded with the action. However, it could include more details without becoming 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?
Given 3 parameters and no output schema or annotations, the description fails to provide sufficient context about return values, pagination details, or the scope of the data listed. The agent lacks information to fully understand the tool's 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?
Schema coverage is 100% and the schema descriptions clearly define each parameter (type, limit, offset). The tool description does not add extra meaning beyond the schema, so 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 explicitly states it lists BGP communities in Peering Manager, which is a specific verb and resource. It clearly distinguishes from sibling tools like list_autonomous_systems and list_bgp_sessions.
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, such as list_bgp_sessions or search_peeringdb. There is no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List IXP connections with IP/VLAN/router mapping.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 100, max 1000) | |
| offset | No | Offset for pagination | |
| status | No | Filter by status (enabled, disabled, maintenance, etc.) | |
| router_id | No | Filter by router ID | |
| internet_exchange_point_id | No | Filter by IXP ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description is too brief. It does not disclose pagination behavior, default limits, filtering behavior, or whether results are sorted. The tool's behavioral traits are largely unspecified.
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, front-loaded with the key action. However, it may be too brief, sacrificing necessary detail 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 5 filter parameters and no output schema, the description is incomplete. It lacks information on response structure, pagination mechanics, and default values, leaving the agent underinformed.
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 each parameter is documented. The description adds no additional semantic value beyond the schema, but the baseline is 3 due to high 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?
Description clearly states verb 'List', resource 'IXP connections', and specifies output includes 'IP/VLAN/router mapping'. It is specific and distinguishes from sibling tools like list_internet_exchanges and list_routers.
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 such as list_internet_exchanges or list_routers. No mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List internet exchange points configured in Peering Manager.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 100, max 1000) | |
| offset | No | Offset for pagination | |
| status | No | Filter by status (enabled, disabled, maintenance, etc.) | |
| local_autonomous_system_id | No | Filter by local AS ID | |
| local_autonomous_system_asn | No | Filter by local AS number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It omits any mention of side effects, safety (read-only nature), rate limits, or pagination behavior beyond what the schema implies.
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 8-word sentence that efficiently conveys the core purpose with no unnecessary words. However, it could benefit from minimal additional context.
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 low complexity (list with optional filters, no output schema), the description is minimally complete but lacks any explanation of return values or usage scenarios.
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 schema already documents all 5 parameters. The description adds no additional meaning or context for the parameters, meeting the baseline for high 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 clearly states the action ('List') and the resource ('internet exchange points'), distinguishing it from sibling 'get_internet_exchange' which retrieves a single exchange.
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 like 'search_peeringdb' or 'list_autonomous_systems', nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List routers configured in Peering Manager.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 100, max 1000) | |
| offset | No | Offset for pagination | |
| status | No | Filter by status (enabled, disabled, maintenance, etc.) | |
| platform_id | No | Filter by platform ID | |
| local_autonomous_system_id | No | Filter by local AS ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should fully disclose behavioral traits. It does not mention that this is a read operation, nor any default behavior like pagination or ordering. The agent is left to infer basic list functionality.
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 concise single sentence. While it could be slightly more informative, there is no wasted content. It is appropriately sized for a simple list operation.
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 lack of output schema and annotations, the description is not complete. It does not explain the return format, pagination behavior, or default filtering. The agent may need more context to use this tool 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 description coverage is 100%, so the baseline is 3. The description does not add any extra meaning beyond what the schema already provides for parameters.
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 routers, which is a specific verb+resource. It distinguishes itself from sibling tools like list_autonomous_systems or list_bgp_sessions, which target different resources.
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 usage guidelines are provided. The description does not mention when to use this tool or when to use an alternative. Although siblings are distinct, there is no explicit guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List routing policies configured in Peering Manager.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by type: export-policy, import-policy, import-export-policy | |
| limit | No | Max results to return (default 100, max 1000) | |
| offset | No | Offset for pagination | |
| address_family | No | Filter by address family (0 = both, 4 = IPv4, 6 = IPv6) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations. Description only says 'list', implying read-only, but lacks details on authentication, pagination behavior, rate limits, or any side effects. Does not compensate for missing 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?
Single sentence, no filler, front-loaded with verb and object.
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?
No output schema. Description minimal but adequate for a simple list operation with optional filtering. Could add details on returned fields or pagination 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?
Schema coverage is 100%, so description adds no parameter meaning beyond the schema. Baseline 3 applies.
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 verb 'list' and resource 'routing policies' with context 'Peering Manager'. Distinct from sibling tools like list_bgp_sessions or list_routers.
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 when-to-use or exclusions, but context is clear from resource name. Siblings are for different resources, so no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search cached PeeringDB data. Supports networks, internet-exchanges, facilities, and network-ixlans.
| Name | Required | Description | Default |
|---|---|---|---|
| asn | No | Filter by AS number (networks and network-ixlans) | |
| name | No | Filter by name | |
| limit | No | Max results to return (default 100, max 1000) | |
| offset | No | Offset for pagination | |
| search | No | Free-text search | |
| resource_type | Yes | PeeringDB resource type to query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only notes that data is 'cached'. It fails to disclose authentication needs, rate limits, error behaviors, or data freshness specifics, which are important for a search tool.
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 extremely concise at two sentences, front-loaded with the action and resource, with no unnecessary words or repetition.
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?
Without an output schema, the description does not explain the return format, pagination behavior, or result structure. While the search functionality is clear, a tool with 6 parameters could benefit from more context on expected outputs.
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 input schema already fully documents each parameter's meaning. The tool description adds no extra semantic value beyond labeling the resource types, achieving the baseline for this dimension.
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 specifies the verb 'Search', the resource 'cached PeeringDB data', and explicitly lists the supported resource types (networks, internet-exchanges, facilities, network-ixlans), distinguishing it from sibling tools that target specific resources.
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 'cached' data implying staleness but does not provide explicit guidance on when to use this tool versus sibling tools (e.g., specific get/list tools). Usage context is implied but not directly 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.
v1.0.0get_autonomous_systemget_bgp_session_detailget_internet_exchangeget_router_configurationlist_autonomous_systemslist_bgp_sessionslist_changeslist_communitieslist_connectionslist_internet_exchangeslist_routerslist_routing_policiessearch_peeringdbScored across 13 tools
Each tool targets a distinct entity (autonomous system, BGP session, internet exchange, etc.) with specific actions (get, list, search). Descriptions are detailed and clarify the scope, leaving no ambiguity between tools.
All tools follow a consistent verb_noun pattern in snake_case (e.g., get_autonomous_system, list_bgp_sessions, search_peeringdb). This makes the set predictable and easy to navigate.
With 13 tools, the server covers a wide range of peering-related resources without being overwhelming. Each tool serves a clear purpose, and the count feels appropriate for the domain.
The tools are entirely read-only (get, list, search), lacking any create, update, or delete operations. For a management interface, this is a significant gap that prevents agents from modifying configurations, leading to dead ends.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
