Skip to main content
Glama

Foundry MCP

by com.foundry-mcp
OverviewDiscussionsAdmin

effect-toggle-status

Toggle a D&D 5e condition on an actor, or on ONE token via tokenId (dnd5e worlds only; in PF2e worlds use pf2e-set-condition / pf2e-remove-condition). Several copies of one actor: tokenId makes only that goblin prone.

Core D&D 5e status IDs: blinded, charmed, deafened, exhaustion, frightened, grappled, incapacitated, invisible, paralyzed, petrified, poisoned, prone, restrained, stunned, unconscious.

Input Schema

NameRequiredDescriptionDefault
activeNotrue = add, false = remove; omitted = toggle
actorIdNoActor ID (from actor-list/actor-filter)
overlayNoShow as the large overlay icon
sceneIdNoScene of tokenId (default: active)
tokenIdNoToken ID (from token-list) instead of actorId: that token's own actor (module 8.14+)
statusIdYesStatus ID: "blinded", "poisoned", "prone", …

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedInput schema / properties / active / description
      Previous value: -"Explicitly set active state (true = add, false = remove). If not specified, toggles current state."New value: +"true = add, false = remove; omitted = toggle"
    • changedInput schema / properties / actorId / description
      Previous value: -"The actor ID to toggle status on"New value: +"Actor ID (from actor-list/actor-filter)"
    • changedInput schema / properties / overlay / description
      Previous value: -"If true, shows as large overlay icon on token"New value: +"Show as the large overlay icon"
    • addedInput schema / properties / sceneId
      Added value: +{
+  "description": "Scene of tokenId (default: active)",
+  "type": "string"
+}
    • changedInput schema / properties / statusId / description
      Previous value: -"The status/condition ID (e.g., \"blinded\", \"poisoned\", \"prone\")"New value: +"Status ID: \"blinded\", \"poisoned\", \"prone\", …"
    • addedInput schema / properties / tokenId
      Added value: +{
+  "description": "Token ID (from token-list) instead of actorId: that token's own actor (module 8.14+)",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "actorId",
-  "statusId"
-]New value: +[
+  "statusId"
+]
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare non-readOnly, non-destructive, non-idempotent and closed-world, so the safety profile is covered; the description adds real behavioral context about token-scoped application ("only that goblin prone") and world-type gating. It stops short of saying what happens when the status is already present/absent or how the change is reported.

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?

Front-loaded scoping rule and target-selection caveat come first, followed by the useful status-ID enumeration; no sentence is redundant and the status list compensates for the absent enum.

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 6-parameter mutation tool with no output schema, the description covers target selection, world gating, alternatives and valid values adequately. Return/shape information and the no-op case (status already applied) are the only noticeable omissions.

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 baseline is 3, but the description adds meaning the schema lacks: the semantic difference between actorId and tokenId in worlds with duplicate actor copies, and a concrete list of valid status IDs since no enum is defined. That is genuine value beyond the structured fields.

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 (toggle) and resource (a D&D 5e condition on an actor or a single token), and immediately distinguishes itself from the PF2e alternatives by naming pf2e-set-condition / pf2e-remove-condition. An agent can route between this and the sibling set without opening either schema.

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?

Explicitly scopes usage to dnd5e worlds and names the PF2e replacement tools for the other case, plus clarifies the actorId-vs-tokenId selection rule when several copies of an actor exist. Both the when and the when-not are stated.

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

All Foundry MCP toolsInspect
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