Agents should not have to trust anyone they've never interacted with.
lowdown-proxy records interactions between AI agents, tools, and services — and makes
that history queryable by anyone. Before choosing a tool, calling an API, or delegating
to another agent, you can ask: what has the network seen from this one?
A transparent stdio proxy for MCP servers is the first entry point. The interaction history layer is open to any agent, tool, or service — not just MCP.
See DESIGN.md for background and design principles.
npx lowdown-proxy -- npx some-mcp-serverThat's it. No signup, no configuration. On first run, a node identity is created automatically at ~/.lowdown/node.json. Your interactions are contributed to the network — and you get deeper data back in return.
Wrap any MCP server in your client config:
// before
{
"mcpServers": {
"search": { "command": "npx", "args": ["search-mcp-server"] }
}
}
// after
{
"mcpServers": {
"search": {
"command": "npx",
"args": ["lowdown-proxy", "--target", "search-mcp-server", "--", "npx", "search-mcp-server"]
}
}
}Related MCP server: SuperBased Observer
Flag | Description | Default |
| Identifier of the calling agent |
|
| Label for the target tool | command string |
|
|
|
Required for recording. The proxy works as a pure pass-through without them.
export LOWDOWN_SUPABASE_URL="https://xxxx.supabase.co"
export LOWDOWN_SUPABASE_KEY="..."No auth required.
# Get reputation of a tool
curl https://lowdown-proxy.vercel.app/api/reputation/brave-search
# With node identity — returns richer data
curl https://lowdown-proxy.vercel.app/api/reputation/brave-search \
-H "x-lowdown-node-id: ld_your_node_id"
# Check your node's contribution
curl https://lowdown-proxy.vercel.app/api/node/ld_your_node_id
# Record an interaction
curl -X POST https://lowdown-proxy.vercel.app/api/interactions \
-H "Content-Type: application/json" \
-d '{"actor":"agent:my-bot","target":"mcp:modelcontextprotocol/brave-search","target_type":"tool","task_type":"web_search","outcome":"success"}'Basic response (no node):
{
"target": "brave-search",
"interactions": 30,
"success_rate": 0.933,
"confidence": "medium"
}Contributor response (with node):
{
"target": "brave-search",
"interactions": 30,
"success_rate": 0.933,
"confidence": "medium",
"task_breakdown": { ... },
"recent_trends": [ ... ]
}Fuzzy matching supported — short names like brave-search, fetch, github resolve automatically.
Run proxy → node_id auto-created → interactions contributed → deeper Lowdown dataEvery proxy instance is a node.
Nodes contribute interaction data to the shared network. Contributors get access to richer query results.
No tokens. No points. No reviews to write.
Just run the proxy and share what your agents experience.
Zero config: run the proxy, everything else is automatic.
Pass-through first: recording never blocks or degrades MCP communication.
Facts only: v0 records success/failure and latency. Quality judgments are out of scope.
Provenance always tagged: every record carries organic / seeded / synthetic so bootstrap data and real traffic are always distinguishable.
30-day public experiment, started September 2026. See DESIGN.md for what's in scope and what's been ruled out.
MIT
한 번도 거래한 적 없는 상대를 에이전트가 무조건 신뢰할 필요는 없습니다.
lowdown-proxy는 AI 에이전트, 도구, 서비스 사이의 상호작용을 기록하고,
그 이력을 누구나 조회할 수 있게 만듭니다. 도구를 선택하거나, API를 호출하거나,
다른 에이전트에게 작업을 위임하기 전에 물어볼 수 있습니다:
네트워크는 이 상대에 대해 무엇을 봤는가?
MCP 서버를 감싸는 stdio 프록시가 첫 번째 진입점입니다. 평판 레이어는 MCP에 국한되지 않고 모든 에이전트, 도구, 서비스에 열려 있습니다.
기록된 데이터는 다른 에이전트가 판단할 때 참고할 수 있는 최소한의 공통 근거가 됩니다.
프록시 실행 → node_id 자동 생성 → interaction 기여 → 더 깊은 Lowdown 조회프록시를 실행하는 것 자체가 노드 참여입니다. 기여할수록 더 상세한 데이터를 조회할 수 있습니다.
설정 없음: 프록시를 실행하면 모든 것이 자동으로 처리됩니다.
패스스루 우선: 기록 로직이 실패하거나 느려도 실제 MCP 통신은 절대 막지 않습니다.
사실만 기록: v0는 성공/실패/지연시간만 기록합니다. 품질 판단은 범위 밖입니다.
출처 구분: 모든 기록은 organic / seeded / synthetic으로 태깅됩니다.
자세한 배경과 설계 원칙은 DESIGN.md를 참고하세요.
Compare multiple tools or agents by their recorded interaction data. Returns a ranked list with success rates and confidence levels.
| Name | Required | Description | Default |
|---|---|---|---|
| task_type | No | Filter by task type if you want task-specific comparison | |
| candidates | Yes | List of tool/agent identifiers to compare |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, but it only discloses the return contents (ranked list, success rates, confidence levels) and is silent on safety profile, permissions, or candidate-count limits. The return-format disclosure is genuinely useful since there is no output schema.
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?
Two tightly written sentences with zero filler; the purpose is front-loaded and the return behavior follows immediately.
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?
With no output schema, the description usefully covers what is returned, and the input schema is fully documented. It stops short of noting the read-only nature of the comparison or any data prerequisites, which would round out an otherwise adequate definition.
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?
Schema description coverage is 100%, so both parameters are already documented in the schema, including the task_type filter intent and the candidate list constraints. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb (compare) and resource (tools/agents) plus the data source (recorded interaction data) and the return shape. This is clearly distinguishable from siblings like record_interaction and get_node_stats without opening any schema.
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 never says when to use this tool versus alternatives such as get_node_stats, nor does it state prerequisites (e.g., that interaction data must already be recorded). Usage is only implied by the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the interaction history and reputation of an agent, tool, or service. Call this before choosing between providers to make an informed decision.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Identifier of the agent/tool/service. e.g. 'mcp:vendor/tool-name' or 'agent:some-agent-id' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden and largely fails to. It implies a read via "Get" but never confirms read-only semantics, permission requirements, latency, or what shape the reputation data takes, which matters because no output schema is provided either.
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?
Two short sentences with zero filler, front-loading what is retrieved before the when-to-use guidance. Every clause earns its place.
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?
Purpose, target source, and usage timing are covered for a simple one-parameter read tool, but with no output schema and no annotations the description should say more about what 'reputation' and 'interaction history' actually return so an agent can interpret and trust the result.
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?
Schema description coverage is 100%, and the single target parameter already documents the identifier format with examples ('mcp:vendor/tool-name', 'agent:some-agent-id'). The description adds nothing beyond what the schema provides, so the baseline 3 applies.
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?
States a specific verb (Get) and resource (interaction history and reputation) scoped to agents, tools, or services. It is clearly distinguishable from the write-oriented record_interaction and comparison-oriented compare_tools siblings, though it never names them explicitly.
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?
"Call this before choosing between providers to make an informed decision" gives explicit timing and intent for use. It stops short of naming an alternative (e.g., compare_tools) or stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your node's contribution stats and network position. Shows how much your proxy has contributed to the Lowdown network.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but for a zero-parameter read it only needs to signal that this is a passive lookup, which 'Get' and 'Shows' do. It does not state whether a node identity/auth is required or whether the stats are scoped to the caller's own proxy, which is the main behavioral ambiguity.
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 core purpose is front-loaded in the first sentence, but the second sentence largely restates it, only adding the 'proxy' and 'Lowdown network' specifics. One of the two sentences is close to redundant.
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?
There is no output schema, so the description should characterize the return values; 'contribution stats and network position' gives a rough shape but no notion of pagination, units, or whether the result is empty for unregistered nodes. For a simple zero-param read this is adequate but not complete.
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?
The tool takes no parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies the node is identified implicitly by the caller rather than by an argument.
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 states a specific verb and resource: 'Get your node's contribution stats and network position,' which is concrete and distinguishable from siblings like record_interaction or compare_tools. It stops short of explicitly contrasting itself with get_lowdown, which is the nearest conceptual sibling.
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?
There is no guidance on when to call this versus get_lowdown or the other siblings, and no prerequisites are stated. The agent must infer from the name that this is the per-node read counterpart to a network-level lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an interaction with an agent, tool, or service after using it. Helps build the shared reputation dataset for the community.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | Yes | Your agent/system identifier | |
| source | No | ||
| target | Yes | Identifier of what you used | |
| outcome | Yes | ||
| task_type | Yes | What kind of task was performed. e.g. 'web_search', 'code_gen' | |
| latency_ms | No | How long it took in milliseconds | |
| target_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It usefully reveals that submitted data feeds a shared, persistent 'reputation dataset for the community' – which implies public visibility of the write. However, it says nothing about required permissions, whether records are immutable, deduplication, or rate limits.
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?
Two short sentences, zero filler, purpose front-loaded in the first clause. Nothing to trim.
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?
This is a 7-parameter mutation tool with no annotations and no output schema, so the description must carry more weight. It omits what happens after submission, whether the call can fail on validation, and what the response contains – important for an agent deciding whether to invoke it.
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?
7 parameters with only 57% schema description coverage, and the description adds no parameter-level meaning at all. Enum-constrained fields (source, outcome, target_type) are self-documenting in the schema, but 'source' in particular has no description anywhere and the description does nothing to compensate for the undocumented fields.
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 states a specific verb and resource ('Record an interaction with an agent, tool, or service'), which is unambiguous. It does not differentiate from the sibling tools (get_lowdown, compare_tools, get_node_stats), but those serve clearly different functions, so confusion risk is low.
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?
'after using it' gives implied timing guidance – call this once you have finished consuming a target. There is no explicit statement of when not to use it, no mention of prerequisites, and no comparison to alternatives.
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.
v0.1.11compare_toolsget_lowdownget_node_statsrecord_interactionScored across 4 tools
Each tool has a mostly distinct purpose: single-entity lookup, interaction recording, multi-entity comparison, and node stats. get_lowdown and compare_tools both surface reputation data, but one targets a specific entity while the other ranks multiple entities, so confusion is limited.
All tools use consistent snake_case with a verb-first pattern: get_lowdown, record_interaction, compare_tools, and get_node_stats. The convention is predictable and readable throughout.
Four tools is well-scoped for a reputation proxy focused on checking, recording, comparing, and node-level statistics. Each tool earns its place without redundancy.
The core lifecycle is covered: check reputation before use, record after use, compare providers, and inspect node contribution. Minor gaps exist around listing/discovering entities or managing recorded data, but the primary workflows are supported.
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Cross-tool persistent memory and context for AI assistants over MCP.
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
