How do I use invgate-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@invgate-mcp list computers with name containing 'IT'" 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.

invgate-mcp

by wdelcant

Overview Schema Related Servers Score Discussions

TypeScript

Remote

invgate-mcp

A curated Model Context Protocol (MCP) server that exposes 12 read-only tools over stdio for InvGate Asset Management. Any MCP-compatible client (Claude Desktop, etc.) can query assets, people, computers, servers, software, and API health through natural language.

Transport: stdio only (the universal default for local agents).
Auth: OAuth2 client-credentials flow (scope=read), in-memory token cache with a 60-second expiry buffer and one-shot 401 retry.
Validation: every tool input is validated with zod; invalid input returns a structured validation_error without calling the API.
Resilience: HTTP, auth, and network failures are converted to MCP text content with isError: true — the server never crashes the host.
Distribution: published to npm, runnable via npx invgate-mcp.

Install

# Run without installing
npx invgate-mcp

# Or install globally
npm install -g invgate-mcp
invgate-mcp

Related MCP server: servicenow-mcp

Configuration

The server reads three required environment variables at startup:

Env var	Description	Example
`INVGATE_BASE_URL`	InvGate public API base URL (ends with `/public-api/v2`)	`https://acme.invgate.net/public-api/v2`
`INVGATE_CLIENT_ID`	OAuth2 client ID	`my-client-id`
`INVGATE_CLIENT_SECRET`	OAuth2 client secret	`my-client-secret`

If any are missing the server prints a descriptive error to stderr and exits with code 1.

The OAuth2 token endpoint is derived from INVGATE_BASE_URL by stripping the /public-api/v2 segment and appending /oauth2/token/, so https://acme.invgate.net/public-api/v2 → https://acme.invgate.net/oauth2/token/.

Claude Desktop config

Add invgate-mcp to your mcpServers block (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "invgate": {
      "command": "npx",
      "args": ["-y", "invgate-mcp"],
      "env": {
        "INVGATE_BASE_URL": "https://acme.invgate.net/public-api/v2",
        "INVGATE_CLIENT_ID": "your-client-id",
        "INVGATE_CLIENT_SECRET": "your-client-secret"
      }
    }
  }
}

Tools

Tool	Input	Behavior
`invgate_list_asset_types`	none	Returns all asset types
`invgate_list_assets`	`page`, `per_page`, `asset_type_id`, `criteria`	Paginated asset list with optional filters
`invgate_get_asset`	`asset_id` (required)	Single asset by ID
`invgate_list_people`	`page`, `per_page`, `criteria`	Paginated people list
`invgate_get_person`	`person_id` (required)	Single person by ID
`invgate_get_person_assets`	`person_id` (required), `page`, `per_page`	Assets assigned to a person
`invgate_list_computers`	`page`, `per_page`, `criteria`	Assets of type "computer"
`invgate_get_computer`	`asset_id` (required)	Single computer asset
`invgate_list_servers`	`page`, `per_page`, `criteria`	Assets of type "server"
`invgate_get_server`	`asset_id` (required)	Single server asset
`invgate_get_health`	none	API connectivity status
`invgate_list_software`	`page`, `per_page`, `criteria`	Paginated installed-software catalog

Parameter mapping

Tool inputs use snake_case; the server maps them to the InvGate API query parameters. per_page → page_size, asset_type_id → asset_types. The criteria object maps to InvGate's nested syntax: { "name": "cont:MacBook" } becomes criteria[name]=cont:MacBook on the query string (op examples: cont, eq, startswith, …).

Results & errors

Success: the raw JSON response body, pretty-printed, as MCP text content.
Errors: structured JSON { "error": "...", "message": "...", "status": ... } as text content with isError: true. Types: validation_error, auth_error, api_error, network_error.

Development

npm install
npm run build       # tsup → dist/index.js (single ESM bundle)
npm run typecheck   # tsc --noEmit
npm test            # vitest run (59 tests, MSW for HTTP interception)
npm run test:coverage # vitest run --coverage (80% gate on src/**)
npm run dev         # tsx src/index.ts

Requires Node.js 20+ (uses native fetch).

License

MIT

Available Tools

12 tools

invgate_get_assetA

Retrieve a single asset by its ID.

ParametersJSON Schema

Name	Required	Description	Default
`asset_id`	Yes	Asset ID (positive integer).

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states retrieval, omits behavioral traits like read-only nature, required permissions, error handling (e.g., ID not found), or response format. Minimal disclosure beyond the obvious.

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?

Single sentence of 7 words, no redundancy, front-loaded with essential information. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter retrieval tool, description is adequate but omits return format and error behavior (no output schema). Could be more informative about what fields are returned or what happens on missing ID.

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

Parameters3/5

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

Schema covers 100% of parameters with description 'Asset ID (positive integer).' Description adds no additional meaning beyond 'by its ID', so no extra value. Baseline 3 is appropriate.

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?

Description clearly states verb 'Retrieve', resource 'single asset', and method 'by its ID'. Distinguishes from sibling list tools and other get tools for different entities.

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?

Implies usage when you know the asset ID and need a specific asset. Context with siblings suggests when not to use (e.g., for multiple assets use list), but no explicit exclusions or alternatives are stated.

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

invgate_get_computerA

Retrieve a single computer by its asset ID.

ParametersJSON Schema

Name	Required	Description	Default
`asset_id`	Yes	Computer asset ID (positive integer).

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided. Description does not disclose behavioral traits such as permissions, side effects, or return format. For a read operation, it fails to add value beyond the schema.

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?

Single sentence, front-loaded with verb and resource. No wasted words. Efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple retrieval with one parameter and no output schema, the description is mostly sufficient. However, missing return value description could be improved.

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

Parameters3/5

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

Schema coverage is 100%, and the description does not add meaning beyond what the schema provides for the sole parameter 'asset_id'. Baseline 3 applies.

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 verb 'retrieve' and the resource 'single computer by its asset ID'. It distinguishes from sibling tools like invgate_list_computers (list) and invgate_get_asset (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage: use when you have an asset ID and need one computer. No explicit guidance on when to use this vs. alternatives like invgate_get_asset or invgate_list_computers. Context is minimal.

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

invgate_get_healthA

Check InvGate API connectivity status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, and the description only repeats the tool's action without disclosing behavioral traits such as what the response contains (e.g., boolean, status object) or any rate limits. This leaves the agent guessing about the output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It could include minimal output expectations without becoming verbose, so it is not a perfect 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should hint at the return value. It does not, leaving the agent unaware of what a 'connectivity status' response looks like. For a simple health check, this is a notable gap.

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

Parameters4/5

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

With zero parameters and 100% schema coverage, the baseline score is 4. The description adds no param-specific detail, but none is needed.

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 checks API connectivity, using a specific verb ('Check') and resource ('InvGate API connectivity status'). It distinguishes from siblings like invgate_get_asset, which retrieve specific resources.

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 use case for verifying API connectivity is clear from the description, but no explicit guidance on when to use or alternatives is given. However, the context is sufficient given the tool's simplicity.

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

invgate_get_personB

Retrieve a single person by ID.

ParametersJSON Schema

Name	Required	Description	Default
`person_id`	Yes	Person ID (positive integer).

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only says 'retrieve'. It omits details like read-only nature, error behavior, permissions, or field names returned. The implied read-only nature is not explicitly confirmed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, concise and front-loaded. However, it could include more useful details without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-param retrieval tool with no output schema, the description is minimally adequate. It lacks information on return format, error handling, or completeness of data, but given simplicity, it just meets the threshold.

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

Parameters3/5

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

Schema coverage is 100% with description for 'person_id' already stating 'Person ID (positive integer)'. The tool description adds no extra semantic value beyond the 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 verb 'retrieve' and resource 'person by ID', distinguishing it from sibling tools that retrieve assets, computers, etc., or list operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like invgate_list_people or invgate_get_person_assets. The description only states what it does, not when it's appropriate.

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

invgate_get_person_assetsB

List assets assigned to a person by their person ID.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (1-based).
`per_page`	No	Items per page (max 200).
`person_id`	Yes	Person ID whose assigned assets to retrieve.

TDQS

B3.4/5.0

Behavior2/5

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 states the core function without mentioning pagination, error handling, or result ordering.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence without fluff, but it could include a brief note on pagination to improve usability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic purpose but lacks information on pagination or expected output format, which is important for a list tool with no output schema.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond what the schema already provides for each parameter.

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 verb 'List' and the resource 'assets assigned to a person by their person ID', distinguishing it from sibling tools that list all assets or get a single asset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing assets by person ID but provides no explicit guidance on when to use this tool versus alternatives like invgate_list_assets.

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

invgate_get_serverB

Retrieve a single server by its asset ID.

ParametersJSON Schema

Name	Required	Description	Default
`asset_id`	Yes	Server asset ID (positive integer).

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It only states 'retrieve', implying a safe read operation, but does not mention permissions, side effects, or rate limits. Minimal context beyond the basic operation.

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 a single sentence that conveys all essential information without redundancy. It is efficiently written and front-loaded with the key action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter, no output schema), the description is largely adequate. However, hinting at the return structure or fields would improve completeness, as there is no output schema to rely on.

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

Parameters3/5

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

The schema covers the sole parameter with description and constraints. The tool description adds no additional semantic meaning beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'retrieve', the resource 'server', and the method 'by its asset ID'. It distinguishes from sibling tools like invgate_list_servers (list) and invgate_get_asset (more generic). It lacks details on what fields are returned, but is specific enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs siblings, such as invgate_get_asset. The description implies usage for retrieving a single server, but does not mention alternatives or 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.

invgate_list_assetsB

List and search assets. Supports pagination, asset-type filter, and criteria.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (1-based).
`criteria`	No	InvGate nested criteria, e.g. { "name": "cont:MacBook" }. Each entry becomes criteria[field]=op:value on the query string.
`per_page`	No	Items per page (max 200).
`asset_type_id`	No	Filter assets by asset type ID.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided; the description carries full burden. It states supported features (pagination, filters) but does not mention whether the operation is read-only, any authentication needs, rate limits, or side effects. As a list operation, likely read-only, but not explicit.

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?

Single sentence with front-loaded purpose ('List and search assets') followed by concise enumeration of supported features. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers basic purpose and features, but lacks details on return format, ordering, error handling, and how it differs from sibling list tools. Given no output schema, more context would be helpful for an agent to use correctly.

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

Parameters3/5

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

Schema coverage is 100%, so each parameter has a description. The description adds context by grouping features (pagination -> page/per_page, filter -> asset_type_id, criteria) but does not provide new meaning beyond the schema descriptions. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List and search assets', which is a specific verb+resource. It mentions key capabilities (pagination, asset-type filter, criteria), distinguishing it from sibling tools like invgate_get_asset (single asset) and invgate_list_computers (specific type). However, it could more explicitly contrast with type-specific lists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. The sibling tools include type-specific lists (invgate_list_computers) and single asset retrieval (invgate_get_asset), but the description does not help choose between them.

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

invgate_list_asset_typesA

List all asset types registered in InvGate.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations exist, so the description must inform behavioral aspects. It only states 'List all asset types', but does not disclose if authentication is required, rate limits, or return format. Minimal behavioral insight.

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?

A single, clear sentence with no unnecessary words. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and a simple task, the description suffices. However, it could briefly mention what kind of data is returned (e.g., list of names) to be fully complete.

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

Parameters4/5

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

The tool has zero parameters, so the baseline is 4 per guidelines. The description adds no parameter info, but none is needed.

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 verb 'List' and the resource 'asset types registered in InvGate'. It distinguishes from sibling tools which list other entities like assets, computers, or people.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. Usage is implied from the name and description, but no when-not-use conditions or sibling comparisons are provided.

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

invgate_list_computersA

List computer assets with pagination and optional search criteria.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (1-based).
`criteria`	No	InvGate nested criteria, e.g. { "name": "cont:MacBook" }. Each entry becomes criteria[field]=op:value on the query string.
`per_page`	No	Items per page (max 200).

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It accurately describes the tool as listing computers with pagination and search, but does not mention any side effects, access requirements, or limitations (e.g., rate limits). This is minimally 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that immediately conveys the tool's core functionality. No superfluous information, perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no output schema, and no annotations, the description is adequate but not fully complete. It lacks details on return format, how criteria nesting works, and differentiation from siblings like invgate_list_assets. Fills basic needs but leaves gaps.

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

Parameters3/5

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

Schema description coverage is 100%, with each parameter already documented. The description adds no new semantic meaning beyond the schema; it merely echoes the existence of pagination and search. Baseline 3 is appropriate.

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 verb 'List', the resource 'computer assets', and key features 'pagination and optional search criteria'. It effectively distinguishes from siblings like invgate_list_assets (all assets) and invgate_get_computer (single computer).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. With siblings like invgate_list_assets and invgate_get_computer, the description does not clarify when to choose this tool, leaving the agent to infer from the name alone.

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

invgate_list_peopleC

List people with pagination and optional search criteria.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (1-based).
`criteria`	No	InvGate nested criteria, e.g. { "name": "cont:MacBook" }. Each entry becomes criteria[field]=op:value on the query string.
`per_page`	No	Items per page (max 200).

TDQS

C2.9/5.0

Behavior2/5

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 mentions pagination and optional search criteria, but does not explain default behavior, output format, authentication needs, or potential side effects. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, one sentence, with the main action front-loaded. No wasted words, though it could benefit from slightly more detail without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given three parameters, no output schema, and no annotations, the description is incomplete. It does not explain the criteria format, pagination defaults, or return structure, leaving ambiguity for the agent.

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

Parameters3/5

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

Schema coverage is 100%, with each parameter described in the schema. The description adds no additional meaning beyond the schema, meeting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'people', with pagination and optional search. However, it does not differentiate from siblings like invgate_list_assets or invgate_get_person, though the resource name is distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. No mention of prerequisites, limitations, or exclusions. The description only states what it does, not when to use it.

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

invgate_list_serversB

List server assets with pagination and optional search criteria.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (1-based).
`criteria`	No	InvGate nested criteria, e.g. { "name": "cont:MacBook" }. Each entry becomes criteria[field]=op:value on the query string.
`per_page`	No	Items per page (max 200).

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'List server assets with pagination and optional search criteria', which implies a read-safe operation but omits details on rate limits, sorting, data access scope, or response format.

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 a single, concise sentence that front-loads the core purpose. Every word is necessary and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters (including a nested criteria object), no output schema, and no annotations, the description is overly sparse. It does not explain the criteria format, result pagination behavior, or what constitutes a 'server asset', leaving critical gaps for the agent.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description adds minor context ('pagination and optional search criteria') but does not significantly enhance understanding beyond the schema's parameter descriptions.

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 'List server assets' with a specific verb and resource, and it distinguishes from sibling tools like invgate_list_assets (all assets) and invgate_list_computers (computers).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer from the tool name alone.

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

invgate_list_softwareB

List installed software with pagination and optional search criteria.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (1-based).
`criteria`	No	InvGate nested criteria, e.g. { "name": "cont:MacBook" }. Each entry becomes criteria[field]=op:value on the query string.
`per_page`	No	Items per page (max 200).

TDQS

B3.3/5.0

Behavior2/5

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

No annotations; description only says 'List installed software' without disclosing side effects, authorization, or rate limits. Lacks default pagination behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise and front-loaded with verb, but could list key features for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema; description lacks return format or defaults. Nested criteria brief but incomplete. Sibling context not leveraged.

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

Parameters3/5

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

Schema covers 100% of parameters with descriptions; description adds 'optional search criteria' but little beyond that.

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?

Description clearly states 'List installed software' with pagination and search, distinguishing from sibling tools that list assets, computers, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Indicates pagination and search are available, but no explicit when-to-use or alternatives guidance.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: get/list for assets, computers, servers, people, and specialized tools for asset types, software, and health. No overlapping purposes.

Naming Consistency5/5

All tools follow the consistent pattern 'invgate_<verb>_<noun>' with snake_case. Verbs are either 'get', 'list', or 'check', and nouns clearly identify the resource.

Tool Count5/5

12 tools is well-scoped for an asset management interface, covering the main entities and common operations without being excessive or sparse.

Completeness2/5

The tool set only provides read operations (get, list) and lacks any create, update, or delete capabilities. For a full asset management lifecycle, this is a significant gap, potentially causing agent failures when write operations are needed.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Microsoft MCP Server for Enterprise
io.github.microsoft
Official Microsoft MCP Server to query Microsoft Entra data using natural language
Search Security
252
Dataassist-IO
io.github.DataAssistIO
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Search Databases
2
mcpOAuth
com.gibsonai
GibsonAI MCP server: manage your databases with natural language
Databases Search
233
ambiscribe
io.ambiscribe
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Monitoring Observability Security
2

Related MCP Servers

InvGate Service Desk
Customer Support Knowledge & Memory
tracegazer
A
license
C
quality
C
maintenance
MCP server for InvGate Service Desk — manage incidents, users, knowledge base, assets and time tracking from any AI assistant.
Updated 2 months ago (2026-07-14 08:44 UTC)
63
3
MIT
servicenow-mcp
ausper-tech
A
license
A
quality
C
maintenance
A read-only MCP server that enables AI assistants to query ServiceNow instances—incidents, changes, users, CMDB—with malformed query linting and injection protection.
Updated 2 months ago (2026-07-20 13:55 UTC)
7
MIT
meraki-mcp
Networking & Infrastructure Observability
reshif
A
license
Not graded
quality
B
maintenance
A read-only MCP server for Cisco Meraki Dashboard, enabling LLMs to discover devices, check health, troubleshoot, and generate reports via natural language.
Updated a month ago (2026-07-26 13:39 UTC)
MIT
bigfix-root-mcp
Databases Monitoring
jgstew
A
license
A
quality
A
maintenance
A read-only MCP server for the HCL BigFix root server REST API, enabling session relevance queries, client fast queries, and server/site/operator lookups through natural language.
Updated 19 days ago (2026-08-17 16:41 UTC)
11
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/wdelcant/invgate-mcp'

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