MCPcopy
hub / github.com/GetBindu/Bindu

github.com/GetBindu/Bindu @2026.22.4 sqlite

repository ↗ · DeepWiki ↗ · release 2026.22.4 ↗
3,345 symbols 12,507 edges 462 files 2,251 documented · 67%
README

Bindu

Bindu

<a href="https://www.python.org/downloads/"><img alt="Python Version" src="https://img.shields.io/badge/python-3.12+-blue.svg"></a>
<a href="https://pypi.org/project/bindu/"><img alt="PyPI version" src="https://img.shields.io/pypi/v/bindu.svg"></a>
<a href="https://coveralls.io/github/Saptha-me/Bindu?branch=v0.3.18"><img alt="Coverage" src="https://coveralls.io/repos/github/Saptha-me/Bindu/badge.svg?branch=v0.3.18"></a>
<a href="https://github.com/getbindu/Bindu/actions/workflows/release.yml"><img alt="Tests" src="https://github.com/getbindu/Bindu/actions/workflows/release.yml/badge.svg"></a>
<a href="https://discord.gg/3w5zuYUuwt"><img alt="Discord" src="https://img.shields.io/badge/Discord-7289DA?logo=discord&logoColor=white"></a>
<a href="https://github.com/getbindu/Bindu/graphs/contributors"><img alt="Contributors" src="https://img.shields.io/github/contributors/getbindu/Bindu"></a>
<a href="https://hits.sh/github.com/Saptha-me/Bindu.svg"><img alt="Hits" src="https://hits.sh/github.com/Saptha-me/Bindu.svg"></a>
<a href="https://www.star-history.com/getbindu/bindu">









        <img alt="Star History Rank" src="https://api.star-history.com/badge?repo=GetBindu/Bindu" />



</a>

English | Deutsch | Español | Français | हिंदी | বাংলা | 中文 | Nederlands | தமிழ்

The identity, communication, and payments layer for AI agents.

A Gmail-shaped inbox for the agent internet. Watch your agents send signed JSON-RPC to each other, verify identities inline, and reply to a swarm like it's a thread.

Bindu inbox — agents talking to agents, signatures verified inline

→ Open the inbox walkthrough

Here's the situation. You built an agent. It works. But to actually let it loose — talk to other agents, prove who it is, take money for the work — you'd be on the hook for a lot of boring plumbing. A DID library to integrate. An OAuth flow to set up. Payment middleware. An HTTP layer that follows whatever protocol the rest of the agent world is using.

Bindu is all of that plumbing, behind one function call. You wrap your handler with bindufy(), and a few seconds later your agent is online with its own cryptographic identity, speaking A2A (the protocol other agents already use), and ready to demand USDC on any EVM chain before it does any work (x402). Your handler stays as small as (messages) -> response. The framework inside the handler — Agno, LangChain, CrewAI, your own thing — Bindu doesn't care.

There are SDKs for Python, TypeScript, and Kotlin, and they all share the same gRPC core. The language is a choice; the protocol and identity are the same either way. When you're ready to go deeper, the docs are the next stop.

Installation

You'll need Python 3.12+ and uv.

uv add bindu

If you're hacking on Bindu itself rather than using it:

git clone https://github.com/getbindu/Bindu.git
cd Bindu
uv sync --dev

To run the examples you'll need an API key for at least one LLM provider — OPENROUTER_API_KEY, OPENAI_API_KEY, or MINIMAX_API_KEY.

Quickstart

Build the agent you want, hand it to bindufy(), and it's online. The block below is the whole thing — copy it into a file, set your OPENAI_API_KEY, run it.

import os
from bindu.penguin.bindufy import bindufy
from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.tools.duckduckgo import DuckDuckGoTools

agent = Agent(
    instructions="You are a research assistant.",
    model=OpenAIChat(id="gpt-4o"),
    tools=[DuckDuckGoTools()],
)

config = {
    "author": "you@example.com",
    "name": "research_agent",
    "description": "Research assistant with web search.",
    "deployment": {"url": "http://localhost:3773", "expose": True},
    "skills": ["skills/question-answering"],
}

def handler(messages: list[dict[str, str]]):
    return agent.run(input=messages)

bindufy(config, handler)

The agent is now live at http://localhost:3773. expose: True opens an FRP tunnel so the rest of the internet can hit it without you setting up port forwarding.

TypeScript equivalent

import { bindufy } from "@bindu/sdk";
import OpenAI from "openai";

const openai = new OpenAI();

bindufy({
  author: "you@example.com",
  name: "research_agent",
  description: "Research assistant.",
  deployment: { url: "http://localhost:3773", expose: true },
  skills: ["skills/question-answering"],
}, async (messages) => {
  const response = await openai.chat.completions.create({
    model: "gpt-4o",
    messages: messages.map(m => ({ role: m.role as "user" | "assistant" | "system", content: m.content })),
  });
  return response.choices[0].message.content || "";
});

The TypeScript SDK spawns the Python core in the background — you won't see it, and you don't need any Python in your own codebase. Same protocol, same DID. Full example in examples/typescript-openai-agent/.

Calling the agent with curl

curl -X POST http://localhost:3773/ \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "method": "message/send",
    "id": "<uuid>",
    "params": {
      "message": {
        "role": "user",
        "kind": "message",
        "parts": [{"kind": "text", "text": "Hello"}],
        "messageId": "<uuid>",
        "contextId": "<uuid>",
        "taskId": "<uuid>"
      }
    }
  }'

Then poll tasks/get with the same taskId until state hits completed.

Security: three layers, on by default

Most agent frameworks treat security as your problem. Bindu treats it as transport.

When an A2A request lands on a Bindu agent, three different middlewares fire before your handler sees the body — and each one answers a question the other two cannot:

Layer The question it answers What it actually is
mTLS Is the socket itself encrypted and mutually authenticated? X.509 cert from Smallstep step-ca, SAN = DID, 24-hour TTL, auto-renewed in-process
OAuth2 via Hydra Is the caller allowed to perform this operation right now? Ed-style bearer token, ~1-hour TTL, validated via Ory Hydra introspection
DID signature Was this exact JSON body authored by the DID it claims? Ed25519 signature over canonical body, carried in X-DID-Signature

You don't pick one. You don't bolt them on. They ship together — and on the operator's personal agent, they're on by default as of 2026.21.1.

Why three layers, not one? Because each fails safe in a way the others can't:

  • An attacker who steals a bearer token still can't decrypt your traffic — mTLS owns the wire.
  • An attacker who somehow forges a cert still can't impersonate a DID — the signature won't verify against the claimed key.
  • An attacker who breaks the signature scheme entirely still can't get past Hydra's authorization check.

The cert lives at the socket. The bearer token lives in the header. The signature lives in the body. Each one rejects a class of attack the others are blind to. No agent framework we surveyed ships all three out of the box.

The full story: docs/SECURITY_STACK.md walks through what each layer does, how a single request flows through all three, today's defaults, the five real bugs we hit shipping default-on mTLS, and a troubleshooting matrix.

Features

Every row here links out to the guide that actually goes into it.

Feature What it does Docs
A2A JSON-RPC The protocol other agents already speak. message/send, tasks/get, message/stream on port 3773.
mTLS transport The socket is encrypted and mutually authenticated. Each agent gets a real X.509 cert from step-ca (SAN = DID), serves uvicorn over TLS, and renews itself every ~16 hours. On by default for the inbox personal agent in 2026.21.1. SECURITY_STACK.md · MTLS_DEPLOYMENT_GUIDE.md
DID identity Every response your agent sends is signed with an Ed25519 key. Callers verify with a W3C DID — there's no shared secret to leak, no central authority to query, and the same DID is the cert's SAN, the OAuth2 client_id, and the message signer. All three have to agree, or the request is rejected. DID.md
OAuth2 via Hydra Scoped bearer tokens (agent:read, agent:write, agent:execute) instead of one key that opens every door. Each agent self-registers as a Hydra client at boot — its DID IS its client_id, so authorization, identity, and transport-layer cert all point at the same actor. AUTHENTICATION.md
x402 payments Flip a flag and the agent demands USDC before your handler ever sees the request. 5 chains pre-configured — Base, Base Sepolia, Ethereum, Ethereum Sepolia, SKALE Europa — and any other EVM chain (Polygon, Avalanche, Arbitrum, …) takes one extra_networks entry. PAYMENT.md
Push notifications The agent webhooks you when a task changes state. Stop polling. NOTIFICATIONS.md
Skills system Declare what your agent can do; callers see it on the agent card before they spend a token asking. SKILLS.md
Private skills Keep your commercial skill descriptions out of the public catalog. Public crawlers see a generic "we do X" — allowlisted partner DIDs see your real menu at a second auth-gated endpoint. Useful when your skill descriptions ARE your product roadmap. PRIVATE_SKILLS.md
Agent negotiation Two agents agree on price, latency, and SLA up front. No surprise bills. NEGOTIATION.md
Storage Postgres for tasks and messages. Swap the backend if you've got a preference. STORAGE.md
Scheduler Redis-backed retries, timeouts, and recurring tasks. SCHEDULER.md
Public tunnel expose: true puts your laptop on the internet. No port forwarding, no router config. TUNNELING.md
Polyglot SDKs Python, TypeScript, Kotlin — same gRPC core underneath, same DID, same auth. GRPC_LANGUAGE_AGNOSTIC.md
Cloud deploy bindu deploy agent.py --runtime=boxd ships your script to a microVM and prints the HTTPS URL. No Dockerfile. runtime/quickstart.md
Gateway A planner LLM that orchestrates a fleet of agents over A2A and streams the result back. GATEWAY.md
Observability OpenTelemetry traces, Sentry errors, a health endpoint. The boring stuff that saves you at 2am. OBSERVABILITY.md

Demo

Bindu demo video

The operator inbox at the top of this page is in inbox/ — same auth, same DID signing, just visible. Run it with cd inbox && npm run dev.

Examples

A handful from examples/:

Example What it shows
Agent Swarm A small society of Agno agents passing work to each other.
Premium Advisor x402 in practice — the caller has to pay USDC before anything runs.
Hermes via Bindu Nous Research's Hermes agent, bindufied in ~90 lines.
Gateway Test Fleet Five agents and one gateway — the multi-agent story end to end.
TypeScript OpenAI Agent A TS-only agent with zero Python in your repo.

There are 20+ more covering CSV analysis, PDF Q&A, speech-to-text, web scraping, multi-lingual collaboration, blog writing, and so on. Browse them in examples/.

Why we built Bindu

We're using Bindu in production to build the Trade Compliance OS — a swarm of agents that handles CBAM, EUDR, HS codes, and Digital Product Passports, so an SMB can ship coffee, textiles, or steel across borders without writing a six-figure check to a law firm. Every agent in that swarm is bindufied. The protocol, the identity, the payment rails — that's all the stuff we needed Bindu to solve in the first place.

If you've built an agent that touches any of this — customs paperwork, supplier audits, materials sourcing, regulatory filings, anything in the neighborhood — we'd love to have it in the network. [Com

Extension points exported contracts — how you extend this code

Metadata (Interface)
* Tool abstraction for the gateway planner. * * Pattern borrowed from OpenCode's `tool/tool.ts` but simpler — no auto
gateway/src/tool/tool.ts
ErrorShape (Interface)
Tiny POST-JSON helper used by every form/action site in the UI. * * Why: four components (compose modal, add-agent mod
inbox/src/lib/fetch.ts
SpawnedGateway (Interface)
* Spawn a gateway from the local monorepo as a child process. * * Used when the operator picks 2+ agents in Compose an
inbox/server/index.ts
ChatMessage (Interface)
(no doc)
sdks/typescript/src/types.ts
MockAgentConfig (Interface)
(no doc)
gateway/tests/helpers/mock-bindu-agent.ts
SessionContext (Interface)
(no doc)
gateway/src/planner/index.ts
ImportMetaEnv (Interface)
(no doc)
inbox/src/vite-env.d.ts
MaskedSettings (Interface)
(no doc)
inbox/server/index.ts

Core symbols most depended-on inside this repo

get
called by 500
bindu/grpc/registry.py
debug
called by 140
bindu/settings.py
get
called by 98
bindu/utils/http/client.py
get_logger
called by 81
bindu/utils/logging.py
Field
called by 48
inbox/src/components/AgentInfoModal.tsx
post
called by 45
bindu/utils/http/client.py
load_config_from_env
called by 43
bindu/utils/config/enricher.py
bindufy
called by 40
bindu/penguin/bindufy.py

Shape

Method 1,688
Function 1,041
Class 435
Interface 123
Route 58

Languages

Python81%
TypeScript19%

Modules by API surface

tests/unit/server/storage/test_memory_storage.py67 symbols
tests/unit/utils/config/test_enricher.py51 symbols
tests/unit/utils/skills/test_loader.py49 symbols
tests/unit/runtime/test_boxd_provider.py49 symbols
bindu/common/protocol/types.py49 symbols
bindu/server/storage/postgres_storage.py44 symbols
tests/unit/extensions/mtls/test_mtls_agent_extension.py38 symbols
tests/unit/auth/test_hydra_client.py37 symbols
inbox/server/index.ts37 symbols
tests/unit/server/workers/test_manifest_worker.py35 symbols
tests/unit/utils/config/test_env_loader.py34 symbols
tests/unit/server/notifications/test_push_manager.py34 symbols

Dependencies from manifests, versioned

@ai-sdk/openai3.0.53 · 1×
@bindu/sdkfile:../../sdks/type · 1×
@effect/platform-node4.0.0-beta.48 · 1×
@grpc/grpc-js1.10.0 · 1×
@grpc/proto-loader0.7.0 · 1×
@hono/node-server1.19.11 · 1×
@langchain/openai1.0.0 · 1×
@noble/ed255192.1.0 · 1×
@noble/hashes2.2.0 · 1×
@phosphor-icons/react2.1.10 · 1×
@pipedream/sdk3.0.2 · 1×
@tailwindcss/vite4.0.0 · 1×

Datastores touched

dbDatabase · 1 repos
(mongodb)Database · 1 repos
binduDatabase · 1 repos

For agents

$ claude mcp add Bindu \
  -- python -m otcore.mcp_server <graph>

⬇ download graph artifact