MCP server for accessing Pinterest data via JDBC connector, enabling SQL queries and metadata discovery on Pinterest tables
Three tools with READ_ONLY scope providing data access via SQL. Naming follows verb_noun convention (get_*, run_*) with clear action verbs. Descriptions are present and moderately detailed (100-200 chars), explaining WHAT the tool does and WHEN to use it. However, parameter descriptions are minimal (single noun phrases), and output schemas are not formally documented, only mentioned as CSV format in descriptions. All tools have proper JSON Schema input validation with required field declarations. Error handling is minimal: tools throw RuntimeExceptions without actionable recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all being read-only. No pagination documented for potentially large result sets.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `pinterest_get_tables` tool to get a list of available tables. The output of the tool will be returned in CSV format, with the first line containing column headers.
Retrieves a list of objects, entities, collections, etc. (as tables) available in the data source. Use the `pinterest_get_columns` tool to list available columns on a table. Both `catalog` and `schema` are optional parameters. The output of the tool will be returned in CSV format, with the first line containing column headers.
Execute a SQL SELECT statement.
Parameter descriptions are minimal (single-word phrases) and lack actionable context. E.g., 'catalog', 'schema', 'table' provide no guidance on format, constraints, or what values to pass. LLMs cannot infer correct usage from bare noun descriptions.
Output schemas are not formally documented. Tools mention 'CSV format with column headers' in descriptions, but there is no structured schema document defining field names, types, and order. LLMs cannot plan downstream operations without knowing response structure.
No tool annotations present. All three tools are read-only, but readOnlyHint is not set. This prevents clients from knowing which tools are safe to invoke without user confirmation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Error handling does not guide recovery. Tools throw RuntimeException('ERROR: ' + ex.getMessage()). LLMs receive no guidance on whether to retry, what went wrong, or how to fix it. Errors should be categorized (retryable vs user-fixable) and include remedial suggestions.
No pagination documented. pinterest_get_tables and pinterest_get_columns may return large result sets (all tables or all columns in a table), but the tool descriptions do not mention result limits, offset parameters, or pagination strategy. Large CSV outputs can blow context windows.
pinterest_run_query description includes SQL dialect and valid clauses inline, which is helpful, but omits key constraints: maximum result rows, timeout duration, and whether non-SELECT statements are rejected. LLMs may attempt UPDATE or DELETE operations.