This server gives an LLM read and write access to a NetBox installation via generic REST API tools for discovery, CRUD, and server-side actions.
Discover all supported NetBox endpoints grouped by app (netbox_list_endpoints)
Inspect field schemas, required fields, types, and valid choices before writing (netbox_get_schema)
List or search objects with optional filters and configurable limits (netbox_list_objects)
Fetch a single object by numeric ID (netbox_get_object)
Create new objects with arbitrary field data (netbox_create_object)
Partially update existing objects (netbox_update_object)
Delete objects, but only with explicit confirmation (netbox_delete_object)
List available server-side actions beyond CRUD, such as IP/prefix/VLAN/ASN allocation, cable trace, config rendering, rack elevation, and data source sync (netbox_list_actions)
Call those actions on specific objects (netbox_call_action)
Run in read-only mode to disable all create/update/delete tools, protecting real NetBox installations
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., "@netbox-mcp List the sites in NetBox and how many devices are in each."
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 server that gives an LLM read and write access to a NetBox installation over its REST API.
By default it points at the public demo instance at https://demo.netbox.dev. Point it at your own NetBox installation later by changing two environment variables — no code changes needed.
Rather than one tool per NetBox object type (there are 100+), this server exposes a small set of generic tools that operate on any endpoint:
netbox_list_endpoints — list every supported app.endpoint value (e.g. dcim.devices, ipam.prefixes), grouped by NetBox app.
netbox_get_schema(endpoint) — get field definitions (required fields, types, valid choices) for an endpoint before writing to it.
netbox_list_objects(endpoint, filters=None, limit=50) — list/search objects.
netbox_get_object(endpoint, id) — get a single object by ID.
netbox_create_object(endpoint, data) — create a new object.
netbox_update_object(endpoint, id, data) — partially update an object.
netbox_delete_object(endpoint, id, confirm=True) — delete an object (requires explicit confirmation).
netbox_list_actions — list every supported server-side "action" (beyond plain CRUD), e.g. allocating the next available IP/prefix/VLAN/ASN, tracing a cable path, rendering a device's config, a rack's elevation, or triggering a data source sync.
netbox_call_action(endpoint, id, action, method="list", params=None, data=None) — call one of those actions on a specific object.
Related MCP server: NetBox MCP Server
Requires uv.
uv sync
cp .env.example .envEdit .env:
NETBOX_URL — your NetBox instance, e.g. https://demo.netbox.dev or your own install.
NETBOX_TOKEN — an API token from your NetBox user profile (Admin > API Tokens). Required for both reads and writes. For the public demo, create a free account (it's reset periodically) then generate a token from your user profile.
NETBOX_MCP_READ_ONLY — set to true to disable all create/update/delete tools. Recommended until you're confident in the setup, especially against a real installation.
NETBOX_VERIFY_SSL — set to false only if your instance uses a self-signed certificate.
uv run netbox-mcpThis runs the server over stdio, which is how MCP clients like Claude Code and Claude Desktop launch it.
uv run mcp dev src/netbox_mcp/server.pyOpens the MCP Inspector so you can call tools directly and see NetBox's responses before wiring the server into a client.
Add to .mcp.json in your project (or user-level MCP config):
{
"mcpServers": {
"netbox": {
"command": "uv",
"args": ["--directory", "/path/to/netbox-mcp", "run", "netbox-mcp"],
"env": {
"NETBOX_URL": "https://demo.netbox.dev",
"NETBOX_TOKEN": "your-api-token",
"NETBOX_MCP_READ_ONLY": "false"
}
}
}
}Add the same netbox entry under mcpServers in your claude_desktop_config.json.
Change NETBOX_URL and NETBOX_TOKEN (in .env, or in the client's MCP server config) and restart the server. Nothing else changes.
"List the sites in NetBox and how many devices are in each."
"What's the schema for creating a device? I want to add a new switch called sw-core-02."
"Find all unused IP addresses in the 10.0.0.0/24 prefix."
"Create a new VLAN 200 named 'guest-wifi' in the site called Amsterdam."
uv run pytestCreate a new object at a NetBox endpoint. Disabled when the server is running in read-only mode.
Args:
endpoint: An "app.endpoint" string, e.g. "dcim.sites".
data: Field values for the new object. Use netbox_get_schema to
see required and valid fields first.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| endpoint | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose a meaningful caveat: 'Disabled when the server is running in read-only mode.' However, it does not mention authorization requirements, error behavior, or whether creation is idempotent, so significant behavioral gaps remain.
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 compact and front-loaded with the primary action and the read-only caveat. The Args block is structured and every line adds useful information without repetition or fluff.
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 two-parameter creation tool, the description covers endpoint format, data meaning, the read-only caveat, and the prerequisite schema lookup. With an output schema available, return values are covered elsewhere; only minor omissions like explicit permission or error-handling details keep this from a 5.
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 only lists 'endpoint' as a string and 'data' as an object, with 0% schema description coverage. The description compensates fully by explaining endpoint as an 'app.endpoint' string with a concrete example and describing data as field values, directing the agent to netbox_get_schema for required and valid fields.
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 and resource: 'Create a new object at a NetBox endpoint.' It also gives the endpoint format ('app.endpoint', e.g. 'dcim.sites'), which distinguishes this creation tool from siblings like netbox_update_object and netbox_delete_object.
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 clearly instructs the agent to call netbox_get_schema first to discover required and valid fields, establishing a prerequisite workflow. It does not explicitly contrast with update/delete/list alternatives, but the 'Create a new object' framing gives clear context for when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an object from a NetBox endpoint. This is permanent. Requires confirm=True to actually perform the deletion, and is disabled when the server is running in read-only mode.
Args:
endpoint: An "app.endpoint" string, e.g. "dcim.devices".
id: The object's numeric ID.
confirm: Must be explicitly set to true to perform the deletion.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| confirm | No | ||
| endpoint | 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 and meets it well. It discloses the most important destructive behavior: deletion is permanent, confirm=True is mandatory, and the operation is disabled when the server is read-only. This is strong transparency for a mutation 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 compact and front-loaded: the critical warnings appear in the first two sentences, and the Args block is lean. Every sentence earns its place without filler or redundant restatement.
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 that an output schema exists and no annotations are provided, the description covers the essential behavior, parameters, and confirmation requirement needed to invoke the tool correctly. It could optionally reference list_endpoints for valid endpoint strings, but nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining all three parameters: endpoint as an 'app.endpoint' string with a concrete example, id as a numeric ID, and confirm as the explicit safety gate that must be true. It adds real meaning beyond the raw 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?
Opens with a specific action and resource: 'Delete an object from a NetBox endpoint.' 'This is permanent' further pins the destructive semantics, and the verb 'delete' plus the endpoint concept distinguishes it from the list/create/update/schema sibling 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 provides clear operational context—permanent deletion, confirm=True required, and read-only mode disabling—but it does not explicitly name alternatives or state when not to use this tool versus update_object or create_object. Routing to siblings is only implied by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single object from a NetBox endpoint by its numeric ID.
Args:
endpoint: An "app.endpoint" string, e.g. "dcim.devices".
id: The object's numeric ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| endpoint | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. The verb "Get" clearly indicates a read-only operation, but no mention is made of not-found behavior, authentication requirements, or error cases. For a simple GET-style tool this is adequate but not rich.
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 sentences plus a compact Args block. No filler, the main action is front-loaded, and every line earns its place by explaining how to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters, an output schema to cover return values, and a straightforward read operation, the description is nearly complete. It lacks only minor details such as behavior for invalid IDs or unavailable endpoints, which are acceptable gaps for a simple getter.
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 fully compensates by explaining both parameters: endpoint is an "app.endpoint" string with a concrete example ("dcim.devices"), and id is the object's numeric ID. This adds meaningful guidance beyond the schema's bare types and titles.
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 starts with a precise verb and resource: "Get a single object from a NetBox endpoint by its numeric ID." This clearly differentiates from list_objects (single vs. multiple), and from create/update/delete operations, so an agent can select it correctly.
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 clear usage context: use when you want one object by numeric ID. It does not explicitly name alternatives or say when not to use it, but the "single object" framing inherently distinguishes it from list_objects without needing exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get field definitions for a NetBox endpoint (names, types, whether required/read-only, and valid choice values), via an authenticated OPTIONS request. Use this before creating or updating objects to see what fields are valid.
Args:
endpoint: An "app.endpoint" string, e.g. "dcim.devices". See
netbox_list_endpoints for valid values.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the operation is an authenticated OPTIONS request, which implies read-only introspection and signals authentication requirements. While it does not explicitly state 'no side effects', the 'get field definitions' framing is clear enough for this tool type.
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 main purpose and usage guidance are front-loaded in the first sentence. The Args block is a bit redundant with the schema but still adds example and format details. No filler or misleading content—compact and purposeful.
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 is simple (one parameter) and has an output schema, so return-value details are already covered. The description supplies everything else: what it returns, how it authenticates, when to use it, and how to obtain valid endpoint values. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that endpoint is an 'app.endpoint' string, provides a concrete example ('dcim.devices'), and directs the agent to netbox_list_endpoints for valid values. This fully disambiguates the sole parameter beyond what the bare schema provides.
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 specifies a clear verb and resource: 'Get field definitions for a NetBox endpoint', with a concrete list of returned content (names, types, required/read-only, choice values). It is unmistakably distinct from sibling tools like netbox_list_objects or netbox_create_object, and even cross-references netbox_list_endpoints for valid endpoint values.
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 states when to use the tool: 'Use this before creating or updating objects to see what fields are valid.' It also references netbox_list_endpoints for valid endpoint strings, giving the agent an actionable path to obtain valid inputs. This is strong usage guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every supported NetBox 'app.endpoint' value, grouped by app, with a short description of what each endpoint represents. Call this first to discover which endpoint strings are valid for the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It makes the non-mutating, discovery-oriented behavior clear by stating that the tool lists supported endpoint values and provides explanatory descriptions. It does not discuss rate limits, auth requirements, or response size, but for a read-only catalog tool this is not a major gap.
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-structured sentence that front-loads the core function, then adds the grouping detail and the critical usage instruction. Every phrase earns its place with no redundant or filler 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 zero-parameter discovery tool with an output schema, the description is complete: it explains what is returned, how it is organized, and why/when to invoke it. The presence of an output schema covers the return-value shape, and the sibling tool names give enough context for the agent to see where this tool fits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so there are no parameter semantics to document. The description usefully reinforces that the tool takes no arguments and simply returns the endpoint catalog. Per the baseline for zero-parameter tools, this is appropriately handled.
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 states a clear, specific action ('List every supported NetBox app.endpoint value') and explains the output structure (grouped by app, with descriptions). This clearly distinguishes it from sibling tools like netbox_list_objects, which list object records rather than endpoint 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?
The description explicitly tells the agent to call this tool first and explains why: to discover valid endpoint strings for the other tools. It provides clear usage context but does not explicitly name alternative tools 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.
List/search objects at a NetBox endpoint.
Args:
endpoint: An "app.endpoint" string, e.g. "ipam.prefixes". See
netbox_list_endpoints for valid values.
filters: Optional field filters applied server-side, e.g.
{"site": "ams1", "status": "active"}. Omit to list all objects.
limit: Maximum number of objects to return (default 50, use 0 for
no limit).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| filters | No | ||
| endpoint | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral burden itself. It discloses that filters are applied server-side, documents the default limit of 50, and explains the special '0 for no limit' behavior. It could add more about auth or response shape, but the output schema exists and 'list/search' implies a read operation.
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 compact and front-loaded with the core purpose, followed by a tight Arg-style breakdown. Each parameter explanation earns its place, with no redundant or filler 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 list/search tool, the description covers the essential call details: endpoint selection, optional server-side filters, and result limiting. It also points to netbox_list_endpoints for valid values, and return-shape concerns are handled by the output schema. The definition is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description compensates thoroughly for all three parameters. It explains the 'app.endpoint' format with an example, provides a concrete filter-object example, and gives the limit's default and zero-meaning. This is far more helpful than the bare schema alone.
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 opens with a specific verb-resource pair, 'List/search objects at a NetBox endpoint', and clarifies the endpoint format with an example ('ipam.prefixes'). This makes it easy to distinguish from siblings like netbox_get_object (single object retrieval) or netbox_list_endpoints (listing endpoints).
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 gives clear context for how to use filters and limit ('Omit to list all objects'), but it never explicitly states when to choose this tool over alternatives such as netbox_get_object or netbox_create_object. The intended use is implied by the name and verb, but no direct when-to-use/when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Partially update an existing object at a NetBox endpoint. Only the
fields included in data are changed. Disabled when the server is
running in read-only mode.
Args:
endpoint: An "app.endpoint" string, e.g. "dcim.devices".
id: The object's numeric ID.
data: Field values to change.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| data | Yes | ||
| endpoint | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates the partial-update behavior ('Only the fields included in `data` are changed') and the important runtime constraint ('Disabled when the server is running in read-only mode'). The description does not contradict any annotations because none exist. It could add more about error handling or idempotency, but for a PATCH-style operation it covers the key behavioral aspects.
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, front-loaded with the core purpose, and then logically lists the parameters in an Args block. Every sentence earns its place, and the structure makes the parameter meanings easy to scan. There is no redundant 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?
The tool is a mutation operation with three required parameters, one of which is a dynamic object, and an output schema is present. The description covers the operation semantics, parameter meanings, and the read-only mode caveat. Return value details are not needed because an output schema exists. Minor gaps such as failure behavior are not covered, but the essential information for selecting and invoking the tool is present.
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 fully compensate for the lack of parameter documentation. It does: endpoint is defined as an 'app.endpoint' string with the clear example 'dcim.devices', id is described as 'The object's numeric ID', and data is explained as 'Field values to change.' This provides meaningful guidance beyond the bare type information in 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 action: 'Partially update an existing object at a NetBox endpoint.' The verb 'partially update' distinguishes it from create and delete siblings, and 'existing object' signals it is not for creation. A sibling like netbox_create_object is clearly differentiated even without opening its schema.
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 when to use the tool: when an object already exists and only some fields need changing, as stated by 'Only the fields included in `data` are changed.' However, it does not explicitly contrast with sibling tools like netbox_create_object or netbox_delete_object, nor does it state when not to use this tool. The usage context is present but left to inference.
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: endpoint discovery, schema introspection, list/search, get by ID, and create/update/delete. The only potential overlap is list_objects vs get_object, but their descriptions make the collection-versus-single-object distinction unambiguous.
All tools follow a consistent netbox_verb_noun pattern (e.g., netbox_list_objects, netbox_create_object, netbox_get_schema). The naming convention is uniform and predictable across the entire set.
Seven tools is well-scoped for a generic NetBox CRUD interface. Each tool covers a distinct operation needed to interact with any NetBox endpoint without being redundant or overwhelming.
The toolset provides full lifecycle coverage for NetBox objects: discovery, schema inspection, listing/searching, retrieving, creating, updating, and deleting. The endpoint-driven design means these operations apply broadly across NetBox's many object types, so there are no obvious dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
Provides access to Civic Plus - See Click Fix, allowing you to interact with your data via an LLM.…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/David41186/netbox-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
