MCP Server Part 4: Expose callbacks as tools

[KoolADE85]

Summary

This PR turns Dash callbacks into fully-described MCP tools. Each tool has four main parts:

Tool description (descriptions/)

A human-readable summary of what the callback does. Built from pluggable sources that each contribute lines:

• description_outputs.py — semantic summary of what the callback returns (e.g. "Returns chart/visualization data" for a Graph.figure output)
• description_docstring.py — the callback function's Python docstring

Each source extracts what it needs from a given CallbackAdapter in order to produce text descriptions. New sources can be added by appending to the _SOURCES list.

Input schema (input_schemas/)

JSON Schema that describes valid inputs for each callback parameter. Each schema is derived from:

• Python type annotations on the callback function (e.g. def callback(metric: str): → {"type": "string"})
• Automatic introspection of the callback's components (e.g. Input("dropdown", "value") → {"type": { "anyOf": ["string", "number", "boolean", null]}})
• Manually curated overrides for components where introspection is insufficient (e.g. the "date" format of date pickers; dropdown values are an array only when multi=True)

Input description (input_descriptions/)

Each parameter also gets a text description assembled from various sources:

• Text content of an html.Label that is associated with the input
• Per-parameter text from the callback's docstring
• A list of props that are used in the app (options, min/max, value, etc) and any chained callbacks that set values for this input

Output schema (output_schemas/)

JSON Schema for the tool's outputSchema field

• A generic schema derived from the dict that Dash callbacks return to dash-renderer.

Manual testing

You can see the JSON that will be presented to LLMs by testing manually:

from dash import Dash, html, dcc, Input, Output
from dash._get_app import app_context
import json

app = Dash(__name__)
app.layout = html.Div([
    html.Label("Choose a metric", htmlFor="metric"),
    dcc.Dropdown(id="metric", options=["revenue", "users"], value="revenue"),
    html.Label(["Threshold value", dcc.Input(id="threshold", type="number", value=100)]),
    dcc.Dropdown(id="sub-metric"),
    html.Div(id="result"),
])

@app.callback(Output("sub-metric", "options"), Input("metric", "value"))
def update_sub_metrics(metric):
    """Update available sub-metrics based on the selected metric."""
    if metric == "revenue": return ["gross", "net", "recurring"]
    return ["daily", "monthly"]

@app.callback(Output("result", "children"), Input("metric", "value"),
              Input("threshold", "value"), Input("sub-metric", "value"))
def filter_data(metric: str, threshold: float, sub_metric: str):
    """Filter data by metric and threshold."""
    return f"{metric}/{sub_metric} > {threshold}"

with app.server.app_context():
    app_context.set(app)
    from dash.mcp.primitives.tools.callback_adapter_collection import CallbackAdapterCollection
    collection = CallbackAdapterCollection(app)
    for adapter in collection:
        tool = adapter.as_mcp_tool
        print(tool)

[github-actions]

Thank you for your contribution to Dash! 🎉

This PR is exempt from requiring a linked issue due to its labels.

[T4rk1n]

Looks good, but need to make the tests in style of the rest of the repo.

• Single function, no class unless necessary.
• code for the tests eg: test_mscp00x_* would be for tests in mcp schema component proptypes.
• More tests files for separation and splitting.

[T4rk1n]

Maybe out of scope of this PR, but are we really running 3.8? min should be 3.9

[KoolADE85]

yeah, all the CI tests are in 3.8 still.
We should definitely consider bumping the min version. The mcp package requires >=3.10 so if we can make that the min version, we would be able to run all tests without any conditions.
I also considered that out of scope for this PR, but maybe worth revisiting?

[T4rk1n]

These tests need a code and number like the rest of the codebase. It makes the test easier to find and you can also filter easily which tests runs.

[T4rk1n]

I'd rather see different files and simple function for the tests instead of classes as sections.

More files == more evenly splitting in the ci.