Skip to main content
Glama
tspvivek

Baasix MCP Server

by tspvivek
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

baasix_create_relationship

Create relationships between collections using M2O, O2M, O2O, M2M, or M2A types. Auto-indexes foreign keys and generates junction tables to optimize query performance.

Instructions

Create a relationship between collections.

RELATIONSHIP TYPES:

  • M2O (Many-to-One): Creates foreign key with auto-index. products.category → categories

  • O2M (One-to-Many): Virtual reverse of M2O. categories.products → products

  • O2O (One-to-One): Creates foreign key with auto-index. user.profile → profiles

  • M2M (Many-to-Many): Creates junction table with auto-indexed FKs. products ↔ tags

  • M2A (Many-to-Any): Polymorphic junction table. comments → posts OR products

AUTO-INDEXING: All foreign key columns are automatically indexed for better query performance:

  • M2O/O2O: Index on the FK column (e.g., category_Id)

  • M2M/M2A: Indexes on both FK columns in junction tables

JUNCTION TABLES (M2M/M2A):

  • Auto-generated name: {source}{target}{name}_junction

  • Custom name: Use "through" property (max 63 chars for PostgreSQL)

  • Junction tables are marked with isJunction: true in schema

EXAMPLE M2O: { "name": "category", // Creates category_Id field + index "type": "M2O", "target": "categories", "alias": "products", // Reverse relation name "onDelete": "CASCADE" // CASCADE, RESTRICT, SET NULL }

EXAMPLE M2M: { "name": "tags", "type": "M2M", "target": "tags", "alias": "products" }

EXAMPLE M2M with custom junction table: { "name": "tags", "type": "M2M", "target": "tags", "alias": "products", "through": "product_tag_mapping" // Custom junction table name }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
relationshipDataYesRelationship configuration
sourceCollectionYesSource collection name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.7

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 load and does so well: it discloses auto-indexing on foreign keys, junction table naming rules, virtual reverse behavior for O2M, and the default onDelete behavior. It does not mention authorization requirements or whether creation is reversible, but the behavioral side effects are unusually well documented.

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 long but every section earns its place given the complexity of five relationship types. It is front-loaded with the core purpose, then organized by relationship types, auto-indexing, junction tables, and examples, with no filler or repeated schema content.

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 no-output-schema tool with no annotations, this is quite complete: it explains side effects, naming conventions, indexing, and provides runnable examples. It stops short of describing the return value, error conditions, or preconditions like target collection existence, which would round out the picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is already solid. The description adds substantial meaning beyond the schema: it explains that 'name' creates a fieldName_Id field plus index, shows what 'through' controls with a max length, clarifies 'alias' as the reverse relation name, and gives full examples with default onDelete behavior.

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?

Description states a clear action ('Create a relationship between collections') and goes beyond a bare verb by enumerating all five relationship types with concrete examples. The name is distinct among siblings like update_relationship and delete_relationship, and the description reinforces that it creates, not modifies or removes.

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

Usage Guidelines3/5

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

The description makes it clear this tool is for creating relationships and provides detailed context for when each relationship type fits. However, it never explicitly contrasts with update_relationship or delete_relationship, so an agent must infer when to choose the create tool over its siblings.

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