Skip to main content
Glama
brownglasses

dotplot-mcp

by brownglasses
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

load_from_db

Export events from your project database into a CSV for dot plot analytics. Run read-only SELECT queries and shape business tables into user_id, date, and event columns.

Instructions

Pull events out of the project's database into a CSV.

How to use it:

  1. The connection string comes from DOTPLOT_DB_URL by default. Tell the user to export it — never ask them to paste a password into the chat: export DOTPLOT_DB_URL="postgresql://readonly:...@host:5432/db" (Supabase: Dashboard > Settings > Database > Connection string)

  2. Read the schema first (information_schema), find the tables that record what users did, and shape them into user_id, date, event. Most products have no events table — ordinary business tables are the event log: SELECT user_id::text, created_at::date AS date, 'purchase' AS event FROM orders Combine several actions with UNION ALL.

  3. Only SELECT runs; anything else is refused. Recommend a read-only role.

Supports postgresql:// (Supabase, RDS, Neon) and sqlite:///path for testing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
db_urlNo
output_csvNoevents.csv

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.4

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that only SELECT runs (other statements are refused), recommends a read-only role, sources the connection string from DOTPLOT_DB_URL, and lists supported URL schemes (postgresql, sqlite). It omits error behavior and what happens to the output file on repeat runs, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the one-line purpose before a numbered how-to, so the agent gets the summary first. The steps are dense but each carries actionable information (env var, schema inspection, SQL example). Slightly verbose for the amount of unique content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description tells the agent the result is a CSV, where the connection comes from, and the safety model, which is enough to invoke it correctly. A moderate-complexity load tool is adequately covered, though sibling routing and the output_csv semantics remain unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It clarifies that query must be a SELECT statement and that db_url defaults to DOTPLOT_DB_URL, which is valuable. However, the third parameter output_csv (default 'events.csv') is only hinted at by 'into a CSV' and never explained as a filename parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Pull events out of the project's database into a CSV.' The agent immediately understands it loads event data as CSV. It does not, however, distinguish itself from data-oriented siblings like describe_events, analyze, or get_report_strings.

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

Usage Guidelines4/5

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

Provides detailed procedural guidance: connection-string setup, reading the schema first, shaping rows into user_id/date/event, and combining actions with UNION ALL. This is clear context for how to use the tool, but it never names an alternative or states when this tool is the wrong choice versus the sibling analysis tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools