Which integrations are available for this server?

Provides tools for analyzing LookML governance, dead code detection, PDT cost visibility, schema drift detection, and safe migration impact analysis for Looker, with optional usage and schema enrichment from BigQuery.

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Strata find dead code in my LookML repo" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Strata

by G-Schumacher44

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Strata — Agentic BI Toolkit for Looker and BigQuery

License Python MCP Offline First

If you're a BI engineer or analyst running Looker on BigQuery, your existing tools validate syntax and catch broken SQL. They usually do not answer the governance questions that decide whether a semantic-layer change is safe:

Which explores had zero queries in the last 30 days?
Which PDTs are rebuilding nightly at ~$45,000/month in estimated BQ compute to serve nobody?
Which BigQuery column drops will silently break LookML before users find out at query time?

Naming, in short:
The tool is Strata. The PyPI package is strata-lookml — the PyPI names strata and strata-mcp belong to unrelated projects.
The commands you type are unchanged: strata, strata-mcp, strata-chart.
pipx users: one of those unrelated packages also installs a command named strata. If it's on your machine, pipx install strata-lookml will refuse the duplicate name.
The uvx form below sidesteps this entirely — it runs in an ephemeral environment, so nothing collides.

What Strata Is

Strata is a local MCP server and CLI toolkit. Point it at your LookML repo. Your AI client gets 18 analysis tools — 17 read-only, 1 sandboxed chart renderer, and 15 domain skills with structured investigation procedures, and a pre-built graph of your resolved LookML dependency structure — enriched with BigQuery usage and schema facts. Offline-first: connecting to your Looker instance is preferred but optional; no credentials are required to start.

Related MCP server: MindGraph

Installation

# Run without installing (recommended) — the console scripts are strata,
# strata-mcp, and strata-chart, not strata-lookml, so pass --from:
uvx --from strata-lookml strata --help

# Or install the CLI + MCP server persistently
pipx install strata-lookml
strata --help

Wire it into an MCP client — the server entry point is strata-mcp, resolved from the strata-lookml distribution via uvx --from strata-lookml strata-mcp:

{
  "mcpServers": {
    "strata": {
      "command": "uvx",
      "args": ["--from", "strata-lookml", "strata-mcp"],
      "env": { "STRATA_REPO_PATH": "/path/to/your/lookml" }
    }
  }
}

Both badges embed the same uvx --from strata-lookml strata-mcp config above; edit STRATA_REPO_PATH to your repo after installing. A prebuilt .mcpb bundle for one-click install in Claude Desktop is attached to each GitHub Release.

Quick Start

# Install
pip install -e ".[dev]"

# Bootstrap your repo — creates conductor/, .mcp.json, and config
strata bootstrap --repo /path/to/your/lookml

# Wire your AI client (Claude Code, Cursor, Gemini)
# .mcp.json is written by bootstrap, or add manually:

{
  "mcpServers": {
    "strata": {
      "command": "strata-mcp",
      "env": { "STRATA_REPO_PATH": "/path/to/your/lookml" }
    }
  }
}

Verify everything is wired before opening your AI client:

STRATA_REPO_PATH=/path/to/your/lookml strata mcp validate

Live Looker enrichment is opt-in — start with offline fixtures, add strata auth login when ready. See Looker OAuth and Token Management.

Three LookML repos and matching fixture JSON ship in the repo. Run the full analysis stack offline in under a minute:

git clone https://github.com/G-Schumacher44/strata-oss.git
cd strata-oss
pip install -e ".[dev]"

export STRATA_REPO_PATH=tests/lookml/enterprise_mono
export STRATA_USAGE_FIXTURE=tests/fixtures/enterprise_usage_facts.json
export STRATA_SCHEMA_FIXTURE=tests/fixtures/enterprise_schema_facts.json

$ strata check
Strata scenario gates passed.

$ strata query status
{
  "node_counts": {"explore": 34, "view": 20, "field": 196, "pdt": 5},
  "edge_count": 378
}

$ strata outputs --out /tmp/strata-demo
{
  "catalog": "/tmp/strata-demo/catalog.json",
  "dead_code_register": "/tmp/strata-demo/dead_code_register.json",
  "pdt_ledger": "/tmp/strata-demo/pdt_ledger.json",
  "schema_drift": "/tmp/strata-demo/schema_drift.json",
  "usage_summary": "/tmp/strata-demo/usage_summary.json",
  "cleanup_roadmap": "/tmp/strata-demo/cleanup_roadmap.json",
  "migration_impact": "/tmp/strata-demo/migration_impact.json",
  "validation_scope": "/tmp/strata-demo/validation_scope.json"
}

$ strata mcp validate
  repo:       .../tests/lookml/enterprise_mono  (from STRATA_REPO_PATH env)
  ✓ repo path exists
  ✓ IR cache found (age: 2235s)
  ✓ skills: 15 found
  ✓ chart templates: 4 found
  ~ BQ project: not set (gcloud default will be used; set bq_project in ~/.strata/config.json for 2-part table names)
  ✗ Looker token missing — run `strata auth login`

  MCP server is ready.

All three included playgrounds (enterprise_mono, gcs_analytics, thelook) have matching usage and schema fixture JSON in tests/fixtures/ — swap --repo and --*-fixture to run against any of them.

Strata utilizes Ruff for linting/formatting and Mypy for type checking.

Linting and type checking:

# Run both ruff and mypy
strata lint

# Fix safe violations automatically
strata lint --fix --format

Install pre-commit hooks to run checks automatically on every commit:

pre-commit install

Every PR is gated by:

ruff check src/ tests/
ruff format --check src/ tests/
mypy src/strata --ignore-missing-imports
python -m pytest

See .github/workflows/strata-ci.yml for details.

LookML Governance

The flagship analysis. Runs fully offline from your LookML files and fixture JSON — no Looker instance, no BQ credentials, no flaky API calls.

Dead Code Campaigns

Strata builds a resolved dependency graph covering explores, views, joins, extends chains, fields, PDTs, and physical tables. Cross-reference against 30 days of Looker System Activity and content usage data, and you get exact dead code with dual evidence: the explore exists in the resolved IR and has zero queries with no dashboard references. Dual evidence is designed to eliminate false positives before you deprecate — see docs/testing-findings.md for the false-positive classes caught and fixed during testing (CTE names misread as physical tables, zombie views invisible to the orphan-only check).

From the enterprise_mono playground:

6 dead explores across 3 legacy connection clusters
5 zombie views — referenced only by those dead explores
~$765,000/year in compute serving no users

PDT Cost Visibility

Surface which PDTs are building on schedule but backing dead explores. Cross-reference build cost against query volume to identify zombie compute. Get the annualized number before you walk into the conversation with the team.

pdt_attribution_full_funnel  →  ~$45,000/30d  →  dead_finance_v2 (0 queries)
pdt_customer_value_score     →  ~$18,750/30d  →  dead_orders_v2  (0 queries)
──────────────────────────────────────────────────────────────────
Zombie PDT cost:  ~$63,750/30d  (~$765,000/year)  [estimated]

Costs are estimated from BigQuery scan volume (bytes_processed from Looker System Activity) at the standard on-demand rate ($5/TB). This is disk I/O — the data BQ reads from storage to build the PDT — not memory or output size. Flat-rate and committed-use customers will see different actual billing.

The demo dollar figures above are hand-authored values baked into the enterprise_mono fixture (tests/fixtures/enterprise_usage_facts.json) for illustration — they are not computed by applying the $5/TB formula to that fixture. The formula itself is real and runs against live BigQuery scan bytes (src/strata/l1/looker.py) whenever strata auth login is used against a real Looker/BQ instance.

Schema Drift Detection

LookML that references a column the warehouse dropped compiles fine in Looker — it fails silently at query time. Strata catches these before your users do, with column-level traceability from field definition back to the physical BQ table.

14 drift hits found across 3 tables in enterprise_mono — 9 from a real int_inventory_risk schema migration that LookML was never updated to reflect.

Safe Migrations and Blast Radius

Before dropping a BQ column or renaming a table, run impact analysis across the full LookML graph. Every view, explore, and field that depends on it — with content reference counts.

CI Gate

strata check --repo . --usage-fixture usage_facts.json

Exits 0 if all gates pass. No Looker instance, no credentials, no flaky API calls. Every PR gets deterministic coverage: extends chains resolved, dead code counted, drift checked, validation scope computed.

Tool	What it does	Where it stops
LookML IDE / Extension	Syntax validation, autocomplete, inline errors	Doesn't know query history, cost, or which explores are actually used
Looker MCP Server	Gives Client(Claude, Gemini, Codex, Cursor) live API access to Looker objects and system activity	A bridge for agents — surfaces data, doesn't analyze it
Spectacles / content validation	Runs explores in Looker to catch SQL compile errors	Reactive — tests what exists, doesn't surface what should be removed
Looker native alerting	Flags broken dashboards and scheduled query failures	Catches failures after they happen, not structural risk before it does

Strata consumes what the Looker MCP Server surfaces (usage facts, system activity) and produces what a Looker Extension could display (cost ledger, cleanup roadmap, drift report). The three tools are complementary layers, not competitors.

Dashboard

strata dashboard builds all 8 output artifacts and serves a self-contained HTML observability panel at localhost:8765. No JavaScript framework, no CDN — all JS is bundled locally so it works in air-gapped or corp-network environments.

The dashboard has four panels:

Overview — KPI tiles (active explores, dead artifacts, total PDT cost, schema drift hits) + the full dependency graph
Dead Code Register — every flagged explore and view with dual-evidence badges (structural + usage). Click any node to see what backs it.
PDT Ledger — cost per PDT per period, zombie vs. active status, which explores reference each PDT
Schema Drift — missing columns/tables per view, mapped back to physical table and connection

strata dashboard \
  --repo tests/lookml/enterprise_mono \
  --usage-fixture tests/fixtures/enterprise_usage_facts.json \
  --schema-fixture tests/fixtures/enterprise_schema_facts.json

Strata dashboard overview — enterprise_mono playground: 23 active explores (11 dead), 11 dead artifacts, 14,242 queries, $63,755.94 estimated PDT cost/30d, 14 schema drift records, and the full dependency graph with zombie PDT diamonds in purple

enterprise_mono — 34 explores, 19 models, 30-day window. Green = active explore, red = dead explore, blue = view, orange = unused PDT, purple = zombie PDT, gray = physical table.

Dependency graph zoomed on dead_finance_v2 — rendered dead-red with a DEPRECATE badge and QUERY COUNT: 0 in the node detail panel

dead_finance_v2 selected — rendered dead-red with a deprecate verdict and QUERY COUNT: 0 in the node detail. Its backing PDT, pdt_attribution_full_funnel, is the purple zombie diamond in the full graph above, rebuilding at ~$45,000/month (estimated fixture data) to serve it.

PDT Cost Ledger — pdt_attribution_full_funnel flagged ⚠ ZOMBIE at $45,000/mo and pdt_customer_value_score at $18,750/mo, each citing its dead consumer explore, above the Cleanup Roadmap's KILL PDT actions

PDT Cost Ledger — both zombie PDTs flagged ⚠ with their monthly cost and the dead explores that consume them, above the Cleanup Roadmap's KILL actions. Every verdict carries evidence links; the Dead Code Register panel (visible at top) applies the same dual-evidence rule — structural and usage tags both required before anything is flagged.

LookML repo (read-only clone)
        │
        ▼
   L0 — IR Builder
        Parse all .lkml files → canonical node/edge graph
        Resolve extends chains, refinements, cross-model dependencies
        No LLM. No network. Pure deterministic Python.
        │
        ▼
   L1 — Enrichment
        Join IR against usage facts (explore queries, PDT builds)
        Join IR against schema facts (warehouse column inventory)
        Produces: dead code evidence, PDT cost ledger, schema drift records
        Offline: fixture JSON  |  Live: Looker OAuth → System Activity API
        │
        ▼
   L2 — Synthesis
        One explore = one verdict with evidence
        Lightweight model, clean structured context
        Outputs: cleanup roadmap, migration impact, validation scope
        │
        ├── JSON artifacts   catalog / dead code / PDT ledger / drift / impact
        ├── HTML dashboard   strata dashboard
        ├── MCP server       18 tools (17 read-only + 1 sandboxed render), stdio, any MCP client
        └── CLI              strata check / outputs / build / validate

L0 never calls any LLM or external API — pure offline deterministic Python. L1 enrichment is offline by default (fixture JSON); live Looker System Activity API access is opt-in via strata auth login. The MCP server transport is stdio-only — no HTTP server, no cloud dependency. All analysis runs against a read-only clone.

Parsing LookML, resolving extends chains, detecting dead code, computing PDT cost — these are deterministic problems. They cost zero tokens. The structure doesn't need an LLM to understand it; it needs to be mapped.

Strata maps it first. Then a lightweight model reasons over a clean, structured context. This gets more capable as models improve and more efficient over time. The deterministic layer never changes.

LookML's declarative model — explicit explore:, join:, view:, extends: — makes this possible. Every dependency is named and resolvable without executing a query. Most BI tools don't have this. A dbt project has a DAG but no semantic layer. A Tableau workbook has implicit dependencies that are hard to traverse programmatically. LookML's structure is what makes "what breaks if I change this?" answerable with certainty, not heuristics.

MCP, Skills, and Agent Workflow

The MCP Layer

18 tools over stdio — 17 read-only, plus strata_render_chart, which writes only to ~/.strata/output or /tmp (sandboxed, never your LookML repo). Works with any MCP client. All tools run against the local IR cache — no live Looker connection required. For live usage enrichment, see Looker OAuth below.

Agent calls: strata_dead_code_register
  → 6 dead explores, 2 zombie PDTs, ~$63,750/mo estimated in unused compute

Agent calls: strata_explore_deps("dead_finance_v2", "em_legacy_v2")
  → full join graph: 4 views, 1 zombie PDT backing this explore

Agent calls: strata_schema_drift
  → 14 drift hits across 3 tables — column drops not reflected in LookML

Agent calls: strata_validation_scope(["views/orders.view.lkml"])
  → 3 explores affected — minimum revalidation set for this PR

Tool	Returns
`strata_ir_status`	Graph summary: node counts, model list, resolution errors
`strata_dead_code_register`	Dead explores + zombie views with dual evidence
`strata_pdt_costs`	PDT ledger: cost/mo, build count, bytes, status
`strata_schema_drift`	Column-level drift: field exists in LookML, missing in warehouse
`strata_explore_deps`	Full join graph for an explore
`strata_query_field`	Field definition: type, SQL, tags, usage
`strata_list_orphans`	Orphaned views, explores, and fields by kind
`strata_usage_summary`	Query counts, top explores, usage gaps
`strata_validation_scope`	Impact set for a set of changed .lkml files
`strata_impact`	Views, explores, and fields affected by a physical table change
`strata_find_field`	Search fields by name, SQL, label, description, or tag
`strata_view_sources`	All views with backing BQ table, field count, orphan flag
`strata_navigate`	One-call ticket brief: views/explores/fields for an anchor, cited as file:line
`strata_list_skills`	Compact metadata for all bundled skills
`strata_skill`	Full skill content — loaded only when requested
`strata_render_chart`	Vega-Lite spec + data → self-contained HTML
`strata_chart_templates`	Available chart types
`strata_conductor_status`	Active workflow slice and next steps

LLM Cost Controls

L0 and L1 analysis costs zero tokens — pure deterministic Python, no model calls. Tool responses return structured JSON, not prose, so each MCP call adds ~200–500 tokens to context rather than paragraphs of explanation. Skills are lazy-loaded: strata_skill("name") pulls one skill on demand; the rest cost nothing. L2 synthesis does use tokens, but against clean structured context. Composite tools keep round-trips low: strata_navigate returns a full ticket brief (views, explores, fields, file:line citations) in one call instead of an agent hand- orchestrating several separate lookup primitives — a single structured payload in place of stitching those calls together, and far fewer context-carrying round-trips.

For long-running investigations, Conductor's slice-based handoffs let an agent resume from a single targeted file load (index + handoff-log) rather than re-deriving state from scratch — keeping per-session context lean without measuring token counts explicitly.

Looker OAuth and Token Management

All 18 tools (17 read-only, 1 sandboxed chart renderer) work fully offline against the local IR cache. Live Looker enrichment is opt-in:

strata auth login --looker-url https://your-instance.looker.com
strata auth status

Token stored at ~/.strata/tokens.json (0600 permissions, 0700 parent directory). HTTPS enforced — http:// rejected except for localhost OAuth callback. Token permissions checked on every read; loose permissions surface a warning before any tool call.

For enterprise: ADC, OIDC for GitHub Actions, and Google Workspace IAM path in docs/enterprise-deployment.md.

Skills — Structured Investigation Procedures

15 domain skills bundled with the package. Zero tokens until an agent calls strata_skill("name"). Each skill defines trigger conditions, allowed tools, a step-by-step procedure, stop conditions, output format, and escalation scripts. lookml_ticket_navigator is the day-to-day ticket entry point: give it a BQ table, field, view, explore, or .lkml file and it returns the source-cited brief an agent needs before editing.

Designed to run with smaller, task-appropriate models — [JUDGMENT] marks the few steps that require reasoning; everything else is mechanical. A typical BigQuery investigation chains skills like this:

Agent reads skill: bq_schema_probe
  → procedure: which BQ datasets to check, how to validate grain, stop conditions
  → agent queries information_schema to map physical tables to LookML views

Agent reads skill: grain_validator
  → detects fan-out risk in joins, missing relationship: declarations

Agent reads skill: sql_builder
  → structured SQL construction for BQ with cost guardrails applied first

Agent reads skill: sql_optimizer
  → optimization rules flagged against the built query

Agent reads skill: bq_query_guardrail
  → final cost and safety gate before any query executes

Domain	Skills	Use when
BigQuery	`bq_schema_probe`, `grain_validator`, `sql_builder`, `sql_optimizer`, `bq_query_guardrail`	Inspect warehouse schema, draft SQL, validate grain, and keep queries cost-safe
LookML	`lookml_ticket_navigator`, `lookml_view_reviewer`, `lookml_explore_join_reviewer`	Find what to touch, review fields/views, and verify explore joins
Looker	`semantic_layer_audit`	Audit semantic-layer health across usage, drift, and dependency evidence
Delivery	`jira_to_bi_spec`, `bi_incident_responder`, `release_notes_generator`	Turn tickets/incidents/merged changes into scoped BI artifacts
Visualization	`chart_composer`, `dashboard_composer`	Compose charts and dashboards from governed fields and evidence
Governance	`conductor_manager`	Manage Conductor slices, phases, and handoffs

Conductor — Agent Workflow Management

Conductor is the session continuity system for agent work. It tracks active slices (bounded work units), acceptance criteria, and handoff state across sessions — so an agent picking up where another left off has full context without re-deriving it.

Deploy Conductor into your repo:

strata bootstrap --repo /path/to/your/lookml
# Creates: conductor/index.md, conductor/handoff-log.md, .mcp.json

During an investigation:

strata conductor new-slice "Audit dead explores in gcs_analytics"
strata conductor status
strata conductor log-handoff --completed "dead code register" --next "PDT cost review"

The handoff log records commit hash, what was completed, and exact next steps. strata validate checks the log format and verifies the referenced commit exists in git — catching hallucinated handoffs before they compound.

For the full investigation workflow — gate verification, findings format, stop conditions, live enrichment options — see the Governance Runbook.

Vega-Lite Charts — Built In

strata chart bar data.json --title "Revenue by Region" --open
strata chart line trend.json --open
strata chart scatter correlation.csv --open
strata chart heatmap activity.json --open

4 chart types. JS bundled locally — charts are self-contained HTML files that render offline. Built on Vega-Lite by the UW Interactive Data Lab (@uwdata).

CLI

15 commands. Full reference: docs/cli-guide.md.

Command	What it does
`strata auth`	Authenticate with Looker and manage local OAuth tokens
`strata bootstrap`	Scaffold Strata into a repo — conductor/, .mcp.json, config
`strata build`	Parse LookML and write the IR cache (`strata_ir.db`)
`strata chart`	Render charts to self-contained HTML
`strata check`	Offline governance gates — dead code, drift, PDT, verdict validation
`strata clean`	Remove `output/`, `strata_ir.db`, `__pycache__`
`strata conductor`	Manage slice-based agent workflow and handoffs
`strata dashboard`	Build artifacts and serve the local HTML dashboard
`strata generate-schema`	Pull BigQuery INFORMATION_SCHEMA facts for drift checks
`strata lint`	Run ruff and mypy checks
`strata mcp`	Run, validate, and inspect MCP server configuration
`strata outputs`	Write 8 JSON artifacts to an output directory
`strata query`	Inspect the IR from the terminal
`strata skill`	List bundled skills or print a skill procedure
`strata validate`	Conductor spine check — handoff format, active slice, replay facts

CI and Bot Deployment

Strata ships two decoupled CI workflows: a hard gate that blocks the build on test failures, and a soft gate that posts advisory PR review without breaking it.

strata-pr.yml runs on every PR and posts a single, self-updating comment with impact analysis — which explores break, validation scope, blast radius — plus the Conductor spine check (strata validate). The comment is upserted in place on each push (no duplicate comments), and a failing strata validate is surfaced in the comment without failing the build, so quick human fixes aren't blocked.

# .github/workflows/strata-pr.yml  (included in repo)
on:
  pull_request:

See .github/workflows/strata-pr.yml and scripts/pr_comment.py for the full workflow.

strata-ci.yml runs lint (ruff), types (mypy), the test suite (pytest), and offline strata check / strata outputs across the bundled playgrounds — verifying dead code, schema drift, and PDT findings deterministically.

# .github/workflows/strata-ci.yml
- name: Strata offline analysis
  run: |
    strata check \
      --repo . \
      --usage-fixture usage_facts.json \
      --schema-fixture schema_facts.json

Exits 0 if all gates pass. No Looker instance, no credentials, no flaky API calls.

Output Artifacts

strata outputs writes 8 JSON files per run: catalog, usage_summary, dead_code_register, pdt_ledger, schema_drift, migration_impact, cleanup_roadmap, validation_scope. All deterministic — same fixtures produce identical output. Feed them to downstream reporting or consume them in your AI client via the MCP layer.

How We Validated

Three offline playgrounds, all findings sourced from actual output artifacts. Full breakdown: docs/testing.md.

enterprise_mono — 19 models, 34 explores, cross-model extends, 3 legacy connection clusters:

6 dead explores (0 queries over 30 days) — all flagged with dual evidence
5 zombie views — referenced only by dead explores
2 zombie PDTs rebuilding at ~$63,750/month estimated — backed exclusively by dead explores
~$765,000/year in compute serving no users
14 schema drift hits across 3 tables (9 from a real int_inventory_risk migration)

gcs_analytics — gold/silver BQ layer, mixed active and legacy:

6 dead items (2 orphan views, 2 zombie views, 2 dead explores)
1 unused PDT (~$156/month estimated, no explore backer)
1 schema drift hit

thelook — Looker's public demo repo, structural baseline:

6 dead items (1 orphan view, 1 zombie view, 4 dead explores)
1 schema drift hit

Each playground ships with matching fixture JSON files (tests/fixtures/) that simulate Looker System Activity API responses — so the full analysis runs offline with no credentials.

Docs

Full index: docs/README.md


`docs/runbook.md`	Governance investigation playbook — gate, workflow patterns, findings format
`docs/cli-guide.md`	Full CLI reference — all commands, env vars, output artifacts
`docs/testing.md`	Playgrounds, scenarios, how to run them
`docs/testing-findings.md`	Full findings — real numbers, drift breakdowns, agentic benchmarks
`docs/security-hardening.md`	Read-only enforcement, credential handling, MCP security model
`docs/enterprise-deployment.md`	IAM, ADC, OIDC for GH Actions, Google Workspace path
`docs/CONTRIBUTING.md`	Contribution guide

License

mcp-name: io.github.g-schumacher44/strata

Available Tools

18 tools

strata_chart_templatesA

List available Vega-Lite chart templates (name, mark).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It signals a read-only listing operation and describes the output fields, which is useful, but it does not explicitly confirm that no side effects occur or describe any environment-specific behavior. For a simple zero-parameter list tool, this is adequate but not rich.

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 sentence with no filler. The main action and resource are front-loaded, and the parenthetical output detail is the only extra information, which is necessary and concise.

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?

For a zero-parameter listing tool with an output schema present, this description provides enough context for an agent to invoke it correctly: what it lists, what the output contains, and nothing else is required. The sibling context does not reveal a missing prerequisite or alternative that needs explanation.

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 zero parameters, so the baseline is 4. The description adds value by clarifying what the returned templates contain ('name, mark') and narrowing the scope to 'available Vega-Lite chart templates'.

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 a specific verb ('List') and a specific resource ('available Vega-Lite chart templates'), and it identifies the output fields ('name, mark'). This clearly differentiates it from sibling tools like strata_render_chart, which presumably consumes rather than lists templates.

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 intended use is implied by the verb and resource: call this tool to enumerate available chart templates. However, it does not explicitly state when to use it instead of an alternative such as strata_render_chart, nor does it mention any prerequisite relationship between listing and rendering templates.

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

strata_conductor_statusA

Get the current Conductor workflow status (active_slice, next_steps, latest_handoff).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. 'Get' implies a read operation, but the description does not explicitly state the absence of side effects, freshness expectations, or failure behavior; the listed fields add some clarity for a simple status read.

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 front-loaded sentence with the verb, resource, and key output labels included. Every word contributes value and there is no filler.

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?

For a zero-parameter status tool with an output schema, the description is largely sufficient: it names the resource and the expected fields. A brief usage note distinguishing it from sibling status tools would improve completeness, but the gap is modest given the tool's simplicity.

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 no parameter documentation is needed and schema coverage is trivially complete. The parenthesized terms appear to describe response content rather than arguments, which is acceptable here.

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 a specific verb ('Get') and a distinct resource ('Conductor workflow status'), then enumerates the key fields returned. This clearly differentiates it from status-like siblings such as strata_ir_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 gives no guidance on when to use this tool versus alternatives like strata_ir_status or strata_validation_scope. An agent must infer the intended context from the tool name alone.

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

strata_dead_code_registerD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

strata_explore_depsD

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes
`explore`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

strata_find_fieldB

Search for fields matching a query string across all views (query, kind, matches, count).

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No		all
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/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 behavioral burden. It does communicate that this is a search/read operation and mentions output components ('matches, count'), but it does not disclose matching semantics, case sensitivity, pagination, or potential limitations. The additional behavioral detail is minimal but not misleading.

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 sentence with no filler. It front-loads the main action and scope, then compactly lists the key inputs and outputs. Every word contributes to understanding the tool's 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?

With only two parameters, an existing output schema, and a one-line description, the tool is minimally callable. However, the lack of sibling differentiation and the weak parameter semantics leave gaps that matter for correct tool selection, especially given the large sibling list.

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 has 0% description coverage, so the description should compensate. It mentions 'query' and 'kind' by name but adds little meaning beyond what the schema already shows. 'matches, count' appear to be output fields rather than parameter documentation, so the semantics of how query matching works or how kind interacts with the search remain unexplained.

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 ('search for fields'), the resource ('across all views'), and hints at the result shape ('matches, count'). It is specific enough to understand the tool's core function, but it does not explicitly differentiate it from the similarly named sibling tool strata_query_field.

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?

There is no when-to-use or when-not-to-use guidance, and no reference to alternatives despite many sibling tools. The phrase 'across all views' gives some scope context, but an agent cannot determine how this differs from strata_query_field or when to prefer one over the other.

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

strata_impactB

Get the downstream impact of a physical table (physical_table, views, explores, fields).

ParametersJSON Schema

Name	Required	Description	Default
`physical_table`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description is the only behavioral signal. 'Get' conveys a read-only operation, and the parenthetical indicates the scope of returned entities, but the description doesn't disclose recursion depth, cost, or any special conditions beyond those.

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?

One short sentence front-loads the verb and object, with the parenthetical adding detail at the end. There is no fluff or repeated schema information.

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 is simple with one required parameter and an output schema, so the basic call shape is inferable. However, missing parameter format details and lack of sibling routing leave meaningful gaps for an agent deciding how and when to call it.

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?

Schema coverage is 0%, so the description must compensate for missing parameter documentation, but it only repeats 'physical_table' without clarifying how to format or qualify it. The parenthetical uses 'physical_table' again in the output list, which can create ambiguity about what the parameter identifies.

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 a specific verb ('Get') and a clear resource ('downstream impact of a physical table'), and the parenthetical enumerates the affected entity types. This distinguishes it from siblings like strata_view_sources and strata_explore_deps, which cover narrower or different dependency questions.

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 implies the tool should be used when downstream impact is needed, but it gives no explicit when-to-use guidance, prerequisites, or alternatives. It does not distinguish itself from sibling dependency tools or explain when one of those would be preferable.

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

strata_ir_statusD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

strata_list_orphansD

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No		all

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

strata_list_skillsA

List available skills (name, domain, mode, complexity, trigger).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/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 disclosure burden. 'List' implies a read-only operation and the description names the output fields, but it does not state scope details or behavioral caveats beyond that. For a simple zero-parameter list tool this is adequate, though minimal.

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 front-loaded sentence that states the action, the resource, and the relevant output attributes with no filler or 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?

For a zero-parameter list tool with an output schema, the description provides sufficient context: it names the operation, the resource, and the fields an agent can expect. No additional guidance is necessary to invoke it correctly.

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 and the schema properties are empty, so parameter semantics are not a concern. The description's field list refers to the output, not inputs, which is fine because there is nothing for the agent to configure.

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 verb and resource: 'List available skills' and enumerates the returned attributes (name, domain, mode, complexity, trigger). It is easily distinguishable from siblings by its plural 'skills' and list semantics, though it does not explicitly contrast with the singular 'strata_skill' tool.

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?

Usage is implied: an agent would call this when it needs a catalog of available skills. However, there is no explicit when-or-when-not guidance, and the sibling 'strata_skill' suggests an alternative that is not mentioned or routed around.

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

strata_navigateA

Classify a ticket anchor and return a full navigator brief in one call.

anchor: BQ table, field name, view, explore, or .lkml filename. Returns the views/explores/fields it touches with source_file:source_line citations, plus an inferred change type and what-to-touch list when ticket is set.

ParametersJSON Schema

Name	Required	Description	Default
`model`	No
`anchor`	Yes
`ticket`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden and does so well: it states the output (views/explores/fields touched, source_file:source_line citations), and the conditional behavior when ticket is set. It doesn't mention side effects, but the language describes a read/analysis operation.

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 compact and front-loaded, with the main action in the first line and supporting output details following. A few phrases ('full navigator brief', 'in one call') are slightly promotional but not harmful.

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?

It covers required anchor semantics and the ticket-conditioned output, and an output schema exists so return values don't need detailing. Missing context includes the meaning of the `model` parameter and any guidance on when to choose this over the many sibling tools.

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 description coverage is 0%, so the description must add meaning. It does clarify `anchor` with allowed value categories and implies `ticket` is optional conditioning the what-to-touch inference, but `model` is left completely unexplained.

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 names a specific action ('Classify... and return') on a specific resource ('ticket anchor'), and enumerates the accepted anchor forms (BQ table, field name, view, explore, .lkml filename). It is clear what the tool does, but it does not explicitly distinguish itself from the sibling tools.

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?

Use is implied: call it when you have a ticket anchor and need a navigator brief with citations. However, it gives no explicit when-to-use vs alternatives or when-not-to-use guidance, and no sibling tool is referenced.

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

strata_pdt_costsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

strata_query_fieldD

ParametersJSON Schema

Name	Required	Description	Default
`view`	Yes
`field`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

strata_render_chartC

Render a chart using a Vega-Lite template and JSON data (path, status).

ParametersJSON Schema

Name	Required	Description	Default
`out_path`	Yes
`data_json`	Yes
`spec_yaml`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/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 the behavioral burden. It says 'Render a chart' but does not disclose whether it writes a file, overwrites existing output, validates the spec, or what side effects occur. The out_path parameter hints at file creation, but this is not explicit.

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 concise sentence with no filler. It front-loads the primary action. The phrase '(path, status)' is somewhat cryptic but does not add unnecessary length.

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 tool with no annotations and minimal parameter documentation, the description does not provide enough context about expected inputs, output file behavior, or how this tool relates to strata_chart_templates. The output schema exists but the description still leaves key invocation details ambiguous.

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 description coverage is 0%, so the description must compensate. It adds some meaning by identifying spec_yaml as a Vega-Lite template and data_json as JSON data with 'path, status' fields, while out_path is self-explanatory. However, it lacks format details, required field structures, and relationship between template and data.

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 a specific action ('Render a chart') and identifies the key inputs: a Vega-Lite template and JSON data. It is distinct from sibling tools like strata_chart_templates, though it does not explicitly contrast itself with 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?

The description offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Usage is only implied: use it when you want to render a chart.

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

strata_schema_driftD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

strata_skillA

Get the full SKILL.md content for a specific skill.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the behavioral burden. It discloses that the tool is a getter returning 'full SKILL.md content' for a named skill. It does not mention behavior on invalid or missing skill names, case sensitivity, or that it is read-only (though 'Get' implies this).

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, front-loaded sentence that uses no filler. Every word contributes to the tool's purpose and scope.

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?

With one required parameter and an output schema present, the description is largely complete. It names what the tool returns and scopes it to a specific skill. The only notable gap is no guidance on what happens if the skill is not found or how to obtain a valid name, but these are minor for such a simple getter.

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 description coverage is 0%, so the description must clarify the 'name' parameter. It does tie the parameter to 'a specific skill', which gives some meaning beyond the schema's bare string type. It does not explain how to identify valid names or provide examples, but with only one parameter this may be sufficient.

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 a specific verb ('Get') and resource ('full SKILL.md content') scoped to 'a specific skill'. This clearly distinguishes it from siblings like strata_list_skills, which lists skills, and other strata_* tools about queries or dependencies.

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 usage: call this when you have a specific skill name and want its full content. However, it does not explicitly state when to use this over siblings (e.g., use strata_list_skills to discover names first) or any exclusions.

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

strata_usage_summaryD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

strata_validation_scopeC

Determine blast radius for changes (impacted_views, impacted_explores, impacted_fields).

ParametersJSON Schema

Name	Required	Description	Default
`changed`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior3/5

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

No annotations are present, so the description must carry behavioral context. It indicates the operation is an analysis ('determine') and names the result categories (impacted_views, impacted_explores, impacted_fields), which is useful. However, it does not disclose prerequisites, side effects, input-validity behavior, or performance characteristics.

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 with no filler and includes key output terms in parentheses. It is compact and easy to scan; additional structure could improve readability, but it is efficiently written.

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 ambiguous one-parameter schema and a large sibling set, the description is too thin. It omits input grammar, typical usage flow, and any relationship to validation or impact-analysis alternatives. The output schema covers return shape, but operational context remains missing.

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?

Schema description coverage is 0%, so the description must explain the 'changed' parameter, but it only says 'changes'. It does not clarify whether elements are file paths, field names, or arbitrary objects, nor the difference between the string and object forms. The agent is left to guess the expected input format.

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 uses a specific verb 'determine' and names the resource ('blast radius for changes') plus expected outputs (impacted views, explores, fields). The purpose is clear, but it does not explicitly distinguish this tool from siblings like strata_impact or strata_find_field beyond those output labels.

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 only usage signal is 'for changes', implying it should be used when assessing change impact. There is no explicit when/when-not guidance, no prerequisites, and no mention of alternatives among the many sibling tools. An agent cannot tell when to choose this over strata_impact or strata_explore_deps.

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

strata_view_sourcesC

List views and their resolved physical tables (model_filter, views, count).

ParametersJSON Schema

Name	Required	Description	Default
`model`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It describes a read-only 'List' operation and what is returned ('views and their resolved physical tables'), which is moderately transparent. However, it does not disclose details like whether any model filter applies, permissions needed, or behavior when the optional model is omitted.

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 one short sentence, front-loaded with the action and resource, and contains no filler. It is highly concise and easy to parse.

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?

Although the tool is simple with one optional parameter and an output schema exists, the description leaves the model parameter unexplained and gives no usage context. For a definition that must help an agent select and invoke the tool correctly, it is under-specified.

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 one parameter, model, with no description. The description's parenthetical '(model_filter, views, count)' appears to describe output fields, not the model parameter, so it provides no meaningful guidance for how to use the model argument. Schema description coverage is 0%, and the description does not compensate.

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 the resource ('views and their resolved physical tables'), and hints at the returned fields. It is specific enough to be distinguished from most sibling tools, though it does not explicitly contrast itself with any sibling.

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?

There is no guidance on when to use this tool versus alternatives like strata_explore_deps or strata_navigate. The description gives no context, prerequisites, or exclusions, so the agent must infer appropriate usage.

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.

18 tool updatesv0.1.8Aug 30, 2026
- First observedstrata_chart_templates
- First observedstrata_conductor_status
- First observedstrata_dead_code_register
- First observedstrata_explore_deps
- First observedstrata_find_field
- First observedstrata_impact
- First observedstrata_ir_status
- First observedstrata_list_orphans
- First observedstrata_list_skills
- First observedstrata_navigate
- First observedstrata_pdt_costs
- First observedstrata_query_field
- First observedstrata_render_chart
- First observedstrata_schema_drift
- First observedstrata_skill
- First observedstrata_usage_summary
- First observedstrata_validation_scope
- First observedstrata_view_sources

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.2/5.0

Scored 2026-08-30 03:30 across 18 tools

Disambiguation2/5

Several tools occupy overlapping impact/navigation territory: strata_impact, strata_validation_scope, and strata_navigate all return affected views/explores/fields, while strata_find_field and strata_query_field have similar search/query semantics. strata_list_orphans and strata_dead_code_register also blur together. Without more detailed descriptions, an agent could easily select the wrong tool.

Naming Consistency3/5

All tools share the strata_ prefix and use snake_case, which provides a consistent namespace. However, the verb_noun pattern is not maintained: list_orphans and find_field sit alongside bare noun phrases like ir_status, pdt_costs, schema_drift, and conductor_status. The singular strata_skill also breaks the list/detail convention established by strata_list_skills.

Tool Count3/5

18 tools is above the typical 3-15 well-scoped range and mixes core data-model analysis tools with meta utilities like skills, conductor status, and chart templates. It is not extreme, but the set feels heavier and broader than necessary for a focused server.

Completeness4/5

For a read-only data-model navigation and impact-analysis server, the surface covers discovery, dependency exploration, impact assessment, orphan/dead-code detection, schema drift, usage, costs, and even rendering charts. Minor gaps exist, such as no explicit per-explore detail tool and no apply flow after validation_scope, but agents can generally work around these.

Maintenance

ActivitySlowing

ResponsivenessSlow

Resources

Need Help?

Related Servers

Related MCP Connectors

Mapnostics
io.github.ffteema
Codebase intelligence for AI agents — dead code, blast radius, ownership.
Code Analysis Developer Tools
1
ArchGraphOAuth
dev.archgraph
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code Analysis Software Architecture Developer Tools
2
XRay-VisionOAuth
com.emtailabs
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Code Analysis Developer Tools Autonomous Agents
2
searchcode A
com.searchcode
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Search Code Analysis Version Control
72

Related MCP Servers

DataHub MCP Server
Search Knowledge & Memory Data Platforms
shemreader
A
license
Not graded
quality
C
maintenance
Enables AI agents to search, explore data lineage, understand business context, and generate SQL queries across an organization's data ecosystem.
Updated 9 months ago (2025-12-14 09:06 UTC)
Apache 2.0
MindGraph
Code Analysis Developer Tools
dycm8009
A
license
Not graded
quality
C
maintenance
Enables AI agents to query and analyze code across multiple repositories through a unified knowledge graph, with tools for symbol search, impact analysis, and graph algorithms.
Updated 2 months ago (2026-07-29 05:15 UTC)
11 npm
MIT
Ecommerce MCP Server
Databases E-commerce & Retail Cloud Platforms
Ethan-Shapiro
A
license
Not graded
quality
C
maintenance
Enables AI agents to query BigQuery ecommerce datasets like TheLook via guarded, read-only SQL tools (dry_run_sql and execute_sql), with benchmarked performance over wiki-style documentation lookup.
Updated a month ago (2026-08-17 03:36 UTC)
MIT
dryrun
Databases Developer Tools Code Analysis
boringSQL
A
license
Not graded
quality
B
maintenance
Gives AI coding assistants, IDEs, and CI full PostgreSQL schema intelligence from an offline snapshot, enabling linting, query validation, migration safety analysis, and foreign key graph exploration without ever exposing database credentials.
Updated 5 days ago (2026-09-17 07:03 UTC)
35
BSD 2-Clause "Simplified"