Port OS Smart Home

endpoint_manage

DestructiveIdempotent

Manage the names, types and registry entries of your devices and connected services.

Send the complete name, type and enablement document for every metadata replacement, with etag from the read and a stable idempotencyKey. Choose one operation: RENAME, SET_TYPE, SET_ENABLEMENT, MERGE_INTO, or DELETE. Use endpoint_query first and copy the full endpoint ID. Rename and type changes are durable across provider rediscovery. Disabled endpoints stay available for explicit metadata reads, but cannot receive messages; rediscovery preserves the disabled state. DELETE removes the registry entry, though a provider may rediscover it later. MERGE_INTO retains the source endpoint as disabled and moves supported references to the target; it does not create a source-ID alias, a simulator endpoint can merge only into a target without a simulator route (two simulator endpoints return 409 CONFLICT; disable or delete the duplicate instead), and the target's enablement remains in effect. Before MERGE_INTO or DELETE, identify the actual endpoint and explain the effect to the user; never assume two endpoints are duplicates because their names match. This tool changes registry metadata only and never performs physical control.

Input Schema

Name	Required	Description
`etag`	Yes	Current endpoint writable document etag from endpoint_query.
`name`	No	Complete replacement name, required with type and enablement on metadata writes.
`type`	No	Complete replacement type, required with name and enablement on metadata writes.
`mergeInto`	No	Full target endpoint ID; only for MERGE_INTO.
`operation`	Yes
`enablement`	No	Complete replacement enablement, required with name and type on metadata writes.
`endpointId`	Yes	Full endpoint ID from endpoint_query.
`targetEtag`	No	Current target etag, required for MERGE_INTO.
`idempotencyKey`	Yes	Unique request key. Reuse it for retries of the same change for 24 hours.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 28, 2026

changedInput schema / properties / enablement / description

Previous value: -"New endpoint enablement; only for SET_ENABLEMENT."New value: +"Complete replacement enablement, required with name and type on metadata writes."

addedInput schema / properties / etag

Added value: +{
+  "description": "Current endpoint writable document etag from endpoint_query.",
+  "type": "string"
+}

addedInput schema / properties / idempotencyKey

Added value: +{
+  "description": "Unique request key. Reuse it for retries of the same change for 24 hours.",
+  "maxLength": 255,
+  "minLength": 1,
+  "type": "string"
+}

changedInput schema / properties / name / description

Previous value: -"New endpoint name; only for RENAME."New value: +"Complete replacement name, required with type and enablement on metadata writes."

addedInput schema / properties / targetEtag

Added value: +{
+  "description": "Current target etag, required for MERGE_INTO.",
+  "type": "string"
+}

changedInput schema / properties / type / description

Previous value: -"New ontological endpoint type; only for SET_TYPE."New value: +"Complete replacement type, required with name and enablement on metadata writes."

changedInput schema / required

Previous value: -[
-  "operation",
-  "endpointId"
-]New value: +[
+  "operation",
+  "endpointId",
+  "etag",
+  "idempotencyKey"
+]

First observedOct 27, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the destructive and idempotent annotations, the description discloses durable rename/type changes, disabled-state preservation, message-delivery implications of disabled endpoints, DELETE rediscovery behavior, MERGE_INTO source/target semantics, and simulator conflict behavior. It also clarifies that the tool changes registry metadata only and never performs physical control.

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 dense but front-loaded: purpose first, then operation model, then critical behavioral caveats. Despite its length, every sentence carries operationally relevant information for a destructive multi-operation tool.

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 an output schema and rich annotations already present, the description completes the picture by explaining prerequisites, operation-specific effects, disabled-state behavior, and merge/delete risks. Nothing essential for correct invocation appears to be missing.

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 high at 89%, so the schema already documents most parameters. The description adds useful meaning by framing name, type, and enablement as a complete replacement document and by emphasizing etag and idempotencyKey requirements for metadata writes.

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 states a specific verb and resource: managing names, types, registry entries, and enablement of devices and connected services. It enumerates the five operations and explicitly contrasts the tool with endpoint_query and physical control, so an agent can distinguish it from siblings.

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

Usage Guidelines5/5

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

It gives explicit workflow guidance: use endpoint_query first, copy the full endpoint ID, choose exactly one operation, and before MERGE_INTO or DELETE identify the actual endpoint and explain effects to the user. It also warns against assuming duplicates based on names and provides simulator-specific merge restrictions.

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

All Port OS Smart Home tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?