Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@indiekit-mcp inspect the schema of my database"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Unified MCP server that auto-discovers and exposes all IndieKit tools through a single endpoint.
One config, all tools.
Claude Desktop / Cursor:
{
"mcpServers": {
"indiekit": {
"command": "npx",
"args": ["@indiekitai/mcp"]
}
}
}Or generate the config:
npx @indiekitai/mcp --configRelated MCP server: mcp-cli-catalog
Tool | Package | Description |
| @indiekitai/pg-inspect | Inspect database schema β tables, columns, indexes, constraints |
| @indiekitai/pg-diff | Compare two databases and return migration SQL |
| @indiekitai/pg-diff | Human-readable diff summary |
| @indiekitai/pg-top | Current pg_stat_activity |
| @indiekitai/pg-top | Database statistics (connections, cache hit, TPS) |
| @indiekitai/pg-top | Current lock information |
Tool | Package | Description |
| @indiekitai/just | List justfile recipes |
| @indiekitai/just | Execute a justfile recipe |
| @indiekitai/just | Parse justfile to AST |
| @indiekitai/throttled | Check rate limit status |
| @indiekitai/throttled | Get rate limit state without consuming quota |
| @indiekitai/env-audit | Scan project for environment variables |
| @indiekitai/llm-context | Count tokens for LLM context estimation |
Tool | Package | Description |
| @indiekitai/lipgloss | Render styled terminal text |
| @indiekitai/lipgloss | Join text blocks horizontally |
| @indiekitai/lipgloss | Join text blocks vertically |
npx @indiekitai/mcp # Start MCP server (stdio)
npx @indiekitai/mcp --list # List all tools
npx @indiekitai/mcp --config # Claude Desktop config JSONThe server automatically discovers additional tools from installed @indiekitai/* packages that export MCP tool definitions:
Scans node_modules/@indiekitai/*/package.json
Checks for exports["./mcp"] or indiekit.mcp: true in package.json
Dynamically imports and registers discovered tools
Export a getTools() function from your package's MCP module:
// src/mcp.ts
import type { ToolDefinition } from '@indiekitai/mcp';
export function getTools(): ToolDefinition[] {
return [{
name: 'my_tool',
description: 'Does something useful',
package: '@indiekitai/my-package',
mode: 'direct',
inputSchema: {
type: 'object',
properties: {
input: { type: 'string', description: 'Input value' },
},
required: ['input'],
},
handler: async (params) => {
// Tool implementation
return { result: 'done' };
},
}];
}Then add to your package.json:
{
"exports": {
"./mcp": "./dist/mcp.js"
}
}MIT
Inspect PostgreSQL database schema β tables, columns, types, indexes, constraints, enums, and extensions
| Name | Required | Description | Default |
|---|---|---|---|
| connectionString | No | PostgreSQL connection string (defaults to DATABASE_URL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, whether it modifies data, or any connection details beyond the optional connection string. Behavioral transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key action ('Inspect PostgreSQL database schema') and lists relevant components. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the description provides basic context. However, it lacks information about the output format or return value, which would be helpful for a schema inspection tool. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (connectionString). The description adds no additional meaning beyond the schema, which already documents it as optional with a default. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects PostgreSQL database schema and enumerates specific components (tables, columns, types, etc.), making the purpose unambiguous. With no sibling tools, differentiation is not needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting a PostgreSQL schema but provides no explicit guidance on when to use it, prerequisites (e.g., need a running database), or exclusions. Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no risk of confusion between tools. The tool's purpose of inspecting PostgreSQL schema is clearly stated and distinct.
The single tool name 'pg_inspect_schema' follows a clear and consistent pattern (verb_noun) and is descriptive, so no inconsistency issues arise.
Only one tool is provided, which is below the typical well-scoped range of 3-15. While the tool itself is comprehensive, the server's scope feels very narrow, making it borderline appropriate.
The tool covers all major aspects of database schema inspection (tables, columns, types, indexes, constraints, enums, extensions), leaving no obvious gaps for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for interacting with the Supabase platform
Nifty's MCP server β exposes tasks, projects, messages, and files as tools for AI agents.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/indiekitai/indiekit-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
