d3-mcp-server

find_example

Search and list D3.js examples from the Observable gallery by query or category, or browse all categories with counts to find relevant code samples.

Instructions

Find D3.js examples from the Observable gallery.

Without arguments, lists all categories with counts. With query, returns top 10 matching examples. With category, lists examples in that category.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_example"
  }
}

Input Schema

Name	Required	Description	Default
`query`	No
`category`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 13, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that query mode caps results at 10 and that each mode returns a different shape, but omits what happens when query and category are both supplied, empty-result behavior, and whether query is exact or fuzzy.

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

Conciseness5/5

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

One purpose sentence followed by three tightly parallel mode clauses, each earning its place with no filler. The purpose is front-loaded before the mode breakdown.

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?

An output schema exists, so return-value explanation is not required, and the description covers all three call modes for a two-optional-parameter tool. The remaining gap is precedence/conflict handling when both parameters are passed.

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 two parameters are undocumented structurally, and the description only partly compensates by describing their effect ('top 10 matching examples', 'lists examples in that category'). It never states accepted string formats or matching semantics for query, nor valid category names.

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 (find) and resource (D3.js examples from the Observable gallery), which is immediately actionable. It does not, however, differentiate itself from the sibling get_example, leaving the agent to guess whether find and get return different things.

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?

Explicitly tells the agent which invocation mode to choose: no arguments for categories, query for matching examples, category for listing. It stops short of stating when to prefer this tool over the sibling get_example or search_docs.

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

Deploy Server