Silica Core
PYPI · SILICA-CORE
Retrieval over the folder the session opened: files, search, read, code_pack, write_note.
Available components
Last scanned (19 hours ago)
Scores higher than 91% of PyPI servers
Category Code Search and Documentation
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs setuptools.build_meta at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
- 2 of 28 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency100
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to kiycoh/silica-core). View diagnostics → Pass
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 1 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability60
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 1944 tokens (~388/item across 5 items; 5 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management67
- Stability observed for 20 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 5 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 6 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 15 Oct 26 +38
- Injection markers: unverified → pass ▲ security
- Tool coverage: unverified → 100 ▲ functional
- Stability: unverified → 0.63 ▲ functional
- MCP protocol: unverified → pass ▲ functional
- 14 Oct 26 0
- Package version: 0.10.2 → 0.11.0 functional
- 13 Oct 26 +15
- Malware scan: unverified → pass ▲ security
- Package version: 0.9.0 → 0.10.2 functional
- 12 Oct 26 0
- Package version: 0.10.1 → 0.10.2 functional
- 10 Oct 26 −50
- Stability: 0.37 → unverified ▼ security
- Malware scan: pass → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Schema quality: Schema quality not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet. functional
- Package version: 0.9.0 → 0.10.1 functional
- 7 Oct 26 +2
No change was recorded against any check on this day. Stability & Change Management went from 27 to 37. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.
- 3 Oct 26 +4
- Stability: unverified → 0.23 ▲ functional
- 30 Sept 26 +15
- Malware scan: unverified → pass ▲ security
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 16 Oct 2026 · Analysed pypi/silica-core@0.11.0
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | pypi |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | kiycoh/silica-core |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/kiycoh/silica-core/.github/workflows/release.yml@refs/tags/v0.11.0 |
| Rekor log index | 3252321895 |
| Predicate type | PyPI publish attestation https://docs.pypi.org/attestations/publish/v1 |
| Subject digest | sha256:f46237a53df1a43c726fc1a1219d8ae4ec1ea67f7fdaa0b802f7a8ffd7193c3a |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | setuptools.build_meta |
Background: Why install scripts are a supply-chain risk →
Dependencies 28 packages
| Packages resolved | 28 |
|---|---|
| Stale | 2 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
silica_code_pack ~224
Use before editing or explaining a source file, or when a traceback or a diff names `file:line`: one call serves the file, a `#Class.member`, or the symbol at `#L<line>`, with its supertypes, extenders, callers, the signatures it names, external dependencies and importers, inside a character budget. Static AST only, same repo state, same bytes. Check `truncated` before treating the target as complete; `dropped` names what did not fit. `languages` lists the parsers this install has.
| Name | Type | Req | Description |
|---|---|---|---|
| budget_chars | integer | – | Character budget for the whole pack; the target is always served |
| sections | array | – | Sections besides the target: any of 'hierarchy', 'callers', 'neighborhood', 'external', 'importers'. Empty = all |
| target | string | yes | Root-relative source path, optionally narrowed with '#Class', '#Class.member' or '#L<line>' (the symbol whose declaration spans that line) |
No output schema declared.
No examples provided.
silica_files ~293
Ask what the index could see before trusting a search or calling absence. Inventory of the root and what the index did with each file: `indexed` (in the index, matches disk), `changed` (differs from the index), `excluded` (an ignore rule or a type the index does not read; `reason` says which), `failed` (read or conversion error), `unconverted` (a PDF whose text layer the index could not read, or an office file with no extracted `.md` beside it; `reason` says which). A PDF is indexed from its own text layer, one section per page, unless a `.md` sits beside it — that sidecar is indexed instead, and both rows carry `source_state`: `stale` means the original changed after the conversion, `unverifiable` that the sidecar records no hash of it or its original is not under the root. `index.state` is `cold` when nothing was ever indexed: an empty listing there is not "no files".
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | string | – | `next_cursor` from the previous page |
| folder | string | – | Root-relative folder to list; empty = the whole root |
| limit | integer | – | Max entries per page |
| status | string | – | Only this status: indexed, changed, excluded, failed, unconverted |
No output schema declared.
No examples provided.
silica_read ~464
Read a located slice before citing it: lines `start..end`, one `section` by heading, a PDF page, or the whole file when it fits `max_chars`, always with the outline and a `version`; `truncated` and `next_start` say how to continue. A PDF is served from its own text layer, page by page: `section="p. 8"` serves one page — the whole page, ~1.2k tokens (measured 2026-09-09), so ask for it to cite a passage a search located, and widen the search's `width` to explore — `pages` counts them, `page_map` gives the pages the slice covers, and `extract_path` is that text on disk, for grep and the harness's own reader (a cache, rebuilt when the PDF changes, under no `version` guard). A PDF or office file with a `.md` extracted beside it is served from that instead, and `source_state` says whether the original still hashes to what the conversion recorded: `stale` means the PDF changed and the `.md` did not, `unverifiable` that the sidecar records no hash or its original is gone. Reading the `.md` itself, the path a search hit carries, reports the same `source` and `source_state`. Either way `source` names the original, and a PDF with no readable text layer is `error.unconverted`. Carry `version` forward as `expect_version` to be refused instead of reading different bytes under an old citation; `version` is the served text's, never the original's.
| Name | Type | Req | Description |
|---|---|---|---|
| end | integer | – | Last line; 0 = to the end, under max_chars |
| expect_version | string | – | Refuse with error.changed when the file's version differs |
| max_chars | integer | – | Cap on the served text |
| path | string | yes | Root-relative file path (from silica_files or a search hit) |
| section | string | – | Serve this heading's section instead (exact title or unique prefix) |
| start | integer | – | First line, 1-based |
No output schema declared.
No examples provided.
silica_search ~401
For a question that names no identifier (what a behaviour is, where it is decided, why), call this before any grep (a Grep tool, or grep or rg in a shell), Glob or Read: it ranks passages and, in a source tree, the functions, methods, classes and constants themselves, by the question's words and their vectors. Do not grep for the words of a question; grep for an exact string or a symbol name you already know. Each hit carries its densest `width`-char window and line; a PDF's section is a page, so on a PDF hit widen `width` (1200-1500) rather than reading the page. `matched_terms` are the query terms in the hit; `coverage` is the share of the query's idf mass they carry (near 1 = every rare term matched, near 0 = only the common words); `terms_absent` are query terms found nowhere in the corpus. No boolean "no answer" exists: read coverage and matched_terms and decide to stop or rephrase. A hit the dense leg alone found carries `dense` and coverage 0. In a source tree a hit's `section` is the symbol, `span` its lines, and `silica_read(path, section=<symbol>)` serves its body.
| Name | Type | Req | Description |
|---|---|---|---|
| folder | string | – | Only documents under this root-relative folder |
| k | integer | – | Max hits |
| per_doc | integer | – | Max sections per document |
| queries | array | – | More query groups, each ranked on its own and fused with `query` by rank: the concept in one, its identifiers in another |
| query | string | yes | Concise question or description of the concept or behavior to find; preserve known names and identifiers |
| width | integer | – | Characters in each hit's window |
No output schema declared.
No examples provided.
silica_write_note ~178
Write one note atomically, as given, then lint it: `lint` lists structural violations and unresolved wikilinks. Refuses to overwrite when `expect_version` does not match or when `create_only` is set and the file exists. Undo is git; the core keeps no journal.
| Name | Type | Req | Description |
|---|---|---|---|
| body | string | yes | Markdown body, written as given; a body escaped twice (no real newline, \n in their place) is decoded first |
| create_only | boolean | – | Refuse when the file already exists |
| expect_version | string | – | Refuse with error.changed unless the existing file has this version |
| frontmatter | object | – | Optional YAML frontmatter, serialised on top of the body |
| path | string | yes | Root-relative path of the note (.md added when missing) |
No output schema declared.
No examples provided.
How do I install the Silica Core MCP server?
Silica Core runs locally as a PyPI package, launched with uvx silica-core. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · silica-core
claude mcp add kiycoh-silica-core -- uvx silica-core
What is the Silica Core MCP server?
Silica Core is an MCP server listed in the public MCP registry as io.github.kiycoh/silica-core. Retrieval over the folder the session opened: files, search, read, code_pack, write_note. This page covers its PyPI package (silica-core).
Is the Silica Core MCP server safe to use?
Silica Core scores 88 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 16 October 2026. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Silica Core MCP server expose?
Silica Core exposes 5 tools: silica_files, silica_search, silica_read, silica_code_pack, silica_write_note. Their descriptions and schemas cost roughly 1,560 tokens of context every time the server is loaded.
Is the Silica Core MCP server still maintained?
Silica Core is still listed as active in the MCP registry. We last reached this channel on 16 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the Silica Core MCP server under?
Silica Core declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.