MCP Tools Reference

The formal 2.0.1 built-in tool surface managed by MCP keys contains exactly five tool names:

Published Custom Tools can extend the tool collection for a bound database, but they are not additional built-in tools.

Recommended discovery flow

Use metadata discovery whenever the client does not already have reliable database structure. Schema tools run inside the authenticated key’s database context rather than accepting a client-supplied connection string.

get_schemas

Returns the schemas reported by the provider metadata runtime for the database bound to the MCP key.

Parameters: none.

Success result: schema names joined as a comma-separated string.

Authorization and limits:

• the key must be permitted to use get_schemas when an explicit tool allowlist exists;
• the database provider/connection must have been resolved from the authenticated key;
• the operation acquires the shared SQL-concurrency limiter;
• success/failure is written to the audit path as mcp.get_schemas.

The tool does not accept a database ID or connection string from the model.

get_tables

get_tables(schemaName: string)

Returns provider-reported tables in the requested schema, filtered by the MCP key’s table whitelist when one is configured.

If semantic metadata exists for the bound Database Management entry, each visible table can also include:

• display name;
• description;
• synonyms;
• metric descriptions scoped to that table.

Success result: a comma-separated string. Entries may therefore be richer than raw physical table names.

Audit action: mcp.get_tables.

get_columns

get_columns(schemaName: string, tableName: string)

The server first checks that the requested qualified table is allowed by the MCP key. It then reads provider column metadata and serializes a JSON array.

Each 2.0.1 ColumnInfo object exposes these properties:

Semantic enrichment can add display names, descriptions, synonyms, and relationship descriptions to Description. Relationship context is included only when both relationship tables are allowed by the key’s table whitelist.

Audit action: mcp.get_columns.

execute_query_sql

execute_query_sql(sql: string)

Accepts one SELECT SQL statement. The public 2.0.1 description explicitly calls out common query forms including JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT/OFFSET, DISTINCT, CTEs, subqueries, and UNION/INTERSECT/EXCEPT.

The request is executed through the F# typed-query runtime. Depending on runtime capabilities, query facts such as referenced tables, CTE presence, and subquery presence are collected during the same governed path and used for audit evidence.

Success result: JSON serialization of the returned row collection.

Failure result: the tool returns text beginning with Execution failed: followed by the failure message. Cancellation requested by the caller is propagated rather than converted into a normal result string.

Runtime boundaries:

• MCP tool allowlist;
• MCP-key database binding;
• table whitelist;
• current security/query policy;
• SQL concurrency limiter;
• source/target SQL capability checks;
• audit event mcp.query.executed with operation, duration, returned rows, and compiler-derived definition facts.

See SQL Support Reference for the human-readable capability summary.

execute_dml_sql

execute_dml_sql(sql: string)

The MCP-visible input is SQL. The McpServer and cancellation token used by the .NET method are runtime-injected infrastructure, not fields an agent supplies.

Supported statement classes in the 2.0.1 MCP DML path are:

For UPDATE and DELETE, approval binds to the exact primary-key row set and commit-time code revalidates row identities inside the transaction. For INSERT VALUES, approval binds to the immutable literal payload and exact compiled command, and commit verifies the approved payload row count.

If the human declines, or validation cannot complete, the mutation is not committed. Audit events use mcp.dml.executed and record operation, processing duration, affected rows, approval status, and error category where applicable.

Read Safe DML for the full protocol.

Errors shared by built-in tools

Common failures include:

• the MCP authorization context is missing;
• the key’s explicit tool allowlist does not contain the tool;
• database provider or connection configuration is invalid;
• the SQL-concurrency limit cannot grant a lease (Server busy);
• a requested table is outside the key whitelist;
• SQL is empty, unsupported, rejected by policy, or rejected by a capability boundary;
• provider execution fails.

The tools deliberately return bounded error information rather than falling back to unrestricted provider execution.

Custom Tools

Published Custom Tools are loaded for the MCP key’s bound Database Management entry and can be included in the same AllowedTools set by name. Their invocation still goes through the runtime database binding, table whitelist, security policy, concurrency controls, audit path, and—when the custom tool is DML—the approval pipeline.

See Custom Tools.

Semantic metadata is not documented as a sixth built-in

The 2.0.1 repository contains semantic-management implementation details, but the formal MCP key built-in registry and Admin key-management surface recognize the five tools listed on this page. Official 2.0.1 documentation therefore treats semantic metadata as an Admin/control-plane capability consumed by schema discovery, not as an additional formal built-in MCP contract.

See Semantic Metadata.