Baasix MCP Server

baasix_create_permission

Create role-based access control permissions by defining actions, allowed fields, and row-level security conditions for a collection.

Instructions

Create a new permission for role-based access control.

ACTIONS: create, read, update, delete

FIELDS:

["*"] for all fields
["name", "price"] for specific fields

CONDITIONS (Row-level security):

Uses same filter operators as queries
{"published": {"eq": true}} - only published records
{"author_Id": {"eq": "$CURRENT_USER"}} - only own records

RELCONDITIONS (Filter related data):

{"reviews": {"approved": {"eq": true}}} - only approved reviews in response

EXAMPLE: { "role_Id": "uuid", "collection": "products", "action": "read", "fields": ["*"], "conditions": {"published": {"eq": true}} }

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "role_Id": "<role_Id>",
      "collection": "<collection>",
      "action": "<action>"
    },
    "name": "baasix_create_permission"
  }
}

Input Schema

Name	Required	Description
`action`	Yes	Permission action
`fields`	No	Allowed fields (["*"] for all)
`role_Id`	Yes	Role ID (UUID)
`collection`	Yes	Collection name
`conditions`	No	Row-level security conditions using filter operators
`defaultValues`	No	Default values auto-set on creation (e.g., {"author_Id": "$CURRENT_USER"})
`relConditions`	No	Filter conditions for related records in response

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.7Aug 30, 2026

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It does a good job explaining the semantics of conditions, relConditions, and fields with concrete examples. However, it does not disclose side effects of creating a permission, such as whether it takes effect immediately, whether it can override existing permissions, or whether it might alter access control behavior in ways that could lock users out.

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 well-structured with clear section headers (ACTIONS, FIELDS, CONDITIONS, RELCONDITIONS, EXAMPLE) and front-loaded with the core purpose. It is longer than average but every section contributes useful information. A small deduction because the example block repeats some information from the schema and the structure could be slightly tighter.

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 complexity of this permission creation tool (7 parameters, nested objects, no output schema), the description is largely complete. It explains the important non-obvious concepts: field whitelisting, row-level security conditions, and related record filtering, each with examples. It does not mention the return value or any permission required to call the tool, but these are minor gaps for an AI being able to construct a valid request.

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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by providing concrete JSON examples for conditions (e.g., {"published": {"eq": true}}), relConditions (e.g., {"reviews": {"approved": {"eq": true}}}), and fields (e.g., ["name", "price"]), which clarifies the expected structure for nested objects. It does not explicitly walk through defaultValues, but the schema already covers that sufficiently.

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 'Create a new permission for role-based access control,' which combines a specific verb (create), a specific resource (permission), and the domain context (role-based access control). This clearly distinguishes it from sibling tools like baasix_update_permission, baasix_delete_permission, and baasix_list_permissions, so an agent can immediately know which tool to pick.

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

Usage Guidelines2/5

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

The description explains how to structure a permission but never states when to use this tool versus the many sibling permission tools (update, delete, get, list). There is no explicit guidance about selecting this tool for creation over others, nor any mention of prerequisites or scenarios such as 'use this to grant a role access to a collection.' The intent is only implicit through the verb 'create.'

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

Deploy Server