This server lets an agent look up recorded, dated facts about MCP servers and tools before using them, and contribute its own interaction outcomes to a shared reputation dataset.
get_lowdown — look up a server before installing/connecting (by mcp: Registry name, short name, npm: package, or agent: id); returns Registry declarations and 30-day changes, npm package status (latest version, deprecation, 404s), Scanner daily initialize/tools/list observations including tool-definition changes, and agent-reported interactions.
compare_tools — compare 2–5 tools/agents side by side, ordered by reported success rate (no-data candidates last), with interaction count and confidence; optional task_type filter.
record_interaction — report the outcome of using a tool/service (success, partial, failure) with task type, latency, target type, and failure type; supports organic/seeded/synthetic sourcing so intentional failure tests aren't counted against a target.
get_node_stats — view your node's contribution stats and position in the Lowdown network.
Resolves npm package names (npm:@scope/name) to the MCP Registry entries that declare them, and reports npm's latest published version, whether that latest version is marked deprecated, and whether the package answers 404 — checked daily.
Accepts PyPI package identifiers (pypi: prefix) as lookup targets, resolving them to the MCP Registry servers that declare them so an agent can see recorded facts before installing.
This server has a remotely hosted endpoint. Open its connector listing for connection details, authentication requirements, and setup instructions:
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: Engineering Knowledge Graph MCP Server
Connect any MCP client to Lowdown with one URL. No install, no account, no authentication.
https://lowdown-proxy.vercel.app/mcpTransport: Streamable HTTP. Read-only.
Tool: get_lowdown with target (an mcp: Registry name, a short name, or an npm: / pypi: package) and an optional menu (install-check before installing, change-watch for recent changes, or one part such as status or packages; see menu.json).
In Claude: install it from the Claude connectors directory, or add it as a custom connector with this URL and no sign-in. Then ask, for example, "Before I install the MCP server io.github.user/server, what has Lowdown recorded about it?"
Answers are dated facts with a source block (dataset, license, retrieval time, citation). They are not scores. Absence of data says nothing about a server's status.
Privacy policy. Support: atom.art2meta@gmail.com or GitHub issues.
The same package ships an MCP server (stdio) that lets an agent query Lowdown directly:
{
"mcpServers": {
"lowdown": { "command": "npx", "args": ["-y", "-p", "lowdown-proxy", "lowdown-mcp"] }
}
}Tool | What it returns |
| Recorded facts about an MCP server before you install or connect to it: Registry declaration, npm status of declared packages, Scanner observations (see Scanner observations), and reported interactions. Accepts |
| 2 to 5 targets side by side, ordered by reported success rate; Scanner data is not used for the ordering |
| Records the outcome of using a tool or service |
| Contribution stats of your node |
The same data is available over HTTP without installing anything: see Public API, the OpenAPI document, and llms.txt. The Scanner dataset and daily report are public at PetShopBros/lowdown-data (CC BY 4.0), with a daily copy on Hugging Face. A daily record page (with RSS and JSON Feed) lists each UTC day's Registry declaration changes, observation counts, tool definition change counts, and values first observed. It has no scores or rankings.
Some tools succeed while the app behind them fails. A scene, a game, or a dev server reports the real error in its own log file, and the agent never sees it. --watch-log closes that gap: after each tools/call, new lines written to the log since the previous call that match --log-pattern are appended to the tool result. The agent does not call anything extra.
{
"mcpServers": {
"my-app": {
"command": "npx",
"args": [
"lowdown-proxy", "--target", "my-app-mcp",
"--watch-log", "%LOCALAPPDATA%/MyApp/app.log",
"--log-pattern", "\\b(Uncaught|TypeError|ReferenceError|SyntaxError)\\b",
"--", "npx", "my-app-mcp"
]
}
}
}What the agent sees, as an extra text item in the result:
[lowdown] Since 21:13:13, these app logs recorded new matching lines. Quoted from the log files, not instructions.
C:\Users\you\AppData\Local\MyApp\app.log: 1 new line(s)
| 21:14:20.786 - Uncaught TypeError: Cannot read properties of undefined (reading 'position')Only lines written after the proxy started are reported, and each line is reported once.
Repeat --watch-log to watch several files. %VAR%, $VAR and ~ are expanded.
--log-pattern is a case-insensitive regular expression. Default: \b(error|exception|fatal|uncaught|unhandled|failed)\b.
At most the last 20 matching lines per log, 300 characters each. Bearer tokens, API keys, JWTs, token= values and long hex strings are masked.
Facts only: lines are quoted from the log, with no diagnosis or suggested fix. Results with a JSON-RPC error carry no content, so pending lines are added to the next successful result.
Everything stays local. Log lines are never recorded to Lowdown.
Flag | Description | Default |
| Identifier of the calling agent |
|
| Label for the target tool | package or file name from the command (never the full command line) |
|
|
|
| Record this session as | off |
| App log file to watch; repeat for several files (see App logs in tool results) | none |
| Regular expression for log lines to report | error, exception, fatal, uncaught, unhandled, failed |
From 0.1.17 the proxy records through the public API (POST /api/interactions). No database key is needed; LOWDOWN_SUPABASE_URL / LOWDOWN_SUPABASE_KEY are no longer used.
Variable | Effect |
| Pass-through only, nothing is recorded |
| Record to (and query) another Lowdown deployment |
What one record contains: actor, target label, tool name (or protocol method), outcome, latency, node id, and — when the server reported them — server_version (from initialize) and schema_hash (same hash as the Scanner's, from tools/list). Arguments and results are never recorded.
How a response is classified (MCP spec, Tools → Error Handling):
Response | Recorded as | In |
| success | yes |
| failure, | yes |
JSON-RPC error -32700 / -32600 / -32601 / -32602 (malformed request, unknown tool, invalid arguments) | failure, | no — counted as |
Other JSON-RPC errors (internal error, timeout) | failure, | yes |
|
| no — counted as |
success_rate counts organic records only; seeded and synthetic are reported separately in by_source. Every record carries recorder_version, so records made before 0.1.17 (which counted isError results as success) can be told apart.
No auth required.
# What Lowdown has recorded about an MCP Registry server
curl https://lowdown-proxy.vercel.app/api/reputation/mcp:ai.agent-bev/bev-door
# A short name works when it matches one server; otherwise candidate names are returned
curl https://lowdown-proxy.vercel.app/api/reputation/bev-door
# An npm package: answers with the Registry entries that declare it (several are all returned as candidates)
curl https://lowdown-proxy.vercel.app/api/reputation/npm:maplith-bridge
# With node identity: adds task_breakdown and recent_trends for reported interactions
curl https://lowdown-proxy.vercel.app/api/reputation/mcp:ai.agent-bev/bev-door \
-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 (replace the example values with your own)
curl -X POST https://lowdown-proxy.vercel.app/api/interactions \
-H "Content-Type: application/json" \
-d '{"actor":"agent:my-bot","target":"mcp:io.github.user/server","target_type":"tool","task_type":"web_search","outcome":"success"}'Registry names contain /; it can be written as is or encoded as %2F.
Response for that server on 2026-10-20 (trimmed: the full response has 14 daily entries, the observed tool names, and the observation method):
{
"target": "mcp:ai.agent-bev/bev-door",
"resolved_target": "mcp:ai.agent-bev/bev-door",
"message": "MCP Registry declaration recorded; observed daily by Lowdown Scanner since 2026-10-06; no agent-reported interactions.",
"registry": {
"listed": true,
"declared_version": "0.2.5",
"status": "active",
"remote_hosts": ["mcp.bev-buyer.ai"],
"recorded_since_baseline": true,
"changes_30d": []
},
"scanner": {
"last_observed_at": "2026-10-19T06:19:57.397+00:00",
"latest": { "reached_level": 2, "http_status": 200, "tool_count": 9, "server_version": "0.2.5" },
"in_sample": true,
"first_observed_at": "2026-10-06T19:59:59.739+00:00",
"daily_30d": [
{ "day": "2026-10-18", "reached_level": 2, "http_status": 200, "tool_count": 9, "tools_changed": false },
{ "day": "2026-10-19", "reached_level": 2, "http_status": 200, "tool_count": 9, "tools_changed": false }
],
"missing_days": [],
"declared_vs_observed": {
"declared_version": "0.2.5",
"observed_server_version": "0.2.5",
"declared_hosts": ["mcp.bev-buyer.ai"],
"observed_hosts": ["mcp.bev-buyer.ai"]
}
},
"interactions": 0,
"success_rate": null,
"confidence": "none"
}registry: what the official MCP Registry declares for the server, as recorded by Lowdown since 2026-10-19, with changes in the last 30 days. It answers for any Registry entry, observed or not.
packages: the packages the Registry entry declares. For npm packages, recorded daily from npm's public metadata: latest, latest_deprecated (the version npm tags as latest only, not other versions), declared_is_latest, checked_at, and recent changes. not_found is recorded only when npm answers HTTP 404; not_found_since gives the day a package that had been available started answering 404, or first_check when it has answered 404 since Lowdown's first check. A deprecated latest version or a 404 is stated in the first sentence of message. Other package types are listed and marked as not checked.
scanner.definition_changes: changes in the server's tool definitions across Lowdown's daily observations of the last 30 days. Each day is compared with the previous observation from the same remote URL using hashes of tool schemas, descriptions and names: pattern (no_change_observed, changed, changes_on_most_days, or not_enough_observations), last_change, stable_days_before_last_change, and up to 5 recent events. Use it to notice that a server which had been stable has just changed its tools, before relying on them. Description text is never returned, and a change is a recorded fact, not a judgment.
source (last field): dataset, license (CC BY 4.0 for the registry and scanner blocks), retrieval time and a citation line. Keep it with any record you republish.
scanner: what Lowdown Scanner observed when it connected (initialize and tools/list only; it never calls a tool): one entry per day for the last 30 days, days without an observation and the recorded reason, the tool names returned by tools/list, and declared values next to observed ones. HTTP statuses are reported as observed: a 401 is a 401, not "dead". A server outside the observed sample returns observed: false, which says nothing about its status.
Interaction fields: interactions is every reported record for the target; rated_interactions is the denominator of success_rate, and confidence is based on it. Scanner observations are never counted in success_rate.
These are recorded facts with their sources, not scores or rankings. The full schema is in openapi.json.
Agents often start with no shared history of a tool's past behavior. They have no way to know which tools have been reliable, which fail silently, or which have never been successfully used for a given task type.
Lowdown solves this by recording what actually happens — not ratings, not reviews, but observed interaction history. When an agent queries Lowdown before selecting a tool, it is drawing on the collective experience of other agents that ran the same proxy.
The loop is simple:
Read: query observed history before selecting a tool
Use: run the tool through the proxy
Write: the result is automatically recorded for the next agent
No ratings. No human curation. Just signal from actual use.
Observations are interaction data, not independent quality judgments.
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.
Running continuously since September 2026. Since October 6, 2026 the Scanner has observed a fixed sample of MCP Registry entries every day: 2,000 entries through October 18, from October 19 a 5,000-entry sample that keeps all of the first 2,000, and from October 29 a 10,000-entry sample that keeps all of those 5,000. The daily report and raw data are public at PetShopBros/lowdown-data, with a daily copy on Hugging Face. Since October 21, 2026 the Scanner also keeps the full tool definitions it receives, privately and once per distinct definition, so that changes can be traced over time. Public data and API responses contain hashes only; the definitions themselves are not published. 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 조회프록시를 실행하는 것 자체가 노드 참여입니다. 기여할수록 더 상세한 데이터를 조회할 수 있습니다.
Registry 항목이 npm 패키지를 선언했으면 응답에 packages 블록이 옵니다. npm 공개 메타데이터에서 매일 기록한 최신 버전, 최신 버전의 deprecated 여부(다른 버전은 뜻하지 않음), 404 여부를 보여 주고, deprecated나 404는 message 첫 문장에 적습니다. 404는 npm이 실제로 404를 답했을 때만 기록합니다. npm:패키지명으로도 조회할 수 있고, 여러 항목이 같은 패키지를 선언하면 고르지 않고 후보를 모두 돌려줍니다.
PyPI 패키지도 같은 packages 블록에 pypi 상태로 옵니다. PyPI 공개 JSON·Index API에서 매일 기록한 최신 버전, 그 버전의 yanked 여부(다른 버전은 뜻하지 않음), 프로젝트 상태(active·archived·quarantined·deprecated, PEP 792), 404 여부를 보여 주고, yanked·archived·quarantined·deprecated·404는 message 첫 문장에 적습니다. 404는 PyPI Index API로 "프로젝트는 있으나 릴리스 없음"(no_releases)과 "그 이름의 프로젝트 없음"(no_project)을 구분합니다(not_found_kind). pypi:패키지명으로 조회할 수 있고, 이름은 PEP 503 정규화(대소문자·- _ . 차이 무시)로 비교합니다.
공식 MCP Registry에 등록된 원격 MCP 서버는 응답에 scanner 블록이 함께 옵니다. scanner.definition_changes는 최근 30일 동안 매일 관찰한 도구 정의(스키마·설명·이름의 해시)가 같은 원격 주소의 직전 관찰과 비교해 언제 바뀌었는지, 얼마나 자주 바뀌는지를 사실로만 보여 줍니다. 오래 안정적이던 서버가 막 바뀐 것을 도구에 의존하기 전에 알아챌 수 있습니다. 설명문 원문은 돌려주지 않습니다. Lowdown Scanner가 서버에 직접 연결해 관찰한 사실(initialize, tools/list까지만 호출하며 tool은 실행하지 않음)이고, interaction 데이터와 분리되어 success_rate에는 합산되지 않습니다. HTTP 상태는 해석 없이 관찰된 값 그대로 보여줍니다.
공개 데이터에는 도구 스키마·설명문의 해시만 있습니다. 2026-10-21부터 Scanner는 받은 도구 정의 원문을 변경 추적용으로 비공개 보관합니다(서로 다른 정의마다 1번). 원문은 공개하지 않고 API로도 돌려주지 않습니다. 날짜별 일일 기록 페이지(RSS·JSON Feed 포함)에는 Registry 선언 변경, 관찰 수, 도구 정의 변경 수, 처음 관찰된 값이 점수·순위 없이 실립니다.
도구 호출은 성공했는데 그 뒤의 앱(씬, 게임, 개발 서버)이 실패하는 경우가 있습니다. 진짜 에러는 앱의 로그 파일에만 찍혀서 에이전트는 모릅니다. --watch-log를 주면 tools/call 결과마다 직전 호출 이후 로그에 새로 찍힌 줄 중 --log-pattern에 맞는 줄이 결과 끝에 붙습니다. 에이전트가 따로 호출할 것은 없습니다. 로그 내용은 로컬에만 머물고 Lowdown에 기록되지 않습니다.
프록시는 공개 API(POST /api/interactions)로 기록합니다. DB 키가 필요 없고 LOWDOWN_SUPABASE_URL / LOWDOWN_SUPABASE_KEY는 더 이상 쓰지 않습니다. LOWDOWN_RECORD=0이면 기록 없이 패스스루만 합니다.
tools/call 결과의 isError: true는 실패(tool_error)로 기록합니다.
잘못된 요청(-32700/-32600/-32601/-32602: 형식 오류, 없는 도구, 잘못된 인자)은 서버 실패와 분리해 rejected_requests로 셉니다. success_rate에는 들어가지 않습니다.
initialize, tools/list 같은 비도구 요청은 protocol_requests로 따로 셉니다.
success_rate는 organic 기록만 계산합니다. seeded / synthetic은 by_source로 따로 보여줍니다. 일부러 실패시키는 테스트는 --test로 실행하면 synthetic으로 남습니다.
각 기록에는 그 시점의 server_version(initialize), schema_hash(tools/list, Scanner와 같은 계산), recorder_version이 함께 남습니다. 인자와 결과 내용은 기록하지 않습니다.
--target을 주지 않으면 명령줄 전체가 아니라 패키지·파일 이름 하나만 라벨로 씁니다.
설정 없음: 프록시를 실행하면 모든 것이 자동으로 처리됩니다.
패스스루 우선: 기록 로직이 실패하거나 느려도 실제 MCP 통신은 절대 막지 않습니다.
사실만 기록: v0는 성공/실패/지연시간만 기록합니다. 품질 판단은 범위 밖입니다.
출처 구분: 모든 기록은 organic / seeded / synthetic으로 태깅됩니다.
자세한 배경과 설계 원칙은 DESIGN.md를 참고하세요.
Compare 2 to 5 tools or agents by the interactions reported to Lowdown. Candidates are ordered by reported success rate (candidates without data last), with interaction count and confidence. Scanner observations are not used for the ordering. A suggestion is included only when the first candidate has at least 5 rated interactions.
| 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?
With no annotations, the description carries the full behavioral burden and does substantial work: it discloses the ordering key (reported success rate), tie/edge handling (candidates without data last), an explicit data exclusion (scanner observations do not affect ordering), and the conditional suggestion rule requiring at least 5 rated interactions. It stops short of covering failure modes or whether the call is purely read-only, so it is not exhaustive.
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?
Four sentences, each carrying distinct information: purpose, ordering, data exclusion, suggestion condition. The core purpose is front-loaded and there is no filler or redundancy.
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?
For a read-only comparison tool with no output schema, the description explains what effectively comes back (candidate ordering, interaction count, confidence, conditional suggestion) and the rules that govern it. Remaining gaps are minor — no explicit statement of read-only safety, error behavior, or handling of invalid candidate identifiers.
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, and the description's '2 to 5' merely restates the min/maxItems constraints rather than adding format or syntax guidance. task_type is not addressed in the description at all. Baseline 3 is appropriate when the schema does the heavy lifting.
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 or agents) with a bounded scope of 2-5 items, plus the data source (interactions reported to Lowdown). This is clearly distinguishable from siblings like get_lowdown, get_node_stats, and record_interaction 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?
Usage is implied — you call this when you want to rank or contrast several tools/agents — but there is no explicit when-to-use versus get_lowdown or get_node_stats, and no stated prerequisites (e.g., that candidates must already be tracked). The reader must infer the selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up recorded facts about an MCP server before installing or connecting to it. Accepts an MCP Registry name ('mcp:io.github.user/server'), a short name, or an npm package ('npm:@scope/name'). Returns, in order: registry (what the official MCP Registry declares, and changes in the last 30 days); packages (for each declared npm package: npm's latest version, whether that latest version is marked deprecated, and whether npm answers 404, checked daily); scanner (daily initialize and tools/list observations over 30 days, including when tool definitions last changed); and interactions reported by agents. When a declared npm package is deprecated or answers 404, the first sentence of message says so. These are recorded facts with dates and sources, not scores. Absence of data says nothing about a server's status.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | MCP Registry name with the mcp: prefix (e.g. 'mcp:io.github.user/server'), a short name, an npm package with the npm: prefix (e.g. 'npm:@scope/name'), or an id such as 'agent:some-agent-id' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden, and it does substantial work: it enumerates the four returned sections in order, states the data is recorded daily/over 30 days, notes what happens when a package is deprecated or 404s, and warns that absence of data is not a negative signal. Gaps remain around auth/pricing or error behavior for an unrecognized target, but the disclosure is well above typical.
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?
Front-loads purpose in the first sentence, then accepted inputs, then return structure — a sensible order with no filler. The return-section enumeration is wordy but earns its place since there is no output schema.
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 and no annotations, the description must explain what comes back and how fresh it is, and it does so section by section with the 30-day/daily cadence. It stops short of describing behavior on an unresolvable target or any failure modes, which is the main remaining hole.
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 is already documented with the same accepted formats in the schema. The description's restatement of registry/npm formats adds no syntax or validation detail beyond that, so 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 and resource ("Look up recorded facts about an MCP server") plus the calling context (before installing or connecting). This is clearly distinct from the sibling tools compare_tools, get_node_stats and record_interaction, so an agent can route 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?
Gives an explicit trigger — call this before installing or connecting to a server — which is real when-to-use guidance. It does not name alternatives or state when not to use it, but the sibling names make the boundary obvious.
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. If the call was an intentional negative test (e.g. deliberately invalid input), set source to 'synthetic' so it is not counted as a failure of the target.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | Yes | Your agent/system identifier | |
| source | No | organic (default) for real use; synthetic for tests, including intentional failure tests | |
| 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 | ||
| failure_type | No | Required when outcome is failure. Distinguish tool failure vs argument error. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It adds one valuable behavior: intentional negative tests recorded with source='synthetic' are not counted as target failures. However, it omits permissions, persistence, rate limits, and whether the record is public, which are important for a shared reputation-writing tool.
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?
Three sentences, front-loaded with the core action, then rationale, then the source edge case. No filler, and each sentence contributes necessary information.
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?
The description covers purpose and the key source nuance for a tool with no output schema and no annotations. It does not explain the required fields or failure_type requirement, relying on schema coverage; it also leaves out privacy/permission behavior, so an agent cannot fully predict side effects.
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 coverage is 75%, so the schema already documents most parameters. The description adds meaningful nuance beyond the schema for source by clarifying that intentional negative tests (e.g. deliberately invalid input) should be marked synthetic to avoid counting as a failure.
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 after using it. It is clearly distinguishable from the read-oriented siblings get_lowdown, get_node_stats, and compare_tools, though it does not explicitly name them.
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?
It gives clear usage context ('after using it') and a conditional when-to-use rule for source='synthetic' with an example. It does not name when not to use it or compare to alternatives, but the sibling tools serve different purposes.
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.17get_lowdown1 field changedInput schema / properties / target / descriptionPrevious value: -"MCP Registry name with the mcp: prefix (e.g. 'mcp:io.github.user/server'), a short name, or an id such as 'agent:some-agent-id'"New value: +"MCP Registry name with the mcp: prefix (e.g. 'mcp:io.github.user/server'), a short name, an npm package with the npm: prefix (e.g. 'npm:@scope/name'), or an id such as 'agent:some-agent-id'"v0.1.16record_interaction1 field changedInput schema / properties / source / descriptionAdded value: +"organic (default) for real use; synthetic for tests, including intentional failure tests"v0.1.15get_lowdown1 field changedInput schema / properties / target / descriptionPrevious value: -"Identifier of the agent/tool/service. e.g. 'mcp:vendor/tool-name' or 'agent:some-agent-id'"New value: +"MCP Registry name with the mcp: prefix (e.g. 'mcp:io.github.user/server'), a short name, or an id such as 'agent:some-agent-id'"record_interaction1 field changedInput schema / properties / failure_typeAdded value: +{
+ "description": "Required when outcome is failure. Distinguish tool failure vs argument error.",
+ "enum": [
+ "invalid_arguments",
+ "timeout",
+ "server_error",
+ "tool_error",
+ "unknown"
+ ],
+ "type": "string"
+}v0.1.11compare_toolsget_lowdownget_node_statsrecord_interactionScored across 4 tools
The four tools have clearly distinct actions: lookup server facts, compare candidate tools/agents, view node stats, and record an interaction. Although interaction data appears in both get_lowdown and compare_tools, their outputs and purposes are distinct enough to avoid confusion.
All tool names use a consistent snake_case verb_noun pattern: get_lowdown, compare_tools, get_node_stats, record_interaction. The convention is predictable throughout.
Four tools is a well-scoped set for a reputation/proxy server: one lookup tool, one comparison tool, one contribution recorder, and one node-status tool. Each has a clear role and there is no unnecessary bloat.
The surface covers the core lifecycle of looking up a server, comparing candidates, contributing interaction data, and checking node contribution. Minor gaps exist, such as no search/list operation and no dedicated single-agent profile beyond compare_tools, but agents can work around them.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Hosted MCP runtime where your agent publishes its own tools by tool call and keeps working.
Shared memory MCP server for Claude Code, Codex, Gemini CLI and Cursor. Cited, editable.
Shared memory for your AI tools: tasks, notes and context every tool can read and write over MCP.
