Loading ToolBench

Reading the current corpus…

pyrite MCP server · C · ToolBench

pyrite

Knowledge-as-Code MCP server for Pyrite knowledge bases. Provides three-tier access (read, write, admin) to knowledge bases with full-text search, semantic search, entry management, and administrative capabilities.

2026-07-28+STDIO5 tools

61/100

Definition Quality69

Protocol Readiness40

SupportabilityNot measured-

Spec posture

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

Static source inference · medium confidence

Current-spec patterns detected

Summary

Pyrite MCP Server provides 5 well-structured read-only tools with comprehensive input schemas and detailed descriptions. All tools have proper JSON Schema definitions with typed parameters and non-empty descriptions. The kb_search tool is exceptionally detailed with extensive filtering options and explicit contract documentation. However, there are gaps in error handling guidance, no tool annotations (readOnlyHint), and output schemas are not explicitly documented. The server follows good naming conventions (verb_noun pattern) and parameter design, but lacks recovery guidance for failure cases. Schema quality is high (all parameters typed), descriptions are thorough and LLM-optimized (ranging 100-1500+ chars, exceeding typical 200-char guideline but detailed and structured), and composition is clean with single responsibilities per tool.

Tools (5)

kb_backlinksread only50/100

Get all entries that link TO a given entry (reverse link lookup).

kb_getread only50/100

Get a specific entry by its ID. Returns full content including body, metadata, sources, and links. Bodies over {body_chunk_default} chars are auto-truncated; use body_offset/body_limit to paginate, or kb_read_body for continuation. A truncated body always carries body_truncated, body_length, body_offset and body_chunk_size.

kb_listread only50/100

List all mounted knowledge bases with their types and entry counts

kb_searchread only50/100

Full-text search across knowledge bases. Supports FTS5 query syntax (AND, OR, NOT, phrases in quotes). Returns entries with snippets ranked by relevance. Filters (entry_type, tags, date_from/date_to, fips, state, status) apply in every mode, on every search leg -- keyword, semantic and hybrid alike -- so a filtered result never contains an entry the filter excluded. When a leg cannot honour a filter it is dropped rather than returning unfiltered rows, and the response carries a "warnings" array naming it; no "warnings" key means every filter was applied on every leg (the key is absent, never null -- test for its presence). The full contract is stated once, in the docstring of SearchService.search: "what a search response owes its caller". Auto-quote rule: special-char tokens (hyphens, dots, colons) are auto-quoted ONLY when the query has no AND/OR/NOT operator and no existing quote. Once you use an operator or a phrase quote, quote special-char tokens yourself (e.g. '"family separation" "cross-link"') or the query can fail with error_code QUERY_SYNTAX (deterministic, not retryable).

kb_timelineread only50/100

Get timeline events within a date range, optionally filtered by importance.

Issues (5)

MEDIUMtool-annotations ↗

No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only operations. The MCP spec (2026-07-28) encourages tool annotations to help clients understand tool safety profiles.

kb_listkb_searchkb_getkb_timelinekb_backlinks

HIGHresponse-shaper ↗

No documented output schema or return type structure. While input schemas are comprehensive, output shapes (fields, types, pagination format) are not formally specified. LLMs cannot plan downstream operations or extract fields reliably.

kb_listkb_searchkb_getkb_timelinekb_backlinks

HIGHrecovery-guide ↗

Error handling lacks recovery guidance. Descriptions mention validation rules (e.g., kb_search's 'error_code QUERY_SYNTAX', 'deterministic, not retryable') but the tool definition does not document error codes, error conditions, or what the agent should do when failures occur.

kb_search

Recommendations

Add tool annotations to all tools: set readOnlyHint=true in the tool definition (MCP spec supports this via toolAnnotations feature). Example: 'toolAnnotations': {'readOnlyHint': true, 'idempotentHint': true}.
Document output schemas for each tool. Example for kb_list: 'Returns {knowledge_bases: [{name: string, type: string, entry_count: number}]}'. For kb_search: 'Returns {results: [{id, kb_name, title, snippet, score, body?, truncated?}], total: number, warnings?: string[], has_more: boolean}'.
Expand template variables in descriptions: replace {body_chunk_default} with the actual number (e.g., '2000'), {body_response_budget} with its value, {body_chunk_max} with its limit. Or move these to separate documentation and reference it: 'See kb_get documentation for body chunking limits.'
Add explicit error handling section to kb_search description: 'Error codes: QUERY_SYNTAX (malformed query, not retryable, quote special chars when using operators), KB_NOT_FOUND (retryable), FILTER_CONFLICT (a filter excludes all results; try relaxing constraints). On QUERY_SYNTAX, rephrase with proper quoting.'
For kb_get and kb_search, document pagination behavior: 'Pagination: use limit (1-100, default 20) and offset (default 0). Response includes total and has_more. To fetch all results, loop: offset += limit until has_more=false.'
Add parameter validation rules to descriptions where LLMs might guess wrong. Example for kb_search.limit: 'Maximum results to return (1-100, default 20). Requesting more than 100 is clamped to 100.'

Score history

Overall score trend

First recorded score · v2 rubric

61/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	61	2026-07-28+	v2