build-connector

Build Connector Workflow

You are building an Elliot connector — a JSON definition that wraps a data source in agent-ready MCP tools.

The tool sequence

Build always follows this order — each tool depends on the one before it:

elliot_set_context      → name the connector + product
elliot_discover_source  → register the API / DB, materialize its tables
elliot_query_sql        → inspect the real columns before designing tools
elliot_create_tool      → define one tool (verb-first description + SQL)
elliot_preview_tool     → run that tool against sandbox data, verify rows
elliot_build_connector  → assemble all registered tools into a connector
elliot_lint_connector   → check the built connector; fix, rebuild, re-lint
elliot_export_connector → write the connector file to disk

elliot_lint_connector, elliot_run_eval, and elliot_export_connector all operate on the connector produced by elliot_build_connector — if you skip the build step they have nothing to work on.

Workspace state

Existing connectors: !ls connectors/*.connector.json 2>/dev/null | xargs -I{} basename {} .connector.json | tr '\n' ', ' || echo "(none yet)" Elliot plugin: !curl -s http://localhost:3000/health 2>/dev/null | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('status','unknown'))" 2>/dev/null || echo "not running — start Elliot first: honcho start"

Steps

1. Name the connector

Call elliot_set_context with:

• name: slug-style name (e.g. "acme-crm")
• description: one sentence describing the product

2. Describe the source

Call elliot_discover_source. Collect from the user:

• Base URL (for REST) or connection string format (for DB — never log the value)
• Auth type: bearer, api_key, basic, or none
• Env var name holding the credential (e.g. ACME_API_KEY)
• Pagination style if REST: cursor, offset, page, link_header, or none

3. Explore the data shape

First, see what's loaded — call elliot_list_sources for a roster of every discovered source (table name, row count, columns).