MCP server providing AT Protocol documentation, lexicons, Bluesky API docs, and cookbook examples as a searchable knowledge base powered by semantic search.
This is a well-designed knowledge-base server with strong tool naming, comprehensive descriptions, and solid schema documentation. All 9 tools follow consistent patterns and provide actionable guidance. However, output schemas are not formally documented (returned as text strings rather than structured JSON), and error handling lacks systematic recovery guidance. The tool set demonstrates clear single-responsibility design and good naming conventions (all verbs: search_*, get_*, list_*, refresh_*, server_status). Descriptions are detailed and contextual (avg ~180 chars, well within the 10-1024 baseline). Parameters have type definitions and descriptions. The main quality gap is the absence of formal output schema declarations and limited structured error categorization.
Retrieve a specific AT Protocol cookbook example by project name. Returns the project README, file listing, and key source code files. Use this when you need implementation examples or starter code.
Retrieve a specific AT Protocol lexicon by its NSID. Returns the full lexicon schema including type definitions, properties, descriptions, and cross-references. Use this when you need the complete definition of a specific endpoint or record type.
List all AT Protocol cookbook examples (starter projects and scripts). Use this to discover available example projects before fetching specific ones with get_cookbook_example.
List all AT Protocol lexicons, optionally filtered by namespace prefix. Use this to discover available lexicons and their NSIDs before fetching specific ones with get_lexicon.
Manually trigger a full refresh of all source repositories and rebuild the knowledge base index. Use this when you want to update the index to the latest documentation without waiting for the automatic refresh interval. The refresh happens asynchronously in the background; this tool returns immediately with status.
Output schemas are text-formatted, not structured JSON. Tools return plain text via _format_search_results() and string concatenation. LLMs cannot reliably parse or extract fields from free-text responses, this violates the pattern:response-shaper requirement and wastes tokens on parsing unstructured output.
Error handling lacks systematic categorization and recovery guidance. KnowledgeBaseNotReady exceptions are caught and converted to text, but there is no pattern for retryable vs. fatal errors, no suggestion of alternatives when a lexicon is not found (except in get_lexicon), and no user-fixable vs. agent-fixable classification. This violates pattern:recovery-guide and pattern:error-classification.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Search across all AT Protocol documentation, lexicons, Bluesky API docs, and cookbook examples. Use this tool to find information about AT Protocol concepts, endpoints, data structures, authentication, federation, and implementation patterns. Search is hybrid (keyword + semantic), so exact identifiers like NSIDs ("app.bsky.feed.getFeed") or endpoint names match reliably.
Search Bluesky API documentation specifically. More targeted search for Bluesky-specific API guides, tutorials, and how-to articles from docs.bsky.app.
Search within AT Protocol lexicons using semantic search. Searches lexicon descriptions, property names, types, and definitions. More targeted than search_atproto_docs when you specifically need lexicon/schema information.
Get the current status of the knowledge base server. Returns whether the index is ready, warming up, or encountered errors. Also reports the number of indexed chunks and lexicons.
refresh_sources is a destructive/stateful tool (WRITE risk) but has no confirmation step, dry-run option, or warning in the description about potential side effects. Agents could accidentally trigger full refreshes in loops. Violates pattern:confirmation-request.
search_atproto_docs, search_lexicons, search_bsky_api, and list_cookbook_examples accept 'limit' as an unbounded integer parameter with only inline description constraints. JSON Schema should formally enforce min/max (1-20 for searches, 1-∞ for lists) to prevent LLMs from passing invalid values like limit=10000 or limit=-1.
source parameter in search_atproto_docs accepts a free-form string with enum values documented only in the description. Should declare source as a formal enum in the JSON Schema (atproto-website, bsky-docs, lexicons, cookbook) so the LLM knows the valid options without parsing text.
content_type parameter similarly is free-form with enum values in description only. Should be a formal enum (guide, spec, blog, reference, example).