Loading ToolBench

Reading the current corpus…

second-brain MCP server · D · ToolBench

second-brain

A personal knowledge archive MCP server that provides tools to search, create, and manage notes, links, and documents with tag-based organization and AI integration via Model Context Protocol

2026-07-28+STDIO5 tools

50/100

Definition Quality70

Protocol Readiness35

Supportability26

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

Server has 5 tools with basic schemas and descriptions, but significant gaps limit production readiness. Tool names follow verb_noun convention (search_content, add_note, get_tags). Descriptions exist but are generic (avg ~80 chars, below 194-char baseline). Input schemas use Zod with type definitions, but parameter descriptions are minimal. Output schemas are not documented. Error handling is present but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint). The ping tool is a deprecated pattern (removed in current MCP spec). Overall structure is functional but falls short of A/B-grade quality.

Tools (5)

add_notewriteauthsource verified72/100

Create and save a new note, link, or document in Second Brain

get_content_by_tagread onlyauthsource verified70/100

Retrieve Second Brain content items filtered by a specific tag

get_tagsread onlyauthsource verified65/100

Get all tags stored in Second Brain

pingread onlysource verified70/100

Ping the Second Brain MCP server

search_contentread onlyauthsource verified73/100

Search user's Second Brain for notes, links, and documents matching a query

Issues (5)

HIGHtool ↗

Output schemas not documented. LLMs cannot infer what fields search_content, add_note, or get_content_by_tag return, forcing them to guess downstream field names and risking broken tool chains.

search_contentadd_noteget_tagsget_content_by_tag

HIGHtool-description ↗

Parameter descriptions are minimal or missing context. 'query' in search_content lacks guidance on format/scope. 'contentType' enum is documented but no hint on when to use each type. Descriptions should be 50-200 chars and explain WHAT, WHEN, and HOW.

search_contentadd_noteget_tags

MEDIUMtool ↗

No tool annotations (readOnlyHint/destructiveHint/idempotentHint). add_note is destructive (WRITE risk) but lacks annotation. LLMs cannot distinguish safe reads from state-modifying calls without explicit hints.

add_note

MEDIUMspec-alignment ↗

Recommendations

Document output schemas for all tools. For search_content, specify: returns array of {id, title, contentType, description, link, tags, createdAt}. For add_note, return {id, title, contentType, link, tags, createdAt}. This enables LLMs to chain tools correctly.
Expand parameter descriptions to 50-200 chars. E.g., search_content.query: 'Search term to match against note titles, descriptions, and tags. Supports partial matches. Returns up to 20 results; use pagination for more.' This matches production baseline.
Add tool annotations via Zod metadata or MCP schema extensions. Mark add_note with destructiveHint=true, search_content with readOnlyHint=true. This signals to LLMs which tools have side effects.
Remove the ping tool. It is deprecated in the current MCP spec and adds no value. Clients should not rely on ping for liveness checks.
Enhance error responses with recovery hints. E.g., if add_note fails: return {error: 'Title already exists', suggestion: 'Try a unique title or call search_content to find the existing note'}. This guides agent retry logic.

Score history

Overall score trend

First recorded score · v2 rubric

50/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	50	2026-07-28+	v2