Skip to main content
Glama

describe_table

Retrieve schema details for a specified table in a Turso database, enabling users to view structure and properties directly from the MCP server.

Instructions

Gets schema information for a table

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
databaseNoDatabase name (optional, uses context if not provided)
tableYesTable name

Implementation Reference

  • The MCP tool handler for describe_table. It resolves the database name from context if not provided, calls the underlying database client function, transforms the column data for better readability (e.g., boolean flags for nullable and primary key), and returns a formatted JSON response.
    async ({ table, database }) => {
    	try {
    		const database_name = resolve_database_name(database);
    		if (database) set_current_database(database);
    
    		const columns = await database_client.describe_table(
    			database_name,
    			table,
    		);
    
    		return create_tool_response({
    			database: database_name,
    			table,
    			columns: columns.map((col) => ({
    				name: col.name,
    				type: col.type,
    				nullable: col.notnull === 0,
    				default_value: col.dflt_value,
    				primary_key: col.pk === 1,
    			})),
    		});
    	} catch (error) {
    		return create_tool_error_response(error);
    	}
    },
  • Zod schema for validating input to the describe_table tool: requires table name, optional database name (falls back to context).
    const DescribeTableSchema = z.object({
    	table: z.string().describe('Table name'),
    	database: z.string().optional().describe('Database name (optional, uses context if not provided)'),
    });
  • Registration of the describe_table tool with the MCP server via server.tool(), providing name, description, input schema, and the handler function.
    server.tool(
    	{
    		name: 'describe_table',
    		description: 'Gets schema information for a table',
    		schema: DescribeTableSchema,
    	},
    	async ({ table, database }) => {
    		try {
    			const database_name = resolve_database_name(database);
    			if (database) set_current_database(database);
    
    			const columns = await database_client.describe_table(
    				database_name,
    				table,
    			);
    
    			return create_tool_response({
    				database: database_name,
    				table,
    				columns: columns.map((col) => ({
    					name: col.name,
    					type: col.type,
    					nullable: col.notnull === 0,
    					default_value: col.dflt_value,
    					primary_key: col.pk === 1,
    				})),
    			});
    		} catch (error) {
    			return create_tool_error_response(error);
    		}
    	},
    );
  • Helper function in the database client that connects to the database, executes PRAGMA table_info(table_name) to get column schema, and returns typed column information. Called by the tool handler.
    export async function describe_table(
    	database_name: string,
    	table_name: string,
    ): Promise<
    	{
    		name: string;
    		type: string;
    		notnull: number;
    		dflt_value: string | null;
    		pk: number;
    	}[]
    > {
    	try {
    		const client = await get_database_client(
    			database_name,
    			'read-only',
    		);
    
    		// Query the table info
    		const result = await client.execute({
    			sql: `PRAGMA table_info(${table_name})`,
    		});
    
    		// Return the column definitions
    		return result.rows.map((row) => ({
    			name: row.name as string,
    			type: row.type as string,
    			notnull: row.notnull as number,
    			dflt_value: row.dflt_value as string | null,
    			pk: row.pk as number,
    		}));
    	} catch (error) {
    		throw new TursoApiError(
    			`Failed to describe table ${table_name} for database ${database_name}: ${
    				(error as Error).message
    			}`,
    			500,
    		);
    	}
    }
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Gets schema information,' implying a read-only operation, but doesn't cover aspects like permissions required, potential rate limits, error handling, or the format of the returned schema information. This leaves significant gaps in understanding how the tool behaves in practice.

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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly, which is ideal for conciseness in tool descriptions.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves schema information. It doesn't explain what 'schema information' includes (e.g., columns, types, constraints) or how results are structured, leaving users uncertain about the output. This gap is significant for a read operation where understanding the return value is crucial.

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?

The input schema has 100% description coverage, clearly documenting both parameters ('database' as optional with context usage, 'table' as required). The description adds no additional meaning beyond this, such as examples or constraints, so it meets the baseline score of 3 where the schema does the heavy lifting without extra value from the description.

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 clearly states the tool's purpose with a specific verb ('Gets') and resource ('schema information for a table'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_tables' or 'execute_query', which might also provide table-related information, so it doesn't reach the highest score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like needing metadata vs. data retrieval (e.g., 'execute_query'), or how it differs from 'list_tables' which might list table names without schema details. Without such context, users may struggle to choose appropriately among siblings.

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

Related 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/spences10/mcp-turso-cloud'

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