Skip to main content
Glama
deenesjakoruzh
tristanmanchester

sifs

by tristanmanchester
OverviewSchemaRelated ServersScoreDiscussions
Rust
Local

SIFS (SIFS Is Fast Search) is a local code-search engine for AI coding agents and the developers who work through them. Point it at a repository and ask questions like "where is authentication handled?", "what validates session tokens?", or "which code builds the MCP handshake?". SIFS returns ranked file paths, line ranges, and code chunks fast enough for an agent to search before reading half the tree.

It runs as a CLI, a Rust crate, or a local MCP server. BM25 mode runs offline with no model files; hybrid and semantic modes run locally once the embedding model is cached.

Across 63 repositories and 1,251 annotated tasks, SIFS builds a cold sparse index in 167 ms, answers warm queries in 2.7 ms, and scores NDCG@10 = 0.8471.

Use SIFS to:

  • Find the code behind a natural-language question.

  • Look up exact symbols and identifiers without warming an IDE.

  • Hand an LLM a compact context pack instead of a whole repository.

  • Give Codex, Claude Code, Cursor, OpenClaw, Hermes, or another agent a search tool it can call before broad file reads.

Quickstart

Install SIFS with Homebrew:

brew install tristanmanchester/tap/sifs

Or install it with Cargo:

cargo install --locked sifs

Then search any local project:

cd /path/to/project
sifs search "where is authentication handled" --mode bm25 --offline --limit 5

BM25 mode runs offline with no model download. Results include the matching file, line range, score, ranking mode, and code chunk.

For semantic search, cache the local model and use the default hybrid mode:

sifs model pull
sifs search "what checks whether a session is expired" --limit 5
sifs pack "how login sessions are created and validated" --budget-tokens 6000 --json

The default search mode is hybrid (semantic + BM25). Omit --source to search the current directory, or pass a local path or Git URL explicitly:

sifs search "parse JWT claims" --source /path/to/project --mode bm25 --offline --limit 10
sifs symbol SessionToken --source /path/to/project --offline --json
sifs outline src/auth/session.rs --source /path/to/project --offline \
  --symbols-limit 200 --chunks-limit 100 --json
sifs find-related src/auth/session.rs 42 --source /path/to/project --limit 8
sifs search "stream upload backpressure" --source https://github.com/owner/project --limit 5

Common entry points:

Goal

Command

Search without downloads

sifs search "query" --mode bm25 --offline

Use semantic + lexical ranking

sifs model pull, then sifs search "query"

Build an offline context pack

sifs pack "query" --mode bm25 --offline --budget-tokens 6000 --json

Build a hybrid context pack

sifs model pull, then sifs pack "query" --budget-tokens 6000 --json

Inspect what was indexed

sifs status --json, sifs list-files --json, sifs symbol <name> --json, sifs outline <file> --json

Teach an agent to use SIFS

sifs agent install --target codex --artifact snippet --file AGENTS.md

Related MCP server: ken

Agent integration

SIFS is most useful when agents know they can search first. Install a project instruction snippet or local skill so Codex, Claude Code, OpenClaw, Hermes, or any skill-aware agent uses SIFS before broad file reads:

sifs agent print --target codex --artifact snippet
sifs agent install --target codex --artifact snippet --file AGENTS.md --dry-run --json
sifs agent install --target codex --artifact snippet --file AGENTS.md
sifs agent doctor --target codex --json

Generated guidance is CLI-first. Agents use MCP tools when they're visible in the current session and otherwise fall back to shell commands like sifs search, sifs pack, sifs list-files, sifs get, and sifs agent-context --json.

Full integration reference: docs/agent-integration.md.

Features

  • Fast local search. 167 ms cold sparse index, 2.7 ms warm query, 4.9 µs cached repeat. Rust, CPU-only.

  • Strong cross-language quality. NDCG@10 of 0.8471 across 63 repositories, 19 languages, and 1,251 annotated tasks.

  • Three search modes. hybrid for most queries, semantic for natural language, bm25 for symbols and identifiers. Switch per query.

  • Offline-capable. BM25 needs no model. Hybrid and semantic work offline once the model is cached.

  • MCP server. Stdio server for Claude Code, Codex, Cursor, and any MCP-compatible agent. Sources index on demand and refresh on request.

  • Structural inspection. Browse indexed paths, symbols, file outlines, chunks, related code, and context packs.

  • Agent skills and snippets. Render, install, inspect, and remove SIFS guidance with sifs agent.

  • Local and remote sources. Pass a local path or Git URL with --source.

  • Machine-readable contract. sifs agent-context --json describes every command, flag, and tool.

  • Profiles and feedback. Save defaults for repeated sessions and log friction with sifs feedback.

  • Benchmark diagnostics. Run quality and latency benchmarks with the diagnostics feature.

Install

# crates.io
cargo install --locked sifs

# Homebrew
brew install tristanmanchester/tap/sifs

# From source
cargo build --release
target/release/sifs search "authentication flow" --source . --mode bm25 --offline

Keep installed binaries current with:

sifs update --check
sifs update --dry-run
sifs update

sifs update delegates to Cargo or Homebrew only when the current binary is owned by that package manager. For copied, development, or ambiguous binaries, it prints manual next actions rather than touching an unrelated install.

The sifs-benchmark and sifs-embed diagnostic binaries require the diagnostics feature:

cargo build --release --features diagnostics --bins

Run the test suite after changing indexing, chunking, ranking, model loading, or MCP behavior:

cargo test

MCP server

Install SIFS as a local stdio MCP server in two commands:

sifs daemon install-agent
sifs mcp install --client all

This registers a reusable server. Tool calls pass source to target a specific local checkout or Git URL.

To pin the server to a single source:

sifs mcp install --client all --source /path/to/project
sifs mcp install --client codex --source /path/to/project
sifs mcp install --client claude --scope local --source /path/to/project

You can also start the server directly. Without --source, the server uses its working directory as the default. Passing --source pins the server to that source, so MCP clients can call search and find_related without sending a source on every tool call.

sifs mcp
sifs mcp --source /path/to/project

The installer calls the client CLIs when they're available:

codex mcp add sifs -- /absolute/path/to/sifs mcp
claude mcp add-json sifs '{"type":"stdio","command":"/absolute/path/to/sifs","args":["mcp"],"env":{}}' --scope local

If a client CLI isn't available, sifs mcp install --dry-run prints the config to paste manually.

Codex (~/.codex/config.toml):

[mcp_servers.sifs]
command = "/absolute/path/to/sifs"
args = ["mcp"]
startup_timeout_sec = 20
tool_timeout_sec = 60

Claude Code (.mcp.json in your project):

{
  "mcpServers": {
    "sifs": {
      "type": "stdio",
      "command": "/absolute/path/to/sifs",
      "args": ["mcp"],
      "env": {}
    }
  }
}

Only commit a project-scoped .mcp.json to repositories you trust. It grants read access to whatever local paths tool calls pass in.

To run the daemon directly:

sifs daemon run --replace-existing-socket
sifs daemon ping
sifs daemon status --json

CLI

# Search the current directory
sifs search "where is authentication handled"

# Search a local project with hybrid ranking
sifs search "parse oauth callback" --source /path/to/project --mode hybrid --limit 10

# Use model-free offline BM25 search
sifs search "SessionToken" --source /path/to/project --mode bm25 --offline --limit 10

# Search a remote Git repository
sifs search "stream upload backpressure" --source https://github.com/owner/project

# Find code related to a known location
sifs find-related src/auth/session.rs 42 --source /path/to/project --limit 8

Use --json, --jsonl, or --format for structured output. Use --language, --filter-path, and --context-lines when an agent needs narrower results.

Use profiles for repeated agent sessions:

sifs profile save current --source /path/to/project --mode bm25 --offline --json
sifs search "mcp startup" --profile current --json

Index caches live in platform cache directories by default (~/Library/Caches/sifs on macOS, ${XDG_CACHE_HOME:-~/.cache}/sifs on Linux). Override with --cache-dir, disable with --no-cache, or opt into a repo-local .sifs/ cache with --project-cache.

Full CLI reference: docs/cli.md.

Platform support

Direct CLI search, library use, and MCP stdio work on macOS and Linux. The shared sifs daemon uses same-user Unix sockets, so daemon mode runs on Unix only. On Windows, use direct CLI or MCP stdio. sifs doctor --json reports daemon platform status.

Rust library

use sifs::{SearchMode, SearchOptions, SifsIndex};

fn main() -> anyhow::Result<()> {
    let index = SifsIndex::from_path("/path/to/project")?;
    let results = index.search_with(
        "where is authentication handled",
        &SearchOptions::new(5).with_mode(SearchMode::Hybrid),
    )?;

    for result in results {
        println!("{} {}", result.chunk.location(), result.score);
    }

    Ok(())
}

Use SifsIndex::from_path_sparse for a BM25-only index that never touches semantic state. Use SifsIndex::from_git for remote repositories. Full API docs, model policy, filters, and chunk-level construction: docs/library.md.

How it works

SIFS walks a repo with .gitignore-aware file selection, splits files into code chunks, builds a sparse BM25 index, and loads semantic state lazily when a semantic or hybrid query needs it.

bm25 — sparse lexical search. Good for identifiers, symbols, and exact terms. No model files required.

semantic — embedding similarity using minishlab/potion-code-16M through a local Model2Vec loader. Tensors and tokenizer files load directly into the Rust process and stay on the machine.

hybrid — the default. Semantic and BM25 rankings fuse with reciprocal rank fusion, then rerank. Symbol-like queries lean on BM25; natural-language questions keep more semantic weight.

  • Query-aware mode weighting. Symbol queries (Foo::bar, getUserById) get more BM25 weight. Natural-language queries stay balanced.

  • Definition boosts. A chunk that defines the queried symbol (class, fn, def) ranks above chunks that only reference it.

  • Identifier stemming. Query tokens are stemmed and matched against identifier stems, so parse config boosts chunks containing parseConfig, ConfigParser, or config_parser.

  • File coherence. When multiple chunks from the same file match, the file is boosted so results reflect file-level relevance.

  • Noise penalties. Test files, compat//legacy/ shims, example code, and .d.ts stubs are down-ranked so canonical implementations surface first.

Use sifs model pull (or its alias sifs model fetch) to pre-download the default model. Use sifs doctor to confirm semantic search is ready for offline use.

Benchmarks

Benchmarks run across 63 pinned open-source repositories, 19 languages, and 1,251 annotated search tasks.

SIFS search quality versus warm uncached query latency

Method

NDCG@10

Cold index

Warm query

Cached repeat

CodeRankEmbed Hybrid

0.8617

57.3 s

16.9 ms

n/a

Semble

0.8544

439.4 ms

1.3 ms

n/a

SIFS

0.8471

167.0 ms

2.7 ms

0.0049 ms

CodeRankEmbed

0.7648

57.3 s

13.3 ms

n/a

ColGREP

0.6925

3.9 s

979.3 ms

n/a

grepai

0.5606

35.0 s

47.7 ms

n/a

probe

0.3872

—

207.1 ms

n/a

ripgrep

0.1257

—

8.8 ms

n/a

SIFS reports separate timing fields so caching effects stay legible:

  • cold_index_ms — fresh sparse/chunk index, no persistent cache

  • cold_semantic_build_or_load_ms — first semantic embedding build or load

  • cold_first_search_ms — first search, including semantic first-use cost

  • warm_uncached_query_ms — normal query after the index exists (use this for comparisons)

  • warm_cached_repeat_query_ms — repeated identical query in the same process

Quality by query type

SIFS is strongest on symbol queries but holds up well on semantic and architecture questions too.

Query type

NDCG@10

symbol

0.9711

semantic

0.8412

architecture

0.7857

SIFS quality by query type and search mode

Context efficiency

The chart below tracks how quickly annotated relevant files enter an agent's context as retrieved chunks are added to the prompt budget.

SIFS context efficiency: recall versus retrieved context tokens

Full methodology, per-language breakdown, ablations, and benchmark artifacts: docs/benchmark-report.md.

File coverage

SIFS indexes code files by default and skips generated files, dependency directories, and caches. It uses the ignore crate, so .gitignore files, Git excludes, global ignores, and hidden files behave the same as in ripgrep or fd.

Recognized extensions: Python, JavaScript, TypeScript, Go, Rust, Java, Kotlin, Ruby, PHP, C, C++, C#, Swift, Scala, Elixir, Dart, Lua, SQL, Bash, Zig, Haskell, Markdown, YAML, TOML, JSON.

Pass --include-docs to add Markdown, YAML, TOML, JSON, and plain text. Use --extension (repeatable) to add custom file types.

Documentation

License

MIT

Available Tools

15 tools
agent_contextB

Return the versioned SIFS CLI/MCP contract for agents.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It only says 'Return', indicating a read operation, but provides no details about the contract's structure, size, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is concise and front-loaded. It states the purpose without extraneous words, earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description provides the basic purpose but lacks details about the contract's format or how it relates to sibling tools, leaving contextual gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is 100%. Per guidelines, 0 parameters warrants a baseline of 4. The description adds no parameter info, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a 'versioned SIFS CLI/MCP contract for agents', specifying the action and resource. It is specific but does not explicitly differentiate from siblings like agent_doctor or agent_print.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description only states what it does, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

agent_doctorB

Inspect SIFS agent artifact readiness. This is read-only and reports unknown for current-session visibility when it cannot be proven.

ParametersJSON Schema
NameRequiredDescriptionDefault
artifactNoall
targetNoall

TDQS

B3.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool is read-only and reveals a key behavioral trait: it reports 'unknown' when readiness cannot be proven. This adds significant value beyond the bare minimum, though it omits details like rate limits or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two sentences. The first sentence front-loads the primary purpose, and the second adds a key behavioral detail. Every sentence earns its place with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose and a notable behavioral aspect (read-only, unknown reporting), but it lacks explanation of the two enum parameters and the return format. Given no output schema, this is a gap; however, for a relatively simple inspection tool, it is minimally adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 2 parameters with 0% schema description coverage, and the tool description does not explain the meaning of 'artifact' or 'target' parameters. Despite having enums, the description adds no context about parameter semantics, failing to compensate for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Inspect') and resource ('SIFS agent artifact readiness'), clearly indicating the tool's function. It adds nuance by noting it is read-only and reports 'unknown' for current-session visibility, which helps distinguish it from sibling tools like agent_context or index_status, though not explicitly naming alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when checking artifact readiness but provides no explicit guidance on when to use this tool versus alternatives (e.g., agent_context or search). No when-not-to-use or alternative tool names are mentioned, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

agent_printC

Render a SIFS agent skill, instruction snippet, or MCP guidance artifact without writing files.

ParametersJSON Schema
NameRequiredDescriptionDefault
artifactYes
profileNo
sourceNo
targetYes

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It only discloses that no files are written, but does not reveal other critical behaviors like whether it has side effects, requires authentication, or what the output format is. For a rendering tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. It is front-loaded with the core action. However, it sacrifices parameter details for brevity, making it slightly under-informative for the number of parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, 0% parameter coverage, and 4 parameters, the description is too sparse. It fails to explain the purpose of profile and source, or the difference between artifact types. The tool likely returns rendered content, but this is unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no parameter information. The four parameters (artifact, profile, source, target) are not explained. The enums for artifact and target are left to the agent to interpret without any semantic hints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Render' and the specific resources: SIFS agent skill, instruction snippet, or MCP guidance artifact. The phrase 'without writing files' adds a key differentiator. Among siblings, no other tool mentions rendering or printing, so it is distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool compared to alternatives. The description lacks any mention of prerequisites, recommended use cases, or exclusion conditions. The agent must infer usage solely from the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

clear_indexA

Remove the selected source from the in-memory MCP cache. The next search or status call rebuilds or reloads it.

ParametersJSON Schema
NameRequiredDescriptionDefault
profileNoSaved profile to use for source defaults.
sourceNoGit URL or local path. Omit only when the server has a default source.

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the rebuild behavior but does not elaborate on scope (e.g., memory vs disk), side effects, or required permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main action, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is fairly complete for a simple removal tool. It explains the action and the rebuild consequence, though could mention when to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters described in the schema. The description does not add additional meaning beyond 'selected source', so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Remove the selected source from the in-memory MCP cache') and distinguishes from siblings like 'refresh_index' and 'index_status' by specifying removal rather than refresh or status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions the consequence ('next search or status call rebuilds or reloads it') but does not provide explicit guidance on when to use this tool versus alternatives like 'refresh_index' or any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

feedback_createC

Record local feedback about SIFS agent friction.

ParametersJSON Schema
NameRequiredDescriptionDefault
command_contextNo
expectedNoOptional expected file path or location prefix for local eval.
messageYes
queryNoOptional search query for local eval.

TDQS

C2.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, and the description only states 'Record local feedback' without disclosing behavioral traits such as mutation effects, permission requirements, or data persistence. The agent lacks understanding of side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence, which is concise and easy to parse. However, it could benefit from a slightly more structured breakdown of parameters or behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and moderate parameter count, the description lacks essential context about what 'friction' means, how feedback is stored, and how parameters like command_context should be used. It is insufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema includes 4 parameters with 50% coverage (2 have descriptions). The tool description adds no additional parameter meaning, leaving command_context completely undocumented. The description fails to compensate for the schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool records local feedback about SIFS agent friction, specifying the verb and object. It distinguishes from the sibling feedback_list tool by focusing on creation rather than listing, though it could explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions. The description is too minimal to help an agent decide between this and similar tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

feedback_listC

List local SIFS feedback entries.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo

TDQS

C2.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should reveal behavioral traits such as read-only nature, authentication needs, or side effects. It only states 'list,' which implies read-only, but does not confirm or add context like default behavior or access restrictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with no extraneous words. Every character serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description should explain what 'SIFS feedback entries' are, how listing works (e.g., ordering, pagination), and any default behaviors. The current text is too sparse for complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter 'limit' has zero schema description coverage, and the description adds no semantics about its purpose, effect, or constraints (beyond the schema's default and minimum). This fails to compensate for the missing parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list) and resource (local SIFS feedback entries), distinguishing it from siblings like feedback_create. However, it lacks clarity on what constitutes a 'SIFS feedback entry,' which could confuse the agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like feedback_create or search tools. There is no mention of prerequisites, filters, or when to use other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_chunkC

Read the indexed chunk containing a repository-relative file path and one-based line.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesRepository-relative file path exactly as shown in a search result or list_files.
lineYesOne-based line number inside the desired chunk.
profileNoSaved profile to use for source defaults.
sourceNoGit URL or local path. Omit only when the server has a default source.

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so description carries full burden. It states 'Read' implying no side effects, but does not disclose error behavior, permissions, or what happens if the file or line is not indexed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence of 16 words directly states the core function with no redundant information. Perfectly front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks output schema, and description does not explain what the chunk contains or its format. No mention of index status or relationship to sibling tools, leaving gaps for an agent to understand full usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions already defining each input. The tool description adds only a summary of the two required parameters, which does not significantly enhance understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states 'Read the indexed chunk' with specific inputs (file path and line), clearly indicating the tool's purpose. It differentiates from sibling tools like search and list_files by focusing on reading a chunk, but does not explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to use this tool versus alternatives such as search or list_files. No mention of prerequisites like index status or the need to call search first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

index_statusA

Inspect the active index for a local path or Git repository.

Use this to discover the selected source, whether it is cached in memory, how many files and chunks are indexed, which languages are covered, and which tools are available before searching.

ParametersJSON Schema
NameRequiredDescriptionDefault
profileNoSaved profile to use for source defaults.
sourceNoGit URL or local path. Omit only when the server has a default source.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description bears the full burden. It discloses the types of information returned (source, cache status, file/chunk counts, languages, available tools) and implies a read-only operation. However, it does not mention potential error conditions or behavior for missing indices, which would enhance transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. The first sentence states the core function; the second lists what can be discovered and when to use it. Information is front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the key outputs (source, cache, file count, chunk count, languages, tools) without an output schema. It lacks mention of edge cases (e.g., no index, errors), but for an inspection tool, the provided information is sufficient for typical use. Slightly more detail on error behavior would raise this to 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for both parameters. The description adds minimal extra meaning beyond the schema, referencing the source parameter implicitly but not elaborating on format or constraints. Baseline score of 3 is appropriate given high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'inspect' with the resource 'active index', specifying the scope (local path or Git repository). It clearly distinguishes from sibling tools like clear_index, refresh_index, search, and get_chunk, which are mutation or search tools, making the inspection purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states 'Use this to discover ... before searching.', providing clear context for when to use the tool. While it does not explicitly list alternatives, the context implies it is for pre-search inspection, and sibling tool names (e.g., search, get_chunk) further clarify the use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

init_agentB

Create the SIFS Claude agent file in the shared workspace.

ParametersJSON Schema
NameRequiredDescriptionDefault
destinationNoOptional path for the generated agent file. Defaults to .claude/agents/sifs-search.md.
forceNoOverwrite an existing file when true.

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It states 'Create' but does not describe write permissions, what happens if the file exists without the force flag, or any other side effects. The description adds little beyond the schema's parameter descriptions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no superfluous words. Every word adds value, and the structure is optimal for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only two optional parameters and no output schema, the description is moderately complete. It explains the file creation action but lacks context on the 'shared workspace' or what the agent file is used for, leaving some ambiguity about the tool's role in the broader workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description does not add any additional meaning or context to the parameters beyond what is already in the schema, such as clarifying the default path or the effect of force.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the verb 'Create' and clearly identifies the resource as 'the SIFS Claude agent file' in the 'shared workspace', making the tool's purpose clear. However, it does not explicitly differentiate this tool from sibling tools like 'agent_context' or 'agent_print', which could also relate to agents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites or exclusion criteria mentioned. The description simply states what the tool does without context on when it is appropriate to invoke.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_filesB

List repository-relative file paths included in the selected index.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of file paths to return.
profileNoSaved profile to use for source defaults.
sourceNoGit URL or local path. Omit only when the server has a default source.

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry full behavioral transparency. It only states the operation is a listing (implying read-only) but omits details like whether the index is maintained across calls, error behavior if no index is set, or any side effects. Minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is direct and wastes no words. While it could be considered too minimal, it does not include irrelevant details. Front-loads the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has moderate complexity with three optional parameters and no output schema. The description lacks details on what happens when no index is selected, default behavior for omitted parameters, or the format of returned paths. Adequate but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with all three parameters described in the schema. The description adds 'repository-relative' which clarifies the path format but does not enhance parameter meaning beyond schema defaults. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists repository-relative file paths from the selected index. It uses specific verb 'list' and resource 'file paths', distinguishing it from siblings like search, index_status, or clear_index which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an index must be selected) or when not to use it. Sibling names provide some context, but the description itself lacks usage instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

profile_listA

List saved SIFS profiles.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden; it implies a read-only operation ('list') but does not disclose any potential side effects, permissions, or result format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, succinct sentence that front-loads the core purpose without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description adequately states the tool's function; however, it omits any mention of returned fields or ordering.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline applies; the description adds no parameter info but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'list' and the resource 'saved SIFS profiles', distinguishing it from sibling tools like profile_show which likely shows a single profile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives; no exclusions or context provided for appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

profile_showC

Show one saved SIFS profile.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits. It only says 'Show', implying read-only, but does not indicate behavior if profile name is missing or invalid, or confirm no side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise (one sentence) with the verb first. However, it may be too terse, missing opportunity to add context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given simplicity (1 param, no output schema, no annotations), the description should at least mention return behavior or read-only nature. It does not, leaving gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no meaning beyond the schema's 'name' parameter. It does not explain that 'name' identifies the profile. 0% schema coverage means the description must compensate, but it fails to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Show') and resource ('one saved SIFS profile'), distinguishing it from sibling 'profile_list' which lists profiles. The verb and resource are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like profile_list. Does not specify prerequisites (e.g., profile must exist) or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

refresh_indexB

Rebuild the selected index and replace the in-memory MCP cache. Use after files change in a long-lived session.

ParametersJSON Schema
NameRequiredDescriptionDefault
profileNoSaved profile to use for source defaults.
sourceNoGit URL or local path. Omit only when the server has a default source.

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states that the tool rebuilds the index and replaces the cache, implying a destructive modification, but does not disclose side effects, authorization needs, rate limits, or whether the operation is synchronous. This leaves significant gaps in behavioral understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the action and purpose. Every word adds value, with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two parameters and no output schema, the description covers the action and primary use case. However, it omits details like what 'selected index' means, whether the operation is synchronous, and what the return state (e.g., success indication) might be.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters described ('Saved profile to use for source defaults' and 'Git URL or local path'), so baseline is 3. The description adds no additional meaning beyond the schema, not explaining how the parameters affect the rebuild process.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Rebuild the selected index') and resource, and adds context about replacing the cache. It distinguishes from siblings like clear_index by implying a rebuild rather than a clear, but does not explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a specific usage scenario ('Use after files change in a long-lived session'), providing clear context. However, it does not mention when not to use it or suggest alternatives among siblings (e.g., clear_index).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.3.3
    • Changedfeedback_create2 fields changed
      • addedInput schema / properties / expected
        Added value: +{
+  "description": "Optional expected file path or location prefix for local eval.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
      • addedInput schema / properties / query
        Added value: +{
+  "description": "Optional search query for local eval.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • Changedsearch1 field changed
      • addedInput schema / properties / explain
        Added value: +{
+  "default": false,
+  "description": "Include per-result ranking evidence such as BM25 rank, semantic rank, alpha, and boosted score.",
+  "type": "boolean"
+}
  2. 15 tool updatesv0.1.0
    • First observedagent_context
    • First observedagent_doctor
    • First observedagent_print
    • First observedclear_index
    • First observedfeedback_create
    • First observedfeedback_list
    • First observedfind_related
    • First observedget_chunk
    • First observedindex_status
    • First observedinit_agent
    • First observedlist_files
    • First observedprofile_list
    • First observedprofile_show
    • First observedrefresh_index
    • First observedsearch
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool targets a clearly distinct purpose: agent_* for agent interactions, index_* and search for indexing, feedback_* for feedback, profile_* for profiles, and specific tools like clear_index vs refresh_index have non-overlapping roles.

Naming Consistency4/5

Naming is predominantly verb_noun in snake_case (e.g., clear_index, get_chunk), but minor inconsistencies exist like profile_list (should be list_profiles) and search (bare verb). Overall pattern is clear and consistent enough.

Tool Count5/5

15 tools is well within the ideal range (3-15). Each tool serves a specific function without redundancy, fitting the server's scope of code indexing and agent management.

Completeness4/5

The tool set covers core indexing lifecycle (search, index_status, clear/refresh_index, list_files, get_chunk, find_related) and agent initialization/inspection. Missing explicit source addition or profile editing, but the primary workflow is fully supported.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • codeix

    montanetech
    A
    license
    Not graded
    quality
    D
    maintenance
    Fast semantic code search for AI agents — find symbols, references, and callers across any codebase.
    9
    Apache 2.0

  • ken

    townsendmerino
    A
    license
    Not graded
    quality
    A
    maintenance
    Fast hybrid code search for agents. Pure Go, single static binary, BM25 lexical + Model2Vec semantic embeddings + RRF fusion + a code-aware reranker, with the retrieval algorithm ported verbatim from semble
    30
    MIT

  • codebase-analyser

    akshith120
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents and IDEs to ingest and search code repositories using hybrid retrieval (dense + sparse) with exact line-level citations for precise code analysis.
    1
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tristanmanchester/sifs'

If you have feedback or need assistance with the MCP directory API, please join our Discord server