Skip to main content
Glama
Txpple

fvtt-mcp-molten5e

by Txpple
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

set-actor-ownership

Control player permissions for actors: grant full ownership, observer, limited, deny, or reset to default, for individuals or entire groups.

Instructions

Set ownership permissions for actors. Use permissionLevel OWNER/OBSERVER/LIMITED to grant access, NONE to explicitly deny it (a stored level-0 entry that OVERRIDES the actor's default ownership), or INHERIT to remove the player's entry so the actor's default applies again. On an actor whose default is permissive (e.g. a shared party stash defaulting to OWNER), NONE revokes access the player would otherwise inherit and INHERIT is what restores it. Supports individual assignments like "Make John the owner of Aragorn" and bulk operations like "Give the party observer access to all friendly NPCs".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorIdentifierYesActor name, ID, or "all friendly NPCs" for bulk operations. Use "party characters" for all player-owned actors.
permissionLevelYesPermission level to assign: LIMITED (basic view), OBSERVER (full view, no control), OWNER (full control), NONE (explicitly DENY — stores a level-0 entry that overrides the actor's default, so it revokes access the player would otherwise inherit), INHERIT (remove the player's entry entirely so the actor's default ownership applies again)
playerIdentifierYesPlayer name, character name, or "party" for all connected players. Supports partial matching.
confirmBulkOperationNoRequired confirmation for bulk operations affecting multiple actors/players

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.3
    • changedInput schema / properties / permissionLevel / description
      Previous value: -"Permission level to assign: NONE (no access), LIMITED (basic view), OBSERVER (full view, no control), OWNER (full control)"New value: +"Permission level to assign: LIMITED (basic view), OBSERVER (full view, no control), OWNER (full control), NONE (explicitly DENY — stores a level-0 entry that overrides the actor's default, so it revokes access the player would otherwise inherit), INHERIT (remove the player's entry entirely so the actor's default ownership applies again)"
    • changedInput schema / properties / permissionLevel / enum
      Previous value: -[
-  "NONE",
-  "LIMITED",
-  "OBSERVER",
-  "OWNER"
-]New value: +[
+  "NONE",
+  "LIMITED",
+  "OBSERVER",
+  "OWNER",
+  "INHERIT"
+]
  2. First observedv1.2.2

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It transparently explains the nuanced behavior of NONE (stores a level-0 entry that overrides default) and INHERIT (removes entry), and how these interact with permissive defaults. It does not mention that bulk operations require the confirmBulkOperation flag, nor potential side effects like reversibility, but the core semantics are well disclosed.

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 detailed but not overly long. It front-loads the purpose and then explains permission levels and examples. Every sentence adds value, though it could be tightened by removing the parenthetical example (e.g., shared party stash) which is illustrative but not essential. Overall it is well-structured and informative.

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 complexity, the description covers the core behavior, permission semantics, and usage examples. It misses the confirmBulkOperation requirement for bulk operations and does not mention error handling or prerequisites, but these are partly covered by the schema. It is nearly complete for an agent to call it correctly, but the missing confirmation detail 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?

Schema coverage is 100%, so the schema already documents each parameter. The description adds value by explaining the conceptual meaning of permission levels, giving examples for actor and player identifiers, and illustrating bulk operations. It enriches the parameter meaning beyond the enum descriptions, justifying a score above the baseline of 3.

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's purpose: setting ownership permissions for actors. It specifies the verb 'set', the resource 'ownership permissions for actors', and details the permission levels and their effects. It also differentiates from siblings like list-actor-ownership by focusing on assignment rather than listing. Examples of individual and bulk operations reinforce the scope.

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 description gives clear usage context with examples like 'Make John the owner of Aragorn' and 'Give the party observer access to all friendly NPCs', and explains when to use NONE vs INHERIT based on the actor's default. However, it does not explicitly mention alternatives or when not to use this tool (e.g., use list-actor-ownership for querying). It implies usage but lacks explicit exclusions.

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

Deploy Server

Other Tools