Skip to main content
Glama

Fine Structure

by ai.finestructure
OverviewDiscussionsAdmin

Set Entity Policy

set_entity_policy
Destructive

Replace server-side entity access policy. Optional action rules override read/write roles and can allow public create without public read, update, or delete. Omitting rules replaces any existing action rules with read/write role behavior.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
readYesRoles allowed to read when rules are omitted
rulesNoNonempty unconditional action/role rules. No matching rule denies access. Include owner/admin actions explicitly. Record conditions are not supported by this MCP input.
writeYesRoles allowed to write when rules are omitted
app_idYesThe app ID
entityYesEntity name, e.g. Booking

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / read / description
      Previous value: -"Roles allowed to read"New value: +"Roles allowed to read when rules are omitted"
    • addedInput schema / properties / rules
      Added value: +{
+  "additionalProperties": false,
+  "description": "Nonempty unconditional action/role rules. No matching rule denies access. Include owner/admin actions explicitly. Record conditions are not supported by this MCP input.",
+  "properties": {
+    "rules": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "actions": {
+            "items": {
+              "enum": [
+                "create",
+                "read",
+                "update",
+                "delete",
+                "write"
+              ],
+              "type": "string"
+            },
+            "minItems": 1,
+            "type": "array"
+          },
+          "description": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "subject": {
+            "additionalProperties": false,
+            "properties": {
+              "roles": {
+                "items": {
+                  "type": "string"
+                },
+                "minItems": 1,
+                "type": "array"
+              }
+            },
+            "required": [
+              "roles"
+            ],
+            "type": "object"
+          }
+        },
+        "required": [
+          "actions",
+          "subject"
+        ],
+        "type": "object"
+      },
+      "minItems": 1,
+      "type": "array"
+    },
+    "version": {
+      "enum": [
+        1
+      ],
+      "type": "integer"
+    }
+  },
+  "required": [
+    "rules"
+  ],
+  "type": "object"
+}
    • changedInput schema / properties / write / description
      Previous value: -"Roles allowed to write"New value: +"Roles allowed to write when rules are omitted"
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already mark the tool as destructive (destructiveHint: true) and not read-only, which aligns with 'replace' in the description. The description adds meaningful behavior beyond annotations: it states that omitting rules replaces any existing action rules with read/write role behavior, and that action rules can allow public create without public read – a non-obvious side effect. This goes beyond what annotations alone convey, giving the agent essential behavioral grounding without contradicting the structured metadata.

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 two sentences, front-loaded with the core purpose, and every clause adds critical information. There is no fluff, no redundant explanation of schema details, and it avoids boilerplate. The structure leads with the action, then explains the two behavioral modes (rules vs. omission) in a compact way. This is exemplary conciseness that respects the agent's attention.

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 tool with nested objects and no output schema, the description covers the essential decision logic: what 'replace' means, the override behavior, and the fallback when rules are omitted. It does not enumerate every rule-field (actions, subject, version) but those are documented in the input schema, so the description need not repeat them. The only minor omission is explicit mention that rules are 'unconditional' or that 'no matching rule denies access', but that is also in the schema. Overall, the description is sufficient for correct invocation.

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 each parameter is documented. The description adds value by explaining the interplay: rules override read/write roles, and omission causes a revert. This clarifies the relationship between the 'read', 'write', and 'rules' parameters – a semantic layer not fully captured in individual property descriptions. It is not just a restatement; it tells the agent how the parameters affect the system state, which is crucial for correct invocation.

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 opens with 'Replace server-side entity access policy' – a specific verb and resource pair that immediately conveys what the tool does. It does not merely restate the tool name; it distinguishes the action from related entity operations like create, update, or schema changes. The mention of 'read/write roles' and 'action rules' adds precision beyond a generic 'set policy' phrasing, making its scope unmistakable.

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 explains the key decision point: optional action rules override read/write roles, and omitting rules reverts to role-based behavior. This gives clear context for when to include rules versus rely on roles. It does not explicitly name a sibling alternative, but it implicitly differentiates from other policy-related tools like set_route_policy by focusing on entity access semantics. The behavior is described well enough for an agent to decide when to call this tool.

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

All Fine Structure toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources