Skip to main content
Glama

Symvanta

by com.symvanta

index_health

Read-onlyIdempotent

Per-project index health. pendingLibraryVersions: cross-repo specifiers still indexing (an empty result may mean "not indexed yet", not "not in code"); call when a query is surprisingly empty. A row with status "skipped" is never going to arrive (a dev or optional dependency, which the catalog does not index) and status "failed" means discovery found no source, so only "indexing" is worth waiting on. architecture: per-repo Louvain module count + modularity Q (low Q = tangled), plus circular-dependency and mutually-recursive-symbol counts (inspect via map view:"architecture"). versionDrift: joined cross-repo SCIP edges whose consumer-pinned package version differs from the sibling's current version (package, pinned vs current, edge count). externalsCoverage: per-repo count of external references joined onto a sibling definition vs left as materialized stubs. unindexableRepositories: repos whose last index produced no graph and left a status (no_default_branch = the remote has no resolvable default branch, e.g. an empty repo; awaiting_upload = an upload-provider repo with no zip yet; remote_head_unresolvable = the remote could not be reached to resolve its head, so this is a network or credential problem, not a repository one), with the worker's log line as indexStatusDetail; explains a silently-empty repo. degradedRepositories: repos that DID index but lost a derived artifact (community_detection_skipped = Louvain clustering did not run, so map view:"architecture" has no modules; raise COMMUNITY_EDGE_CEILING or set COMMUNITY_DETECTION=true, then reindex). Both carry a human-readable reason.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
feedbackNoOptional: report how a previous answer worked out; piggybacks on any call.
projectIdNoProject id from init/list_projects. Omit for the active project.
repositoryNoRepository full name, e.g. "owner/repo". Omit when the project has one repository.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The annotations already mark the tool as read-only and idempotent, and the description adds substantial behavioral detail beyond that: empty results may mean 'not indexed yet', 'skipped' rows will never arrive, 'failed' means no source was found, and specific statuses distinguish network/credential problems from repository problems. This is rich, useful behavioral context.

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

Conciseness4/5

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

The description is dense and long, but almost every clause earns its place by explaining a status code or metric interpretation. It is front-loaded with the core purpose and the key call signal, though the heavy use of nested parentheses and semicolons makes it harder to parse than it could be with structured bullets.

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?

With no output schema, the description carries the burden of explaining return semantics, and it does so thoroughly, covering each health field, possible status values, and their practical meaning. It also tells the agent what actions to take for degraded or failed indexes, making the tool fully actionable.

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?

All three parameters already have descriptions in the schema, so the baseline is 3. The description mentions 'per-project' and 'per-repo' concepts that imply the projectId and repository parameters, but it does not add explicit parameter-level guidance beyond what the schema already provides.

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 states 'Per-project index health' and then enumerates the specific health categories it reports, so an agent knows exactly what this tool produces. It also distinguishes itself from siblings by focusing on index status rather than search, reindexing, or repository management.

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 explicitly says to call this tool when a query is surprisingly empty, and it explains what different statuses mean and which statuses are worth waiting on. It also references alternatives like 'inspect via map view' and remediation through reindexing, giving clear guidance on when this tool is the right choice.

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

All Symvanta toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Tools generally target distinct operations—repository attachment, symbol resolution, graph traversal, source access, indexing health—and the detailed routing notes reduce ambiguity. A few pairs still overlap in intent (quick_lookup vs locate symbol, context vs ask_codebase), so it is not perfectly unambiguous.

Naming Consistency3/5

All names are lowercase snake_case and readable, but the set mixes verb_noun patterns like add_repository and list_projects with single-word nouns/verbs like context, history, map, relate, and source, plus one acronym (adr). There is no predictable convention across the full surface, though individual names are clear.

Tool Count3/5

25 tools is at the high end for a single MCP server and falls in the 'feels heavy' range. The breadth is justified by the code-intelligence/query domain, but the selection surface is large for an agent to navigate efficiently.

Completeness4/5

The code indexing, search, graph query, source access, history, ADR, test lookup, and scope estimation needs are well covered. Minor gaps remain—no detach/remove repository, no ADR content editing, and source access is gated by an add-on—but these are workable.

Resources