Building a data layer, not a dashboard
Most developer tools over-invest in the human UI and under-invest in the API. We flipped that. The agent is the primary customer.
When you build a developer tool, the instinct is to build a beautiful dashboard. Charts, usage graphs, settings pages, onboarding flows. It feels like product work.
But for an MCP server, the primary customer isn't a human looking at a dashboard — it's an AI agent making API calls. The dashboard is secondary. It exists so the human operator can manage their API key, check usage, and buy credits. That's it.
Designing for the agent first
We made a deliberate choice: the API comes first, the dashboard comes second. Every design decision starts with "what does the agent need?" not "what looks good in a screenshot?"
This means:
- Clean, predictable tool names — bunnings_search, bunnings_product — not clever abstractions
- Structured responses — JSON with consistent shapes, not markdown or HTML
- Standard protocol — MCP with JSON-RPC 2.0, not a custom REST API
- Minimal auth — Bearer token, no OAuth flows, no consent screens
The dashboard exists to serve the human who pays the bill. But the agent is the one doing the work.
What the dashboard actually does
Our dashboard has four jobs:
1. Show the API key — so the human can copy it into their agent config 2. Show usage — so the human can see what their agent is calling and what it costs 3. Sell credits — so the human can keep the agent running 4. Link to docs — so the human can figure out how to integrate
That's it. No charts for the sake of charts. No settings pages for features nobody uses. Every screen earns its place.
The result
By focusing on the API first, we shipped faster and built something that actually works with real agents. The dashboard took a fraction of the time because it didn't need to be clever — it just needed to be functional.
If you're building developer tools, ask yourself: who's the primary customer? If it's code, design for code first.