Xyvenra

Database

database

Destructive

List or create Data tables, delete a table, and list, query, get, create, batch-create, update, or delete records on a Data project this account owns. list_records accepts the same filter, search, order, and cursor as the project Data API and applies them to the latest 250 rows. list_changes polls records updated after since. Field changes stay in the Data app. This is not a websocket, Supabase Realtime, Auth, or Edge Functions. Private files are the files tool.

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": {
      "action": "<action>",
      "projectId": "<projectId>"
    },
    "name": "database"
  }
}

Input Schema

Name	Required	Description
`q`	No	list_records text search across the record id and JSON.
`op`	No
`data`	No	One record for create_record, or a field patch for update_record.
`name`	No	Table name for create_table.
`limit`	No	list_records page size, from 1 to 100. Default 100.
`order`	No	list_records sort: id, created_at, updated_at, or field:NAME. Default created_at.
`since`	No	ISO-8601 timestamp for list_changes. Returns rows with a later updated_at. This is a poll, not a websocket.
`value`	No	list_records filter value. Booleans are true or false. Empty checks omit value.
`action`	Yes
`cursor`	No	list_records cursor from next_cursor. Do not combine with offset.
`filter`	No	list_records field name. Send op and value with it.
`offset`	No	list_records offset, from 0 to 249. Do not combine with cursor.
`columns`	No
`records`	No	Batch of 1 to 250 records for create_record. Do not also send data.
`recordId`	No
`direction`	No	list_records sort direction. Default asc.
`projectId`	Yes
`tableName`	No
`expectedUpdatedAt`	No	Optional update_record check. Must match the record updated_at you read.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true, and the description earns extra credit by disclosing that list_records applies filters to only the latest 250 rows and that list_changes is a poll driven by updated_at. It stops short of stating that table/record deletes are irreversible or what permissions are required, which matters for a destructive multiplexed tool.

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?

Capability enumeration is front-loaded in the first sentence and the behavioral caveats follow in compact order. The exclusion sentence is useful but slightly sprawling as a list of four unrelated product surfaces.

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 19-parameter, 9-action tool with no output schema, the description covers the core read paths and the polling model well. The remaining gap is that it never says which parameters are required or forbidden per action, leaving batch-create and update flows to be reconstructed from the schema.

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

Parameters3/5

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

Schema description coverage is 68% across 19 parameters, so a baseline of 3 applies. The description adds genuine meaning to list_records (filter/search/order/cursor semantics) and to since/list_changes, but leaves most action-specific parameters (columns, records, expectedUpdatedAt, offset versus cursor) to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the concrete resources and operations (tables and records on a Data project) and explicitly bounds scope to projects 'this account owns.' It also distinguishes itself from adjacent surfaces ('not a websocket, Supabase Realtime, Auth, or Edge Functions') and routes private files to the files tool, so an agent can tell what this tool is and is not.

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?

It gives explicit negative guidance (not Realtime, not Auth, not Edge Functions, files go to the files tool) and clarifies that list_changes is a poll rather than a subscription. What is missing is per-action routing guidance across the nine action values, which the agent must infer from the action enum alone.

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

All Xyvenra tools Inspect

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

Need Help?