Skip to main content
Glama
nihar777

apollo-cache-copilot

by nihar777
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Inspect dangling refs

inspect_dangling_refs
Read-only

Audit a serialized Apollo Cache to identify dangling __refs, unreachable entities, and objects Apollo could not normalize, enabling repair planning.

Instructions

Audit a serialized Apollo InMemoryCache (cache.extract() output) for dangling __refs, unreachable entities, and objects Apollo could not normalize. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cacheYesThe full serialized cache, exactly as returned by `cache.extract()`. Keys are cache IDs (e.g. "ROOT_QUERY", "User:1"); values are that entity's stored fields, which may contain `{ "__ref": "<cache id>" }` pointers to other entries in this same object.
rootIdsNoCache IDs to treat as reachability roots for the UNREACHABLE_ENTITY check, e.g. ["ROOT_QUERY"]. Omit to use every one of ROOT_QUERY / ROOT_MUTATION / ROOT_SUBSCRIPTION that is present in `cache`. Has no effect on ORPHANED_REF or normalization-gap findings.
includeUnreachableNoInclude UNREACHABLE_ENTITY findings for entities no root can reach (candidates `cache.gc()` would collect). Set false to skip reachability analysis and only check refs/normalization.
includeNormalizationGapsNoInclude MISSING_TYPENAME / MISSING_ID findings for inline (non-entity) objects that Apollo could not normalize because they lack a `__typename` or an `id`/`_id` field.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statsYesAggregate counts over the whole cache, independent of the findings list.
findingsYesEvery defect found, in walk order.

Schema Changelog

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

  1. Changed14 schema fields changedv1.0.2
    • addedInput schema / properties / cache / additionalProperties / description
      Added value: +"One normalized store entry: the raw field/value map Apollo keeps under a single cache key."
    • addedInput schema / properties / cache / description
      Added value: +"The full serialized cache, exactly as returned by `cache.extract()`. Keys are cache IDs (e.g. \"ROOT_QUERY\", \"User:1\"); values are that entity's stored fields, which may contain `{ \"__ref\": \"<cache id>\" }` pointers to other entries in this same object."
    • addedInput schema / properties / includeNormalizationGaps / description
      Added value: +"Include MISSING_TYPENAME / MISSING_ID findings for inline (non-entity) objects that Apollo could not normalize because they lack a `__typename` or an `id`/`_id` field."
    • addedInput schema / properties / includeUnreachable / description
      Added value: +"Include UNREACHABLE_ENTITY findings for entities no root can reach (candidates `cache.gc()` would collect). Set false to skip reachability analysis and only check refs/normalization."
    • addedInput schema / properties / rootIds / description
      Added value: +"Cache IDs to treat as reachability roots for the UNREACHABLE_ENTITY check, e.g. [\"ROOT_QUERY\"]. Omit to use every one of ROOT_QUERY / ROOT_MUTATION / ROOT_SUBSCRIPTION that is present in `cache`. Has no effect on ORPHANED_REF or normalization-gap findings."
    • addedOutput schema / properties / findings / description
      Added value: +"Every defect found, in walk order."
    • addedOutput schema / properties / findings / items / properties / danglingRef / description
      Added value: +"The unresolved cache key the ref pointed at. Only present when kind is ORPHANED_REF."
    • addedOutput schema / properties / findings / items / properties / message / description
      Added value: +"Human-readable explanation of this finding."
    • addedOutput schema / properties / findings / items / properties / path / description
      Added value: +"Dotted path to the defect from its cache key, e.g. \"User:2.posts.1\"."
    • addedOutput schema / properties / stats / description
      Added value: +"Aggregate counts over the whole cache, independent of the findings list."
    • addedOutput schema / properties / stats / properties / danglingCount / description
      Added value: +"Of those refs, how many did not resolve."
    • addedOutput schema / properties / stats / properties / entityCount / description
      Added value: +"Total cache keys in the input."
    • addedOutput schema / properties / stats / properties / refCount / description
      Added value: +"Total `__ref` pointers encountered."
    • addedOutput schema / properties / stats / properties / unreachableCount / description
      Added value: +"Entities no root reaches."
  2. First observedv1.0.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already provide readOnlyHint, and the description repeats 'Read-only.' It adds the scope of audit findings but no additional behavioral context such as error behavior, performance implications, or what the tool does not inspect. With the safety profile already covered by annotations, 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 two short sentences totaling 19 words. It front-loads the verb, resource, and primary finding types, and 'Read-only' is a harmless, minimal redundancy with the annotation. Every word contributes to understanding what the tool does.

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

Completeness4/5

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

The tool has 4 parameters, 2 siblings, and subtle optional-parameter interactions, but the input schema is exceptionally detailed and an output schema exists, so the short description is sufficient for invocation. The main completeness gap is the lack of an explicit decision rule versus diagnose_cache_graph, preventing a 5.

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

Parameters3/5

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

Schema description coverage is 100%, with detailed parameter documentation for cache, rootIds, includeUnreachable, and includeNormalizationGaps, including defaults and effects on findings. The description itself adds no parameter-level detail beyond the cache.extract() context, so the baseline of 3 applies.

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 opens with the specific verb 'Audit' and names the exact resource: a serialized Apollo InMemoryCache from cache.extract(). It then enumerates the three distinct finding categories (dangling __refs, unreachable entities, normalization gaps), which makes the tool's scope precise and differentiates it from the write-oriented patch_cache and the broader-sounding diagnose_cache_graph.

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: use this when you have cache.extract() output and need to audit for ref/reachability/normalization issues. However, there is no explicit when-to-use versus alternatives, no exclusions, and no routing to sibling tools such as diagnose_cache_graph. The context is clear but the guidance is not explicit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nihar777/apollo-cache-copilot'

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