Skip to main content
Glama
Sign In
Shop Database MCP Server

Shop Database MCP Server

by melixetian
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

inspect_database

Read-only

Inspect database schema before querying to discover tables, columns, keys, relationships, and row counts.

Instructions

Use before your first query or whenever the schema is uncertain. Returns tables, columns, keys, relationships, and row counts.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "inspect_database"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
tablesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. It adds behavioral context by describing what is returned (tables, columns, keys, relationships, row counts), and its 'returns...' phrasing makes clear this is a read/inspection operation. There is room for more detail about potential performance cost or staleness, but the description is adequate given the 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?

Two sentences, front-loaded with the usage trigger, and every clause earns its place. The list of returned schema elements is efficient and informative without padding.

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 zero-parameter inspection tool with readOnly annotations and an output schema, the description is complete. It tells the agent when to use it and what to expect in return, and no additional information is needed to invoke it correctly.

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?

The tool has zero parameters, so there is nothing for the description to clarify about inputs. A baseline of 4 is appropriate for a no-parameter tool since parameter-semantics burden is eliminated.

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 states a specific verb ('inspect') and resource ('database'), and its purpose is unmistakable: return schema metadata. It also positions itself as a pre-query reconnaissance step, which distinguishes it from the sibling query_database.

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

Usage Guidelines5/5

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

Explicitly says 'Use before your first query or whenever the schema is uncertain,' giving clear conditions for use. This implicitly excludes using it for data retrieval, which is handled by query_database. The guidance is concrete and actionable.

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