Accepts account-less micro-payments over the Bitcoin Lightning Network via the L402 protocol (10-15 sats per call) to unlock access to all database intelligence tools.
Target output of the ORM model compiler, which generates Drizzle ORM models from relational database schemas.
Accepts account-less micro-payments in native ETH on Base Ethereum via the MPP protocol to unlock access to all database intelligence tools.
One of the SQL dialects targeted by the polyglot SQL transpiler, allowing SQL statements to be converted to and from MySQL alongside other supported dialects.
One of the SQL dialects targeted by the polyglot SQL transpiler, and supported by the schema migration differ, query plan optimizer, index advisor, and other SQL tools.
Target output of the ORM model compiler, which generates Prisma schema models from relational database schemas.
Accepts account-less micro-payments in native SOL over the Solana blockchain via the x402 protocol to unlock access to all database intelligence tools.
One of the SQL dialects targeted by the polyglot SQL transpiler, allowing SQL statements to be converted to and from SQLite alongside other supported dialects.
Target output of the ORM model compiler, which generates Zod validation schemas from relational database schemas.
Click on "Deploy 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., "@Diogenes Database Intelligence, SQL Engine & Schema Guard MCP Convert this to SQL: active users who signed up last month"
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.
12 deterministic database intelligence, AST SQL & schema reliability tools: natural language to SQL synthesizer, AST SQL injection & tautology auditor, query plan EXPLAIN optimizer, breaking schema migration differ, polyglot SQL transpiler (PostgreSQL/MySQL/SQLite), composite B-tree index advisor, relational 3NF/BCNF normalization validator, SQL telemetry PII scrubber, relational mock seed fixture generator, connection pool headroom calculator, transaction isolation hazard auditor, and ORM model compiler (Prisma/Drizzle/Zod).
Add directly to your MCP client config (Cursor, Claude Desktop, Windsurf, Zed):
{
"mcpServers": {
"database-intelligence": {
"url": "https://diogenes-micro-gateway.corinth.workers.dev/mcp/database-intelligence",
"transport": "streamable-http"
}
}
}Install and run via npx:
npx @stand-out-of-my-sun/diogenes-database-intelligence-mcpRelated MCP server: mcp-postgres
All tools are accessible account-less via:
Bitcoin Lightning Network: L402 protocol (10-15 sats per call)
Solana: x402 protocol (Native SOL)
Base Ethereum: MPP protocol (Native ETH)
Free Demo: Append ?demo=true or pass X-Demo: true header to test any tool instantly.
Manifest: https://diogenes-micro-gateway.corinth.workers.dev/.well-known/mcp/database-intelligence.json
Health: https://diogenes-micro-gateway.corinth.workers.dev/api/v1/health
Analyzes SQL EXPLAIN execution plans to detect sequential table scans, high-cost cartesian joins, and buffer memory bottlenecks. Use when diagnosing slow queries, optimizing database performance, or evaluating query cost; for getting index recommendations, use recommend_database_indexes instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'explain_plan_or_query' ('optimization_target' defaults to 'eliminate_seq_scans'), supports '?demo=true' or L402 (15 sats), and returns HTTP 400 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| database_engine | No | Database engine name (e.g., 'postgres', 'mysql', 'sqlite'). | |
| optimization_target | No | Optimization goal: eliminate sequential scans, reduce memory buffers, or minimize join costs. | |
| explain_plan_or_query | Yes | Raw text or JSON output of EXPLAIN / EXPLAIN ANALYZE or the candidate SQL query. |
| Name | Required | Description |
|---|---|---|
| bottlenecks_detected | Yes | Identified query execution bottlenecks (e.g., Seq Scan on large table, Nested Loop join). |
| recommended_rewrites | Yes | Specific SQL query rewrites and predicate adjustments to improve performance. |
| estimated_cost_reduction_pct | Yes | Estimated potential query cost reduction percentage with recommended optimizations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds real operational context: stateless edge call, 32 KB payload cap, 60 RPM rate limit, L402 payment of 15 sats, demo mode, and HTTP 400 on invalid input. The only gap is that payment/demo mechanics are described as query-string behavior not reflected anywhere in the input schema, which could confuse an agent about how to supply them.
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?
Two sentences, front-loaded with purpose before the alternative and the operational constraints. The second sentence is a dense run-on cramming size limit, rate limit, parameter default, payment scheme, and error code together, which costs some scannability but no sentence is wasteful.
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?
With an output schema present, return values need not be explained. The description covers purpose, routing to the sibling, parameter default, resource limits, auth/payment, and error behavior — everything an agent needs to call it correctly. Only the demo/payment mechanism lacks a corresponding schema field.
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 coverage is 100%, so baseline is 3; however the description adds a fact the schema omits — that 'optimization_target' defaults to 'eliminate_seq_scans' — which is genuinely useful for deciding whether to pass the argument. It adds no meaning for 'explain_plan_or_query' or 'database_engine' beyond the schema.
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?
Specific verb + resource: 'Analyzes SQL EXPLAIN execution plans to detect sequential table scans, high-cost cartesian joins, and buffer memory bottlenecks.' This names the exact artifacts it detects, so an agent can distinguish it from siblings like audit_sql_injection_ast or validate_sql_query_ast without opening any schema.
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?
Gives explicit triggering conditions ('diagnosing slow queries, optimizing database performance, or evaluating query cost') and names the alternative with the condition that selects it ('for getting index recommendations, use recommend_database_indexes instead'). Nothing about routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Statically parses SQL queries via AST lexical analysis to detect second-order injection, tautology conditions, and stacked queries. Use when auditing dynamic query parameters or untrusted user input before database execution; for sanitizing query strings for telemetry logging, use sanitize_sql_telemetry instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'raw_sql' ('audit_sensitivity' defaults to 'strict_zero_dynamic_taint'), supports '?demo=true' or L402 (10 sats), and returns HTTP 400 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_sql | Yes | Raw SQL query string to parse and audit for injection vulnerabilities. | |
| allow_comments | No | Whether SQL inline comments are allowed or treated as injection vectors. | |
| audit_sensitivity | No | Audit sensitivity mode: strict zero dynamic taint, second order injection check, or standard syntax audit. |
| Name | Required | Description |
|---|---|---|
| is_safe | Yes | True if the SQL query passed AST security audit with zero injection indicators. |
| risk_score | Yes | Continuous vulnerability score between 0.0 (safe) and 1.0 (critical exploit). |
| ast_fingerprint | Yes | Normalized structural AST hash of the parsed statement tree. |
| vulnerabilities | Yes | List of flagged injection mechanisms (e.g., tautology_always_true, stacked_statement, comment_truncation). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive/closed-world, yet the description still adds material facts an agent cannot get elsewhere: stateless edge call, 32 KB input cap, 60 RPM rate limit, HTTP 400 on invalid input, and that either 'demo=true' or an L402 payment of 10 sats is required. That is exactly the beyond-annotation context this dimension rewards.
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?
Front-loaded with purpose, then routing, then operational constraints in a single dense paragraph with no filler sentences. It is packed tightly enough that the payment/rate-limit clause reads as a run-on, but nothing is wasted.
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?
An output schema exists, so return values need no prose; annotations carry the safety profile; the description supplies the remaining operational facts (size limit, rate limit, auth/payment gate, failure mode). Nothing an agent needs before calling is missing.
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%, so the baseline is 3. The description does add one genuinely new fact – that 'audit_sensitivity' defaults to 'strict_zero_dynamic_taint' – but leaves 'allow_comments' entirely unmentioned, so the gain over the schema is marginal.
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?
Uses a specific verb and mechanism ('statically parses SQL queries via AST lexical analysis') and names the exact vulnerability classes detected: second-order injection, tautology conditions, stacked queries. An agent can distinguish this from summarize_sql or sanitize siblings without opening the schema.
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?
Explicitly states the trigger condition ('auditing dynamic query parameters or untrusted user input before database execution') and names an alternative for the adjacent-but-different job ('for sanitizing query strings for telemetry logging, use sanitize_sql_telemetry instead'). It does not address the closest sibling, validate_sql_query_ast, so the routing guidance is good but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audits database transaction workflows for concurrency anomalies, dirty reads, non-repeatable reads, and deadlock risks. Use when reviewing financial transfer procedures, inventory decrement operations, or multi-step checkout workflows; for calculating connection pool headroom, use calculate_pool_headroom instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'transaction_steps' ('target_isolation_level' defaults to 'read_committed'), supports '?demo=true' or L402 (15 sats), and returns HTTP 400 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_steps | Yes | Sequential SQL commands or description of business operations within the transaction. | |
| strict_deadlock_check | No | Whether to perform exhaustive cross-table lock acquisition ordering analysis. | |
| target_isolation_level | No | Candidate SQL isolation level: read committed, repeatable read, or serializable. |
| Name | Required | Description |
|---|---|---|
| deadlock_risk | Yes | Deadlock risk severity rating (NEGLIGIBLE, MODERATE, HIGH_REVERSED_LOCK_ORDER). |
| recommended_isolation | Yes | Optimal transaction isolation level to ensure ACID safety for the workload. |
| vulnerable_to_dirty_reads | Yes | True if transactions could read uncommitted intermediate state from other sessions. |
| vulnerable_to_phantom_reads | Yes | True if concurrent inserts could introduce phantom rows between sequential reads. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations, which only declare readOnly/idempotent/non-destructive/closed-world. The description adds statelessness, a 32 KB payload cap, a 60 RPM rate limit, demo-mode and L402 (15 sats) payment paths, the default isolation level, and a 400-on-invalid-input failure mode — all operationally decisive for an agent orchestrating the call.
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?
Three sentences, front-loaded with the purpose before the alternative and the operational constraints. The middle sentence is heavily parenthetical (nested quotes around parameter names plus payment/rate-limit clauses), which slightly hurts scannability but every clause carries real information.
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?
An output schema exists, all three parameters are documented, annotations cover the safety profile, and the description supplies limits, auth/payment mode, defaults, and error behavior. Nothing an agent needs to invoke this correctly is missing.
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 coverage is 100%, so the baseline is 3; the description earns an extra point by disclosing that target_isolation_level defaults to 'read_committed', a default the schema does not state. The remaining parameters, notably strict_deadlock_check, are left entirely to the schema, so it stops short of full compensation.
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?
States a specific verb (audits) and resource (database transaction workflows) with enumerated failure modes: concurrency anomalies, dirty reads, non-repeatable reads, deadlock risks. It also explicitly names the sibling it is not (calculate_pool_headroom), so an agent can discriminate without opening either schema.
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?
Gives concrete triggering contexts (financial transfer procedures, inventory decrement operations, multi-step checkout workflows) and routes the connection-pool-headroom case to calculate_pool_headroom. Clear positive guidance and one explicit exclusion, though no general statement of when this tool is inappropriate (e.g., non-transactional SQL review, which might belong to validate_sql_query_ast or analyze_query_plan).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates optimal connection pool sizing, idle timeouts, and client headroom based on server RAM and concurrency profile. Use when sizing PgBouncer, HikariCP, or Prisma connection pools to avoid server out-of-memory crashes; for checking transaction isolation hazards, use audit_transaction_isolation instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'server_ram_mb' and 'max_concurrent_clients' ('workload_profile' defaults to 'high_concurrency_oltp'), supports '?demo=true' or L402 (10 sats), and returns HTTP 400 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| server_ram_mb | Yes | Total available RAM in megabytes dedicated to the database server instance. | |
| workload_profile | No | Workload operational characteristics: high-concurrency OLTP, heavy analytical OLAP, or serverless edge burst. | |
| max_concurrent_clients | Yes | Peak anticipated concurrent client connections or serverless worker threads. |
| Name | Required | Description |
|---|---|---|
| memory_headroom_mb | Yes | Estimated unallocated memory buffer in megabytes remaining for query sorting. |
| recommended_min_idle | Yes | Recommended standby idle connection count for warm latency response. |
| connection_timeout_ms | Yes | Recommended pool connection acquisition timeout in milliseconds. |
| recommended_max_connections | Yes | Calculated optimal max pool size to avoid database thrashing and memory exhaustion. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds real operational context: stateless edge call, 32 KB payload cap, 60 RPM limit, `?demo=true` or L402 payment at 10 sats, and HTTP 400 on invalid input. These are traits an agent cannot get from the annotations and that affect how it should call and retry the tool.
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?
Two sentences, front-loaded with purpose and alternative routing before the operational constraints. Every clause carries information (cost, rate limit, error behavior); nothing is redundant with the title or restates structured fields.
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?
Since an output schema exists, return values need no explanation, and the description covers the remaining agent needs: inputs, default behavior, rate/size caps, payment option, and error response. Nothing required to invoke it correctly is missing.
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 coverage is 100%, so baseline would be 3, but the description adds meaning beyond the schema by naming the default value for workload_profile ('high_concurrency_oltp'), which the schema does not state. It also frames server_ram_mb and max_concurrent_clients as the two accepted inputs, reinforcing their roles.
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?
States a specific verb ("Calculates") applied to concrete outputs: pool sizing, idle timeouts, and client headroom, derived from server RAM and concurrency profile. It also names the sibling audit_transaction_isolation as the tool for a different concern, so an agent can separate the two without opening either schema.
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?
Gives an explicit use condition (sizing PgBouncer, HikariCP, or Prisma pools to avoid OOM crashes) and an explicit exclusion routing the agent to audit_transaction_isolation for isolation hazards. Nothing about when to pick this tool is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compares source and target DDL schemas to identify breaking changes, destructive column drops, and lock-inducing mutations. Use when verifying CI/CD migration scripts before production deployment to prevent downtime; for verifying relational normal form, use validate_schema_normalization instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'current_schema' and 'target_schema' ('risk_tolerance' defaults to 'zero_downtime_strict'), supports '?demo=true' or L402 (15 sats), and returns HTTP 400 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| target_schema | Yes | Proposed new database DDL schema representing target migration state. | |
| current_schema | Yes | Current production database DDL schema representing live tables and columns. | |
| risk_tolerance | No | Deployment safety policy: zero downtime strict, allow transient locks, or permissive dev. |
| Name | Required | Description |
|---|---|---|
| risk_level | Yes | Categorical migration risk assessment (LOW, MEDIUM, HIGH_LOCK_RISK, CRITICAL_DATA_LOSS). |
| breaking_operations | Yes | List of destructive changes (e.g., column dropped, non-null without default, type narrowing). |
| breaking_changes_detected | Yes | True if breaking changes or destructive table mutations were identified. |
| migration_steps_safe_order | Yes | Recommended zero-downtime phased rollout steps (expand, migrate, contract). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds genuinely non-redundant operational traits: statelessness, a 32 KB payload cap, 60 RPM rate limiting, the 'zero_downtime_strict' default, a demo bypass or L402 payment of 15 sats, and HTTP 400 on invalid input. These are failure modes and cost constraints an agent cannot infer from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, purpose front-loaded, then routing advice, then operational constraints. The second sentence is a dense run-on stacking size limit, rate limit, params, payment, and error code, which makes it slightly harder to scan than it could be, but nothing is wasted.
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?
With an output schema present the description need not explain return values, and it already covers inputs, defaults, alternative tool, limits, and error behavior. Nothing an agent needs to invoke this correctly is missing.
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 coverage is 100%, so the baseline is 3; the description earns above that by disclosing the default value of 'risk_tolerance' ('zero_downtime_strict'), which the schema does not state, and by naming both required inputs. The enum values themselves are still only explained by the schema.
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?
States a precise verb and resource pair ('Compares source and target DDL schemas to identify breaking changes, destructive column drops, and lock-inducing mutations'), and explicitly names the sibling it is not (validate_schema_normalization for normal-form checks). An agent can distinguish this from detect_openapi_breaking_changes and recommend_database_indexes on the description alone.
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?
Gives an explicit trigger ('Use when verifying CI/CD migration scripts before production deployment to prevent downtime') and an explicit exclusion with the correct alternative (validate_schema_normalization for relational normal form). Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compiles SQL DDL schemas into type-safe ORM entities and TypeScript validation schemas (Prisma, Drizzle, SQLAlchemy, Zod). Use when scaffolding application models, generating TypeScript data layers, or synchronizing schemas; for translating raw SQL across dialects, use transpile_sql_dialect instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'schema_ddl' ('orm_target' defaults to 'drizzle_orm_typescript'), supports '?demo=true' or L402 (15 sats), and returns HTTP 400 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| orm_target | No | Target ORM framework standard: Prisma schema, Drizzle ORM TypeScript, SQLAlchemy Python 2.0, or Zod types. | |
| schema_ddl | Yes | Database schema DDL statements defining tables, primary keys, and relationships. | |
| include_relations | No | Whether to generate explicit foreign key relation decorators and navigation properties. |
| Name | Required | Description |
|---|---|---|
| compiled_code | Yes | Generated type-safe model code matching the specified ORM or validation schema framework. |
| orm_framework | Yes | Name of the target ORM framework output produced. |
| models_generated | Yes | List of model entity names successfully parsed and compiled from the schema. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds materially new operational facts: statelessness, a 32 KB payload ceiling, 60 RPM rate limit, the '?demo=true' bypass or L402 payment of 15 sats, and HTTP 400 on invalid input. These are exactly the runtime constraints annotations cannot express.
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?
Purpose is front-loaded, then usage, then operational constraints — a sensible order. The second sentence is dense with parenthetical detail, which borders on crowded but every clause carries real decision-relevant information.
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?
An output schema exists, so return-value explanation is unnecessary; the description instead covers the things that matter for a hosted compiler call — size limit, rate limit, auth/payment path, and failure mode. An agent has everything needed to invoke it correctly.
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%, so the baseline is 3; the description earns a bump by disclosing the default for orm_target ('drizzle_orm_typescript'), which is absent from the schema. It does not, however, explain include_relations semantics beyond what the schema already says.
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?
Opens with a specific verb and resource — 'Compiles SQL DDL schemas into type-safe ORM entities' — and enumerates the target outputs (Prisma, Drizzle, SQLAlchemy, Zod). It also names the sibling it is not (transpile_sql_dialect), so an agent can distinguish it without opening either schema.
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?
Gives explicit trigger contexts ('scaffolding application models, generating TypeScript data layers, or synchronizing schemas') and an explicit exclusion routing to transpile_sql_dialect for raw SQL dialect translation. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommends optimal single-column and composite B-Tree/BRIN indexes based on slow query WHERE, JOIN, and ORDER BY clauses. Use when optimizing database response times and eliminating full-table scans; for inspecting full execution plans, use analyze_query_plan instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'slow_queries_or_workload' ('index_type_preference' defaults to 'btree_and_composite'), supports '?demo=true' or L402 (15 sats), and returns HTTP 400 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| max_new_indexes | No | Maximum number of index creation statements to recommend. | |
| index_type_preference | No | Target indexing strategy: B-tree and composite, BRIN and GIN sparse, or covering indexes with INCLUDE. | |
| slow_queries_or_workload | Yes | Collection of slow SQL queries or workload log statements to analyze for index gaps. |
| Name | Required | Description |
|---|---|---|
| recommended_indexes | Yes | List of recommended CREATE INDEX DDL statements with target columns. |
| storage_overhead_est | Yes | Estimated index disk storage footprint overhead impact. |
| expected_speedup_factor | Yes | Estimated average query execution speedup multiple (e.g. 14.5x). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds substantial context beyond them: stateless edge call, 32 KB payload cap, 60 RPM rate limit, demo mode, L402 payment of 15 sats, and HTTP 400 on invalid input. That is exactly the operational detail annotations cannot convey.
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?
Front-loaded with purpose and routing before the operational clauses, and every sentence carries information. It borders on dense with the payment/limit parenthetical, but nothing is redundant.
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?
An output schema exists, so return values need not be described. The description supplies rate limits, size cap, payment/auth model, and error behavior, leaving nothing an agent needs in order to invoke it correctly.
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%, so each parameter is already documented. The description names 'slow_queries_or_workload' and states the default for 'index_type_preference', adding marginal value, but does not add syntax or format detail beyond what the schema provides. Baseline 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?
States a specific verb (Recommends) plus resource (single-column and composite B-Tree/BRIN indexes) and even the input basis (WHERE, JOIN, ORDER BY clauses). The final clause routes the agent to the sibling analyze_query_plan, so it is distinguishable from related tools without opening a schema.
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?
Explicitly says when to use it ('optimizing database response times and eliminating full-table scans') and names the alternative for a different need ('for inspecting full execution plans, use analyze_query_plan instead'). Both the use case and the exclusion are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Masks PII, financial values, and credential literals from raw SQL query logs and slow-query dumps before telemetry storage. Use when scrubbing production database query logs before shipping to APM tools, Datadog, or external log collectors; for auditing SQL injection vulnerabilities, use audit_sql_injection_ast instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'query_logs' ('masking_policy' defaults to 'mask_pii_and_literals'), supports '?demo=true' or L402 (10 sats), and returns HTTP 400 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| hash_salt | No | Optional salt string for deterministic pseudonymization of user IDs. | |
| query_logs | Yes | Raw SQL query text or multi-line database query log strings requiring sanitization. | |
| masking_policy | No | Scrubbing rigor policy: mask PII and literals, anonymize all constants, or strict AST parameterization. |
| Name | Required | Description |
|---|---|---|
| sanitized_logs | Yes | Clean query logs with sensitive constants replaced by parameter placeholders. |
| parameterized_templates | Yes | Normalized abstract query patterns suitable for APM metrics grouping. |
| redacted_literals_count | Yes | Total number of strings, numbers, and PII literals scrubbed from logs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substantial context beyond them: stateless edge call, 32 KB payload cap, 60 RPM rate limit, the default masking policy, demo/L402 (10 sats) access, and a 400 error on invalid input. These are operational facts an agent cannot get from structured fields.
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?
Two sentences, front-loaded with purpose and alternative before operational constraints. Dense but every clause carries information; the only cost is that the constraint clause is packed into one long sentence that is harder to scan than a short bullet list would be.
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?
With an output schema covering return values and annotations covering the safety profile, the description fills the remaining gaps an agent needs: input limits, rate limit, default policy, payment path, and error behavior. Nothing required to call it correctly is missing.
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 coverage is 100%, so the schema carries the parameter burden and 3 is the baseline. The description adds the meaningful default for masking_policy (mask_pii_and_literals) which the schema omits, but never mentions hash_salt or the policy trade-offs, so it doesn't go beyond the schema in a substantive way.
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?
States a specific verb plus resource: masks PII, financial values, and credential literals from raw SQL query logs and slow-query dumps before telemetry storage. It also names the sibling it is not (audit_sql_injection_ast), so an agent can route correctly without opening either schema.
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?
Explicit trigger context: 'Use when scrubbing production database query logs before shipping to APM tools, Datadog, or external log collectors.' It names an alternative and the condition selecting it ('for auditing SQL injection vulnerabilities, use audit_sql_injection_ast instead'), leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates deterministic relational test seed fixtures respecting foreign key constraints, unique indexes, and data bounds. Use when provisioning mock database datasets for automated testing, staging environments, or sandbox demos; for compiling ORM models from schemas, use generate_orm_models instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'schema_ddl' ('fixture_volume' defaults to 'minimal_smoke_test_5'), supports '?demo=true' or L402 (15 sats), and returns HTTP 400 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| schema_ddl | Yes | Target database schema DDL defining tables, column types, and foreign key relations. | |
| fixture_volume | No | Mock dataset volume profile: minimal smoke test (5), standard dataset (50), or stress dataset (500). | |
| deterministic_seed | No | Integer seed for reproducible pseudo-random data generation. |
| Name | Required | Description |
|---|---|---|
| sql_inserts | Yes | Executable SQL INSERT statements populated with realistic mock records. |
| foreign_keys_satisfied | Yes | True if all foreign key dependencies and unique constraints were verified valid. |
| records_generated_per_table | Yes | Count of generated records partitioned by target table name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly/idempotent/non-destructive), and the description adds genuinely non-structured behavior: 32 KB payload ceiling, 60 RPM rate limit, L402 payment of 15 sats with a ?demo=true bypass, and HTTP 400 on invalid input. This is well beyond annotation coverage; it stops short of 5 only because error/limit context is compressed into one dense clause rather than explained.
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?
Two sentences, front-loaded with the core purpose before the usage/alternative clause. The final sentence packs limits, rate, payment, and errors into one semicolon-chained line — efficient but slightly dense; still, every clause carries information.
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?
With an output schema present, return values need not be described. The description still covers auth/payment, size and rate limits, failure mode, parameter defaults, and the sibling boundary — everything an agent needs to invoke it correctly.
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 coverage is 100%, so baseline is 3, but the description adds a fact the schema omits: that 'fixture_volume' defaults to 'minimal_smoke_test_5'. That default-value disclosure is real added meaning; 'deterministic_seed' is left entirely to the schema, which is acceptable given full coverage.
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?
Specific verb+resource: 'Generates deterministic relational test seed fixtures' with the key constraint ('respecting foreign key constraints, unique indexes, and data bounds') stated immediately. The title and description also make the boundary with generate_orm_models explicit, so an agent can distinguish the two without opening a schema.
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?
Explicit when-to-use list ('provisioning mock database datasets for automated testing, staging environments, or sandbox demos') plus a named alternative and the condition that selects it ('for compiling ORM models from schemas, use generate_orm_models instead'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translates natural language questions into dialect-accurate, optimized SQL SELECT queries with schema awareness and safety checks. Use when generating reporting queries or automated data analytics pipelines; for analyzing SQL execution performance and EXPLAIN plans, use analyze_query_plan instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'natural_language_request' and 'schema_ddl' ('sql_dialect' defaults to 'postgresql_dialect'), supports '?demo=true' or L402 (15 sats), and returns HTTP 400 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| schema_ddl | Yes | Database schema DDL statements defining available tables, columns, and relations. | |
| sql_dialect | No | Target SQL dialect specification: PostgreSQL dialect, MySQL dialect, or SQLite dialect. | |
| read_only_mode | No | Whether to enforce strict read-only SELECT query constraints. | |
| natural_language_request | Yes | Natural language question or reporting requirement to transform into SQL. |
| Name | Required | Description |
|---|---|---|
| dialect | Yes | Database engine dialect target the query was generated for. |
| sql_query | Yes | Synthesized, formatted SQL query tailored to the provided schema and dialect. |
| query_type | Yes | Operation classification (e.g., SELECT_AGGREGATE, SELECT_JOIN, FILTERED_SCAN). |
| explanation | Yes | Step-by-step rationale explaining table joins, filtering predicates, and grouping logic. |
| safety_checked | Yes | True if AST static analysis verified the query has zero mutation side-effects. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations: it is stateless and read-only, capped at 32 KB and 60 RPM, defaults sql_dialect to postgresql_dialect, supports demo mode or L402 payment, and returns HTTP 400 for invalid input. These operational constraints and failure modes are exactly the kind of context annotations alone do not convey.
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 front-loaded: purpose first, usage and alternative second, operational constraints third. Every sentence contributes distinct information, and the parenthetical details are dense but purposeful rather than ornamental.
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?
With full schema coverage, annotations, and an output schema present, the description supplies the remaining operational context an agent needs: statelessness, size and rate limits, dialect default, payment/demo behavior, and error behavior. Nothing important for correct invocation appears to be missing.
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 already 100%, so the schema carries most parameter meaning. The description adds useful semantics by noting that sql_dialect defaults to 'postgresql_dialect', but it does not add much about read_only_mode or the required inputs beyond naming them.
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 gives a specific verb and resource: translating natural language questions into dialect-accurate, optimized SQL SELECT queries with schema awareness and safety checks. It also explicitly distinguishes the tool from the sibling analyze_query_plan, so an agent can tell when this is the right NL-to-SQL generator rather than a query-plan analyzer.
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?
It states the intended use cases directly: generating reporting queries or automated data analytics pipelines. It also names a concrete alternative, analyze_query_plan, for SQL execution performance and EXPLAIN plans, which gives the agent a clear routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transpiles SQL queries and DDL schemas across PostgreSQL, MySQL, and SQLite dialects, rewriting functions and syntax quirks. Use when migrating application queries across database backends or testing against in-memory SQLite; for generating new queries from natural language, use synthesize_sql_query instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'sql_code' and 'source_dialect' ('target_dialect' defaults to 'sqlite'), supports '?demo=true' or L402 (10 sats), and returns HTTP 400 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| sql_code | Yes | SQL query or DDL statement to convert from source dialect into target dialect. | |
| source_dialect | Yes | Original SQL dialect of the input code: postgresql, mysql, or sqlite. | |
| target_dialect | Yes | Destination SQL dialect to transpile into: postgresql, mysql, or sqlite. |
| Name | Required | Description |
|---|---|---|
| transpiled_sql | Yes | Transpiled SQL code compliant with the target database dialect specification. |
| compatibility_warnings | Yes | Potential semantic differences or unsupported features flagged during transpilation. |
| syntax_transformations | Yes | List of dialect-specific transformations applied (e.g., NOW() to CURRENT_TIMESTAMP). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: stateless edge call, 32 KB payload cap, 60 RPM throttle, demo flag, L402 payment of 10 sats, and HTTP 400 on invalid input. This is exactly the runtime context annotations cannot express, though the payment gating is stated tersely and its interaction with a 'read-only' call is not explained.
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?
Front-loaded with purpose, then usage, then operational constraints — a sensible order with no filler. However the second half is a dense semicolon-chained run of limits, payment, and error codes that would scan better as discrete clauses.
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?
For a 3-parameter, fully-described, output-schema-backed tool, the description supplies everything an agent still needs: trigger conditions, the sibling alternative, size/rate ceilings, and failure mode. Return values are correctly left to the output schema rather than duplicated.
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 coverage is 100% with enums on both dialect parameters, so the baseline is 3. The description adds a claim that 'target_dialect' defaults to 'sqlite', which conflicts with the schema listing it as required — potentially misleading an agent into omitting it. The 'sql_code' size limit is the only genuinely additive parameter fact.
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?
States a specific verb and resource ('Transpiles SQL queries and DDL schemas') plus the exact scope (PostgreSQL, MySQL, SQLite) and the concrete work performed ('rewriting functions and syntax quirks'). 'Transpile' is distinct from sibling verbs like synthesize_sql_query, validate_sql_query_ast, and analyze_query_plan, so an agent can separate it without opening a schema.
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?
Gives two positive triggers — migrating application queries across backends and testing against in-memory SQLite — and an explicit exclusion routing to synthesize_sql_query for natural-language query generation. When-to-use and when-not-to-use are both stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audits database schemas for third normal form (3NF) compliance, transitive dependencies, and missing foreign key constraints. Use when reviewing database architectures, preventing update anomalies, or validating relational integrity; for detecting breaking schema migrations, use detect_breaking_migrations instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'schema_ddl' ('target_normal_form' defaults to 'third_normal_form_3nf'), supports '?demo=true' or L402 (10 sats), and returns HTTP 400 if invalid.
| Name | Required | Description | Default |
|---|---|---|---|
| schema_ddl | Yes | Database schema DDL statements defining table columns, primary keys, and relations. | |
| strict_keys | No | Whether to enforce explicit foreign key constraints on all ID references. | |
| target_normal_form | No | Target normalization standard: 3NF, Boyce-Codd BCNF, or denormalized OLAP star. |
| Name | Required | Description |
|---|---|---|
| conforms_to_target | Yes | True if the schema strictly satisfies the chosen normal form requirements. |
| normalization_score | Yes | Schema relational design quality score on a 0 to 100 scale. |
| redundancies_flagged | Yes | List of redundant fields, missing primary keys, or transitive dependencies identified. |
| refactoring_suggestions | Yes | Specific table decomposition and foreign key recommendations to achieve compliance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), and the description goes beyond them with statelessness, a 32 KB payload cap, 60 RPM rate limit, demo mode or L402 payment of 10 sats, and HTTP 400 on invalid input. These are operational facts an agent cannot obtain from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and the sibling alternative before the operational constraints, with no filler sentences. It is dense to the point of being one long sentence with stacked parentheticals, which slightly hurts scanability.
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?
An output schema exists, so return values need no explanation, and the annotations carry the safety profile. What remains — payload limits, rate limit, payment path, error behavior, and the parameter default — is all covered, leaving nothing an agent needs to call it correctly.
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%, so the baseline is 3; the description adds genuine value by disclosing that target_normal_form defaults to 'third_normal_form_3nf', a default the schema does not state. It adds little else about strict_keys, keeping it below a 5.
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?
States a specific verb and resource set: audits schemas for 3NF compliance, transitive dependencies, and missing foreign key constraints. It also explicitly names the sibling it is not (detect_breaking_migrations), so an agent can distinguish it without opening either schema.
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?
Gives concrete use cases (reviewing database architectures, preventing update anomalies, validating relational integrity) and an explicit exclusion routing to detect_breaking_migrations for migration breakage. Both the when and the when-not are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0analyze_query_planaudit_sql_injection_astaudit_transaction_isolationcalculate_pool_headroomdetect_breaking_migrationsgenerate_orm_modelsrecommend_database_indexessanitize_sql_telemetrysynthesize_seed_fixturessynthesize_sql_querytranspile_sql_dialectvalidate_schema_normalizationScored across 12 tools
Each tool targets a distinct artifact-action pair: query synthesis, injection auditing, plan analysis, migration risk, dialect transpilation, index recommendation, normalization validation, telemetry masking, fixture generation, pool sizing, isolation auditing, and ORM generation. Descriptions explicitly cross-reference sibling tools ('for X, use Y instead'), eliminating the few plausible overlaps such as performance analysis vs. index recommendation.
Every name follows a strict verb_noun snake_case pattern (synthesize_sql_query, audit_sql_injection_ast, detect_breaking_migrations, calculate_pool_headroom). Verbs are semantically precise and non-duplicated, so the naming reads as a coherent taxonomy.
Twelve tools is squarely in the well-scoped range and each covers a distinct concern in the database-intelligence domain. No filler or redundant entries appear.
The surface covers schema validation, migration safety, query generation/optimization, security auditing, data provisioning, and ORM scaffolding—a full lifecycle for read-only DB intelligence. Minor gaps remain (e.g., no query-execution/EXPLAIN retrieval tool and no lock/deadlock inspection beyond isolation auditing), but agents can work around these.
Deterministic safety, correctness & cost gate that vets Postgres SQL before your AI agent runs it.
Supabase-compatible Postgres for agents: projects, branches, SQL, auth, storage, email.
JSON/YAML, regex, diff, JWT, SQL dialects — the keyless millisecond ops an agent needs mid-task.
Persistent memory, hybrid search and a goal graph for AI agents, over stdio or remote HTTP.
