Skip to main content
Glama
dantalan

baatjie-mcp-server

by dantalan

Insert Rows

baatjie_insert

Insert rows into tanOS or sigsche tables with audit logging. Specify project, table, and rows to write data while the actor is recorded in the audit trail.

Instructions

Insert one or more rows into any table in tanOS or sigscheCore. Every insert is recorded in tanOS audit_log with the actor you supply.

Args:

  • project ('tanos' | 'sigsche'): Which system

  • table (string): Target table

  • rows (object[]): Rows to insert, 1-100. Omit columns with database defaults.

  • actor (string): Who is writing, for the audit trail (default: 'mcp')

  • response_format ('markdown' | 'json'): Output format

Returns: { "ok": true, "table": string, "action": "insert", "affected": number, "rows": object[], "audit_logged": boolean, "note"?: string }

Examples:

  • Log a signed agency -> table='locare_accounts', rows=[{"agency_name":"Cape Letting","brm_id":"...","tier":"Growth","status":"active"}]

  • Record a payment -> table='payments', rows=[{"lease_id":"...","amount":3400,"payment_date":"2026-08-08","method":"payroll"}]

Note: writes to occupant-facing tables (tenants, leases, notices, payments) are flagged in the response, because a row there corresponds to a real person's tenancy or money. A 'notices' row in particular represents a notice served on an occupant — South African arrears and eviction notices carry statutory requirements, so route the wording through your legal-exposure-check skill before sending rather than after.

Error Handling:

  • Foreign key failures name the missing parent record

  • CHECK constraint failures point at columns with restricted values

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsYesRows to insert
actorNoWho is performing this write, recorded in tanOS audit_log (e.g. 'baatjie', 'marius-ai', 'deon-ai')mcp
tableYesTarget table
projectYesWhich system: 'tanos' (property OS, pipeline, sequencing) or 'sigsche' (signal scheduler)
response_formatNoOutput format: 'markdown' for human-readable, 'json' for machine-readablemarkdown
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, etc.), the description discloses critical behaviors: every insert is recorded in tanOS audit_log with the actor, rows are limited to 1-100, and foreign key/CHECK constraint failures produce specific error messages. It also warns that writes to occupant-facing tables are flagged and that 'notices' rows carry statutory legal requirements. This is far richer than the annotations alone.

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 well-structured with clear sections: purpose, Args, Returns, Examples, Note, and Error Handling. Every sentence earns its place—there is no filler or repetition of schema details. The most important purpose statement is front-loaded, and the legal warning is set off as a prominent note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with no output schema, the description is remarkably complete. It provides the return shape, example payloads, error behavior, special-case warnings, and even guidance on legal compliance. This enables an agent to invoke the tool correctly without needing additional external context.

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?

The input schema has 100% coverage, but the description adds substantial meaning: 'Omit columns with database defaults,' the 1-100 row limit, the default actor 'mcp,' and the project enum explanation ('tanos' vs 'sigsche'). The concrete examples show exactly how to structure rows for real use cases, which goes well beyond the schema's bare property definitions.

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 a specific verb and resource: 'Insert one or more rows into any table in tanOS or sigscheCore.' It clearly distinguishes itself from siblings like baatjie_update, baatjie_delete, and baatjie_query by focusing on adding new rows, not modifying or removing. The scope is explicit, naming the two systems and covering the core action.

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 context on when to insert rows, including examples like logging an agency and recording a payment. It does not explicitly name alternatives such as 'use baatjie_update to modify existing rows,' but the insert-vs-update distinction is strongly implied by the examples and the 'Insert' title. The legal caution for occupant-facing tables adds important usage guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dantalan/baatjie-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server