Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@historical-kb-mcp search for similar past defects with a NullPointerException in the auth service"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Stores and retrieves completed defect-triage analyses so the orchestrator can find similar past defects when triaging a new ticket. This is the third MCP in the Rapid7 SI Triage pipeline — the persistent memory of the system.
Store — after the triage agent completes its analysis, it calls
store_analysis with the full triage result: root cause, verdict, fix,
affected class/method, error signature, PR link, confidence, and 30+ other
metadata fields. If the same ticket is stored again, fields are merged
(upsert).
Search — at the start of a new triage, search_similar runs hybrid
retrieval (dense + BM25 via Reciprocal Rank Fusion) to find historical
defects with similar error signatures, root causes, or components.
Retrieve — get_analysis returns the full record for a specific ticket.
Update — update_analysis patches fields (e.g. adding the PR link after
the fix is merged, or upgrading the verdict after investigation).
List — list_analyses with optional filters for browsing/dashboarding.
Delete — delete_analysis removes a record.
Stats — get_kb_stats returns counts by verdict, defect type, component,
product, and average resolution time.
Related MCP server: Context Graph MCP Server
Tool | Purpose |
| Store or merge a triage result (ticket_id required) |
| Retrieve full record by Jira key |
| Hybrid search with optional filters |
| Patch specific fields |
| Filtered listing |
| Remove from KB |
| Aggregate statistics |
Every analysis stores 30+ fields across these categories:
Identity — ticket_id, record_id
Ticket context — summary, description, product, component, version, environment, reporter, priority, labels
Triage analysis — root_cause, verdict, defect_type, severity_assessed, confidence
Code location — affected_class, affected_method, affected_file, affected_line
Error signature — error_type, error_message, error_code, stack_trace_signature
Fix / resolution — fix_description, fix_type, pr_link, pr_status, commit_hash, branch, files_changed
Linked artefacts — confluence_page_ids, related_tickets, log_query_used, log_chunks_referenced
Timestamps — created_at, resolved_at, resolution_time_hours, updated_at
Agent metadata — analyst, model_used, pipeline_version
Extension — tags, custom_fields
code_fix · config_change · infra · dependency · data_issue ·
user_error · duplicate · wontfix · needs_info · not_a_bug
null_pointer · class_cast · arithmetic · concurrent_modification ·
number_format · parse_error · resource_leak · timeout ·
connection_failure · auth_failure · permission_denied · missing_table ·
schema_mismatch · config_invalid · thread_pool · memory · other
cd historical-kb-mcp
python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e .
cp .env.example .env # adjust SI_DATA_DIR if needed
# stdio (for Claude Desktop / local MCP client):
python -m historical_kb_mcp --transport stdio
# HTTP (for MCP Inspector / remote clients):
python -m historical_kb_mcp --transport http
# Serves at http://127.0.0.1:8082/mcpThis server is one of four processes in the SI Triage POC (this + the Jira/Confluence and Log Intelligence MCPs + the orchestrator). For the full multi-service manual startup sequence,
.envlayout across all four repos, and end-to-end test steps, seeorchestrator-agent/si-triage-automation/README.md→ "Running the full system manually".
python -m historical_kb_mcp.seedThis pre-populates the KB with completed triage analyses for all 10 planted
defects (root causes, verdicts, fixes, PR links, error signatures), so
search_similar returns meaningful results immediately.
npx @modelcontextprotocol/inspector
# URL: http://127.0.0.1:8082/mcp{
"mcpServers": {
"historical-kb": {
"command": "python",
"args": ["-m", "historical_kb_mcp", "--transport", "stdio"],
"env": { "SI_DATA_DIR": "/absolute/path/to/si_data" }
}
}
} Orchestrator (Claude)
│
├──1─▶ jira-confluence-mcp (get ticket, download logs, search Confluence)
│ └─writes→ si_data/logs/<ticket_id>/
│
├──2─▶ log-intelligence-mcp (ingest logs, hybrid query)
│ └─reads← si_data/logs/<ticket_id>/
│ └─writes→ si_data/vector_store/
│
├──3─▶ historical-kb-mcp ◀── THIS MCP
│ ├─ search_similar(error_signature) ← find past defects
│ └─ store_analysis(triage_result) ← save when done
│ └─writes→ si_data/kb/records/ + si_data/kb/vectors/
│
└──4─▶ jira-confluence-mcp (post comment, update ticket)All three MCPs share SI_DATA_DIR — set it to the same absolute path.
Same approach as the Log Intelligence MCP:
Dense — sentence-transformers all-mpnet-base-v2 (768-dim) for semantic
similarity ("payment failed" ≈ "authorization error")
BM25 — keyword matching for exact identifiers (class names, error codes, CVEs)
Reciprocal Rank Fusion — merges the two rankings without fragile score normalisation
The text embedded is the concatenation of error signature fields, root cause, fix, summary, description, and class/method — ordered so the most semantically distinctive fields dominate.
Concern | Production | Offline fallback |
Embeddings | sentence-transformers | Hashed n-gram TF-IDF (numpy) |
Vector store | Chroma (persistent) | Numpy |
Sparse search | BM25 (always) | same |
EMBED_BACKEND=auto / VECTOR_BACKEND=auto use production backends when
importable and fall back otherwise. The offline backends are real (genuine
vectors, real cosine search) — not mocks.
pytest # in the POC environment
python tests/_runner.py # offline (when pytest isn't installed)12 tests: model serialisation, searchable text ordering, BM25 keyword ranking, store/retrieve, update (field merge), search (hybrid + filters), delete, list (with filters), stats aggregation, upsert merge (no duplicates), and the full seed of all 10 defects.
See .env.example. Key variables: SI_DATA_DIR, EMBED_BACKEND,
VECTOR_BACKEND, RRF_K, DEFAULT_TOP_K, MCP_HTTP_PORT (default 8082).
Remove an analysis record from the KB (vectors, BM25 index, and JSON).
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly reveals that the operation removes multiple underlying artifacts (vectors, BM25 index, and JSON), signaling a destructive, irreversible action. It does not mention permissions or idempotency, but the core behavioral impact is well communicated.
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 description is a single focused sentence with no filler. The core action is front-loaded, and the parenthetical detail about what gets removed adds meaningful specificity without bloat.
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 one-parameter delete operation with no output schema, the description is reasonably complete: it states what is deleted and from where. It could add explicit usage guidance, but the low tool complexity means very little is missing for correct invocation.
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 0%, so the description must compensate for the undocumented ticket_id parameter. It does not explicitly state that ticket_id identifies the analysis record to delete, nor does it provide format or provenance details. The parameter meaning is only recoverable from the parameter name and title.
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 uses a specific verb ('Remove') with a clear resource ('analysis record') and explicitly states the scope of deletion: vectors, BM25 index, and JSON. This distinguishes it from siblings like get_analysis, update_analysis, and store_analysis without needing to open schemas.
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?
No guidance is given about when to use this tool versus alternatives such as update_analysis or store_analysis. The description implies deletion by its wording, but it does not explicitly state when this is the right choice or when another sibling should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full analysis record for a ticket by its Jira key.
Returns every field: root_cause, verdict, fix_description, PR link, affected class/method, error signature, confidence, timestamps, and all linked artefacts.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states this is a read operation ('Retrieve') and explicitly enumerates the return fields, giving an agent a concrete expectation of the output. It does not mention not-found behavior or performance, but the core behavior for the main use case is well covered.
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 description is efficiently structured: the first sentence states the purpose, and the second enumerates the return fields. Every sentence adds value, there is no filler, and the most important information is front-loaded.
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 simple single-parameter read tool with no output schema, the description is largely complete. It specifies the input semantics and the full set of return fields. The only gap is edge-case behavior (e.g., what happens if the ticket key does not exist), but the core use case is adequately covered.
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 schema only provides the parameter name 'ticket_id' as a string with 0% description coverage. The description compensates by clarifying that this is a 'Jira key', which adds semantic meaning beyond the bare schema. It stops short of providing a format example (e.g., 'PROJ-123'), but the essential meaning is conveyed.
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 uses a specific verb ('Retrieve') and resource ('full analysis record for a ticket by its Jira key'), and explicitly lists the fields returned. It is clear about what the tool does, but it does not explicitly differentiate from sibling tools like list_analyses or get_kb_stats, relying on the tool name and context instead.
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 implies when to use this tool (when you need the full analysis record for a specific ticket) but provides no explicit guidance on alternatives or exclusions. Given siblings like list_analyses and store_analysis, a sentence directing the agent to those tools for other scenarios would have been helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate statistics: records by verdict, defect type, component, product, and average resolution time across the whole KB.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that the operation is aggregate and global in scope, which strongly implies a read-only, non-mutating behavior. It does not explicitly state side-effect-free behavior, permissions, or return characteristics, but the 'aggregate statistics' wording provides reasonable transparency for this simple read-only 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?
The description is a single efficient sentence that front-loads the core action ('Aggregate statistics') and then lists the concrete dimensions. Every phrase earns its place; there is no filler or repetition.
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 zero-parameter statistics tool, the description is largely complete: it states the scope and enumerates the returned aggregates. Without an output schema, it could be slightly more explicit about the exact return shape, but the listed breakdowns give enough context for an agent to invoke it and interpret results.
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 has zero parameters and schema coverage is effectively 100%, so there is no hidden input surface. The description reinforces the absence of filters by saying 'across the whole KB,' which confirms the agent does not need to supply or worry about parameters.
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 clearly names the operation (aggregate statistics), the resource (across the whole KB), and the specific breakdowns (verdict, defect type, component, product, average resolution time). This distinguishes it from the sibling analysis tools, which target individual stored analyses rather than KB-wide stats.
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 phrase 'across the whole KB' implies this is for global, cross-record statistics rather than per-analysis retrieval, so the usage context is inferable. However, the description does not explicitly state when to prefer this over siblings like get_analysis or list_analyses, nor does it provide any exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List stored analyses with optional filters by component, verdict, or product.
Returns a compact summary per record for browsing/dashboarding.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| product | No | ||
| verdict | No | ||
| component | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that results are compact summaries rather than full records, which is useful. However, it remains quiet on ordering, pagination behavior, and the exact meaning of the limit parameter, leaving notable behavioral gaps.
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 sentences, zero filler, and the core verb+resource+filter information is front-loaded. The added 'compact summary' detail is purposeful and 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?
For a simple read-only list tool, the description covers the main invocation concerns: what it lists, the available filters, and the shape of the return (compact summaries). It does not address limit or ordering, but these are minor given the self-explanatory schema and default limit.
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 0%, so the description must compensate. It does meaningfully group component, verdict, and product as optional filters, but it omits limit entirely and does not clarify filter combination or matching semantics. Thus it only partially compensates for the bare schema.
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 starts with a clear verb+resource pair ('List stored analyses') and adds scope via optional filters. It also differentiates from siblings by promising 'a compact summary per record for browsing/dashboarding,' which contrasts with get_analysis likely returning full details.
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 gives a clear use context ('for browsing/dashboarding') and implies this is the list/browse counterpart to get_analysis. It does not explicitly say when not to use it or name alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hybrid semantic + keyword search for similar past defects in the KB.
Combines dense vector similarity with BM25 keyword matching via Reciprocal Rank Fusion. Use this at the start of a new triage to find historical defects with similar error signatures, root causes, or affected components. Optional filters narrow results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| product | No | ||
| verdict | No | ||
| component | No | ||
| error_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the hybrid retrieval mechanism (dense vectors + BM25 via Reciprocal Rank Fusion) and that optional filters narrow results. It does not describe output shape or limits, but the non-mutating search behavior is clear and well-specified.
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 with no filler. The first sentence summarizes the tool, the second explains the mechanism, and the third gives usage guidance. It is front-loaded and every sentence 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?
The description adequately covers what the tool does, when to use it, and how ranking works. However, with no output schema and no parameter descriptions, it leaves top_k semantics, filter value expectations, and return format implicit, requiring the agent to infer important details.
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 0%, yet the description only mentions 'Optional filters narrow results' without explaining query, top_k, product, verdict, component, or error_type. Parameter names are somewhat self-explanatory, but the description fails to compensate for the complete lack of schema-level documentation.
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: 'search for similar past defects in the KB.' It clearly differentiates itself from the sibling CRUD and stats tools by describing a hybrid semantic + keyword retrieval operation.
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 explicitly says when to use it: 'Use this at the start of a new triage to find historical defects with similar error signatures, root causes, or affected components.' It provides clear context, though it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a completed triage analysis in the Historical KB.
Accepts a dictionary with ticket_id (required) and any of: summary, description, product, component, version, root_cause, verdict, defect_type, confidence, affected_class, affected_method, error_type, error_message, error_code, stack_trace_signature, fix_description, fix_type, pr_link, pr_status, commit_hash, branch, files_changed, confluence_page_ids, related_tickets, analyst, model_used, tags, etc.
If the ticket already has a record, fields are merged (non-empty new values overwrite existing).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description carries the burden of behavioral disclosure. It discloses that fields are merged with non-empty new values overwriting existing ones, which is a key behavior. However, it doesn't mention whether the operation requires special permissions, what the response looks like, or whether it creates a new record vs. updates (though merge implies both). This is adequate but not fully transparent.
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 description is structured with a clear first sentence naming the action, followed by a parameter key list and a merge behavior note. It is efficient and front-loaded with the core purpose. The list of keys is somewhat long but necessary given the permissive 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?
Given the tool accepts a free-form dictionary, the description provides enough context for basic use: required ticket_id, optional fields, and merge semantics. It does not describe return values or error conditions, and there is no output schema, but the essential behavior for calling is present. The lack of explicit differentiation among siblings like update_analysis is a minor gap.
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 input schema has only one parameter 'data' with additionalProperties: true and no description, so schema coverage is 0%. The description compensates by providing a long list of accepted keys within the data object and clarifies the required ticket_id. However, it doesn't explain the value types or nesting expectations beyond being a dictionary, and the 'etc.' suggests the list is not exhaustive.
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 ('Store') with a clear resource ('completed triage analysis in the Historical KB') and lists accepted fields, distinguishing it as a write operation from sibling tools like get_analysis or delete_analysis. It does not explicitly contrast with sibling update_analysis, but the merge/overwrite behavior implies updating existing records.
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 explains when to use it: to store a completed triage analysis, and the merge behavior when a ticket already has a record. It doesn't explicitly say when not to use it or mention alternatives, but the context of storing completed analyses is clear enough to differentiate from read or search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update fields on an existing analysis record.
Common use: adding the PR link and commit hash after the fix is merged, updating verdict after further investigation, or enriching with confluence_page_ids.
| Name | Required | Description | Default |
|---|---|---|---|
| updates | Yes | ||
| ticket_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It lists common update scenarios but does not explain partial-update semantics, whether existing fields are preserved, required permissions, reversibility, or what happens with invalid or unknown update keys. For a mutation tool, this leaves significant 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 description is concise, front-loaded with the core purpose, and followed by a compact use-case list. Every sentence adds useful information and there is no redundancy or filler. It is ideally sized for an AI agent to process quickly.
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 tool has no output schema, no annotations, and a low-coverage schema, so the description must carry more weight. While the use cases help, the description does not specify return behavior, error cases, whether updates replace or merge the existing object, or constraints on the free-form updates object. This is incomplete for an update operation with free-form input.
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 0%, so the description must compensate. It partially does by giving concrete example fields such as PR link, commit hash, verdict, and confluence_page_ids, which helps infer what the free-form 'updates' object may contain. However, it does not clarify expected key names, value formats, or how ticket_id is used beyond being a required identifier.
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 clearly states a specific verb and resource: 'Update fields on an existing analysis record.' It distinguishes from create/store and read/delete siblings by emphasizing 'existing' and listing update-specific use cases. However, it does not explicitly name or contrast the closest sibling, store_analysis, leaving some differentiation to inference.
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 'Common use' examples imply when to call this tool: after a fix is merged, after further investigation, or when enriching with confluence_page_ids. These examples provide contextual guidance but no explicit when-not-to-use guidance or alternatives. The usage conditions are implied rather than stated as rules.
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.0delete_analysisget_analysisget_kb_statslist_analysessearch_similarstore_analysisupdate_analysisScored across 7 tools
Most tools are clearly distinct: get_analysis, list_analyses, search_similar, delete_analysis, and get_kb_stats each serve different purposes. However, store_analysis and update_analysis overlap because store_analysis is an upsert that merges fields into existing records, making the boundary between creating and updating ambiguous.
The naming is predominantly verb-first and predictable: store_, get_, update_, list_, delete_, search_, get_. Minor deviations include list_analyses being plural while other resource tools are singular, search_similar lacking a direct object, and get_kb_stats using an abbreviation instead of a full noun.
Seven tools is well-scoped for a knowledge-base server: full CRUD plus specialized search and statistics. Each tool earns its place, and the count is neither too thin nor excessively heavy.
The surface covers the full lifecycle of analysis records: create via store_analysis, read via get_analysis, update via update_analysis, delete via delete_analysis, and browse via list_analyses. The additional search_similar and get_kb_stats tools round out the domain without leaving obvious dead ends.
Ingest, manage, and retrieve documents for RAG-powered AI applications
Persistent AI memory with semantic search, conflict detection, and ticketing.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
