Skip to main content
Glama
openl-tablets

OpenL MCP Server

Official

Create New Table

openl_create_project_table

Create decision tables, spreadsheets, datatypes, and other table types in an OpenL project. Specify the module, table structure, and type-specific fields like rules or rows.

Instructions

Create a new table/rule in an OpenL project (Create New Project Table API). This is the recommended tool for creating new OpenL tables programmatically. Use cases: Create Rules (decision tables), Spreadsheet tables, Datatype definitions, Test tables, or other table types. Requires moduleName (an EXISTING project module — modules correspond to the project's .xlsx files; a freshly created blank project has a single module named 'Main') and a complete table structure (EditableTableView). The table structure must include 'tableType' and 'name'. CRITICAL: 'tableType' is a CASE-SENSITIVE discriminator — use EXACTLY one of: Datatype, Vocabulary, Spreadsheet, SimpleSpreadsheet, SimpleRules, SmartRules, SimpleLookup, SmartLookup, Data, Test, RawSource (a lowercase value like 'datatype' is rejected by the backend). Add type-specific data: fields (Datatype), rules (SimpleRules/SmartRules), rows (Spreadsheet), steps (SimpleSpreadsheet), values (Vocabulary). For RULES/DECISION tables (SimpleRules/SmartRules) and lookups you MUST also provide: 'returnType' (e.g. "String"), 'args': [{name,type}] (the input parameters), and 'headers': [{title}] (the column captions — one per rule-row key, the return column is usually titled "RET1"); each 'rules' row is a map keyed by those header titles. There is NO 'signature' field — the method is defined by name + returnType + args. Example SimpleRules: {tableType:"SimpleRules", name:"CreditCategory", returnType:"String", args:[{name:"creditScore",type:"Integer"}], headers:[{title:"creditScore"},{title:"RET1"}], rules:[{creditScore:"< 580", RET1:"Poor"}, {creditScore:">= 800", RET1:"Excellent"}]}. WARNING: the backend rejects unknown/extra fields with an opaque 400 "Failed to read request". 'id' is optional. Use get_table() on an existing table as a reference for the structure (for a blank project with no tables, use the tableType list and the SimpleRules example above). The response contains the created table's metadata (id, signature), NOT a compilation result — call openl_project_status afterward to confirm the project still compiles. This tool uses the Create New Project Table API endpoint.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tableYesComplete table structure (EditableTableView), selected by the CASE-SENSITIVE 'tableType' discriminator (Datatype, Vocabulary, Spreadsheet, SimpleSpreadsheet, SimpleRules, SmartRules, SimpleLookup, SmartLookup, Data, Test, RawSource — lowercase like 'datatype' is rejected). Each table type has a DIFFERENT shape (shown per branch); the backend rejects unknown/extra fields with a 400 'Failed to read request'. Rules tables use args/returnType/headers[{title}]/rules; Data and Test tables use headers[{fieldName}]/rows[{values}] (Test also needs testedTableName) — do NOT mix the two. There is NO 'signature' field. Tip: openl_get_table() on an existing table of the SAME type returns this exact shape to copy.
projectIdYesProject ID returned by backend. Use the exact 'projectId' value from openl_list_projects() response without modification or reformatting.
sheetNameNoName of the sheet where the table will be created within the Excel file. If not provided, the table name will be used as the sheet name.
moduleNameYesName of an existing project module where the table will be created (for example, 'Main' or 'Rules').
response_formatNoResponse format: 'json' for structured data, 'markdown' for human-readable (default), 'markdown_concise' for brief summary (1-2 paragraphs), 'markdown_detailed' for full details with contextmarkdown
Behavior5/5

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

The description discloses critical behavioral traits beyond the openWorldHint annotation: the backend rejects unknown/extra fields with a 400, there is no 'signature' field, tables require exact case-sensitive tableType, and the response contains metadata not compilation results. It recommends calling openl_project_status afterward, adding transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a lengthy wall of text, dense with information but lacking structural breaks like bullet points or sections. While every sentence earns its place for a complex tool, the readability could be improved. It is front-loaded with core purpose but the detailed parameter guidance could be better organized.

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?

Given the tool's complexity (11 table types, many fields, no output schema), the description is remarkably complete. It covers prerequisites, pitfalls, examples, and post-creation steps. For a creation tool, the response metadata description is sufficient and the advice to check project status afterward addresses completeness.

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 baseline is 3, but the description adds immense value: it explains each oneOf branch for 'table' with examples, pitfalls (case-sensitivity, missing fields), and tips (using openl_get_table for reference). It also clarifies moduleName (modules = .xlsx files, default 'Main'), projectId (exact from list_projects), and response_format options. This far exceeds minimal schema documentation.

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 clearly states the tool creates a new table/rule in an OpenL project with specific verb and resource. It distinguishes from siblings by being the recommended creation tool and lists diverse use cases (Rules, Spreadsheet, Datatype, etc.). The action is unambiguous.

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 provides extensive usage guidance: it is the recommended tool for creation, lists use cases, and explains prerequisites (moduleName must exist, table structure must be complete). It implicitly excludes misuse by detailing required fields and pitfalls. However, it does not explicitly contrast with sibling tools like openl_update_table or openl_append_table.

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/openl-tablets/openl-mcp'

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