Lists the user stored procedures the login can see, with line count, join count and number of referenced objects as rough complexity metrics. Use it to find procedures and pick the complex ones; for one procedure's text use get_procedure_definition. definition_visible is false, and the metrics null, for a procedure whose text is hidden from the login; referenced_object_count is null when the login cannot read dependencies. SQL Server leaves out procedures the login has no permission on without an error: get_database_overview says whether that happens, check_permissions why.

Generates a Graphviz DOT diagram of the dependencies between database objects: an arrow runs from each table, view, procedure or function to the object it depends on, through a foreign key or a reference in its code. Returns the DOT text in 'dot', ready for 'dot -Tsvg', and the same graph as 'nodes' (with node_kind) and 'edges' (with dependency_kind). Use it to draw the graph; for the edges alone use get_dependency_graph, and for what references a single table use get_table_usage. A whole database makes an unreadable diagram, so narrow it with schema. 'visibility' says when references from code are missing for lack of permission.

Lists the user schemas of a database with their owners, leaving out system schemas. Use it to learn the names the 'schema' filter of the other tools accepts; for object counts and sizes per schema use get_schema_summary instead.

Returns the dependency edges between database objects as data: foreign keys between tables, and references among views, procedures and functions. Use it to analyze dependencies programmatically; for a diagram use generate_dependency_dot, and for what references one table use get_table_usage. Fails, saying so, when the login cannot read sys.sql_expression_dependencies; without VIEW DEFINITION the module edges cover only modules the login can read.

Reports what the connected login can and cannot see in a database: identity, roles, effective permissions, server version and, for each group of tools, whether it sees everything ('complete'), only part ('partial') or nothing ('unavailable'), with the missing permission and the GRANT that adds it in this server version's syntax. Also reports 'write_access', so an account meant to be read-only can be verified rather than assumed. Call it when a listing looks short, a definition comes back hidden, get_database_overview reports incomplete visibility, or a tool fails with a permission error: SQL Server leaves out what a login cannot see without raising any error.

Lists the logical database names this server is configured to reach, with each one's row limit and command timeout. Call it first: every other tool, starting with get_database_overview, takes one of these names as its 'database' argument. It reads only the server's configuration and never connects to SQL Server; when nothing is configured it answers ok: false with the file to create, where the server looked and an example.

Returns the CREATE PROCEDURE text of one stored procedure. Use it to read or review a procedure found with list_procedures; this server never executes procedures. A procedure the login can see but not read comes back with definition null and definition_visible false.

Compares the table and column structure of two configured databases, such as development and production: tables present in only one, columns present in only one, and columns whose type or nullability differ, each with its type_declaration so a difference reads as 'nvarchar(250) vs nvarchar(50)'. Use it to check a migration or detect drift. It compares tables and columns only, not views, code, indexes or data; to see one differing table in full, call get_table_schema on each database.

Returns the CREATE VIEW text of one view together with its columns, in the same detail as get_table_schema. Use it to see how a view derives its data; for the objects it reads from use get_dependency_graph. A view the login can see but not read comes back with definition null and definition_visible false, which check_permissions explains.

Lists user tables with schema, approximate row count, data and index size in MB, and creation and modification dates. Use it to find tables by name or schema and to spot the large ones; to find tables by a column they hold use find_columns, and for one table's columns and keys use get_table_schema. Narrow large databases with schema and name_pattern.

Runs a SELECT on one table or view, with optional column list, filter, ordering, grouping, aggregates (COUNT, SUM, AVG, MIN, MAX), pagination and random sampling, and returns the rows in an object with row_count and a measured 'truncated' flag, so a short result is never mistaken for a complete one. Rows are capped by the database's max_query_rows. Call get_table_schema first for exact column names; for null ratios, distinct counts and frequent values use get_data_profile instead of paging through rows. Reads actual data; never runs INSERT, UPDATE, DELETE or procedures.

Finds every table and, by default, every view holding a column whose name matches a pattern, with each column's type_declaration and nullability. Use it to answer 'which objects have this column?' before a rename, a widening or an impact review; to find objects by their own name use list_tables or list_views.

Returns the CREATE FUNCTION text of one user-defined function. Use it to read or review a function found with list_functions; this server never executes functions. A function the login can see but not read comes back with definition null and definition_visible false.

Returns the full structure of one table or view: columns with an unambiguous type_declaration (such as 'nvarchar(250)'), max_length_chars, every extended property, computed-column definitions and whether they are persisted; plus primary key, foreign keys, check and unique constraints, and indexes with key column order and declared key width. Call it before query_table to learn exact column names and types; for a view's SQL text use get_view_definition. max_length is the raw sys.columns value in BYTES, so reason about text length with type_declaration or max_length_chars.

Summarizes one database: real name, server and instance, connected login, counts of tables, views, procedures, functions and schemas, and allocated size in MB. Use it after list_databases to size up a database before exploring it; for the same figures per schema use get_schema_summary. Counts cover only what the login can see: 'visibility.complete' is false when SQL Server hides objects, and check_permissions then says which GRANT is missing.

Profiles the columns of one table or view: null ratio, distinct count, minimum, maximum and most frequent values. Use it to learn how data is distributed without paging through rows with query_table. It reads actual row values and scans the table, so on a large table it can take a while; limit it to the columns you need.

Lists user views with their schema. Use it to find views by name or schema; for a view's columns and SQL text use get_view_definition, and for tables use list_tables. Narrow large databases with schema and name_pattern.

Reports index health by schema: duplicate index candidates, unused indexes and missing-index suggestions. Use it when reviewing indexing or slow queries; for one table's indexes use get_table_schema. Unused and missing indexes come from server DMVs, which reset when SQL Server restarts; without VIEW SERVER STATE they come back null and 'visibility.unavailable' says why, while duplicates are still reported.

Summarizes each schema of a database: counts of tables, views, procedures and functions, approximate rows and estimated data and index size. Use it to see where a database's weight lies before exploring or planning a refactoring; for whole-database totals use get_database_overview, and for the tables of one schema use list_tables.

Lists the user-defined functions the login can see (scalar, inline table-valued and multi-statement table-valued), with the same complexity metrics and visibility flags as list_procedures. Use it to find functions; for one function's text use get_function_definition. SQL Server leaves out functions the login has no permission on without an error: get_database_overview says whether that happens, check_permissions why.

Lists everything that references one table: foreign keys to and from it, and the views, procedures and functions whose code uses it. Use it for impact analysis before changing a table; for the dependency graph of the whole database use get_dependency_graph. sql_module_usage is null when the login cannot read dependencies, and 'visibility' says when the list may be incomplete.