Skip to main content
Glama
infino-ai

Infino MCP server

Official
by infino-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Create an Infino table

infino_create_table

Create typed tables with full-text BM25 indexes and optional vector embeddings, enabling keyword, semantic, and hybrid search over stored data.

Instructions

Create a table from a {column: type} descriptor. Full-text (BM25) indexes go on the columns named in 'fts' (default: every large_utf8 column; the index requires that type). With vector: true the server adds an 'embedding' column sized to its embedder and a cosine vector index on it, so semantic and hybrid search work and rows added without a vector are embedded from their text. Every column is required in every row you add, so declare only columns you will always fill. Give every table a stable key column of type utf8 so rows can be replaced or removed later by predicate (e.g. key = 'doc-1'); keep utf8 for ids and short labels and large_utf8 for the text to search, so the searches infer the right column.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ftsNoColumns to full-text index. Default: every large_utf8 column. Must be large_utf8.
tableYesTable name.
vectorNoAdd an 'embedding' vector column sized to the server's embedder, with a cosine index. Default false.
columnsYesColumns as {name: type}. large_utf8 for text to search; utf8 for a key, ids, and short labels.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.14.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already mark this as a write operation (readOnlyHint=false). The description adds valuable behavioral detail: fts indexes are created on large_utf8 columns by default, vector:true adds an embedding column and cosine index, rows without a vector are embedded from text, and every declared column is required in all rows. It does not state behavior if the table already exists, but there is no contradiction with annotations.

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?

Four dense sentences, each earning its place: the first states the core action, the second explains fts, the third explains vector behavior, and the fourth gives schema design guidance. It is front-loaded and contains no filler.

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 table-creation tool with no output schema, the description covers defaults, side effects, required-column policy, and search implications. It even explains how column type choices affect later searches. The only omitted detail is behavior on duplicate table names, but the idempotentHint=false annotation already signals that, so the description is complete for correct invocation.

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 coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: fts defaults and type requirements, vector column creation behavior, column type guidance (utf8 vs large_utf8), and the purpose of a stable key column. This enriches the agent's understanding of how to set each parameter.

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: 'Create a table from a {column: type} descriptor.' It clearly distinguishes this tool from siblings like infino_create_database, infino_describe_table, and infino_drop_table, and it conveys the core schema-definition responsibility without ambiguity.

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 for when to use this tool and how to shape input: it explains fts defaults, vector behavior, required columns, and the recommendation to add a stable utf8 key column. It does not explicitly name alternatives or state when not to use it, but the guidance is strong enough for an agent to select it correctly.

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