How do I use inception-mcp?

1. Click on "Deploy 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., "@inception-mcp show me any doors that are unlocked" 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.

inception-mcp

by ndwalters

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

inception-mcp

A small, read-only MCP server for the Inner Range Inception REST API. It lets an MCP client (Claude Code, Claude Desktop, etc.) see areas, doors, inputs, outputs and the review (event) log. It cannot arm, disarm, unlock, toggle outputs or change configuration.

Tools

Tool	What it does
`inception_get_system_info`	System name, serial, REST protocol version, and whether the firmware is supported (7.3.0.8528 or later)
`inception_list_items`	Areas / doors / inputs / outputs with decoded state (`Disarmed`, `Locked`, `Active`, ...). Filter by `name_contains` and `has_state` (e.g. inputs that are `Active` = open zones)
`inception_get_events`	Review log query: time range, categories, event type IDs, involved item IDs, pagination. Events come back with category and event-type name
`inception_list_event_types`	Offline search of the 500 event types in the API docs, to find IDs for `message_ids` (e.g. "disarmed" → 5201)

Related MCP server: entraid-mcp

Why it is read-only

The HTTP client only issues GET and only to these fixed paths: /api/protocol-version, /api/v1/system-info, /api/v1/control/{area|door|input|output}/summary and /api/v1/review. There is no generic "call any endpoint" tool and no request bodies.
No user, credential, PIN or configuration endpoints are exposed.
Give the Inception API user only the permissions it needs to see items. If the panel has no view-only permission level, remove Arm/Disarm/Control/Access rights entirely: controls would then fail with 403 even if this code had a bug.

Setup

1. Inception API user

In Inception: Users → Manage Users, add a user (e.g. MCP Read-only).
Set Web Page Profile to REST Web API User.
Under Permissions, add the areas, doors, inputs and outputs you want visible (minimum rights).
Under Credentials → User API Token, generate a token. Generating a new one invalidates the old one.
Enable Review permission for the user if you want events (a 404 on /review usually means it is missing).

2a. Claude Desktop: one-click bundle (recommended)

Download inception-mcp.mcpb from the latest release, then double-click it, or drag it into Claude Desktop (or Settings → Extensions → Advanced settings → Install Extension).
Click Install, then fill in the form using:
1. The controller URL (either local http://192.168.1.50 or through your SkyTunnel serial https://skytunnel.com.au/Inception/IN12345678).
2. The previously created Inception User API Token.
Enable the extension.

No Node.js install, no config-file editing: Claude Desktop runs the bundle with its built-in Node runtime, and the token is marked sensitive so it is stored in your OS credential store (Windows Credential Manager / macOS Keychain) rather than in a plain-text JSON file. To change the URL or token later: Settings → Extensions → Inner Range Inception → Configure.

2b. Claude Code (or any stdio MCP client)

Needs Node.js 20+.

npm install          # also builds dist/ via the prepare script
claude mcp add inception --scope user \
  -e INCEPTION_URL=<your Inception URL> \
  -e INCEPTION_API_TOKEN=<your User API Token> \
  -- node "$(pwd)/dist/index.js"

Stdio is the default transport, so nothing else is required. The client launches the server as a child process on demand; there is no port and nothing to keep running.

Building the bundle yourself

npm install
npm run pack:mcpb     # -> inception-mcp.mcpb (validated against the MCPB manifest schema)

manifest.json defines the install form (user_config) and maps it to environment variables. Bump version in package.json and re-pack to release an update; installing the new .mcpb replaces the old one.

Firmware / protocol version

Requires Inception firmware 7.3.0.8528 or later (REST API protocol version 18). This is fixed, not configurable: the server checks GET /api/protocol-version when it starts and exits with a clear message on older firmware. To check your controller:

curl http://<inception-ip>/api/protocol-version

If the panel is unreachable at startup the server still starts (with a warning) and tools return a clear error until it is back.

Available Tools

4 tools

inception_get_eventsQuery Inception review eventsA

Read-onlyIdempotent

Queries the controller's review (event) log. Returns most recent first by default. Each event has a numeric messageId, its category (System, Audit, Access, Security, Hardware, Integration), an event type name and the panel's description, plus who/what/where. Filter by time range, category, message IDs (use inception_list_event_types to find IDs, e.g. area armed/disarmed) or involved item IDs. For paging use offset, or reference_id + reference_time from an earlier event instead of start/end.

Name	Required	Description	Default
`end`	No	ISO 8601 end of range. Not combinable with reference_id.
`limit`	No	Maximum events to return (panel default is 100).
`start`	No	ISO 8601 start of range, e.g. 2026-09-25T09:00:00. Not combinable with reference_id.
`offset`	No	Events to skip, for pagination.
`direction`	No	desc = newest first, asc = oldest first.	desc
`categories`	No	Only these event categories.
`message_ids`	No	Only these numeric event type IDs.
`involved_ids`	No	Only events whose who/what/where ID matches one of these item or user IDs.
`reference_id`	No	ID of an anchor event (use with reference_time). Not combinable with start/end.
`reference_time`	No	ReferenceTime of the anchor event.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds behavior beyond that: default sort order (most recent first), the shape of each returned event, and the mutual-exclusivity rule that reference_id/reference_time cannot be combined with start/end.

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?

Front-loaded with what the tool returns, then filtering, then paging – a logical order with no filler sentences. It is dense but slightly cramped, packing return fields, filters, and two paging modes into four sentences.

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

Completeness5/5

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

With 10 optional parameters and no output schema, the description compensates by describing the return record structure and both paging approaches. An agent has everything needed to construct a correct call without opening the schema.

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?

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema does not: it explains the two paging strategies (offset vs. reference_id + reference_time) and that message_ids correspond to event type IDs discoverable via inception_list_event_types. That cross-tool linkage is genuine added value.

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?

States a specific verb and resource ('Queries the controller's review (event) log') and enumerates the returned fields (messageId, category, type name, description, who/what/where), which is more than a name restatement. It routes the agent to the sibling inception_list_event_types for resolving message IDs, distinguishing it from the other siblings.

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?

Gives clear usage context: filter by time range, category, message IDs, or involved item IDs, and use inception_list_event_types to find IDs. It also names the preferred paging mechanism (offset, or reference_id + reference_time instead of start/end). It lacks explicit guidance on when NOT to use this tool versus siblings like inception_get_system_info, so it falls short of a 5.

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

inception_get_system_infoInception system infoA

Read-onlyIdempotent

Returns the Inception controller's name, serial number and REST API protocol version, and whether the firmware is supported (7.3.0.8528 or later, protocol version 18). Use it to confirm connectivity.

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/non-destructive, so safety is covered. The description adds real behavioral context: it enumerates the returned fields and defines the firmware support threshold (7.3.0.8528+, protocol 18), which tells the agent how to interpret the result.

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?

One compact sentence states the return payload and the support criterion, followed by a short usage clause. Front-loaded with the tool's output, no filler.

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

Completeness5/5

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

With no parameters, complete annotation coverage, and no output schema, the description fully compensates by listing what is returned and the version threshold. An agent has everything needed to call and interpret it.

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?

There are zero parameters, so per the rubric the baseline is 4. Nothing further is required of the description on this dimension.

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?

States a specific verb (Returns) and resource (Inception controller's name, serial number, API protocol version, firmware support status). Clearly distinguishable from the sibling list_* tools, which enumerate items/events rather than reporting controller identity.

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?

"Use it to confirm connectivity" gives a clear context for invoking it. It does not name alternatives or state when-not to use it, but for a zero-arg diagnostic read that exclusion set is small.

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

inception_list_event_typesLook up Inception event type IDsA

Read-onlyIdempotent

Searches the catalogue of review event types (from the Inception API docs) so you can find numeric IDs to pass as message_ids to inception_get_events. Example: query='armed' or 'disarm', category='Security'. Works offline; does not contact the panel.

Name	Required	Description
`limit`	No
`query`	No	Case-insensitive words to match against the event type name, e.g. 'door forced' or 'disarmed'.
`category`	No
`include_obsolete`	No

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: it works offline and does not contact the panel, which concretizes the openWorld=false hint and matters for an agent reasoning about 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.

Conciseness5/5

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

Two tightly packed sentences: purpose and downstream use first, then an example, then the offline caveat. Every clause earns its place with zero filler.

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 read-only lookup with no output schema, the description conveys what it returns (numeric event type IDs) and the offline behavior. The gap is the unexplained limit and include_obsolete parameters, which an agent must infer from the schema alone.

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 only 25%, so the description must compensate. It clarifies query and category semantics via examples ('armed'/'disarm', category='Security'), but says nothing about limit's pagination cap or include_obsolete's default and purpose, leaving two parameters undocumented in both places.

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?

States a specific verb+resource ('Searches the catalogue of review event types') and clarifies its role as an ID-lookup aid for inception_get_events. An agent can distinguish this from inception_get_events and the other siblings without opening any schema.

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?

Clearly frames when to use it: to find numeric IDs to pass as message_ids to inception_get_events, with concrete example queries. It does not provide explicit when-not-to-use guidance or disambiguate against inception_list_items, so it falls short of a 5.

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

inception_list_itemsList Inception items with current stateA

Read-onlyIdempotent

Lists areas, doors, inputs or outputs the API user can see, each with its current state decoded into names. Area states include Armed, Disarmed, Alarm, EntryDelay, ExitDelay, ArmReady, AwayArm (Full), StayArm (Perimeter), SleepArm (Night). Door states include Locked, Unlocked, Open, Closed, Forced, HeldOpenTooLong, LockedOut. Input states include Active (unsealed/open), Sealed, Tamper, Isolated. Output states are On/Off. Use has_state to filter, e.g. type=input with has_state=["Active"] lists open zones.

Name	Required	Description
`type`	Yes	Kind of item to list.
`limit`	No	Maximum items to return.
`has_state`	No	Only return items whose decoded state includes ALL of these names (case-insensitive).
`name_contains`	No	Case-insensitive substring to match against the item name.

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: it explains that states are decoded into human-readable names and gives the vocabulary for each item type, which is essential to interpreting results.

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?

Front-loaded with purpose, then the state enumerations, then the filter example. The long state lists are dense but each set maps to a valid type value, so most sentences earn their place; it is slightly list-heavy but not padded.

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?

No output schema exists, so the description carries some return-value burden: it tells the agent each item comes with a decoded state, but never describes the item's shape (id, name fields) or result ordering/pagination behavior. Adequate for choosing the tool, incomplete for consuming its output.

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%, so all four parameters are already documented in the schema; the baseline is 3. The description reinforces has_state semantics and adds a worked example linking type=input with has_state, but adds no format or syntax detail the schema lacks.

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?

States a specific verb (Lists) and resource (areas, doors, inputs or outputs) with scope ('the API user can see') and explains what 'current state' means by enumerating decoded state names per type. This clearly separates it from siblings like inception_get_events and inception_get_system_info.

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?

It provides a concrete usage example for the has_state filter ('type=input with has_state=["Active"] lists open zones'), which teaches how to apply the tool. However it never says when to prefer this over inception_get_events or other siblings, nor any exclusions, so usage is implied rather than guided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.3Oct 7, 2026
- First observedinception_get_events
- First observedinception_get_system_info
- First observedinception_list_event_types
- First observedinception_list_items

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-10-07 07:40 across 4 tools

Disambiguation5/5

Each tool targets a clearly distinct purpose: connection/system metadata, listing configured items, browsing the offline event-type catalogue, and querying the event log. The only superficially similar pair (list_event_types vs get_events) is explicitly disambiguated in the descriptions as catalogue lookup versus actual log query.

Naming Consistency5/5

All four tools use a uniform prefix + verb_noun pattern (inception_get_system_info, inception_list_items, inception_list_event_types, inception_get_events). No casing or verb-style deviations.

Tool Count4/5

Four tools is lean but defensible for a read/inspection-focused integration, and each tool earns its place. It is slightly under-scoped rather than bloated.

Completeness3/5

Coverage is read-only: connectivity, item listing, event-type lookup, and event retrieval are all present, but there is no way to act on the panel (arm/disarm areas, control doors or outputs) and no per-item detail fetch. For a security panel integration, the absence of any control operation is a notable gap.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

KrystalView Analytics A
io.github.KrystalView
Read-only MCP access to sessions, funnels, campaigns, errors, live visitors, and anomalies.
Monitoring Observability
132
https://krystalview.com/mcp
ambiscribe
io.ambiscribe
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Monitoring Observability Security
2
https://mcp.ambiscribe.io/mcp
Infrly
com.getinfrly
Read-only access to your Infrly services, deploys, logs, metrics and billing.
Cloud Platforms Observability
1
https://mcp.getinfrly.com/mcp
InfluSense AIOAuth
io.github.Case-resolve-tech
Read-only access to InfluSense influencer discovery, ratings, watchlists, and reports via MCP.
Marketing Social Media
1
https://mcp.influsense.tech/mcp

Related MCP Servers

KVMFleet MCP Serverofficial
Virtualization Monitoring
KVMFleet
A
license
A
quality
D
maintenance
Read-only MCP server that allows AI assistants to query and monitor KVM Fleet devices, audit logs, and console sessions through the official REST API.
Updated 4 months ago (2026-06-26 12:25 UTC)
5
2 npm
1
MIT
entraid-mcp
Security Cloud Platforms
sedattavukcu
F
license
Not graded
quality
C
maintenance
Read-only MCP server for Microsoft Entra ID (Azure AD) that enables querying user sign-in logs, group memberships, and assigned Microsoft 365 licenses via Microsoft Graph API. Provides security and audit visibility without any write operations.
Updated 3 months ago (2026-08-07 14:57 UTC)
-
trmm-mcp
OS Automation Observability
JohnGilligan2
A
license
Not graded
quality
C
maintenance
Enables read-only MCP access to Tactical RMM, allowing agents to query devices, clients, sites, audit logs, software, and pending actions without any mutating capabilities.
Updated 2 months ago (2026-08-22 03:31 UTC)
MIT
Timesheet Portal MCP server
ERP Systems Finance Project Management
dragosh29
A
license
A
quality
C
maintenance
Enables MCP clients such as Claude and ChatGPT to read a Timesheet Portal account, including timesheet time and cost reports, invoices, leave bookings and balances, projects or jobs, clients, users and cost centres, across both the Standard and Recruitment editions. It is read-only, with personal and pay data withheld unless explicitly requested.
Updated 24 days ago (2026-09-30 09:27 UTC)
8
MIT

inception-mcp

Tools

Why it is read-only

Setup

1. Inception API user

2a. Claude Desktop: one-click bundle (recommended)

2b. Claude Code (or any stdio MCP client)

Building the bundle yourself

Firmware / protocol version

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

KVMFleet MCP Serverofficial