de en es ja ko ru zh

scry

Name: scry
Author: prmichaelsen

by prmichaelsen

Overview Schema Related Servers Score Discussions

Python

Local

scry

Scry Marker Specification — в этом проекте реализован формальный общий контракт scry-маркеров, определённый здесь

Обзор см. на scryspec.com.

MCP-сервер SQL-кэша с индексацией по маркерам. Scry индексирует маркеры @scry.*, находящиеся в файлах, в базу данных SQLite, которую агенты запрашивают через SQL только для чтения, предоставляя структурированные знания о проекте без применения LLM-рассуждений.

PyPI Python

Установка

uv pip install scry-mcp
# or:
pip install scry-mcp

Дистрибутив на PyPI называется scry-mcp (простое имя scry на PyPI уже занято). Имя импорта и устанавливаемая консольная команда — оба scry.

Related MCP server: Context Bunker MCP

Быстрый старт

# In your project root:
scry init                # scaffolds agent/ + driver dirs, updates .gitignore

Затем добавьте его в конфигурацию MCP-клиента:

{
  "mcpServers": {
    "scry": {
      "command": "scry"
    }
  }
}

MCP-клиент наследует cwd из места своего запуска, и scry поднимается оттуда вверх в поисках каталога agent/ — поэтому одна и та же конфигурация работает для любого проекта. Просто scry (без подкоманды) запускает MCP-сервер через stdio — именно его вызывает Claude. Остальные подкоманды:

Команда	Назначение
`scry`	Запуск MCP-сервера (по умолчанию).
`scry init [path]`	Создаёт `.scry/{data,runtime,scripts}/` и `.scry/.gitignore`. Идемпотентно — безопасно запускать внутри проекта ACP.
`scry surface [--force]`	Разовый пакетный переиндекс без запуска сервера.
`scry version`	Выводит версию пакета.

Сервер поднимается вверх от cwd, пока не найдёт каталог .scry/; он становится корнем проекта (если ничего не найдено, используется cwd). Кэш находится в .scry/data/project.db и игнорируется git.

Режим маркеров

marker_mode в .scry/config.toml управляет обработкой маркеров:

Режим	Поведение
`inline` (по умолчанию)	Маркеры находятся непосредственно в исходных файлах.
`sidecar`	Маркеры находятся в sidecar-файлах `agent/scry/`, сохраняя исходники чистыми; `extras.source` указывает на описываемый файл.
`off`	Маркеры не читаются и не записываются. Регистрируются только `scry_grep`, `scry_surface` и `scry_db_health` — scry превращается в быстрый полнотекстовый поиск по файлам. Направьте его на любой проект (создайте `.scry/config.toml` с `marker_mode = "off"`); внедрение маркеров не требуется.

Маркеры

Scry распознаёт три вида маркеров согласно scry-spec v1.2.0: @scry.entry и @scry.anchor — блочные маркеры с YAML-телом между открывающим и закрывающим токенами; @scry.bind — строчный или блочный маркер, объявляющий перекрёстные ссылки.

<!-- @scry.entry
id: design.auth-flow~a1b2c3d4
kind: design
summary: >
  JWT auth middleware, token validation, refresh flow
status: active
weight: 0.85
tags: ["scope:auth", "topic:security"]
rationale: >
  Missing this causes auth bypass bugs
applies: modifying auth, adding protected endpoints
seeded_questions:
  - How does token refresh work?
extras:
  owner: auth-team
  jira: AUTH-1247
  reviewed_at: 2026-05-19
@scry.entry.end -->

<!-- @scry.anchor auth-check~f1e2d3c4
description: JWT validation point for protected routes
@scry.anchor.end -->

# @scry.bind validate-jwt~a1b2c3d4 spec.auth~xyz89012#FR3
# @scry.bind jwt-expiry~b2c3d4e5 spec.auth~xyz89012#UT1

Блочные маркеры можно встраивать в любой стиль комментариев языка-хоста (HTML, Python, JS, JSDoc, Rust, чистый YAML). Префиксы комментариев определяются автоматически по YAML-телу — настройка для каждого языка не требуется.

Поле `extras` (scry-spec v1.2.0, FR4.B)

@scry.entry принимает необязательное поле extras: одноуровневую карту произвольных строковых ключей со скалярными значениями (string | number | boolean | null). Используйте его, чтобы прикреплять структурированные метаданные, не входящие в основную схему: владельца, идентификаторы тикетов, учёт затрат, отметки времени ревью — всё, что вы захотите запрашивать позже.

Ограничения:

Только один уровень — значения должны быть скалярными; вложенные карты и списки являются диагностическими нарушениями.
Сериализованный размер ≤ 4 КБ (ограничение уровня SHOULD по спецификации).
Чрезмерно большие полезные нагрузки ДОЛЖНЫ полностью проходить цикл без изменений — это ограничение диагностическое, а не порог усечения. Пустой extras: {} вызывает предупреждение уровня SHOULD.

Индексируется и доступно для запросов начиная с v0.17.0. Поле extras сериализуется в компактный JSON-текст в столбце scry__doc.extras (NULL при отсутствии) и доступно для scry_sql через SQLite JSON1. Документ с

extras:
  cost_usd: 12.5
  tier: gold
  active: true

отвечает на запросы вроде:

SELECT id,
       json_extract(extras, '$.cost_usd') AS cost,
       json_extract(extras, '$.tier')     AS tier
FROM scry__doc
WHERE kind = 'deliverable'
  AND json_extract(extras, '$.active') = 1
ORDER BY cost DESC;

Преобразование туда-обратно побайтово эквивалентно для YAML-карты скаляров: целые числа, числа с плавающей точкой, строки, логические значения и null сохраняются.

Значения `kind` для `@scry.entry` (базовая версия v1.2.0)

kind	назначение
`design`	документация по архитектуре и дизайну
`pattern`	канонические рецепты, устоявшиеся паттерны
`spec`	требования и спецификации
`lesson`	постмортемы, «я попробовал X, и это не сработало, потому что Y»
`internal`	особенности сервисов, недокументированное поведение
`task`	отдельные рабочие задачи
`milestone`	маркеры фаз, критерии завершения
`goal`	цель, достигаемая набором результатов через типизированную связь `satisfies` (v1.2.0)
`report`	отчёты о wake/сессиях
`audit`	аудиты безопасности или целостности
`research`	исследовательские заметки
`code`	документация по конкретной реализации

MCP-инструменты

Инструмент	Назначение
`scry_sql(query)`	Шлюз SQL только для чтения. Отклоняет ключевые слова-мутаторы. Возвращает JSON `{results, row_count}`.
`scry_grep(query, kind?, status?, path_glob?, limit?)`	Полнотекстовый поиск по индексированным телам файлов (`scry__file_fts`). Дополняет `scry_sql`, когда нужно искать в тексте, а не только в полях маркеров.
`scry_mint(kind, prefix)`	Генерирует ID без коллизий и схему маркера.
`scry_mint_with_check(kind, prefix)`	Предпочтительный генератор — как `scry_mint`, плюс предупреждения о коллизиях уровней tier-1/tier-2.
`scry_surface(force=false, path?)`	Пакетный переиндекс с диска. `force=true` жёстко удаляет записи, исходный файл которых больше не существует; `path` ограничивает обход одним файлом или подкаталогом.
`scry_sink(then_surface=false)`	Возвращает индекс в состояние «только диск» — атомарно усекает все таблицы индекса (схема сохраняется, маркеры на диске не затрагиваются). Требует подтверждения пользователя; `then_surface=true` перестраивает индекс одним вызовом.
`scry_scrub()`	Создаёт git-ветку `<branch>--clean`, в которой из всех не-agent файлов удалены маркеры `@scry.*`.
`scry_script(action, script?, params?)`	Находит и запускает скрипты валидации из `src/scry/scripts/` и `.scry/scripts/`.
`scry_db_health()`	Проверяет БД проекта и сообщает `status` ∈ {`ok`, `corrupt`, `locked`}, результат `integrity_check` и количество строк в `scry__doc`. Для циклов автоматического восстановления substrate, которым нужно отличать повреждение от временной конкуренции за блокировку записи WAL.

Схема базы данных

Основные таблицы на основе маркеров:

Table	Holds
`scry__doc`	Одна строка на маркер `@scry.entry` — id, kind, status, weight, summary, rationale, applies, current_path, ephemeral, missing_since, content_hash, extras, timestamps.
`scry__doc_tag`	Теги как таблица связей — `(doc_id, tag)`.
`scry__doc_seeded_question`	Созданные вопросы для документа — `(doc_id, ordinal, question)`.
`scry__anchor`	Одна строка на маркер `@scry.anchor` — id, doc_id, description, content_hash, timestamps.
`scry__anchor_seeded_question`	Созданные вопросы для якоря — `(anchor_id, ordinal, question)`.
`scry__bind`	Одна строка на маркер `@scry.bind` — source_doc_id, source_local_id, target_id, target_fragment, comment, content_hash, timestamps.
`scry__rel`	Типизированные рёбра между документами — `(from_id, to_id, predicate, fragment)`. Предикаты: `depends_on`, `implements`, `supersedes`. Обнаружение циклов применяется к `depends_on`.
`scry__file`	Универсальный индекс содержимого файлов — `(path, doc_id, body, content_hash, last_modified)`. Заполняется во время `scry_surface`.
`scry__warning`	Предупреждения в стиле lint, выдаваемые парсером/индексатором — id, kind, marker_kind, marker_id, file_path, message, detected_at.
`migration`	Журнал миграций схемы.

FTS5 virtual tables (trigger-maintained, queryable via FTS MATCH):

FTS table	Searches
`scry__doc_fts`	Сводка документа, rationale, applies, current_path.
`scry__doc_tag_fts`	Строки тегов.
`scry__doc_seeded_question_fts`	Созданные вопросы документа.
`scry__anchor_fts`	Описания якорей.
`scry__bind_fts`	Bind source_local_id, target_id, comment.
`scry__file_fts`	Полные тела файлов. Предпочитайте инструмент `scry_grep` запросам, написанным вручную.

Кэш полностью восстанавливается с диска с помощью scry_surface. База данных находится в .gitignore; после git pull агенты вызывают scry_surface для пересборки.

Watcher

Фоновый поток работает вместе с MCP-сервером, наблюдая за деревом проекта с окном дебаунса 150 мс. Файл блокировки в .scry/runtime/lock выполняет выбор первичного экземпляра на основе PID, чтобы несколько сессий не конкурировали за записи. Первичный экземпляр выполняет холодное сканирование при запуске; вторичные наблюдают и ждут.

При удалении файла: документы мягко удаляются (устанавливается missing_since); якоря и связи удаляются жёстко.

Tests

uv pip install -e ".[dev]"
pytest

159 тестов покрывают парсер, SQL-шлюз, mint, surface, внутренности watcher, обнаружение скриптов, обнаружение циклов в связях, индексацию extras для FR4.B + возможность запросов через JSON1, обратное заполнение миграций схемы и поведение повторных попыток при параллельных подключениях.

License

MIT — см. LICENSE.

Available Tools

9 tools

scry_db_healthA

Probe the scry project database and report health.

Designed for substrate code (e.g. reflection's wake.py auto-restore loop) that needs to distinguish actual corruption from transient WAL write-lock contention. The same scry-mcp connection primitives are used as for every other tool — long busy_timeout, WAL journal mode, retry semantics — so a healthy-but-busy DB will not be reported as corrupt.

Returns JSON with these fields:

status "ok" | "corrupt" | "locked" integrity result of PRAGMA integrity_check (string), or null when the probe could not run (e.g. status=locked) doc_count integer row count of scry__doc, or null when the table does not exist yet (fresh / unmigrated DB) doc_count_error populated when doc_count is null and the count query failed for a known-benign reason (table missing); null otherwise db_path absolute path to the project.db file probed error string explanation when status != "ok"; null otherwise

Status semantics for substrate decisions:

status="ok" DB is healthy. Do not quarantine. status="locked" DB is healthy but contended. Do NOT quarantine; retry the probe on the next wake. Substrate code that conflates this with corruption causes the Group-C cascade described in the May 2026 diagnostic. status="corrupt" DB failed PRAGMA integrity_check or could not be opened as a SQLite database at all. Safe to initiate auto-restore.

A status="ok" with doc_count=null and doc_count_error="no such table: scry__doc" is a fresh-and-unmigrated DB. Substrate should run migrations (or call scry_surface) rather than quarantine.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description fully bears the burden of disclosing behavior. It details the tool's retry semantics, WAL journal mode, busy_timeout, and how it handles different database states. It also explains the output fields and their meanings.

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 longer than average but well-structured with sections for output fields and status semantics. It front-loads the purpose in the first sentence. While concise, the length is justified by the need for detailed behavioral guidance.

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

Completeness5/5

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

Given no parameters and an output schema exists, the description covers all necessary context: purpose, usage, behavioral details, output semantics, and decision rules for substrate code. It is fully complete for a health-check tool.

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?

The tool has zero parameters, so the description cannot add parameter semantics beyond the schema. Baseline for 0 params is 4, and the description provides extensive context about the tool's operation and output, which compensates for the lack of parameters.

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 explicitly states 'Probe the scry project database and report health', with a clear verb and resource. It is distinct from siblings like scry_grep or scry_mint, 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 Guidelines5/5

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

The description provides explicit guidance on when to use this tool, including distinguishing corruption from transient WAL lock contention, and interpreting status values ('ok', 'locked', 'corrupt') for substrate decisions. It also explains what to do when doc_count is null (fresh DB).

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

scry_grepA

Full-text search over all indexed file bodies (scry__file_fts).

Complements scry_sql: use this when you want broad full-text search across file content, not just curated marker fields.

Returns one hit per file (highest BM25-ranked match).

Args: query: FTS5 query string — plain words, phrases ("foo bar"), boolean (foo AND bar, foo OR bar, NOT foo). Accepts standard FTS5 syntax. kind: Optional: filter to files whose associated doc has this kind (e.g. 'design', 'lesson', 'pattern'). Files without a doc marker are excluded when this filter is set. status: Optional: filter by doc status (e.g. 'active', 'draft'). Files without a doc marker are excluded when set. path_glob: Optional: GLOB pattern on file path, e.g. 'agent/design/' or '.py'. Applied before FTS. limit: Max number of results to return (default 20).

Returns JSON: { "hits": [ { "path": "agent/design/...", "doc_id": "design.foo~abcd1234" | null, "snippet": "...text with matches highlighted...", "score": 12.4, "match_count": 3 } ], "total_matches": 47, "query": "...", "filters_applied": { "kind": null, "status": null, "path_glob": null } }

Tips:

Combine with scry_sql: get doc IDs from scry_grep, then JOIN to scry__doc_tag or scry__doc for richer metadata.
Use path_glob to scope to a subtree: 'agent/design/*'
scry__file is populated during scry_surface; call that first if results are empty on a fresh DB.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No
`limit`	No
`query`	Yes
`status`	No
`path_glob`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

Describes return behavior (one hit per file, BM25-ranked), return JSON structure, and filter behavior. Lacks explicit statement about read-only nature, but overall transparent.

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?

Well-structured with intro, args, return format, and tips. Front-loaded purpose, every sentence adds value, no fluff.

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

Completeness5/5

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

Covers purpose, usage, parameters (all 5 detailed), return JSON, and tips. No gaps given complexity and presence of output schema described.

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

Parameters5/5

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

Each parameter is thoroughly explained with syntax examples (query FTS5, kind filter, path_glob pattern, etc.), adding significant value beyond the bare schema.

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?

Clearly states 'Full-text search over all indexed file bodies' with verb+resource. Distinguishes from sibling scry_sql by noting broader full-text search vs curated marker fields.

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

Usage Guidelines5/5

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

Explicitly says 'use this when you want broad full-text search across file content, not just curated marker fields.' Provides tips for combining with scry_sql and prerequisite scry_surface call.

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

scry_mintA

REQUIRED before writing any @scry.* marker. Generates a collision-free ID and returns the marker schema with per-field instructions. Follow the returned instructions exactly when filling fields.

Also performs collision detection and returns warnings alongside the ID:

tier1_collisions — markers with the SAME prefix already in the DB. If any tier-1 hit is the same logical concept, ABANDON the new ID and reference the existing marker instead — stranded IDs pollute scry.

tier2_neighbors — markers in the same kind+first-segment family (informational; may reveal related prior work to link against).

Args: kind: "entry", "anchor", or "bind" prefix: Human-readable prefix. entry: MUST contain a dot (e.g. "design.auth-flow", "task.fix-bug") anchor/bind: MUST NOT contain dots (e.g. "auth-check", "validate-jwt")

Returns JSON with: id, schema (marker_open/close + per-field instructions), and optionally tier1_collisions + tier2_neighbors when they exist.

Field quality matters (FR4.A authoring guidance): summary — prose sentences + 'Also:' keyword cluster at the end. "JWT auth middleware, validates bearer tokens. Also: JWT, bearer-token, auth-guard, refresh-flow" tags — carry both classifier and bare-keyword forms. ["topic:auth", "auth", "scope:runtime", "runtime"] rationale — Why this artifact exists: the problem it solves or the role it fills. Not why you would search for it, not a findability claim, not its importance. Lesson: "prevents re-introducing the auth bypass fixed in PR 412". Design: "centralizes token checks so endpoints do not each re-implement them". Track wake: "owns the reflect-mcp build-to-PyPI path". Bad: "invisible to scry without this", "this is important". applies — verb-shaped triggers (actions, not topics). "modifying auth, adding protected endpoints" not "when working on auth" seeded_questions — include both full questions AND fragment queries. ["What is the JWT refresh flow?", "JWT refresh token implementation"]

ParametersJSON Schema

Name	Required	Description	Default
`kind`	Yes
`prefix`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description must disclose behavior. It explains collision detection and that the tool returns an ID and schema. However, it is unclear whether the tool modifies state (e.g., stores the marker) or if it is read-only. No mention of side effects, permissions, or destructive nature.

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

Conciseness3/5

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

The description is detailed but lengthy, including extensive field quality guidance (summary, tags, rationale, etc.) that could be separated. It is structured with sections (Args, Returns, etc.), which helps, but efficiency is moderate.

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 only 2 parameters and an output schema described in text, the description covers purpose, parameter semantics, return format, and usage constraints. Missing error handling and sibling differentiation, but otherwise complete for a minting tool.

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

Parameters5/5

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

Schema coverage is 0%, so the description fully explains both parameters. 'kind' lists exact allowed values ('entry', 'anchor', 'bind') with examples. 'prefix' gives formatting rules per kind (dot required for entry, forbidden for anchor/bind). This adds critical meaning beyond the schema's bare type declaration.

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 it generates a collision-free ID and returns marker schema, and is required before writing any @scry.* marker. It distinguishes its role from siblings like scry_mint_with_check, though not explicitly contrasting them.

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 starts with 'REQUIRED before writing any @scry.* marker,' giving explicit when-to-use guidance. It also provides conditional behavior for tier1 collisions (abandon ID if same logical concept). However, it does not compare against scry_mint_with_check or state when not to use this tool.

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

scry_mint_with_checkA

PREFERRED over raw scry_mint. Generates a collision-free scry marker ID (same as scry_mint) and augments the response with existing-marker warnings:

Tier 1 — exact-prefix collision: markers with the same prefix already in scry__doc. If any tier-1 hit is the same logical concept, ABANDON the new ID and reference the existing marker instead — stranded IDs pollute scry.

Tier 2 — family-slug neighbors: related markers in the same slug family (informational; may reveal related prior work to link against).

Args: kind: 'entry', 'anchor', or 'bind' prefix: Human-readable prefix. entry MUST contain a dot (e.g. 'design.auth-flow', 'task.fix-bug'). anchor/bind must NOT contain dots (e.g. 'auth-check', 'validate-jwt').

Returns: id, marker schema (same as scry_mint), plus tier-1/tier-2 collision info.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	Yes
`prefix`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

No annotations, but description fully discloses collision detection tiers (exact-prefix and family-slug neighbors), the abandonment logic, and the consequence of stranded IDs polluting scry. This is comprehensive behavioral transparency.

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?

Description is well-structured with sections and bullet points, but contains some redundancy (e.g., 'stranded IDs pollute scry' could be integrated). Still efficient and easy to scan.

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

Completeness5/5

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

Given output schema exists, description explains return structure (id, marker schema, tier-1/tier-2 collision info). Input parameters fully described. Sister tool context is provided. No gaps.

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

Parameters5/5

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

Schema has 2 params with 0% coverage (no param descriptions in schema). Description adds significant meaning: explains kind values ('entry', 'anchor', 'bind') and prefix constraints (entry must contain dot, others must not). This compensates fully for schema lack.

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?

Description clearly states the tool generates a collision-free scry marker ID and augments with warnings. It explicitly distinguishes from sibling scry_mint by stating 'PREFERRED over raw scry_mint' and describing additional collision detection.

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

Usage Guidelines5/5

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

Explicitly says 'PREFERRED over raw scry_mint', telling when to use this tool vs sibling. Also provides guidance on when to abandon the new ID (if tier-1 hit is same logical concept) to avoid stranded IDs.

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

scry_scriptA

Run validation or transformation scripts with DB access.

Actions: list — discover available scripts (bundled + project-local) run — execute a named script

Args: action: "list" or "run" script: script name (required for action="run") params: arbitrary params passed to the script (optional)

Scripts have read-write DB access. They return structured JSON.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`params`	No
`script`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Without annotations, the description carries full burden. It explicitly states that scripts have 'read-write DB access' and 'return structured JSON', which are critical behavioral traits. No contradictions or omissions beyond what is reasonable for a script runner.

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—three short paragraphs. It front-loads the purpose, then lists actions with bullet-style clarity. Every sentence is informative and necessary.

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

Completeness5/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, actions, parameters, DB access rights, and return format. With an output schema present, it does not need to detail return values further. No gaps remain for typical agent invocation.

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

Parameters5/5

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

Schema coverage is 0%, so description must add meaning. It specifies that action can be 'list' or 'run', script is required when action='run', and params are optional arbitrary inputs. This fully explains the parameters beyond the schema's bare types.

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 verb ('Run validation or transformation scripts') and resource ('with DB access'). It distinguishes between two actions (list and run), which differentiates it from sibling tools that handle other responsibilities like raw SQL or data checks.

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 provides clear guidance on when to use 'list' vs 'run' and notes constraints (script required for run). However, it does not explicitly exclude use cases or reference sibling tools as alternatives, which would improve clarity.

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

scry_scrubA

Create a clean PR branch with all @scry.* markers stripped.

By default, files inside agent/** and any AGENT.md are excluded from scrubbing — their markers are left intact. Only tracked files outside the agent workspace are cleaned. This matches the common workflow: agent/ is gitignored (or excluded via .git/info/exclude), so only the tracked source files need clean markers for PR submission.

Set include_agent=true to restore the prior behavior: scrub everything and remove the agent/ directory entirely.

Creates {branch}--clean from current HEAD. Does not stage or commit — leaves unstaged changes for the user.

Fails if on main/master or if working tree is dirty.

ParametersJSON Schema

Name	Required	Description	Default
`include_agent`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

No annotations provided, so description carries full burden. Discloses that tool does not stage/commit, leaves unstaged changes, and fails under specific conditions. This is comprehensive behavioral information.

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?

Description is front-loaded with main purpose and each sentence adds value. Slightly verbose but still efficient. Could be tightened without losing information.

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

Completeness5/5

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

Covers all essential aspects: default vs. alternative behavior, failure conditions, what the tool does and doesn't do. With output schema present, no need to describe return values. Complete for a tool with one parameter.

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

Parameters5/5

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

Only parameter is include_agent. The description explains its effect ('restore prior behavior: scrub everything and remove the agent/ directory entirely'), adding meaning beyond the input schema (boolean, default false). With 0% schema description coverage, this fully compensates.

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?

Clearly states verb+resource: 'Create a clean PR branch with all @scry.* markers stripped.' Distinct from siblings like scry_mint (create something else), scry_grep (search), etc.

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

Usage Guidelines5/5

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

Explicitly describes default behavior (excludes agent/** and AGENT.md), when to use include_agent=true, and failure conditions (main/master branch or dirty working tree). Provides clear context for use.

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

scry_sinkA

Lower the index back to disk-only state. The DB forgets; the disk remembers.

Truncates all scry index tables (scry__doc, scry__anchor, scry__bind, scry__rel, scry__file, scry__warning, and join tables) in a single atomic transaction. Schema is preserved; FTS tables update via existing triggers. Disk markers are never modified.

Requires protocol-level user confirmation via MCP elicitation before executing — the operation will not proceed if the confirmation is declined, cancelled, or unavailable.

Args: then_surface: If True, immediately runs scry_surface after the sink to rebuild the index from disk markers in a single call. Equivalent to "reset + reindex."

Returns JSON with pre-deletion counts and operation result.

ParametersJSON Schema

Name	Required	Description	Default
`then_surface`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries full burden and excels: it details atomicity, schema preservation, FTS trigger behavior, that disk markers are untouched, and the mandatory user confirmation. These go well beyond basic read/write tagging.

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 well-structured: an evocative first line, clear technical details, a notable requirement (confirmation), parameter explanation, and return value. Every sentence serves a purpose with no redundancy.

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

Completeness5/5

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

Given the tool's complexity, the description covers purpose, tables affected, transactional behavior, side effects, parameter, and return format. An output schema exists to further detail the return structure, making this entirely sufficient.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate. It does: the sole parameter `then_surface` is explained in detail, including its effect and equivalent operation ('reset + reindex'). This adds essential meaning beyond the schema's default value.

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: 'Lower the index back to disk-only state' and 'Truncates all scry index tables'. It uses specific verbs and resources, and distinguishes itself from the sibling `scry_surface` by offering the `then_surface` parameter to combine reset and rebuild.

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 implies when to use (to reset the index while preserving disk markers) and mentions the need for user confirmation. It does not explicitly compare to other siblings like `scry_scrub` or `scry_db_health`, but the context is clear enough for an agent to decide.

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

scry_sqlA

Execute a read-only SQL query against the scry project database. Use this to discover project state, search docs, check coverage, inspect anchors.

Supports SELECT and WITH (CTE) queries only. All mutator keywords (INSERT, UPDATE, DELETE, DROP, etc.) are blocked.

Key tables: scry__doc — knowledge graph entries (@scry.entry markers) columns: id, kind, status, weight, summary, rationale, applies, current_path, ephemeral, missing_since, content_hash, extras (JSON1; NULL when absent), created_at, updated_at extras: single-depth scalar map per scry-spec FR4.B (v1.1.0+). Query with JSON1, e.g. SELECT id, json_extract(extras, '$.cost_usd') AS cost FROM scry__doc WHERE kind = 'deliverable' ORDER BY cost DESC scry__doc_tag — tags as a join table: doc_id, tag scry__doc_seeded_question — seeded questions: doc_id, ordinal, question scry__anchor — named code location bookmarks: id, doc_id, description, content_hash, created_at, updated_at scry__anchor_seeded_question — anchor seeded questions: anchor_id, ordinal, question scry__bind — binding markers (@scry.bind): id, source_doc_id, source_local_id, target_id, target_fragment, comment, content_hash, created_at, updated_at scry__rel — typed edges between docs: from_id, to_id, predicate (depends_on|implements|supersedes|satisfies), fragment scry__file — universal file body index: path, doc_id, body, content_hash, last_modified scry__bind_fts — full-text search over bindings (source_local_id, target_id, comment) scry__warning — lint-style warnings: id, kind, marker_kind, marker_id, file_path, message, detected_at (kinds: misplaced_doc, depends_on_cycle) scry__doc_fts — full-text search over docs (id, summary, rationale, applies, current_path) scry__doc_tag_fts — full-text search over tags (tag, doc_id UNINDEXED) scry__doc_seeded_question_fts — full-text search over seeded questions (question, doc_id UNINDEXED) scry__anchor_fts — full-text search over anchors (id, description) scry__file_fts — full-text search over file bodies (path, body); prefer scry_grep tool

Returns JSON: {"results": [...], "row_count": N}

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description fully discloses read-only behavior, lists blocked keywords, and details the return format (JSON with results and row_count). It covers all behavioral traits an agent needs to know, including safety and output structure.

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 front-loaded with the core purpose and guidelines, followed by a well-organized table listing. Every sentence adds necessary context (constraints, table schemas, return format) without wasted words, achieving both conciseness and completeness.

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

Completeness5/5

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

Given the complexity of a SQL tool with many tables, the description is highly complete: it covers all tables, columns, constraints, supported queries, return format, and even references an alternative tool. The output schema exists, but the description adds sufficient detail for safe usage.

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

Parameters5/5

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

Although the input schema has 0% coverage and no parameter description, the description extensively compensates by listing available tables, columns, and query examples. This provides complete semantic context for the single 'query' parameter, adding immense meaning beyond the schema's simple type string.

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 executes read-only SQL queries against the scry database, specifying supported query types (SELECT and WITH) and explicitly blocking mutations. It distinguishes from siblings by mentioning scry_grep for file body searches, showing clear resource and scope.

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 explicitly lists use cases (discover state, search docs, check coverage, inspect anchors) and specifies supported query types while noting that mutators are blocked. It references an alternative tool (scry_grep) but does not explicitly state when not to use this tool beyond mutation prohibition.

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

scry_surfaceA

Rebuild the DB from disk markers. Use after git pull, bulk file moves, or if query results seem stale. The file watcher handles live indexing — only call this for full re-scans.

Walks all project files, parses @scry.* markers, upserts to DB. Idempotent. Uses content-hash dedup.

Args: force: If true, hard-deletes records whose files no longer exist. If false (default), sets missing_since and warns. path: Optional scope, relative to project root. None (default) — full corpus walk. Current behavior, unchanged. — re-index exactly that one file. — re-index every file under that directory, recursively. If path does not exist on disk, returns a clear error. Scoped reconciliation: flagged_missing, misplaced_doc warnings, and force-deletes are all scoped to the path — docs outside the scope are never flagged as missing.

Returns JSON with counts per marker type, any warnings, and a scope field echoing the path argument (null for a full walk).

ParametersJSON Schema

Name	Required	Description	Default
`path`	No
`force`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Describes idempotency, content-hash dedup, behavior of force parameter (hard-delete vs missing_since), path scoping and reconciliation. No annotations provided, but description fully covers behavioral traits.

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?

Well-structured with summary, usage, behavior, and parameter details. Slightly lengthy but justified by parameter complexity. Front-loaded with purpose.

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

Completeness5/5

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

Covers all aspects: purpose, usage, behavior, parameter details, return value. No missing context despite no annotations or output schema details.

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

Parameters5/5

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

Schema coverage is 0%, but description provides detailed explanations for both 'force' and 'path' parameters, including defaults, edge cases (e.g., path not existing returns error, scoped reconciliation). Adds significant meaning beyond bare schema.

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?

Description clearly states 'Rebuild the DB from disk markers' and specifies use cases (after git pull, bulk moves, stale results). Contrasts with live file watcher, distinguishing from siblings like scry_mint and scry_scrub.

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

Usage Guidelines5/5

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

Explicitly states when to use (after git pull, bulk moves, stale results) and when not to (file watcher handles live indexing). Provides clear advice for agent decision-making.

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.

9 tool updatesv0.19.0Jul 12, 2026
- First observedscry_db_health
- First observedscry_grep
- First observedscry_mint
- First observedscry_mint_with_check
- First observedscry_script
- First observedscry_scrub
- First observedscry_sink
- First observedscry_sql
- First observedscry_surface

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation3/5

The tools are mostly distinct, but scry_mint and scry_mint_with_check have overlapping functionality—both generate IDs and report collisions, with the latter described as 'preferred'. This could confuse an agent about which to use. Other tools like scry_grep and scry_sql are complementary and well-differentiated.

Naming Consistency4/5

All tools consistently use the 'scry_' prefix, and most follow a verb or verb_noun pattern (e.g., scry_grep, scry_scrub). However, scry_mint_with_check breaks the pattern with a prepositional suffix, and scry_db_health is a noun_noun form. Overall, naming is readable and predictable with minor inconsistencies.

Tool Count5/5

With 9 tools, the server provides a well-scoped interface for managing scry markers and the database. Each tool serves a clear purpose without unnecessary overlap or excessive granularity. The count is appropriate for the domain.

Completeness4/5

The tool surface covers core workflows: marker creation (scry_mint, scry_mint_with_check), search (scry_grep, scry_sql), database rebuild (scry_surface), reset (scry_sink), cleanup (scry_scrub), health checks (scry_db_health), and scripting (scry_script). Minor gaps exist, such as no dedicated tool for updating or deleting markers directly, but these are manageable via scry_sql and file operations.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
H-Index A
ai.xr-utilities
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Search Documentation Access
2

Related MCP Servers

Hoard
Knowledge & Memory RAG Systems Agent Orchestration
thrr87
A
license
Not graded
quality
D
maintenance
Local MCP server for indexing personal knowledge into SQLite with hybrid search, chunk-level citations, memory tools, and agent orchestration.
Updated 7 months ago (2026-02-07 12:52 UTC)
4
MIT
Context Bunker MCP
Code Analysis Developer Tools
tonghaoch
A
license
Not graded
quality
D
maintenance
An MCP server that indexes your codebase using tree-sitter AST parsing and gives AI tools instant access to structural intelligence like dependency graphs, call trees, and dead code detection from a local SQLite database.
Updated 6 months ago (2026-03-03 02:28 UTC)
MIT
MCPSaver
Knowledge & Memory Search Developer Tools
cpntodd
A
license
Not graded
quality
B
maintenance
Local MCP server for persistent, searchable agent memory using SQLite FTS5, replacing flat MEMORY.md files with efficient full-text search and workspace context caching.
Updated a month ago (2026-07-27 07:23 UTC)
GPL 3.0
Semdex
Code Analysis RAG Systems
raghavwahi
A
license
Not graded
quality
C
maintenance
A local MCP server that parses codebases into semantic chunks, indexes them in SQLite with vector embeddings, and exposes MCP tools for LLM agents to query.
Updated a month ago (2026-07-29 19:36 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/prmichaelsen/scry'

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

scry

Установка

Быстрый старт

Режим маркеров

Маркеры

Поле extras (scry-spec v1.2.0, FR4.B)

Значения kind для @scry.entry (базовая версия v1.2.0)

MCP-инструменты

Схема базы данных

Watcher

Tests

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Поле `extras` (scry-spec v1.2.0, FR4.B)

Значения `kind` для `@scry.entry` (базовая версия v1.2.0)