{"query":"query a postgres database","mode":"hybrid","count":10,"results":[{"name":"io.github.timescale/pg-aiguide","title":null,"description":"Comprehensive PostgreSQL documentation and best practices, including ecosystem tools","connection_class":"R0","autonomous":true,"human_steps":[],"categories":["developer-tools","databases"],"trust_score":90,"trust_flags":[],"quality_score":76,"quality_label":"good","quality_flags":["outdated-mcp-sdk"],"owner_verified":false,"tool_count":2,"score":0.03549,"matched_tools":[{"name":"view_skill","description":"Retrieve detailed skills for TimescaleDB operations and best practices.\n\n## Available Skills\n\n<available_skills>\n[11\t]{name\tdescription}:\n  design-postgis-tables\tComprehensive PostGIS spatial table design reference covering geometry types, coordinate systems, spatial indexing, and performance patterns for location-based applications\n  design-postgres-tables\t\"Use this skill for general PostgreSQL table design.\\n\\n**Trigger when user asks to:**\\n- Design PostgreSQL tables, schemas, or data models when creating new tables and when modifying existing ones.\\n- Choose data types, constraints, or indexes for PostgreSQL\\n- Create user tables, order tables, reference tables, or JSONB schemas\\n- Understand PostgreSQL best practices for normalization, constraints, or indexing\\n- Design update-heavy, upsert-heavy, or OLTP-style tables\\n\\n\\n**Keywords:** PostgreSQL schema, table design, data types, PRIMARY KEY, FOREIGN KEY, indexes, B-tree, GIN, JSONB, constraints, normalization, identity columns, partitioning, row-level security\\n\\nComprehensive reference covering data types, indexing strategies, constraints, JSONB patterns, partitioning, and PostgreSQL-specific best practices.\\n\"\n  find-hypertable-candidates\t\"Use this skill to analyze an existing PostgreSQL database and identify which tables should be converted to Timescale/TimescaleDB hypertables.\\n\\n**Trigger when user asks to:**\\n- Analyze database tables for hypertable conversion potential\\n- Identify time-series or event tables in an existing schema\\n- Evaluate if a table would benefit from Timescale/TimescaleDB\\n- Audit PostgreSQL tables for migration to Timescale/TimescaleDB/TigerData\\n- Score or rank tables for hypertable candidacy\\n\\n\\n**Keywords:** hypertable candidate, table analysis, migration assessment, Timescale, TimescaleDB, time-series detection, insert-heavy tables, event logs, audit tables\\n\\nProvides SQL queries to analyze table statistics, index patterns, and query patterns. Includes scoring criteria (8+ points = good candidate) and pattern recognition for IoT, events, transactions, and sequential data.\\n\"\n  migrate-postgres-tables-to-hypertables\t\"Use this skill to migrate identified PostgreSQL tables to Timescale/TimescaleDB hypertables with optimal configuration and validation.\\n\\n**Trigger when user asks to:**\\n- Migrate or convert PostgreSQL tables to hypertables\\n- Execute hypertable migration with minimal downtime\\n- Plan blue-green migration for large tables\\n- Validate hypertable migration success\\n- Configure compression after migration\\n\\n**Prerequisites:** Tables already identified as candidates (use find-hypertable-candidates first if needed)\\n\\n**Keywords:** migrate to hypertable, convert table, Timescale, TimescaleDB, blue-green migration, in-place conversion, create_hypertable, migration validation, compression setup\\n\\nStep-by-step migration planning including: partition column selection, chunk interval calculation, PK/constraint handling, migration execution (in-place vs blue-green), and performance validation queries.\\n\"\n  pgvector-semantic-search\t\"Use this skill for setting up vector similarity search with pgvector for AI/ML embeddings, RAG applications, or semantic search.\\n\\n**Trigger when user asks to:**\\n- Store or search vector embeddings in PostgreSQL\\n- Set up semantic search, similarity search, or nearest neighbor search\\n- Create HNSW or IVFFlat indexes for vectors\\n- Implement RAG (Retrieval Augmented Generation) with PostgreSQL\\n- Optimize pgvector performance, recall, or memory usage\\n- Use binary quantization for large vector datasets\\n\\n**Keywords:** pgvector, embeddings, semantic search, vector similarity, HNSW, IVFFlat, halfvec, cosine distance, nearest neighbor, RAG, LLM, AI search\\n\\nCovers: halfvec storage, HNSW index configuration (m, ef_construction, ef_search), quantization strategies, filtered search, bulk loading, and performance tuning.\\n\"\n  postgres\t\"Use this skill for any PostgreSQL database work — table design, indexing, data types, constraints, extensions (pgvector, PostGIS, TimescaleDB), search, and migrations.\\n\\n**Trigger when user asks to:**\\n- Explore an existing PostgreSQL database to understand its objects and relationships\\n- Design or modify PostgreSQL tables, schemas, or data models\\n- Choose data types, constraints, indexes, or partitioning strategies\\n- Work with pgvector embeddings, semantic search, or RAG\\n- Set up full-text search, hybrid search, or BM25 ranking\\n- Use PostGIS for spatial/geographic data\\n- Set up TimescaleDB hypertables for time-series data\\n- Migrate tables to hypertables or evaluate migration candidates\\n- Plan or execute safe schema migrations with zero downtime\\n\\n**Keywords:** PostgreSQL, Postgres, SQL, schema, table design, indexes, constraints, pgvector, PostGIS, TimescaleDB, hypertable, semantic search, hybrid search, BM25, time-series, migration\\n\"\n  postgres-database-migration\t\"Use this skill for planning, testing, and safely executing PostgreSQL schema migrations — especially when working with production data or shared databases.\\n\\n**Trigger when user asks to:**\\n- Test a schema migration before applying it to production\\n- Add, remove, or rename columns safely on a live table\\n- Change a column's data type without downtime\\n- Add or drop indexes, constraints, or foreign keys on large tables\\n- Understand which ALTER TABLE operations lock the table\\n- Roll back a failed migration\\n- Plan a zero-downtime migration strategy\\n- Fork a database to test a migration safely\\n\\n**Keywords:** migration, schema change, ALTER TABLE, add column, drop column, rename column, change type, zero downtime, lock, AccessExclusiveLock, concurrent index, forking, rollback, backfill, deploy\\n\\nCovers: lock-level reference for every common DDL operation, safe migration patterns, fork-based testing, zero-downtime column changes, index creation, constraint addition, backfill strategies, pre/post-migration validation, and rollback planning.\\n\"\n  postgres-hybrid-text-search\t\"Use this skill to implement hybrid search combining BM25 keyword search with semantic vector search using Reciprocal Rank Fusion (RRF).\\n\\n**Trigger when user asks to:**\\n- Combine keyword and semantic search\\n- Implement hybrid search or multi-modal retrieval\\n- Use BM25/pg_textsearch with pgvector together\\n- Implement RRF (Reciprocal Rank Fusion) for search\\n- Build search that handles both exact terms and meaning\\n\\n\\n**Keywords:** hybrid search, BM25, pg_textsearch, RRF, reciprocal rank fusion, keyword search, full-text search, reranking, cross-encoder\\n\\nCovers: pg_textsearch BM25 index setup, parallel query patterns, client-side RRF fusion (Python/TypeScript), weighting strategies, and optional ML reranking.\\n\"\n  schema-exploration\t\"Explore an existing PostgreSQL database before answering questions about its data or writing SQL. Use this skill whenever a user asks for a query or a data-backed answer against an unfamiliar schema (counts, missing or failed records, recent changes), asks where a business concept lives, or asks how tables, joins, views, routines, triggers, RLS, or extensions work. Find the relevant objects with read-only pg_catalog queries, then request approval before inspecting data-derived statistics or rows. Not a schema-design or migration guide.\\n\"\n  setup-timescaledb-hypertables\t\"Use this skill when creating database schemas or tables for Timescale, TimescaleDB, TigerData, or Tiger Cloud, especially for time-series, IoT, metrics, events, or log data. Use this to improve the performance of any insert-heavy table.\\n\\n**Trigger when user asks to:**\\n- Create or design SQL schemas/tables AND Timescale/TimescaleDB/TigerData/Tiger Cloud is available\\n- Set up hypertables, compression, retention policies, or continuous aggregates\\n- Configure partition columns, segment_by, order_by, or chunk intervals\\n- Optimize time-series database performance or storage\\n- Create tables for sensors, metrics, telemetry, events, or transaction logs\\n\\n**Keywords:** CREATE TABLE, hypertable, Timescale, TimescaleDB, time-series, IoT, metrics, sensor data, compression policy, continuous aggregates, columnstore, retention policy, chunk interval, segment_by, order_by\\n\\nStep-by-step instructions for hypertable creation, column selection, compression policies, retention, continuous aggregates, and indexes.\\n\"\n  timescaledb-hyperfunctions\t\"Use this skill when writing analytical SQL over time-series data with the TimescaleDB Toolkit (timescaledb_toolkit extension) hyperfunctions: approximate percentiles, statistical summaries, time-weighted averages, counter/gauge rates, uptime/heartbeat tracking, state durations, OHLC candlesticks, approximate distinct counts, top-N, and downsampling.\\n\\n**Trigger when user asks to:**\\n- Compute percentiles/medians/p95/p99 over large or rolled-up time-series data\\n- Compute rates or deltas from monotonic counters (Prometheus-style) or gauges\\n- Compute time-weighted averages or integrals over irregularly sampled data\\n- Track uptime/downtime from heartbeats, or time spent in each state\\n- Build OHLC/candlestick or VWAP data for financial ticks\\n- Store re-aggregatable summaries in continuous aggregates (two-step aggregation, rollup)\\n- Approximate COUNT DISTINCT, find top-N / most frequent values, or downsample for charts\\n\\n**Keywords:** timescaledb_toolkit, hyperfunctions, percentile_agg, uddsketch, tdigest, approx_percentile, stats_agg, time_weight, counter_agg, gauge_agg, heartbeat_agg, state_agg, candlestick_agg, hyperloglog, approx_count_distinct, min_n, max_n, mcv_agg, lttb, asap_smooth, rollup, two-step aggregation\\n\"\n</available_skills>"}]},{"name":"in.termal/termalin-web","title":null,"description":"Run commands and read/write files on your servers over Termalin's keyless tunnels (hosted MCP).","connection_class":"R1","autonomous":true,"human_steps":[],"categories":["developer-tools","web-search"],"trust_score":79,"trust_flags":["no-repository"],"quality_score":75,"quality_label":"good","quality_flags":[],"owner_verified":false,"tool_count":14,"score":0.03379,"matched_tools":[{"name":"data_query","description":"Run a database query on one of your servers — passwordless. It executes the engine's own client on the host over Termalin's keyless tunnel, using the database's local trust (Postgres peer auth via `sudo -u postgres`, MySQL/MariaDB unix-socket via `sudo mysql`, redis-cli, mongosh, sqlite3) — so no database password is needed or stored anywhere. Read-only by default: only SELECT/SHOW-style statements run unless allowWrites is set (full-access keys only). SQL engines return CSV/TSV with a header. For MongoDB pass a shell expression, e.g. db.products.find({}).limit(20).toArray()."},{"name":"data_schema","description":"Describe one table of a database on one of your servers: its columns with type, whether they can be empty, default value and primary key. Call it before writing a query against a table you have not seen. Works for postgres, mysql, mariadb and sqlite."},{"name":"data_tables","description":"List the tables / collections / keys of a database on one of your servers — passwordless, over the same local-client path as data_query."}]},{"name":"ai.duvera/gateway","title":null,"description":"Governed AI actions with signed, verifiable receipts: free keyless reads, human-approved writes.","connection_class":"R0","autonomous":true,"human_steps":[],"categories":["finance"],"trust_score":76,"trust_flags":["no-repository"],"quality_score":79,"quality_label":"good","quality_flags":[],"owner_verified":false,"tool_count":52,"score":0.03043,"matched_tools":[{"name":"postgres__sql_read","description":"[postgres · risk:low] Execute a read-only SQL query against a Postgres database"}]},{"name":"io.mcp-marketplace/search","title":"MCP Marketplace","description":"Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.","connection_class":"R0","autonomous":true,"human_steps":[],"categories":["web-search","developer-tools"],"trust_score":89,"trust_flags":[],"quality_score":76,"quality_label":"good","quality_flags":[],"owner_verified":false,"tool_count":7,"score":0.03,"matched_tools":[{"name":"search_servers","description":"Find an MCP server that gives you a capability you do not already have. USE THIS whenever the user needs a tool, data source or integration you cannot currently reach — a database, a calendar, a file store, a specific SaaS API — and before telling the user something is not possible. `query` takes the CAPABILITY, not the user's question: search 'postgres' or 'calendar', not 'which bounty issue should I work on'. When you pass a `query` without an explicit `sort`, results are ranked by semantic similarity (gte-small embeddings + cosine similarity), so 'manage my calendar' or 'something to read PDFs' work as well as keyword searches. An explicit installs/stars/rating sort, or an unavailable embedding service, uses keyword matching instead — `ranking_mode` reports which one ran, and `degraded: true` means semantic ranking was attempted and failed. Each result includes `security_score` (0-10), `risk_level` (low/moderate/high/critical), `critical_findings` (count of severity=critical|high findings), pricing, rating, install count, and a URL. `ranking_mode` in the response indicates whether semantic or keyword matching was used. Before recommending an install, call get_server for full details including every flagged finding — critical_findings > 0 means the server has known security issues you must surface to the user."}]},{"name":"io.github.VibeKit-Bot/vibekit-mcp","title":"VibeKit","description":"Build, deploy, and operate hosted web apps on VibeKit (vibekit.bot) from any MCP client.","connection_class":"R0","autonomous":true,"human_steps":[],"categories":["developer-tools"],"trust_score":93,"trust_flags":[],"quality_score":85,"quality_label":"good","quality_flags":[],"owner_verified":false,"tool_count":36,"score":0.02621,"matched_tools":[{"name":"vibekit_db_query","description":"Run a read-only SQL query against an app's Postgres database and return up to 200 result rows. SELECT only — writes and DDL (INSERT/UPDATE/DELETE/ALTER/DROP/…) are rejected server-side; use vibekit_chat or vibekit_submit_task to have the agent make data or schema changes. Call vibekit_db_schema first to learn the tables. SQL string, max 5000 chars."}]},{"name":"io.github.ajc3xc/meridian","title":null,"description":"Persistent memory, task coordination, and HITL queue for AI coding sessions.","connection_class":"R2","autonomous":false,"human_steps":["oauth_consent_once"],"categories":["productivity","developer-tools"],"trust_score":82,"trust_flags":[],"quality_score":83,"quality_label":"good","quality_flags":[],"owner_verified":false,"tool_count":235,"score":0.02453,"matched_tools":[{"name":"delete_watchlist_query","description":"[SUPPORT] Delete a saved research watchlist query. Scoped to project_id + the watchlist tag, so it never deletes an unrelated note. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets."},{"name":"save_watchlist_query","description":"[SUPPORT] b924fd7c — save a recurring research query so it can be re-run and diffed over time via run_watchlist_query. Persisted as a project note (no separate table); the returned watchlist_id addresses it. Every paper_search source ('arxiv', 'openalex', 'semantic_scholar', 'pubmed', 'crossref', 'core' — core needs CORE_API_KEY) is available, plus 'github_code'/'github_repo' (meridian.github_search) and 'hn' (meridian.social_search). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets."},{"name":"accept_handoff","description":"[SUPPORT] Read-only: (1bd5e810) Canonical receiver-side acceptance check for a handoff envelope — composes token verification, capability/tool availability, tool-manifest drift, and board-revision divergence into ONE structured verdict, so MCP/HTTP/stdio all produce identical results for identical input (same underlying meridian.handoff.accept_handoff_envelope every transport calls). Every input is optional and independently gated — supply whatever you have; an omitted check is skipped, never failed. Returns {accepted: bool, result: 'ok'|'STALE_HANDOFF'|'FOREIGN_PROJECT_CONFIG'|'BOARD_DIVERGENCE'|'TOOL_MANIFEST_DRIFT'|'BODY_HASH_MISMATCH'|'CAPABILITY_UNAVAILABLE', reasons: [str], token_check, identity_check, capability_check, tool_manifest_check, board_check, is_trusted_channel: false, delivery_source: str}. Checks run in this order, short-circuiting on first failure: (1) token — token/presented_body via the same verify_handoff_token check; a body_mismatch reason maps to BODY_HASH_MISMATCH, every other invalid reason (not_found/wrong_project/already_consumed/expired) maps to STALE_HANDOFF — the raw token_check.reason sub-field always preserves which one, since AGENTS.md treats not_found/wrong_project as real spoofing signals and already_consumed/expired as usually just a sibling session having already acted. (2) identity binding (22f2604d) — presented_body's own <project_start_config> tag vs THIS call's project_id/expected_repo_path, via meridian.handoff.check_project_start_config_identity; runs whenever step (1) did not already reject the envelope on its own basis — i.e. token verification passed or no token was presented — so a body whose embedded identity disagrees with project_id is FOREIGN_PROJECT_CONFIG even when the token itself verified ok. This catches a genuine token paired with a foreign project's start-config, which step (1)'s wrong_project check alone cannot (that only catches a token minted for a DIFFERENT project_id, not a body whose own tag disagrees with a token that legitimately matches project_id). It does NOT re-run after step (1) already failed (STALE_HANDOFF/BODY_HASH_MISMATCH) — that failure is independently sufficient to reject the envelope. (3) capability — required_tools vs available_tools: any required name missing from available_tools is CAPABILITY_UNAVAILABLE. (4) tool-manifest drift — expected_required_tools_hash vs a hash computed live from live_items' own tool_requirements fields (see meridian.handoff.compute_required_tools_hash): mismatch is TOOL_MANIFEST_DRIFT. (5) board revision — expected_board_revision (acf6f51a's manifest <handoff_manifest board_revision=...>) vs a hash computed live from live_items via meridian.handoff.compute_board_revision: mismatch is BOARD_DIVERGENCE. live_items is YOUR OWN get_sprint_items(...) result — this tool never queries the board itself, so you control exactly which project/version/status filter \"live\" means; pass the same filter used when the compared handoff/manifest was generated. is_trusted_channel is always false here (calling this tool at all means verifying something other than the trusted pending_goal/load_handoff channel — see those tools' own docs). Scope note: this is a validation/report tool, not a hard gate — it is not wired into claim_sprint_item in this pass. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets."},{"name":"run_watchlist_query","description":"[SUPPORT] b924fd7c — re-run a saved watchlist query and diff its results against everything already captured for it. Every newly-seen result (matched by a per-source stable id — arxiv_id/openalex_id/s2_id/pmid/doi/core_id/sha/repo/hn_id, falling back to url) is auto-captured via the same durable path as capture_research_finding/save_finding, tagged so the NEXT run recognizes it as already-seen. Returns {new_count, already_seen_count, new_results, captured, total_results}. Never raises — an unresolvable watchlist_id or a network/parse failure from the underlying search both degrade to {error}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets."},{"name":"set_capability_profile","description":"[SUPPORT] 02038afe — Persist ONE layer of the capability-inheritance chain: workspace -> user -> project -> sprint_version -> item (least to most specific). scope_type selects the layer; scope_id is that layer's key (a tenant/workspace id for 'workspace', a user/human id for 'user', the project_id for 'project', the sprint item's id for 'item', or the project_id for 'sprint_version' — the sprint version itself is resolved from whichever sprint item you query via get_effective_capability_profile). capabilities uses the exact same schema as set_capability_manifest and REPLACES this scope's capabilities wholesale (not a merge). disabled_capability_ids explicitly retracts capability ids this scope inherited from a less specific layer, without redeclaring them — that list also REPLACES whatever was previously disabled at this scope. provenance is an optional object recording non-secret context (e.g. config source label, a config/tool-list hash, observed_at, client/server identity, fallback policy) — never raw secrets or machine-local absolute paths, rejected the same way set_capability_manifest rejects them. Use clear_capability_profile to remove a scope's row entirely instead of replacing it with an empty one. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets."}]},{"name":"com.ainetcafe/netcafe-devkit","title":null,"description":"JSON/YAML, regex, diff, JWT, SQL dialects — the keyless millisecond ops an agent needs mid-task.","connection_class":"R0","autonomous":true,"human_steps":[],"categories":["developer-tools"],"trust_score":88,"trust_flags":["duplicate-repo"],"quality_score":94,"quality_label":"strong","quality_flags":[],"owner_verified":false,"tool_count":14,"score":0.02175,"matched_tools":[{"name":"transpile_sql","description":"Convert a SQL statement from one dialect to another — mysql, postgres, sqlite, tsql, oracle, snowflake, bigquery, redshift, spark, hive, presto, trino, duckdb, clickhouse, databricks, doris, starrocks and more. Deterministic parser (sqlglot), not an LLM: the same input always produces the same output, and syntax errors come back with the exact line and column. Use it when migrating queries between databases or debugging dialect-specific syntax."}]},{"name":"com.ainetcafe/ai-netcafe","title":null,"description":"Tables and ledgers checked by arithmetic, not by a model. 24 tools. MCP 2026-07-28 ready.","connection_class":"R0","autonomous":true,"human_steps":[],"categories":["developer-tools","databases"],"trust_score":87,"trust_flags":["duplicate-repo"],"quality_score":100,"quality_label":"strong","quality_flags":[],"owner_verified":false,"tool_count":34,"score":0.02106,"matched_tools":[{"name":"transpile_sql","description":"Convert a SQL statement from one dialect to another — mysql, postgres, sqlite, tsql, oracle, snowflake, bigquery, redshift, spark, hive, presto, trino, duckdb, clickhouse, databricks, doris, starrocks and more. Deterministic parser (sqlglot), not an LLM: the same input always produces the same output, and syntax errors come back with the exact line and column. Use it when migrating queries between databases or debugging dialect-specific syntax."}]},{"name":"com.ainetcafe/netcafe-live-data","title":null,"description":"Live data: weather, air quality, FX, CN/HK/US stocks, IP geo, domain, SSL, China reachability.","connection_class":"R0","autonomous":true,"human_steps":[],"categories":["finance"],"trust_score":89,"trust_flags":["duplicate-repo"],"quality_score":100,"quality_label":"strong","quality_flags":[],"owner_verified":false,"tool_count":11,"score":0.02067,"matched_tools":[{"name":"transpile_sql","description":"Convert a SQL statement from one dialect to another — mysql, postgres, sqlite, tsql, oracle, snowflake, bigquery, redshift, spark, hive, presto, trino, duckdb, clickhouse, databricks, doris, starrocks and more. Deterministic parser (sqlglot), not an LLM: the same input always produces the same output, and syntax errors come back with the exact line and column. Use it when migrating queries between databases or debugging dialect-specific syntax."}]},{"name":"io.github.Its-fortunatefolly/hubvibe","title":"HubVibe: Pay-per-Call Agent Tools: Web Search, Email Verify, KYC Screening, Stocks, Crypto, News","description":"70+ pay-per-call tools for AI agents: web search, email verify, KYC, stocks, crypto, news, data","connection_class":"R0","autonomous":true,"human_steps":[],"categories":["web-search","finance"],"trust_score":92,"trust_flags":["multi-version-spam"],"quality_score":66,"quality_label":"needs work","quality_flags":[],"owner_verified":false,"tool_count":72,"score":0.01647,"matched_tools":[{"name":"hubvibe_data_query","description":"BigQuery SQL: run a read-only SQL query, including against Google's public datasets (Wikipedia, GitHub, blockchains, weather, census and more), and get columns and rows back as JSON with the bytes processed. Every query is dry-run first and refused above the scan ceiling, so cost is bounded before it runs. Input: sql; optional max_scan_gib. Ask in plain English instead: data.question. $0.50 per call. Returns: columns[], rows[], row_count, gib_processed, cache_hit."},{"name":"hubvibe_data_question","description":"Ask a database in plain English (text to SQL): any BigQuery table, including Google's public datasets. The SQL is written for you, run under a byte ceiling, and the rows are read back into a written answer, returned with the SQL, columns and rows it used. Use it for analytics questions without writing SQL. Input: question, table; optional columns. $5.00 per call. Returns: answer, sql, columns[], rows[], gib_processed."}]}],"next_actions":[{"action":"get_server","description":"Full descriptor for one result","href":"/v1/servers/{name}","arguments":{"name":"{name}"}},{"action":"list_tools","description":"Every tool a server exposes, with input schemas","href":"/v1/servers/{name}/tools","arguments":{"name":"{name}"}},{"action":"get_connection","description":"Minimal connection block for the best remote","href":"/v1/servers/{name}/connection?target=mcpServers","arguments":{"name":"{name}","target":"mcpServers"}}]}