A read-only MCP server that lets AI assistants query Kenda token spend and waste data directly from the terminal. It never captures or writes usage data.
kenda_spend_summary — Retrieve top-line spend, waste, and health metrics for your entire org (e.g. "how much did I spend this week?")
kenda_waste_by_agent — Get a per-agent breakdown of spend and redundant (wasted) dollars to identify which agents are wasting the most
It uses the Kenda API token from ~/.kenda/config.json and integrates with hosts like Claude Code, Cursor, Windsurf, VS Code, Codex CLI, and Gemini CLI.
Provides tools for querying Kenda token spend and waste data, enabling Windsurf (by Codeium) to answer questions about organizational token usage.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kenda-ingestion-mcp how much did I spend this week?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A small, read-only Model Context Protocol server that lets an AI host (e.g. Claude Code) answer questions about your Kenda token spend and waste straight from the terminal — "how much did I spend this week?", "which agent is wasting the most?".
It is a query surface only: it never captures or writes usage. It reads the token-authed
/collector/* endpoints of the Kenda API using the endpoint + token from ~/.kenda/config.json
(the same ingest token the Kenda collector writes), which resolve the token to its org
server-side — so the terminal needs no browser/Auth0 session.
Tool | Endpoint | Returns |
|
| Top-line spend, waste, and health for your org |
|
| Per-agent spend and redundant (wasted) dollars |
Related MCP server: agentburn
uv tool install ingestion-mcp # or: pipx install ingestion-mcpThe console script kenda-mcp runs the stdio server. uvx ingestion-mcp runs it without
installing anything.
uv and pipx are recommended over a bare pip install because this ships a command-line
entry point, and pip refuses to install into a Homebrew or distro-managed interpreter at all
(error: externally-managed-environment, PEP 668). If you only have pip, use
pip install --user ingestion-mcp. Both uv and pipx install into ~/.local/bin, which is
not on PATH by default on macOS — if kenda-mcp is not found afterwards, that is why.
The server reads ~/.kenda/config.json:
{
"endpoint": "https://api.kenda.app",
"token": "kenda_your-ingest-token"
}Only endpoint and token are required for queries. Both are written for you by
kenda-collect init (the Kenda collector) or the Claude Code plugin's /kenda-setup. Environment
variables override the file (KENDA_ENDPOINT, KENDA_TOKEN) for CI and power users.
The server is plain stdio MCP: every host below runs the same one-line command, kenda-mcp —
only the config file differs. After registering, ask your assistant: "what did I spend this
week?" or "which agent is wasting the most?".
.mcp.json in the project (or claude mcp add kenda -- kenda-mcp):
{
"mcpServers": {
"kenda": { "command": "kenda-mcp" }
}
}~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project):
{
"mcpServers": {
"kenda": { "command": "kenda-mcp" }
}
}~/.codeium/windsurf/mcp_config.json (docs):
{
"mcpServers": {
"kenda": { "command": "kenda-mcp" }
}
}.vscode/mcp.json for one workspace — or run MCP: Open User Configuration from the
command palette to register it for all workspaces. Note the key is servers here, not
mcpServers:
{
"servers": {
"kenda": { "type": "stdio", "command": "kenda-mcp" }
}
}~/.codex/config.toml (or codex mcp add kenda -- kenda-mcp):
[mcp_servers.kenda]
command = "kenda-mcp"~/.gemini/settings.json (or .gemini/settings.json in a project):
{
"mcpServers": {
"kenda": { "command": "kenda-mcp" }
}
}If your host reports the server as failed, run the built-in self-test — it works even when
the mcp package is broken, and tells you whether the problem is your config, the network,
or the host:
kenda-mcp --checkIt prints the version, the config it resolved (token masked), and the result of one live API call; exit code 0 means the server side is healthy, so the problem is host config.
python -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"
ruff check .
pytestThe HTTP query layer is pure stdlib and unit-tested (tests/test_query.py); the MCP transport is
driven end-to-end with an in-memory client (tests/test_server.py), including a schema-regression
test that pins host-safe tool shapes; the --check doctor mode is covered by tests/test_check.py.
The mcp package is a runtime dependency, so all suites run in CI.
MIT — see LICENSE.
Top-line Kenda spend, waste, and health for your org.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description adds minimal new behavioral info. The term 'Top-line' suggests aggregated data, but no further details on data freshness, scope, or limits are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the key information without any extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description adequately explains the high-level output. It could mention that it covers the entire org, but the current text is sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description does not need to add parameter details, and the empty schema indicates no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns top-line Kenda spend, waste, and health for the user's organization. It distinguishes itself from the sibling tool 'kenda_waste_by_agent' which focuses on waste by agent, indicating a broader aggregate view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for high-level overview, but does not explicitly state when to use this tool versus alternatives like kenda_waste_by_agent. No usage conditions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-agent spend and redundant (wasted) dollars.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the tool is per-agent and focuses on wasted dollars, which provides some behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, perfectly concise, front-loaded with key information. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description is minimal but sufficient. It could benefit from clarifying what 'redundant dollars' means, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns per-agent spend and redundant (wasted) dollars, distinguishing it from the sibling tool kenda_spend_summary which likely provides overall spend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the sibling kenda_spend_summary. The description implies it is for per-agent waste analysis, but lacks direct comparison or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1kenda_spend_summary1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "kenda_spend_summaryDictOutput",
+ "type": "object"
+}kenda_waste_by_agent1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "kenda_waste_by_agentDictOutput",
+ "type": "object"
+}v0.1.0kenda_spend_summarykenda_waste_by_agentThe two tools have clearly distinct purposes: one provides an org-wide summary of spend/waste/health, the other breaks down waste per agent. No overlap or ambiguity.
Both tool names use the 'kenda_' prefix and are descriptive (spend_summary, waste_by_agent). While not a strict verb_noun pattern, the naming is consistent in style and clearly conveys the tool's function.
With only 2 tools, the server is minimal but appropriately scoped for a focused domain of Kenda spend/waste. The count is slightly low but reasonable for a targeted set.
The server covers top-level summary and per-agent waste, but lacks other potentially useful operations like time trends, department breakdowns, or cost allocation. Notable gaps exist for a more complete spend analysis surface.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Run AI customer support from your terminal: conversations, knowledge base, and chat widget.
Provide AI agents and automation tools with contextual access to blockchain data including balance…
AI brand/token visibility, prediction-market odds & cheap x402 data feeds for AI agents.
OpenAI-compatible LLM MCP (7 tools); chat via balance key or x402 USDC on Base
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kenda-co/ingestion-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
